今天，是我在广州阿里中心办公的最后一天。虽然 Last day 设定在了 5 月 20 日，但后面全部是假期，应该不会再回来这里。这些年的年假我都没有用过，总是到年底自动作废，今年算是休全（一小半）了。回顾我的职业生涯，2001 年之前在北京经历了创业，而后又短暂的工作了数月。之后便在网易工作了十年，直到 2011 年离开。2011 年底，我们创办了简悦，原本以为会把这家公司一直开下去，但在各种机缘下，于 2017 年底被阿里巴巴收购。之后，我便退出公司的管理，专心开发游戏引擎。每段经历，印证着不同的心境。幸运的是，每次开始和结束，都是我的自主选择。感谢那些容忍着我的任性的伙伴，而我执着于自己想法的同时，也回报了周遭的人。毕业的开始缘于大学时代交的诸多热爱游戏的朋友，年轻气盛的孩子们梦想做出自己的游戏。当我觉得自己能力还不足时，不愿意只是为了工资而把精力消耗在不太喜欢的事情上，所以我选择离开，独自提高自己。进入网易，因为我从大学期间就在开发的风魂引擎。阴差阳错，我又挽救了一个失败的游戏项目（大话西游），然后一干十年。而离开，是为了重新开始。当我发现我无法在网易做出更多想做的东西时，能自己去主导做事，是莫大的诱惑。创办简悦轻松自然，虽说是创业，但几乎没有感觉到压力。这应该是整个团队经历过成功带来的自信吧。虽然前两年并不成功，接连两个项目都做失败了，但又奇迹般搭上了手机游戏的快车活了过 ...继续阅读 (70)

最近和公司一个开发团队探讨了一下他们正在开发的游戏中遇到的性能问题，看看应该如何优化。这个游戏的战斗场景想模仿亿万僵尸(They are billions）的场景。在亿万僵尸中，场景中描绘了上万的僵尸潮，但我们这个游戏，超过 500 个僵尸就遇到了性能问题。固然，手机的硬件性能比不上 PC ，但 500 这个数量级还是略低于预期。对于游戏中大量类似的动画物体，肯定有方法可以优化。我们来看看渲染这些动画可行的优化方向：常见的方式是把僵尸先预渲染成图片，而动画自然就是多个图片帧。对于亿万僵尸这个游戏来说，它本身就是基于 2D 渲染引擎的，这么做无可厚非。如果引擎本身基于 3d 渲染管线，也可以以预渲染图片的方式去渲染它们，但图片是否比基于三角形的模型渲染有更好的性能，这个需要根据具体场景去分析。当我们在运行时，将模型的三维顶点信息传递给 GPU ，让 GPU 做光栅化，通常可以获得两个方面的好处：一，最终渲染出来的像素有更准确的光照信息，它是根据该像素在场景中的空间状态计算出来。而预渲染图片上的像素则是根据预渲染时的固定空间状态计算，所以不准确。二，可以省掉顶点着色器的计算过程，对像素着色过程也简化为一个简单的复制（而不必计算光照）。但是，渲染图片也未必一定有绝对的性能优势。这是因为，预渲染图片本质上是将渲染过程预处理，烘焙到贴图上。约等于用空间换时间的优化。图片本身相比顶点数据会消耗 ...继续阅读 (72)

早上上班的路上，在必经的一条马路，看到一个蓝衣人趴在路中间隔离带的水泥桩上。车流比较大，一晃就开过去了。我问坐在副驾驶的老婆：刚才那个人好奇怪啊。她说是啊，那个人怎么了？我说，昨天你没看到吗？他保持那个姿势已经一整天了，感觉连手指头都没动过。说到这里，我赶紧把车靠边停下来打了 110 ，附近的派出所联系了我，说马上派人过去看看。我的心情久久不能平静。走在路上，我喜欢观察四周的细节，其实昨天就感觉不对了。路上没有血迹，我以为他/她（看不到脸）是在翻越隔离带时身体不舒服想休息一下。但一个人保持那种姿势几分钟而不动肯定不正常。如果昨天这个时候就报警或许更好呢？如果下一次看到这样的情况，我想我会停车下来拍一拍，说不定就能救人一命了。后面的路上，老婆和我讨论了死亡。她说她很怕死，不愿意去想。她父亲是做警察的，曾经还做过侦察兵上过越南战场。小时候就见过父亲一身是伤回家，据说是骑车追罪犯摔了一跤。她当时非常害怕。我说，人终有一死，现在不愿意想，总有一天也会想的。我有一个理念：年轻的时候，人人都怕死，这可能是刻在基因里的。我们都回避不了这种恐惧。但说不定人老了就不会那么怕了，在死前的十年，每个人都会慎重的思考死亡，想的多了，或许就释然了。就好像我们小时候去想长大后的人生，结果想法一天天都在变化，等真的长大了，发现想法完全变了。死亡可能也是一样，想着想着到那一天，你就和死亡和解了。我上上一辈的亲人最 ...继续阅读 (66)

最近一段时间都在公司内寻找项目可以合作推进Ant Engine的使用。我觉得自研引擎的一个重要优势在于我们可以针对具体游戏更好的做性能优化。在目标设备硬件性能允许的范畴内，把画面质量和交互体验做到更好。而同样的优化手段，在通用商业引擎上面做会困难的多，甚至无法顺利完成。我们用 Ant Engine 制作的第一款游戏Red Frontier在一年前是性能完全不达标的。它在 iPhone 8 上甚至都达不到 30fps ，无法流畅游戏。很多性能问题是已知问题，比如我们用 Lua 搭建了整个引擎，一开始只考虑了引擎结构和正确性，把性能搁置在一边待后面再处理。优化方案是一开始就想好的：借助 lua ecs 框架，把数据结构放在 C 内存中，必要时可以绕过 Lua 代码，直接用 C 代码控制核心数据。我们花了大约 3 个多月的时间将核心渲染系统用 C 重写后，就把性能提高了 1 个数量级以上。这个过程可以说是一直掌握在手中，按计划推进。但即使可以让游戏运行在 60fps 下，优化的目标也远远没有达到。这是因为对于手机设备来说，用户更容易产生电量焦虑。在固定座位上插着电玩主机或 PC 游戏，玩家不会去想游戏机耗了多少电；即使把 switch 外带玩游戏，也可以一直玩到没电；但用手机不光是用来玩游戏的，如果消耗电量太快，玩家会担心手机等一下会不会无法支付交通费用，不能扫码吃饭……我甚至一度怀疑 ...继续阅读 (71)

ltask 是 Ant engine 的基础设施之一，在对 Ant engine profile 的过程中，我们发现了 ltask 的一些值得提升的地方。我们希望尽可能的提升游戏帧率，缩短渲染每一帧的的时间。因为 Ant engine 是由很多并行任务构成的，任务调度器的策略会直接影响单帧需要的时间。ltask 虽然和 skynet 想解决的问题是一样的：管理 m 个线程（任务/服务），让它们运行在 n 个 cpu 核心上。而它们的应用场景不同，ltask 目前用在游戏客户端，它由一两个重负荷任务和若干低负荷任务构成，优化目标是低延迟；而 skynet 主要用在服务器上，由数以千计的类似负荷的任务构成，优化目标是高负载。低延迟和高负载在某些方面是对立的。对于服务器，为了提高负载能力，应该最简化调度器，最好感觉不到调度本身，并充分利用所有的 CPU 核心。最简单的办法是，为每个 CPU 核心准备一个任务队列，把任务公平的分摊给它们。在任何一个核心快要闲置的时候，就从起他核心的任务队列上匀过一些任务，让它们都不要闲置。也可以用一个大的任务队列，让每个核心都从这里取任务，同时设计一个好的算法减少多个核心取任务时对这个大任务队列的竞争。对于客户端，如果想降低绝对帧时间，需要做的是让主线任务有最低的延迟：每个步骤在它所依赖的任务准备好后，可以最快时间开始运行。尽量不要耽误主线任务的运作，因为 ...继续阅读 (71)

在 skynet 中，服务之间并行运行，而每个服务自身的业务都是串行的。一个服务由开发者自行切分成多个时间片，每个时间片串行运行在不同的工作线程上。最常见的做法是在每个服务中运行一个 Lua 虚拟机，用 coroutine 切分时间片，这样从编写代码的角度看，任务是连续的。这个设计的目的是，让开发者轻松享受到多核带来的并发性能优势，同时减轻编写多线程程序带来的心智负担。用过 skynet 的应该都碰到过：当我们在服务中不小心调用了一个长时间运行而不返回的 C 函数，会独占一个工作线程。同时，这个被阻塞的服务也无法处理新的消息。一旦这种情况发生，看似是无解的。我们通常认为，是设计问题导致了这种情况发生。skynet 的框架在监测到这种情况发生时，会输出maybe in an endless loop。如果是 Lua 函数产生的死循环，可以通过发送 signal 打断正在运行运行的 Lua 虚拟机，但如果是陷入 C 函数中，只能事后追查 bug 了。那么，如果我原本就预期一段 C 代码会运行很长时间，有没有可能从底层支持以非阻塞方式运行这段代码呢？即，在这段代码运行期间，该服务还可以接收并处理新的消息？在很长时间里，我认为在保证前面说的严格约束条件下，无法实现这个特性。这个约束就是，skynet 的服务必须以串行方式运行。但最近，我发现其实用一点巧妙的方式，还是有可能做到的。但我们需要 ...继续阅读 (79)

虚拟文件系统 (vfs) 是 Ant 引擎的核心模块。在 wiki 上有介绍，blog 上也有总结。最近在按前段时间拟定的思路重构编辑器。在这个过程中对 vfs 有了一些新想法。短期内不打算把工作重心放到重构 vfs 上面，先记录一下。最早设计 vfs 的时候，是从网络文件系统的角度看待它的。我把它设想为一个类似 git 的组织方式，带版本控制的网络文件系统。所以，很多设计思路都是延续这个而来。但是，经过了这些年的数次重构，我对最初的思路产生了一些怀疑。其中，最重要的一条：在游戏运行时，游戏程序看到的 vfs 是一个树结构的不变快照。这样，它像 git 一样，就可以用一个 Merkle tree 的 hash 值就可以代表这个快照，也可以方便的通过网络同步它。为了实现编辑器，我们在这个设计上打了一些补丁，让编辑器可以在运行时动态的修改它。而我今天反思，“不变快照” 这一点是否是多余的？或者并不需要这个约束，也可以用简单的方案实现现在所有的功能。经过一些思考后，我认为可以用这样一个新方案：vfs 是一个在运行时可以动态增删的树结构，而这个树结构只存在于内存中，不需要持久化。一开始，vfs 只有一个空的根目录。在运行时，需要不断的对 vfs 进行增改。把空的根目录扩展出更多的文件。我们可以设置一个路径 path 为一个特定的 hash 值。如果这个 path 中的任意一个子目录不存在， ...继续阅读 (72)

这两天在改 log 模块。我们需要一个并发写 log 的模块，它有多个 log 生产者一个消费者，这个唯一的消费者在 log 线程中把 log 数据持久化。大多数 log 生产者是在第三方库的 callback 函数中调用的，比如 bgfx ，如果写 log 不够快的话，就会阻塞渲染。这个 callback 需要自己保证线程安全。因为 bgfx 支持多线程渲染，所以写 log 的 callback 可能在不同的线程触发。过去在实现bgfx 的 luabinding时，我实现了一个简单的 mpsc 队列，get_log这个函数就是那个单一消费者，它取出队列中所有的 log 信息，返回到 lua 虚拟机中。它是用spin_lock实现的。这两天，我想应该可以实现一个更通用的无锁版本。在我的需求中，log 信息是允许丢掉的。所以我开了一个固定大小的 ringbuffer 收集各个不同线程生产出来的 log ，然后在一个单一线程定期（通常是一个渲染帧一次）取出它们。只要取的频率够高，而生产的 log 数量不那么快的话，一个合适大小的 ringbuffer 就能以最简单的数据结构解决问题。我觉得一个无锁结构的 log 系统需要两个 ringbuffer 。我们缓存的 log 条目数目上限估计不用太大，4096 或许是个合适的数字：即，每帧不会产生超过 4000 条 log 。那么就用一个 4 ...继续阅读 (87)

bgfx 提供了一组调试文本输出的 api ，可以把一些文本信息显示在屏幕上。这些 API 非常简陋，只是提供了一个文本模式缓冲区。离控制台还很远。具体见文档中的 dbgText* 系列函数。随着我们的游戏引擎中越来越多的信息需要展示，直接使用这些 api 就越发简陋了。最近萌发的想法是干脆使用 imgui 来绘制调试信息界面。但我又觉得保留 bgfx 自带的这个文本模式也有一些好处。这个周末，孩子被爷爷奶奶带回老家去了。难得有不需要陪娃的一天。我周六一大早起来就在想写点什么。最开始的想法是，使用基于 ncursors 的 UI 库。翻了一下没看见什么特别喜欢的。而且 bgfx 的文本模式并不是一个终端，可能还需要先把它改造成一个 VT100 终端先。在 github 上搜索了一番，我用 VT100 Emulator 找到一些简单的库，没见到开箱即用的。感觉自己实现一个 VT100 终端也不算太复杂。大约 400 行代码就够了。主要是实现 ansi escape code ，有了这个，就能对接 ncursors 或 pdcursors 之类的库，然后文本界面 TUI 的选择也有很多。然后，我发现了imtui这样一个有趣的玩具。它给 imgui 加了一个文本模式的 backend 。看起来还是挺炫酷的。但仔细一看，项目不太活跃很久没更新了。翻了下实现，也就几百行代码，花了半个小时就懂 ...继续阅读 (78)

我在自己研发的游戏引擎上已经工作了 6 年了。在 2017 年底，我写下了对这个新引擎最初的构想。现在回头来看，当初的想法居然都落实了，只有一点例外：我们中途把编辑器从 IUP 转移到了 ImGUI 上。2022 年，我们启动了第一个用这个引擎开发的游戏项目，它是一个和日本公司合作的动作游戏。后来，这个项目没有走下去就取消了。之后，因为我们的引擎开发组喜欢 Factorio ，便想用自己的引擎在手机上重现一个 Factorio Like 的游戏，这一干就是一年多。现在，游戏的技术部分基本完成，可以验证引擎的可用性（功能完整、性能达标），只是游戏性方面还有不少路要走。简单说就是还不太好玩。从一开始，我就希望以开源模式经营这个游戏引擎，但同时又觉得没有得到验证的东西不适合拿出来。既然引擎已经初步可用，现在就应该迈开这一步了。毕竟引擎是公司的资产，原来我是自己创业公司的老板，但现在公司已经被阿里收购。开源并不是我一个人可以做的决定。最近一段时间，我争取到了公司的支持。甚至，公司不仅同意我将整个引擎项目开源，还愿意把我们正在制作的游戏的代码及其美术资产也捐赠给这个开源项目。这可以方便引擎开源后潜在的用户去理解引擎。关于这个开源引擎，有太多的东西可以写，我这里先摘录一些我在向公司申请开源时的报告中的一些内容。文字上有一些吹嘘之词，也有一些未经核实的臆断，但总体上可以反应我的看法，一家之言，姑 ...继续阅读 (89)

我们游戏 UI 基于 RmlUI 的 fork，做了大量的改造。它实际上类似目前的 web 前端技术，使用 CSS 来表示 UI 的布局。所以，我们做的底层工作也都是围绕如何高效实现一套基于 CSS 的 UI 引擎来做的。一年多前，我写过一篇 blog 介绍了一些优化的工作。最近，在游戏开发的使用中，我们又发现了一些性能热点，最近在着手优化。这一篇 blog 记录一下其中的一个优化点。按目前引擎的抽象，每个 style 其实是一组 attrib 的列表。而单个 attrib 则是一个 k/v 对。k 虽然使用上是一个字符串，但实际上会被转换为 [0,127] 的数字 id 。也就是说，引擎只支持一百来个不同的 key 。就目前 RmlUI 定义的 css 规范来说，够用了。而 value ，也是一个字符串。但对于不同的 key 有不同的结构。对 stylecache 模块来说，它并不关心其结构，全部视为字符串。这个字符串根据不同的 key ，可能是布尔量、数字、字符串、也可以是一组数字、甚至是一个字典这类复杂结构。RmlUI 是用 C++ 编写的，我们把 style 从字符串取出时，转换为一个 C++ 可以方便访问的类。过去，这是通过序列化和反序列化进行的。即，当我们把 attrib 从 style 中取出时，将 attrib 通过反序列化变成一个 C++ 对象。这个对象可以方便的 ...继续阅读 (92)

上周五在公司内做了一个技术分享，介绍我们最近五年来自研的游戏引擎，以及最近一年用这个引擎开发的游戏。大约有一百多个同学参加了这次分享会，反响挺不错。因为这些年做的东西挺多，想分享的东西太多，很多细节都只是简单一提，没时间展开。我谈到，我们的引擎主要专注于给移动设备使用，那么优化的重点并不在于提高单帧渲染的速度，而在于在固定帧率下，一个比较长的时间段内，怎样减少计算的总量，从而降低设备的能耗。当时我举了几个例子，其中有我们已经做了的工作，也有一些还没做但在计划中的工作。我提了一个问题：如果上一帧某个像素被渲染过，而若有办法知道当前帧不需要重复渲染这个像素，那么减少重复渲染就能减少总的能耗。这个方法要成立，必须让检查某个像素是否需要重复渲染的成本比直接渲染它要低一个数量级。之所以现存的商业引擎都不在这个问题上发力，主要是因为它们并没有优先考虑怎么给移动设备省电，而要做到这样的先决条件（可以廉价的找到不需要重新渲染的像素），需要引擎本身的结构去配合。我没有在分享会上谈细节，是因为我不大想谈还没有做出来而只是在构想中的东西。但我同时承诺会写一篇 blog 展开说一下，便有了现在这篇。我们尚未去实现这个想法是因为目前引擎的性能已经被优化到比较满意的程度，而完善游戏本身要重要得多。对于只有 3,4 个人的小团队来说，必须推迟一些不重要的工作。我们的引擎虽然是用 Lua 编写的，但性能瓶颈目前在 ...继续阅读 (88)

提起游戏引擎，特别是商业通用游戏引擎，比如 Unreal 或是 Unity ，给人的第一印象会是它们的可视化编辑器。而在实际开发中，在不同引擎下做游戏开发，影响最大的是引擎层的 API 以及这些 API 带来的模式。而对于使用自家专有引擎开发出来的游戏，却少见有特别的编辑器。比如以 Mod 丰富见长的 P 社游戏，新系列都使用一个名叫 Clausewitz 的引擎，玩家们在之上创造了大量的 Mod ，却不见有特别的编辑器。Mod 作者多在文本上工作，在游戏本身中调试。游戏程序本身就充当了编辑器：或许只比游戏功能多一个控制台而已。在这类引擎上开发，工作模式还是基于命令行。游戏引擎中的那个编辑器无疑是引擎开发中耗工时最多的部分。我们自己研发游戏游戏已有 5 年，其中编辑器完全重做了两次，目前第二个人维护着第三版。在这几年里，我一直在思考：游戏引擎到底需要一个怎样的编辑器、它应该用来解决怎样的问题。在 20 多年前，我写风魂的时候，它受 Allegro 的影响最多。当时，只要封装出 API ，解决图形、声音、键盘、鼠标、系统窗口等的底层调用就解决了游戏开发中最难的部分。后来，到 2001 年开发大话西游，我根据游戏的需求为引擎写了几个小工具，用来编辑场景、2D 动画等等，支撑了游戏开发。那些工具是为游戏定制的，同样定制的还有一些对应的程序模块。我认为不属于引擎的范畴。后来，各大游戏公司纷 ...继续阅读 (88)

我们的游戏引擎是基于虚拟文件系统，可以通过网络把开发机上的目录映射到手机上。这对开发非常方便，开发者只需要在自己的开发机上修改资源，立刻就能反应到手机上。但当游戏发行（也就是我们正在准备的工作），我们还是需要把所有资源打包，并当版本更新时，一次性的下载更新补丁更好。之前一直没时间做这方面的工作，直到最近才考虑这个问题。我们到底应该设计一个怎样的补丁更新系统。我不是第一次设计这玩意，早在 20 多年前我就为大话西游设计过一个。但我这次想重新思考这个问题，用一些更标准的技术来做，比如，使用标准的 zip 包格式，而不是自己重新设计。当然，怎么把文件打包是次要问题，主要问题是怎么解决版本间的差异更新。用户可能停留在不同的版本上，都应该可以正确更新到最新的版本。如有可能，还应该支持版本回滚。传统的方法是用一个递增的版本号，打包时，仅打包版本间的差异。用户要更新版本时，下载从本地版本到最新版本间的所有 patch 文件，按严格的次序依次打包。我觉得这个方法固然没什么大问题，但不是特别好。因为它不够健壮，缺失一个 patch 就会让升级无法完成。而频繁的版本更迭会导致太多的 patch 。虽然可以定期打包一个全量的包来阻止太多的 patch 文件，但也只是个不太干净的补救手段。版本回滚和分支版本发布都会比较麻烦。我们的 vfs 系统其实是一棵 Merkle tree 。每个文件的文件名就是它内 ...继续阅读 (112)

Lua 的数据类型非常有限，用 C 编写的 Lua 模块也没有统一的生态。在不同模块间传递内存块就是件很头疼的事情。简单通用的方法就是用 Lua 内建的 string 类型表示内存块。比如 Lua 原生的 IO 库就是这么干的。读取文件接口返回的就是字符串。但这样做有额外的内存复制开销。如果你用 Lua 编写一个处理文件的程序，即使你的处理函数也是 C 编写的模块，也会复制大量的临时字符串。我们的游戏引擎是基于 Lua 开发的，在文件 IO 上就封装了自己的库，就是为了减少这个不必要的字符串复制开销。比如读一个贴图、模型、材质等文件，最后把它们生成成渲染层用的 handle ，数据并不需要停留在 Lua 虚拟机里。但是，文件 IO 和资源组装（比如贴图构造）的部分是两个不同的 C 模块，这就需要有效的内存交换协议。我们又不想让所有的 C 模块统一依赖同一个自定义的 userdata 类型。例如bgfx 的 Lua binding就是一个通用模块，不一定只在我们这个游戏引擎中使用。引入一个特定的 userdata 感觉不太好。所以，我倾向于协定一个数据交互的协议，而不是共同依赖同一个库实现的特定用户类型。首先，用 string 交换内存块肯定是最通用的协议，它的问题是低效，有无谓的内存拷贝，多余的对象需要通过 gc 清理。我们很早就给几乎所有的 C 库增加了 raw userdata ...继续阅读 (116)

我们游戏引擎的 UI 使用的是类似网页的技术，是将 RmlUI fork 出来的自行维护的版本。目前游戏中大量遇到的一个需求是：把 3d 模型作为 UI 组件使用。这个需求在我经历过的历史项目中都曾遇到过，在不同的游戏引擎中我见过各种解决方案。最典型的是 RPG 类游戏的人物属性面板。通常需要在面板上显示 3D 人物模型。通常还可以旋转这些模型，让玩家 360 度观看。我们目前的游戏类似 Factorio ，没有 Avatar ，但点开建筑的信息面板时，也需要把建筑的 3D 模型动态展现出来。最初，我们没去细想 3D 渲染怎么和已有的 RmlUI 结合在一起，直接把模型渲染在 UI 层之上。相当于在 UI 模块外开了个后门。UI 上只需要把位置空出来，等 UI 渲染完后，再叠加 3D 模型上去。但这样做的坏处是很明显的：3D 模型无法和 UI 窗口有一致的层次结构。后来，我们额外构造了一个 render target ，改造了一点 RmlUI ，让它可以支持一个矩形区容纳这个 rendertarget 的画布 。这样，3D 模型渲染就比较好的和 UI 模块融合在一起。但是需要单独编写 UI 上 3d 元素的相关代码，尤其是管理它 ( rendertarget ）的生命期。最近，我希望在 UI 上增加更多 3d 模型。它们仅仅是用来取代原来的 2D 图片。从 UI 角度看，这些就应该 ...继续阅读 (103)

上篇谈了一下我们游戏引擎的虚拟文件系统（vfs）。我觉得这个系统中，游戏资产的管理部分还是个满有意思的设计，值得写一下。VFS 的设计动机是方便把开发机磁盘上的数据同步到运行设备（通常是手机）中。传统游戏引擎的做法通常是建一个叫做资产仓库的东西，在开发期间不断添加维护这个仓库。需要把游戏部署在运行设备时，再打包上传过去。因为传统游戏引擎在开发期间一般直接在开发机上运行，所以打包上传（从开发机转移游戏资产）并不频繁。而我们的游戏引擎特别为手机游戏开发而设计，我们不可能直接在手机设备上开发，所以开发机一是和运行机分离的。为了提高开发效率，所以我们设计了 VFS 系统。可以通过网络同步资源仓库。为了方便持续开发，vfs 被设计成带版本管理的。这里，我们借鉴了 git 的做法：所有仓库中的文件都以其内容的 hash 值为索引。当文件发生改变时，就产生了一个新索引项。而内容相同的文件，无论它的文件名是什么，放在什么目录下，在仓库中都只有唯一一份。vfs 可以把本地文件系统的任意目录嫁接在一个虚拟目录树中。这里采用了 mod 机制，可以把两个目录按优先级合并从 vfs 上的同一个虚拟目录。vfs 的目录结构是一颗 Merkle tree 。仓库中的每个目录是一个文本，内容是它所包含的所有文件的真实文件名以及文件 hash 值的列表。因为 vfs 仓库在游戏运行期间是不变的。整个 vfs 仓库根 ...继续阅读 (103)

目前我们游戏用的引擎早在 2018 年就开始了。因为一开始，它就定位为一个主要用于手机平台的游戏引擎，要方便手机开发。因为我们不太可能直接在手机设备上编写代码、制作资源，所以开发机一定是和游戏运行环境分离的。从一开始，我们就设计了一个虚拟文件系统，它可以通过网络，把开发机上的文件系统映射到手机设备上，同时兼有版本管理的功能。这样，才可以做到在开发期间，开发机上所做的大多数修改，都能立刻反映到手机上。我们的游戏引擎的大部分是用 Lua 开发的，这也意味着文件系统中不光有游戏用的资源素材，还包括了代码本身。甚至包括了虚拟文件系统自身的实现。这个东西比一开始想的要麻烦，我们这几年不断地修改它，直到最近。比如一开始认为最麻烦的自举部分，在去年就去掉了，为的就是减少系统的复杂度。简单说两句自举的问题：常规的考虑是有一个自更新的机制，在发现需要增加需求或修补已有的 bug 时，可以不经过 app 重新打包的流程将新版本更新并持久化在外存中，并可以在自举过程中完成更新顺利初始化新版本的系统并无缝启动引擎（文件系统一定要先于整个引擎完成初始化）。但由于 iphone 手机这样的特殊环境，我们很难启用多个进程完成这个这个工作，甚至难以重启自身进程，所以做起来非常麻烦。另外，一旦更新失败，还需要一定的自恢复机制，保证在不重新安装 app 的前提下，回滚到上一个版本。我们最初的实现虽然基本完成了任务，但 ...继续阅读 (104)

最近在手机上玩我们正在开发的游戏时间比较多（之前主要运行的是 Windows 版），发现有许多操作值得改进。这里列举两个值得一提的交互优化。第一，触摸屏上点击特别小的物件时很难精确。去年我提过一个解决方案，我们的游戏一直是这样处理的：连续 tap 屏幕同一个位置，会轮询这个位置附近的物件。这样，一次点不准的话，可以多点几次选到想要的焦点。这不仅可以解决小物件密集的时候，tap 不好区分的问题，还可以选到重叠的物件。这个方法其实在鼠标游戏中已有这么使用的了，比如 rimworld 就是用类似方法处理同一个格子上有多个可选物件的。但实际用下来，玩家在处理小物件选取时，被培养的最好的操作习惯还是先用双指放大，推进镜头，让小物件在屏幕空间变得很大，然后才去选取。这不仅仅是因为触摸屏不够精确，还因为手指会挡住视线，如果物件过小，很难确定是否选中。对于手指挡住视线的问题，我用额外的一个提示窗口显示在旁边来解决。选取这件事，我想应该照顾用户的操作直觉，并提供遍历。所以我最近换了一种交互方法：当用户长按屏幕，摄像机转到顶视角，并推进。作为一个 3d 游戏，处于视觉美观的原因，我们平常游戏时，摄像机不不是垂直向下的。而近距离选择物件，则用顶视角更好。这样，高大的建筑才不会挡住背后的东西。如果手指不离开屏幕的话，移动手指不再移动摄像机（即不再移动画布），而改为移动选取焦点。操作者可以通过移动手指选取刚 ...继续阅读 (93)

这两天遇到一个任务调度算法引起的性能问题，花了颇多精力排查和解决。问题出在我写的ltask这个 lua 多任务库上。ltask 最初是对 skynet 的一些反思中开始的，最初只是想换一种思路实现 skynet ：做一个库而不是框架、更少的锁竞争、避免服务因为消息队列堆积而过载……后来、我们游戏引擎开始尝试基于 ltask 利用手机设备上的多核，渐渐的便完善起来，也发展出和 skynet 不同的部分。它最近两年一直是围绕移动设备客户端程序优化，所以网络部分并非重点，也就不需要像 skynet 那样把网络模块做在框架底层，而是以一个独立服务存在。而网络 IO 、文件 IO 、客户端窗口这些部分又不适合于其它渲染相关的服务混在一起，因为它们需要和操作系统直接打交道，所以我在 ltask 中又分出了独占线程和共享工作线程两种不同的线程，可以把不同的服务绑在不同的线程上。甚至对于 iOS ，还必须让窗口线程运行在主线程上，而不得不在 ltask 里做特殊的支持。最近发现的这个问题也是游戏客户端特有的，它很能说明用于游戏服务器的 skynet 和用于客户端的 ltask 在实现侧重点上的不同。问题是这样的：我们发现在游戏主逻辑循环中，有一个系统特别简单，但每帧消耗的时间长期统计下来居然达到了 4ms 之多。而我们游戏在此设备上大约每帧 10ms ，也就是占据了 40% 的时长。经过排查后，我 ...继续阅读 (106)

所有在桌面玩的游戏都算作桌面游戏。几乎所有的人都玩过，比如象棋、围棋、扑克。如果不计这些传统的抽象游戏，我玩现代桌面游戏已经有十多年了。过去，是和朋友一起玩，而最近几年，更多的是和家人（小孩）一起玩。和许多不玩现代桌游的人想象的不一样，虽然电子游戏脱胎于桌面游戏，但桌面游戏却并没有被淘汰，反而一直在推陈出新，每年都有许多新的佳作面世。玩桌游这么些年，我发现桌游其实可以分出几个子类。像我这些各种桌游都玩的玩家很多，但有相当一部分人专注于特别一个子类，对其它类的桌游兴趣不大。有时，隐隐觉得不同子类之间还有一些鄙视链存在。我们很多时候提到桌游，并不指大多数人都会玩的棋牌（象棋、扑克、麻将等）。其实，这些的确和在桌游店里玩到的桌游有很大的不同，它们历史悠久，早已没有知识版权的保护。这类棋牌游戏可算作桌面游戏的一个大的子类，即抽象类桌游。可以说，人人都是桌游玩家，想在身边找出一个从没玩过棋牌的人恐怕很难。但也不是所有抽象类游戏都是古老的棋牌，也有很多近年类的新作相当有趣。比如我很喜欢的 Azul （花砖物语）就在家经常开。我们还可以把专门为 6 岁以下儿童玩的桌游归为另一个子类，儿童类桌游。如果成人玩这些游戏的话，恐怕会因为缺乏挑战而索然无味。我家娃还小的时候，我有几年特别关注这类游戏，想带着娃玩。如果娃太小的话，多半只能玩玩物理类的游戏、敲砖块、搭积木之类。现在娃大了，这些游戏早就束之高阁 ...继续阅读 (107)

上次提到，经过数据分析发现，我们引擎（游戏）目前特效系统占了很大的 CPU 比例。虽然特效的计算已经放在独立线程，不影响帧率，但 CPU 的开销会导致电池消耗，最终会引起手机热量上升，最终让手机降频。所以，当时想了一些牺牲准确性的方案来做优化：即，不在镜头内的特效不运算。让视觉裁剪同时也裁剪掉特效粒子片的计算。最近做了这方面的重构工作。其中的难点在于：特效模块是第三方的，并不完全贴合我们的引擎设计，而短期内又没有重新实现或改造的计划。其中最麻烦的一点是，我们引擎有一个挂钩 (hitch) 的特性。场景中可以有很多挂钩挂接的是同一个子树。这样，相同的对象就会被渲染多次，状态完全相同，只是位置因挂钩的不同而不同。我们引擎也针对它做了一些优化，比如可以把多个部件用 instance 绘制优化。对于引擎内部支持的模型，可以很方便的基于 Hitch 做批量提交。内部数据结构只有一份，但可以在每帧绘制多次。但是，当 Hitch 挂接的的部件中有特效时，特效模块并不支持复制多份多次提交绘制。我们只能在特效模块内创建多个相同的对象，且这些对象的内部状态是独立的，而我们又需要让它们永远保持状态一致，这会导致实现上的一些麻烦。好在当我们场景上需要有多个相同的物件，都带着相同的特效时，按引擎的定义它们是完全一致的。虽然我们创建了多个特效对象，但并不需要严格的和屏幕对象持久对应。比如，这一帧屏幕上有四个状 ...继续阅读 (116)

第一次感染 covid-19是在去年底，距今已有 8 个月了。最近似乎又中招过一次，特此记录一下。上周四（ 8 月 10 日）午饭过后，感觉有点困，就靠在办公椅上打了个盹。我平常没有固定午休的习惯，觉得自己是头天没睡好的缘故。14 点多醒了，感觉依旧精神不好。起身去上厕所时发现有些头晕，不过没太在意。18 点下班时，感觉头晕没有缓和，似乎更严重了。去食堂的路上走路有点飘。没什么胃口，快速吃完，觉得自己的体力不足以步行回家，就搭了个同事的顺风车赶紧回家睡觉。这时有点怀疑自己二阳了。但检测体温 36.3 ，没有发烧的症状，也没有类似感冒的其它症状，就只有头晕。之前一周，坐我对面的同事说他确定二次感染了 covid-19 （自测抗原）。发烧了一晚，恰逢周末（8 月 5/6 日），休息了两天后恢复。而我没有发烧症状，不确定是不是。家里没有抗原检测，也懒得出去买。没有吃药，就只多喝了几杯开水，20 点就上床睡了，一直睡到周五早上 7 点，感觉还是没有完全恢复。和公司同事打了个招呼，说上午不去公司了。周五下午坐公交去了办公室。和同事聊了一下工作进展，没有什么心情写程序。到 18 点下班去食堂吃完饭就坐公交回家了。头还是有点晕，但比周四要好一些。周末感觉体力不行，没有去攀岩。周六和周日一直在家睡觉。到周日下午觉得精神好了不少，就看了半本小说。因为头晕，不想打博德之门 3 ，拿出之前没打完的《银河 ...继续阅读 (121)

我们的手机游戏引擎一直在跟随着游戏项目的进程不断优化。一开始是因为游戏引擎在手机上帧数达不到要求。得益于 ECS 框架，我们把初期用 Lua 快速开发出来的几个核心 system 用 C 重写后，得到了质的飞跃。其实这些核心代码总量并不算大。例如在 profile 中表现出来的非常消耗 CPU 的一个场景树更新系统，用 C 重写了也才 200 行代码 ，但在优化前 Lua 版本会消耗超过 1ms 的时间，而用 C 重写后，时间已可以忽略不计。另外，我们采用了类似 skynet 的ltask做多线程框架，把业务尽量拆分到多线程中并行处理，这也极大的减少了每帧的耗时。除了主业务逻辑外，UI 、粒子系统、IO 被分为几个并行线程。且渲染底层的 bgfx 也是按多线程渲染设计的。这些并行流程间只通过少量的消息通讯，所以，并行的总工作量并没有比单线程模型更多。ltask 也可以很方便的调节工作线程的个数，用来更好的适配手机的 CPU 。从xcode 的调试信息看，在游戏场景丰富时，大约会占用 280% 的 cpu 。换句话说，如果我们采用的是单线程架构，在不删减特性的前提下，是无论如何都无法做到流畅的。我的开发用手机为 iPhone 12 mini 。目前，游戏锁定在 30fps ，而每帧实际时间开销为平均 10ms 左右 （7ms ~ 15 ms 之间）。所以理论上锁定 60fps 也是完 ...继续阅读 (113)

在我们的 ecs 模块中，有一个重要的内部数据结构是 eid 的数组。它是 Component 结构的一部分，表示每个 Component 属于哪个 Entity 。目前，它是以一个有序的 id 数组实现的。这个数据结构常见的操作分别是：遍历、随机访问、查找 id 所在的位置。一个有序数组可以很好的完成任务。O(1) 的随机访问时间，O(Log N) 的查找时间。我们的 Entity ID 是 48bit 的，我觉得保存 48 或 64bit 的 id 数组有点浪费，且空间越大，实际操作效率也会相应降低。实际上，Entity 的个数不会太多，我觉得限制在 2^24 (一千六百万左右）足够了，所以用了一个间接索引，保存 24bit id ，再用它去索引真正的 entity id 。三个字节保存内部 id 听起来有点别扭，因为内存访问没有对齐。但是 4 字节又略显浪费，2 字节我担心不够用。所以，在上个月时，尝试做了一点优化：将数据按固定 32 (或至多256) 个元素分组。每组 64bits header + 32 * 8bits 。header 保存第一个元素的高 40bits ，后面是每个元素的低 8bits 。每组分为三个区段: 1. 高位相同 2. 高位+1 3. 其它离散数据。header 中用 2 bytes 保存 1,2 区段个数。用 16bits 保存离散数据的 of ...继续阅读 (140)

我们的游戏引擎使用的是stb 的 truetype 库来处理 ttf 字体的。最近发现在使用公司提供的阿里巴巴普惠体时出了一点问题。引擎渲染出来的汉字比标称的像素高度矮了不少，想渲染 100 像素高的汉字，结果只有 70+ 像素左右。我们之前测试使用的中文字体（ Windows 自带默认字体）没有这个问题。在网上翻了一下，找到这么一个帖子：https://github.com/nothings/stb/issues/689以及imgui 也遇到过类似问题。原来，stb truetype 库提供了两个计算字模大小的 api ，stbtt_ScaleForPixelHeight()和stbtt_ScaleForMappingEmToPixels()分别用两种方式计算字模高度比例。作者比较提倡用前一个 api ，但也保留了后一个 api 的使用场景。computes a scale factor to produce a font whose EM size is mapped to 'pixels' tall. This is probably what traditional APIs compute, but I'm not positive.另外在获取字体的 ascent 以及 decent 时，也有两个不同的 api :stbtt_GetFontVMetrics()和stbtt ...继续阅读 (129)

这一篇是延续去年的想法。最近正在按这些想法改进我们正在制作的一款类异星工厂的手机游戏。我们的游戏引擎是在 PC 上开发的，但希望专门用于手机。虽然我希望日常游戏开发都在真机上进行，引擎为之也做了很多的努力。但实际并不算顺利。主要还是引擎以及游戏的核心 C 部分还在频繁改动，在真机上调试毕竟不如 PC 上方便。好在最近已经慢慢稳定下来，开发中使用真机的机会越来越多，也就更多的考虑在手机上的交互问题。我意识到的第一个问题就是：在 PC 上模拟的版本是无法体验手机上的交互感受的，想把手机上的交互做好，就必须时刻在手机上体验。我们引擎原本的交互界面都是基于鼠标消息，触摸屏消息只是对鼠标消息的模拟。这样是不对的。意识到问题后，我们首先把鼠标消息从引擎中去掉，把触摸屏手势消息改为 first class ，而鼠标消息则反过来用手势消息模拟。基本手势其实有四个：点击、长按、拖动、缩放。其中在不同场合下，拖动可以被清扫取代，但两者不可共存。玩建设类游戏，触摸屏交互和鼠标交互看似差不多，实际差别很大。触摸屏的点击面其实是一个圆形区域，而鼠标则是一个点。鼠标更容易精确定位点击，而触摸屏难以做到精确。鼠标有移动和悬停消息，在类似游戏中非常有用，但触摸屏是没有悬停事件的。手指点击物件的时候，手指会遮挡住点击处，如果按鼠标的模式进一步做拖动，更是会一直挡住被拖动物件，这会导致非常糟糕的交互体验。所以，我思考 ...继续阅读 (121)

之前教孩子玩扑克牌，从抽王八入手。孩子们都很喜欢。这是一个传统游戏，在西方叫Old Maid。规则很简单，就是把一副 54 张的扑克牌中抽掉一张王和一张 8 （或其它任意牌）。把牌平均发给参加的玩家。每个玩家将得到的牌中成对的牌都扔掉，保留在手上的全部是单牌。然后，每个人每个回合抽下家一张牌，如果能和手上已有的牌配对，便可以把成对的牌扔掉，否则必须把抽到的卡保留在手中。先打完手牌的玩家胜利，而到游戏最后，最后一个玩家手上肯定保留了一张王和一张八，而其他玩家都出完手牌。这种玩法非常简单欢乐，小孩子一学便会。但我觉得玩起来毫无技巧可言，所以我最近把规则改进了一下，变成了一个非常依赖记忆力的游戏。改进规则如下：在发完手牌后，玩家把手上的若干单牌一一盖在面前的桌面上，每张牌相互不可重叠。一旦摆好后，就不可以再查看，也不能移动牌的位置。最好自己记住每张牌。抽下家的牌时，从对方桌面自由选择一张盖住的牌，自己暗自查看（不能给其他玩家看，包括被抽牌的玩家），然后可以选择： 背过来放在自己面前，加入已有的牌组；或是正面朝上打出，同时翻开自己面前牌组中的一张牌，如果两张牌成对，就可以把两张扔到弃牌堆，如果不配对，则将两张牌都翻过来盖上。这个过程必须让所有玩家可见。打牌过程中，除了抽牌后可以翻开特定的一张牌，不可以查看自己面前的牌，即使想起来自己还有成对的牌也不可以翻开。消牌只能在抽下家的牌后才能进行一 ...继续阅读 (121)

...继续阅读 (113)

云豆想要一块电话手表。我了解到现在的小孩大多用小天才儿童手表，但考虑到云豆其实没有什么社交需求，我自己也有一块 apple watch ，所以想试试给他买一块。最初的想法是，儿童手表过两年估计娃就不愿意带了，而 apple watch （系列）可以用到成年。而似乎 apple 似乎也愿意做儿童市场，现在 apple watch 有家人使用的模式，不妨试试。周六，网上订购的 apple watch se 到了。我给他创建了一个苹果的儿童账号，很顺利的就设置好了手表。但简单适用了之后就被劝退。apple watch 的家人模式功能上大打折扣，手表其实还是挂在我账号下的，而表上多绑了一个儿童账号。这导致除了苹果官方默认 app 之外，几乎所有的 app 都不能安装。包括微信支付宝这些。除了打电话，能用的通讯就只剩下 iMessage ，对小孩几乎没什么用。我想在手表上装个交通卡也未能成功：因为年龄不够（苹果要求 14 周岁），不能在钱包里添加卡片。苹果官网查了一下，儿童账号的支付功能只在美国才能开。折腾了一晚上儿童账号后，只能说这玩意想得很美好，极度的不好用，尤其不适合我家的现状。iPAD 换上儿童账号后，我差点自己都不会用了。动不动就锁死 app ，不少国产的 app 的年龄限制做得不好，导致在儿童账号下体验不佳。儿童账号下，不少设置功能的入口我都走不到了，想删个 app 都需要 go ...继续阅读 (102)