Mark24
管窥蠡测从思考游戏到实现2048
大家好，我是Mark24，可以叫我Mark
前言
本文比较啰嗦，更倾向于是自言自语。不过我写完回顾，这更像是这段时间，自由思考的总结 :P
不过我不是游戏领域的人，这部分都是业余摸鱼思考的记录，如果有勘误，请与我联系，非常乐意交流。
文章可能需要30分钟。
主要涉及的主题：
- 游戏之难
- 游戏基本构成
- 游戏引擎
- 游戏与交互程序
- 框架和库思考
- 语言是否是游戏的瓶颈
- 双缓冲模式
- 线程和协程的讨论
- 线程队列&中断
使用Ruby实现demo。
rb2048
项目安装: gem install rb2048
进入游戏
帮助信息： rb2048 --help
Usage: rb2048 [options]
--version verison
--size SIZE Size of board: 4-10
--level LEVEL Hard Level 2-5
开始游戏 rb2048
-- Ruby 2048 --
-------------------------------------
| 16 | 16 | 2 | 16 |
-------------------------------------
| 0 | 0 | 0 | 0 |
-------------------------------------
| 0 | 0 | 0 | 2 |
-------------------------------------
| 0 | 0 | 0 | 0 |
-------------------------------------
Score: 16 You:UP
Control: W(↑) A(←) S(↓) D(→) Q(quit) R(Restart)
升级难度 rb2048 --size=10 --level=5
-- Ruby 2048 --
-----------------------------------------------------------------------
| 8 | 16 | 0 | 0 | 0 | 0 | 0 | 2 | 0 | 0 |
-----------------------------------------------------------------------
| 0 | 16 | 0 | 16 | 0 | 8 | 0 | 0 | 0 | 0 |
-----------------------------------------------------------------------
| 0 | 0 | 0 | 2 | 0 | 0 | 0 | 0 | 16 | 8 |
-----------------------------------------------------------------------
| 0 | 16 | 0 | 8 | 0 | 0 | 0 | 0 | 0 | 2 |
-----------------------------------------------------------------------
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
-----------------------------------------------------------------------
| 0 | 8 | 8 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
-----------------------------------------------------------------------
| 8 | 0 | 0 | 0 | 0 | 4 | 0 | 0 | 0 | 0 |
-----------------------------------------------------------------------
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
-----------------------------------------------------------------------
| 0 | 0 | 0 | 4 | 0 | 0 | 0 | 0 | 0 | 0 |
-----------------------------------------------------------------------
| 0 | 4 | 0 | 0 | 4 | 8 | 0 | 0 | 0 | 16 |
-----------------------------------------------------------------------
Score: 0
Control: W(↑) A(←) S(↓) D(→) Q(quit) R(Restart)
背景
我觉得命令行的程序比较赛博朋克，一直想做个命令行的交互程序。 目前在游戏公司，虽然我不是游戏工程师，但是接触了一些游戏行业的优秀小伙伴，我也忍不住思考关于游戏的主题。
我想做的命令行交互式程序，其实和游戏的思想内核是一致的。一拍即合。
我以前做过一点点研究。记录了一些笔记。关于Ruby中如何实现交互式命令行程序。 本文也是建立在这个基础之上。
用最简单的方式实现了一个 [贪吃蛇]
rb2048心路历程
rb2048 亮点
rb2048有趣的地方在于，在设计的时候，没有简单实现了之。毕竟有太多2048了，不差这一个。
对于我不是完成一个任务。由于最近两天关注于线程的使用，于是我把线程方面的使用加入到rb2048。这算是一个实验性的例子。验证我的想法：
rb2048将:
- 用户I/O
- 游戏数据计算
- 游戏渲染
这三部分分别用单独的线程实现，用队列通信。麻雀虽小，五脏俱全。虽然粗糙，但是代表了游戏引擎典型的设计思路。 （虽然我了解的不多）
认知变化
简单说说我最近的思考吧:
1）对于计算机不同领域认识发生了变化
以前会觉得：游戏是游戏，web是web，语言是语言，元编程就是元编程……也许还有很多概念，但是渐渐现在觉得无非是一件事 —— 编程罢了。
随着看到思考的东西逐渐变多，很多计算机领域的问题，在我的角度觉得都一样。
2）第一性原理 + 交流，向内习得
这次摸着石头过河，比较新奇的体验就是，从当初一个想法到原理的讨论到最后实现。主要是思考推理，还有和优秀的同事的聊天中习得 （这里感谢 @谷神)。
- 刻意学习 VS 内在习得
现实中有很多游戏引擎。他们也许内有乾坤，不过其实是否研究他们也不重要。
我也不在乎别人的实现，或者更好地实现，是否有实现过了可以参考。其实没什么可参考的。只要我们自己想明白了，别忘了我们上面说的，他们都是一件事 —— 编程罢了。 当我们面临新问题，我们也会加强我们的 “引擎”。从思想上，他们是平等的。:P
可能与以前向外求知，现在会额外的向内思考。比较神奇的体验是，一些东西听个大概，也能盲猜个七八分。
从游戏开始聊吧
游戏之难
其实2048没啥好聊，写2048的背后是对游戏的一些思考。
其实游戏是一个比较特别的存在。他是一种比较特殊的程序，特殊在哪儿呢？
1）他是持续交互程序
不同于简单的脚本，跑完结束。或者传递一个初始参数，就像函数一样运行完结束。
他是一个持续交互的过程，随着时间累计游戏的方方面面都在变化。
2）多面平衡
不同于你写一段function就结束了。游戏要在运行的生命周期里：
- 用户交互事件
- 游戏数据计算
- 渲染视图
在至少这三个方面互相作用。
还可能有:
- 网络
- 调度
- 硬件CPU、GPU加速渲染
- AI
- 资源生成
- 数据采集
- 各种优化技术
其他周边并不展开
3）稳定的帧率
如果是60HZ的游戏，必须在 16.6ms 内完成动作进行刷新。
这也不是普通业务脚本、程序一直跑自己的线性逻辑就算了，根本不关心时间。
4）密集对象计算
简单的游戏还好，传统的模式是面向对象建模，一切看起来还算自然。
但是也出现了万人同台的游戏，这里传统的编程模式已经满足不了游戏对象的遍历了，很快会达到性能瓶颈。
这几年，出现了ECS架构（Entity-Component-System）。
小结：
其实还有各种发散。如何使用CPU、GPU加速渲染，这就不再提了。
游戏是一个非常特殊的存在，它意味着密集型计算、密集型IO混合出现的场景。我理解是比Web复杂在另一个维度上。
游戏涉及到 编程架构、网络、图形学、美术设计、资源加载…… 诸多丰富的话题。
这些就不是我这个门外汉靠管窥蠡测能够说得清的。我今天可以只谈谈我对游戏的理解和认识，以及构建2048的思考。
游戏基本构成
其实一个基本游戏可以用如下代码描述：
loop do
IOEvent
UpdateGameData
Render
end
游戏处在一个主循环中，我们依次要处理用户输入事件，根据用户输入事件进行游戏模型的变化，最后再把数据渲染在屏幕上。
这是一个单线程，主循环的例子。
现实中每个部分都可以额外变得复杂。也可以用线程单独实现。一切看需求。
游戏与交互应用程序
你会发现游戏就是交互程序。
上面的三部分，你也可以和 MVC 强行扯在一起。
- M 就是 Model 游戏数据
- V 就是 View 负责渲染视图
- C 就是 Controler 可以对应事件控制
MVC 的典型程序，除了桌面软件，Web也算是， App也算。
看似是在说游戏，实际上他们是一回事。
游戏引擎的秘密
游戏引擎其实就是框架，很佩服他们会起名字。
框架、引擎其实是一个东西，他们的特征就是一个半成品的软件。
loop do
IOEvent
UpdateGameData
Render
end
比如这个游戏循环，如果我们封装了主循环，封装了事件对象。对外暴露了一些生命周期。 这种半成品软件就是 所谓的框架，在游戏领域就是引擎。
作为下游，游戏引擎/框架的使用者来说，我们写的程序就像填空一样和主循环工作在一起。
主循环决定了什么是框架、什么是库
所以我个人觉得，决定了什么是 框架Framework 和 库Library 的本质区别是 —— 主循环。
当你的程序是一种可被调用的状态，那么基本上你的程序可以看成一个lib 当你的程序如果拥有了主循环的状态，基本宣告了不可被直接调用。那么它其实是一个 Framework了。除了各种Pattern很少见到主循环的lib 展示，不存在的原因是因为拥有主循环的程序，一般以具体的软件形态出来：
- 某种语言，比如 自带调度的 golang、自带EventLoop的JavaScript 引擎V8
- 某种框架，比如 Web框架自带监听循环
- 某种引擎，比如 游戏引擎
Framework式的程序，你的工作任务就会转向熟悉这个程序暴露的对象，期待你的程序和主循环能一起工作。
编程语言会是游戏的瓶颈么？
我们再来聊聊游戏引擎和编程语言。
Unity的背后是 C# 支撑；虚幻引擎的背后是 C++。他们采用了更底层的语言。那么问题来了，编程语言会成为制约游戏的瓶颈么？
这也是我自己思考的一个问题。
我们可能会很粗暴地觉得 动态语言普遍慢，当然是越接近底层越好。其实我更想知道，如此这样选择的标准在哪儿？
其实我们可以思考下，这个结论不难获得。
动态语言真的慢么？
其实动态语言在执行一个命令的时候，Ruby这种最后C实现；Golang最后也落在C（Golang实现自举之后，那就用汇编思考吧）。其实他们在执行一个具体操作的时候，数量级一致的。
他们其实差不多。
速度差距在哪儿呢？
1）载入环境
C、Golang这种可以打包成二进制的语言。他编译阶段会把需要执行的代码编译成二进制。
所以执行的时候载入的是所需要用到的部分功能。
Python、Ruby 这种其实 二进制是语言的解释器。运行的时候更多的时间花费在加载解释器。
不过，当你的程序复杂到涉及大量IO、基础库的时候，Golang的打包结果会趋向于接近一个解释器的大小，比如 Ruby 差不多在 30M左右。
我曾经比较过：
Golang的一个项目命令行编辑器 micro 、Ruby的一个项目命令行编辑器 diakonos
micro运行内存16M，也就是他本地大小；diakonos运行内存30M，也就是Ruby解释器差不多的大小。ruby代码会执行才加载，所以可以忽略不计。
最大的差距，在于 30-16 的载入速度差，这个量级是不同的。
2）语言构件
C语言就像是一个高级一点的汇编。C的角度一切都需要手动管理。那么其实对于底层语言，更现实一点的是会自己手动实现数据结构。
Ruby这种动态语言，内部默认会有一个数据结构。
举个例子：
比如 a = "GAME"
C语言实际上只会手动创建 “GAME” 四个字符
Python 底层可能创建一个 20字符长度的数组。存GAME。也有好处，可以不定长支持动态扩容。
在生成语言构建的时候存在速度差。 动态语言等于多创建了很多语言在内存里的解构。
3）解析时间
二进制的文件，直接载入内存执行。
动态语言有一个解析的过程。当然，也有优化空间，我们可以提前编译动态语言为虚拟机字节码。这样就获得了 对于解释器是二进制类似的东西。
4）GC时间
和C语言相比，Python、Ruby自带GC。
他们存在一个 必须 GC 暂停的那么一个问题。C语言的策略是手动回收。
双缓冲模式
我们好像列举了一大堆 动态语言的缺点似的。实际上自动管理的数据结构、自带GC、可以动态的编译执行…… 这些都是动态语言的缺点。
虽然付出了些许时间的代价。只要我们不滥用语言构件 和 特别烂的算法，真是巧妙的接近底层高效的实现。
其实我想说，动态语言至少在目标上不是特别大的瓶颈。
Java也有游戏的例子；C# 也是自带GC。GC不会是瓶颈。
语言的速度不会绝对意义上成为一个游戏组成的阻碍。
EVE 这样的大型游戏，内部使用了 巨慢的 Python 就可以说明问题。
之所以语言不一定构成拖慢游戏的原因，还有一个就是游戏和屏幕的刷新机制 —— 双缓冲模式。
其实可以理解为一个 内存空间，我们称之为 Buffer。我们有两个 Buffer，分别叫 A Buffer、B Buffer。
显示器先从A Buffer中读取数据渲染屏幕。我们程序写入B Buffer，等我们真的写完了，可慢或者快，但是无所谓，反正屏幕这时候在稳定的读取 A Buffer 内容。我们计算完毕，B Buffer中写入了我们想要的东西，这时候只要把显示器读取的指针指向B Buffer，下次屏幕就会获得我们想要的画面。这就是双缓冲模式。由于存在双缓冲解构，算快和快慢，至少不会成为画面撕裂的原因。
rb2048 使用了 Curses 库来绘制界面，而 Curses 内部使用了双缓冲模式。
线程和协程的讨论
我们自己研究了两天线程和队列。主要是Ruby的实现。
这里不教线程和协程，只记录我觉得好玩的交流结果。
Ruby线程的问题
缺点：
Ruby存在线程锁，这导致每一时刻只能运行一个线程。线程就像背后虽然有很多工人，但是只能交替的一人一锤子。
这背后的原因在于 Ruby 考虑安全更多一点 —— 线程安全。
这样的多线程无法利用CPU多核心并行的特点。希望利用多核的，可以去用 JRuby，因为Java底层没有加锁。
Ruby3中也有了无锁线程的替代品 Ractor 也可以了解下。
CRuby如果想利用多核心可以使用进程替代线程。如果设计得当，其实差不多。Ruby里面Webserver有名气的Puma采用的就是多进程实现。
优点：
加上锁最大好处是线程安全，你可以自由的编码，Ruby帮你加锁。这样多线程访问变量的时候，不会出错。
但是你退出来想，反正你自己也要加锁啊，谁加不是加。Ruby默认的线程其实书写起来非常友好。
进程、线程、协程 傻傻分不清楚
我觉得再这样介绍这三个概念，这文章太冗长了。
直接说结论吧，直观上，这三者存在量级差，不仅体现在空间资源，时间资源都差不多。
进程 » 线程 » 协程
比如一台机器4G内存：
可能只能实际生成几百个进程就不太行了。 同样，可以生成几千个线程，就动不了了。 协程可以生成几十万个。
他们大概就是这个差距(有更好数据支持的，请联系我)。
他们切换上下文的时间也遵循这个比较关系。
所以我们一般的策略，尽量多用协程&线程，少用进程。
如果任务独立运行还好，就怕彼此还要通信，出现互相等待的局面。
线程具有CPU亲和性（一般语言来讲）。
比如 Golang的 M:N 模型，主张 先生成 M 个线程，M 是机器CPU核心数，然后再在M个线程之间调度实际产生的N个任务。
比如 Nginx 的配置也主张 配置线程核心数和CPU核心数一致。
什么时候用线程、什么时候用协程？
线程、协程产生的原因是什么？
其实还是为了调度。
线程是细分进程下共享内存的场景；协程是为了细化调度。
因为进程、线程本质上是操作系统在调度。操作系统并不清楚什么时候应该调度。只能采用各种优先计算法、平均算法。再怎么算，也是盲人摸象罢了。
协程给了程序员一个口子，你可以用 协程在 涉及阻塞部分进行让出控制权。
简而言之，经验之谈：
涉及到 计算密集型 请用线程。
如果涉及到IO阻塞密集，请用协程。
我们的目的不是为了用而用，而是使用调度，提高我们代码执行的效率，减少等待。
硬件中断
如果说其实没有 if-else\switch\while，计算机器其实只有 goto。
如果你看过汇编，大概理解我是什么意思。
同样，计算机里进程、线程、协程背后调度的秘密，都来自于 CPU的硬件中断功能。
只不过是上下文快速切换，切换上下文多和少罢了。
2048 的实现
其实2048的关键就是相邻元素合并，实现这么一个算法，反复执行到无元素可以继续合并。再把这个应用到 x\y 方向所有行列就好了。
具体线程
目前实现成通过队列来实现通信：
IO线程，用户产生一个输入，进入事件队列。 游戏读取事件队列，开始计算游戏数据，把结果塞入渲染队列。 渲染线程，读取渲染队列数据进行渲染。
后续讨论
我和同事交流了一下，就2048而言其实可以很多方式做：
1) 如果是队列依赖式
我们等于做出一个pipline的方式了
2) 我们也可以解开队列阻塞
真正的自由渲染。虽然2048看不出效果
队列追赶问题
用户不断地敲击，产生时间，如果队列里一致产生数据，那不是渲染永远追不上？
多线程队列需要思考 生产者、消费者模型，需要设计匹配的方式。
解决方法
1）控制生产频率，生产和消耗相抵消
事件采样、渲染 可以保持一个频率
2）不控制生产，但是跳过生产
事件采样，可以携带时间戳。
如果渲染的时候，每次时间超时，跳过关键帧。
当然这些都是很细化的问题了。
总结
我倾向于研究一个东西，思考他的全部，寻找最佳的路径。 这些都是摸鱼结果，简单分享下。更深的感受还需要实践和交流。
后续
上文提到游戏里面最新流行 ECS 架构。ECS 抛弃了面向对象的思想，把同类数据摆放在一起，亲和CPU运行机制，方便大规模属性遍历。
ECS 应该如何用Ruby实现呢？