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

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 ...继续阅读 (107)

我们游戏引擎的 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 角度看，这些就应该 ...继续阅读 (94)

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

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

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

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

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

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

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

我们的手机游戏引擎一直在跟随着游戏项目的进程不断优化。一开始是因为游戏引擎在手机上帧数达不到要求。得益于 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 也是完 ...继续阅读 (102)

在我们的 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 ...继续阅读 (125)

我们的游戏引擎使用的是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 ...继续阅读 (121)

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

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

...继续阅读 (103)

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

今天有同学在老帖子上留言，看到下面杨博去年问这方面有什么进展，想想应该补上这么一篇。最近几年，因为疫情的缘故，在家的时间比较长。孩子也长大了不少，能开的桌游多了许多。我现在几乎很少在外面和朋友玩桌游了，而在家几乎每周都会开三到四次。云豆马上九岁了，可可也已经六岁半。兄妹俩的喜好已经明显有区别，我们能一起玩的桌游不多，一般我都是分开带哥哥玩，或单独带妹妹玩。不过有一款游戏大家一起玩的很多，那就是 Splendor （宝石商人）。这款游戏发行商标注的是 10 岁+ ，在 bgg 上用户投票以 8 岁+ 居多，我感觉也是。7，8 岁的年龄完全可以充分理解游戏规则，制定整局规划。可可不到 6 岁多点也能玩，但是年纪比较小，仅能理解规则，无法深度思考怎样赢得游戏。好在她的胜负心很弱，每次输掉都能自我开解：玩个游戏嘛，输赢无所谓的。在家开四人局时，可可就是陪玩。她每次都只看当下的目标。因为游戏是靠拿 15 分胜利，她就几乎不拿无分的初级卡，每次都攒够资源直取二级卡。就这样，有一盘居然运气好到离谱获得过一次最终胜利，被她津津乐道了很久。云豆则非常想赢，而她妈妈从来不让步。我们家经常开三人局，云豆拿第二次数最多。每次输掉后，我就找机会帮他复盘。引导他大致记住卡牌的分布，教一点点概率知识，教他制定长远一点的计划。这两年我们估计开了数十盘，他都快输的没信心了，但最近一局扎扎实实的得了一次第一。终于完成 ...继续阅读 (97)

五一前，我遇到了一个非常难缠的 bug ，前后花了两天时间才把它解决。其刁钻程度，可以列入我职业生涯的前三，非常值得记录一下。问题发现在节前两天，很多同事都请了假，我也打算好好休息一下，陪孩子玩几天。就在我例行更新游戏项目的仓库后，突然发现程序崩溃了。一开始，我并不以为意。因为我们的游戏是用 Lua 为主开发的，并不需要在更新后重新编译。我大约一周才会构建一次项目。或许这只是因为我太久没有 build 了，所以我随手构建了一下。但问题依然存在，只不过发生的概率偏低，大约启动三次有一次会出问题。这不寻常，因为我已经很久没见过 Segmentation fault 了。我们的游戏引擎是专门为手机设计的。为了开发时可以实时关注在手机上的效果，我们不像别的游戏引擎那样，开发时在开发机上跑一个 Windows 或 Mac 版本，只在需要的时候输出一个手机版。我们用 C/C++/Obj-C 编写了引擎的内核，编译了一个 iOS 上的 App ，在引擎中内置了一个虚拟文件系统。开发时，在开发机上运行一个叫做 fileserver 的进程，把开发机本地的一个目录映射到虚拟文件系统上。这样，手机上的引擎内核在运行时，就会直接读取开发机的目录，我们在开发机上所做的任何修改，就能即刻反应到手机的 App 上。手机上运行的引擎内核，是项目组统一定期编译发布的，一般我并不自行编译。这次崩溃的是我本地的这个 ...继续阅读 (122)

我们正在开发一款类似 Factorio 的游戏 ，以修建自动化工厂为主要玩点。其游戏背景接近火星殖民。所以，最近一年我玩了相当数量有类似点的游戏，希望能得到一些启发。其中有三款以火星殖民为主题的新游戏我个人很喜欢，值得推荐一下：其一是 Farlanders ，像素化的画风很复古，很对我的胃口。游戏是回合制的，节奏很快。从中可以找到许多桌游的元素。紧凑的四边形格子地图，地形改造，隧道、电线、水管，这些都需要玩家精心布局。如果玩自由模式的话，后期会偏简单，有点无趣。但是它的故事模式的难度调的相当好。如果选困难（我觉得开发者是围绕这个难度制作的），到了第 6 关就很难一次过关了。btw, 我在这个游戏中还学到了一个交互设计上的防呆处理手法。菜单有一个按钮是不希望玩家误碰的（因为可能会删除档案），一般的做法是按了之后再弹出一个模式对话框二次确认；也有人做成这种按钮需要长按一段时间才能确认。而这个游戏的做法是按了这个按钮后，在按钮的右侧再出现一个新的按钮，上面有画有一个勾勾。玩家需要移动鼠标去点击这个新的勾勾按钮才真的执行该操作。没有其它额外的说明文字。这个防呆设计让我觉得很舒服，而且非常适合在手机上实现。第二个游戏是 Plan B: Terraform 。这个游戏目前的内容少了点，给人有点虎头蛇尾的感觉。我玩的第一感觉是那个无人机平台的物流设计有些惊艳。这启发了我，我们正在开发的游戏立刻做 ...继续阅读 (92)

昨天做内部晋升评审时听到候选人介绍他即将开始的一个项目。大致是我们公司从韩国买过来一个游戏（有全部源码）打算自己运营。该游戏服务器全部用 C++ 编写，使用 SQL Server 做数据库。我们这个项目，除了需要根据市场做二次开发外，还希望把 SQL Server 迁移到 MySQL 上。成本是最主要的原因，如果可以迁移成功，成本将减半甚至更多。该成本差异主要在 SQL Server 的使用执照费用，以及同等任务所需要的云成本。我在反复确认了这项工作是否真的有做的价值（从 SQL Server 改为 MySQL）后，讨论了一下具体实施方案。移植的难点在于该项目大量使用了 SQL Server 的存储过程。几乎所有的业务逻辑都是人肉写在 SQL Server 的存储过程中的，大约有 20 万行。虽然 SQL Server 的存储过程和 MySQL 的差异不是特别大，但再靠人一点点重写成本上也不划算。负责的这个同学说他考虑用 ChatGPT 来做翻译工作，并做了一点点预研工作。结论是，AI 可以辅助这件事，提高开发效率，但是，翻译结果还是需要人工来审校。工作量并不小，而且一旦出错，损失会很大。我对 SQL Server 和 MySQL 都不熟悉，但我觉得既然都是 SQL 数据库，那么一一对译应当问题不大。但我认为应该选择一条渐进的路线，让项目可以一步步推进，每步都能直接看到结果。据此， ...继续阅读 (111)

今天解决了一个问题，觉得很有趣。本来想发到推特，发现一两句话说不清。所以写一篇 blog 记录一下。我们正在开发的游戏中，会用一个 id 来表示一个游戏对象到底是什么。比如，“铁片” 是 1 ，“煤” 是 2 ，“采矿机” 是 3 …… 这样，在运行时，C 代码可以根据对象的类型方便的查询对象的属性。而对象的属性则是用 Lua 配置好，在运行期不变的。例如每燃烧一个单位的“煤”，可以产生 100KJ 的热量；一箱“铁片”有 100 个。为了在 C 和 Lua 间快速共享这些配置数据，我还专门写了一个 cache 模块。问题出在 ID 的持久化上。因为游戏中的物品种类并不是特别多，出于时间以及空间性能的考量，我把 ID 设计为 16bits 。64K 种物品种类的上限看起来足够了。但 ID 的分配却比较麻烦。最简单的做法是，在程序运行时，用一个自增 ID 分配给每个物品类型。但这会导致 ID 极不稳定，考虑到 ID 需要持久化，在开发过程中，持久化的存档也变得很不稳定。所以我选择了用物品的名称以及一些内在的参数（例如版本号）一起计算 hash 值当作 ID 使用。但 16bits 的 ID 显然会发生 hash 冲突，所以最终还是结合了一个自增算法为每种物品赋予 ID 。这个方法在很长时间相安无事。大多数小版本更新都没有破坏老版本的存档，偶尔的版本更迭导致存档失效也是可以接受的。我们 ...继续阅读 (110)

这段时间忙游戏项目之外，继续花了几天学习神经网络。上一篇 blog发布以后，收到了图灵的朋友的 email 。然后，我收到了一大堆（九本）图灵出版的关于人工智能的中文书。通常出版社的同学给我邮寄新书，或多或少是希望我能写点什么。我不想刻意帮人宣传新书，但倒是不介意推荐一些我自己读过的不少的东西。这次收到的书太多，当然没有全部读完。但书的内容相关性都很强（差不多一个主题）。去年的时候，我读了《如何阅读一本书》，里面提到读书的四个层次。第四个层次就是就一个主题同时读多本书是非常有意义的。这次，我也颇有收获。在这堆书中，关于神经网络的入门。除了上一篇 blog 中提到的那本免费英文书（已经有中文版《深入浅出神经网络与深度学习》了），我还推荐日本人写的《深度学习入门》。我觉得日本的科普入门书都讲的特别细致，并配了大量图解。果然这一本补充了许多我在阅读前本书中忽略的细节。尤其是误差反向传播算法，我觉得读了之后脉络更清楚一些。btw, 我在 twitter 上推荐这本书时（并没有写出书名，只有一张照片），还收到了作者斋藤康毅的回复。世界真是小啊 :)在实作环节、我给自己定的小目标是实践一下卷积网络。但几本书的实践代码都不再像之前那个简单的全连接网络那样有非常简单的实现了。我还是打算完全自己从零写（不借助任何包括数学向量计算在内的库）。这次没有太多可以参考的代码，所以难度更大。倒不是说代码会特别 ...继续阅读 (105)

最近 AI 很火。我从读书的时候就对 AI 有兴趣，90 年代的时候读过一本关于神经网络的书。但当时没有能力完全理解。2000 年初刚毕业那会儿想搞明白点，又研究过一段时间。了解了很多相关知识，感觉自己弄明白了，但却没有真正动手实践过。现在，所有人都看得到，AI 已经变成了一个可以真正帮助我们提高生产力的工具了。我觉得有必要好好学习一下。我并不期望几篇文章就可以搞清楚，那样只会让自己好像懂了，和人聊天估计够用，想理解它还是得自己动手。真正写几段代码，才有触碰的感觉，明白别人到底在解决什么问题。一开始，我是从维基百科的Machine learning开始读的。顺着看了一整天，了解了近年发展的脉络。好多词条，乱七八糟的笔记记了一大堆，感觉快消化不了了。疑问也积累了很多，觉得看下去效率会越来越低。不如换一条路。然后我开始读Neural Networks and Deep Learning这本书。读了两章后，我想，手写数字识别看起来是一个非常好的实践手段，不如自己写一遍最快。有这么一个基础，后面可以继续修修补补，沿着前人的轨迹走一下，可以更好的理解为什么。现在的条件远超 20 年前，训练这么一个简单的前馈神经网络估计在我的机器只要不到一分钟，可以很快得到反馈。有很多现成的代码可以比对，出了 bug 容易查。练习需要的数据也是唾手可得：THE MNIST DATABASE of handwr ...继续阅读 (106)

上周看到了 Redis 作者的新玩具语言Aocla，感觉很有启发。它是 FORTH 和 Lisp 的杂合体，又增加了一些内嵌局部变量的支持。非常像我前两年给我们数学库做的一个小东西。最初的想法是为数学库设计一个 DSL 潜入 Lua ，在做复杂的数学计算过程时，可以把计算过程停留在 C Side ，减少 Lua 和 C 之间的边界成本。最初的版本是我模仿 FORTH 设计的基于栈的小语言。希望牺牲一些表达能力，换取一点性能。但实用起来过于别扭，后来又增加了一些特性却没有本质改进。最后终于决定把这个 DSL 彻底从数学库中剥离了。看过 Aocla 后，我又有了一些新的想法。Aocla 只有一千多行代码，我判断实现这么一个小玩具应该在 2 天之内，所以实验成本并不高。那么，不如直接动手试试重新实现一个看看。我并没有看 Aocla 的具体实现。我设想的 DSL 只是提供完整的控制结构，数据类型基于 list 就够了。这方面我已有一些经验写起来应该很顺手。参与运算的数值类型应该是根据需求从外部注入的，类似 Lua 的 userdata ，但提供更高的效率以及类型支持。毕竟，在 Lua 中实现自定义数据类型最大的问题是它们是二等公民，Lua 和 C 之间的边界成本颇高。如果是嵌入 Lua 使用，那么原生的 string 类型是不必要的。所有数值都可以是类型加 ID ，它们就有了固定的大小。我 ...继续阅读 (104)

ECS 中，同一个 Entity 是否可以由多个同类型的 Component 构成？在 Unity 中，答案是可以。我们的引擎在设计之初也是可以的。当时有一个问题：在 Lua 中，如何访问同类型的 Component ？如果有多个同类 Component ，最自然的方式是把它们放在一个数组里。但是、绝大多数情况下我们用不上这个特性，每次访问 Component 都加一次 [1] 或 [0] 的数组索引显得画蛇添足。若单个 Component 不用数组，多个才用数组，写起来又有极大的心智负担。因为这样做，它们就成了两个不同的类型。后来，我们干脆利用 Lua 的特性，把数组和 Component 本身放在一个 table 中。如果有多个 Component 就把这个数组直接放在第一个 Component 的 table 内。就这样用了一段时间后，最后还是受不了这个脏技巧。等到用 C 编写luaecs后，就砍掉了这个特性。ECS 不是万能灵药。如果需要让相同的 Component 聚合在一起，那么就使用额外的数据结构，或是不只使用一个 world 。这是我们目前实践给出的答案。去年在luaecs 的 issue 9也讨论过类似问题。最近，我们在不同的地方又碰到类似的问题。我觉得这个问题的本质是，ECS 虽然提供了一个高效的、不同于 OOP 中的对象的数据模型，但它对数据结构的实现有很大 ...继续阅读 (101)

今天是年前最后一天工作，我想对最近做的一些事情做一些记录。我们在使用自研引擎开发游戏时，遇到了不少和预期设计有距离的问题，针对问题再反思了原有的设计并做出改进。我认为、凭空设计一个通用游戏引擎是不可能的，必须结合实际项目，做许多针对性的实现。但同时应不断反思，避免过多的技术债。在最近一年，我参与的引擎具体编码工作很少，更多的是站在一个反思者位置，监督代码和设计的演变。我们的引擎主体框架是基于 Lua 的，受益于 Lua 的动态性，可以很方便的把各个模块粘合在一起。但是、Lua 和 C/C++ 相比，又有两个数量级的性能差异，对于渲染代码而言，若将和 GPU 沟通的 API 完全放在 Lua 的 binding 层，对于对象数量巨大的场合，很容易出现性能问题。我估计、在手机环境这个“巨大” 差不多在 10K 这个数量级吧，而 PC 环境还能支撑到 100K 左右。Lua 项目的优化无非两条路：使用 jit 技术、把热移到 C side 。正如 Roberto 所言，"Finally, keep in mind that those two options are somewhat incompatible" 这两条路需要的操作往往是互斥的。而我不喜欢 jit 带来的复杂度和不确定性，所以选择了后者。为了解决大数量对象的批量操作问题，我在 2021 年进入了luaecs。这个库现在已经 ...继续阅读 (96)

上次谈游戏引擎的虚拟文件系统是去年 10 月了。最近我们又做了一些修改。我们的虚拟文件系统有两个工作模式。一种模式主要用于编辑器和开发环境，所有的文件名和路径都基于原生文件系统，我们叫它编辑器模式；另一种模式被称为运行时模式，主要用于运行时环境。文件均用类似 git 仓库的形式，用文件内容的 hash 值作文件名，储存在一颗 Merkle tree 上，并通过一个专门的 file server 为运行环境提供资源的更新服务。在编辑器模式下，并不是直接映射原生文件系统的整棵目录树的，而是增加了一个 mount 配置，可以把很多不同的目录装配在一起。当初这么设计是希望提供一定的灵活度，方便游戏项目可以把引擎提供的基础功能和资源组装进来。最近做了一些改动。把这个 mount 机制改成了 mod 机制。mod 机制在很多游戏中都能见到。即，可以指定一个 mod 目录，这个目录下有着和游戏主目录相同的结构。游戏运行的时候，这个目录下的文件有着比游戏主目录下同名文件更高的优先级。游戏程序想读取某个文件时，会优先读取 mod 目录下的文件，如果文件在 mod 目录下不存在，才会查找游戏的主目录。mod 目录通常可以有多个，可以定义优先级次序，一级级查找。Paradox 的游戏都支持 mod ，玩家可以方便的用这种方式扩展游戏。我就维护着群星的一个非官方汉化 mod。我最近玩的较多的 factor ...继续阅读 (101)

月初还和同事调侃，这次谁也躲不掉，感染是迟早的事。最近全家都中招了，好在病毒这次还算轻柔，差不多都痊愈了。在此记录一下这次的历程。起点是广州的全面开放。老婆在家已经被关了快一个月，憋得不行。开放第一个周末，就约了同事出去玩，周五晚上密室、周日下午（12 月 11 日）出去拍照。我觉得广州已经放开，这次病毒的 R0 相当高，快速传播开无可避免，第一个周末外出有非常大的风险。所以取消了原本每个周末的攀岩活动，和两个孩子继续关在家中。儿子一直有点咳嗽，我有一些感冒，有流鼻涕的症状。Day 0 (12 月 12 日周一）老婆被通知一起玩的同事已经确诊，需要她居家办公，观察一天再考虑回办公室。我当天正常上班了。这天我之前的感冒症状（流鼻涕）已经完全消失，精神状态非常好。晚上她有一点低烧（38 度），自测抗原阴性，觉得是因为感冒。这一晚，女儿和妈妈睡觉。Day 1老婆有点不舒服，在家休息，我继续上班。感觉她有很大的可能已被感染，所以我上班时带严了口罩，和同事聊了这件事，大家都很放松。中午的时候，老婆发消息来说她发高烧了，抗原自测阳性。我担心我也被感染了，可能传染给同事，赶紧交代了一下接下来的工作就回家了。家里有一点含对乙酰氨基酚的感冒药（不是泰诺、备的泰诺用完了），还有一瓶没开封的美林（布洛芬混悬液）。给她服了美林，很快就退烧了，但是精神状态很糟糕。注：美林是给小孩用的，所以服用的时候按体重换 ...继续阅读 (91)

我们现在制作的游戏以手机优先，交互都是围绕着触摸屏来做。如果开发的时候总是在 PC 上用鼠标测试，很多交互问题都容易被忽视掉。所以，我们自研的引擎花了很大气力在手机设备上即改即所得。在开发时推荐开发人员直接在手机上修改、调试。这样更容易发掘出平时用鼠标操作难以察觉的问题。btw，直接在手机上开发比在 PC 上开发还有另一个好处，就是随时能关注画面元素（尤其是字体）的大小是否合适。鼠标和触摸屏在交互上有很多类似的地方，但也有很大的不同。鼠标的点击是精确到单点的，触摸屏的 tap 其实是一个面。很多框架直接取了面的中心点和鼠标事件划上等号，这是不对的。我们做交互的时候，时刻应该清楚，触摸屏的 tap 事件并不是像鼠标点击事件那样有一个精确的屏幕坐标。触摸屏是有多个触摸点同时存在的，而鼠标指针一般只有一个。我们未必要深入使用多点触摸的交互逻辑，但在用手机的时候，一只手不小心压住了屏幕一侧，另一只手做 tap 操作，这非常常见。鼠标的基础操作有移动、左键点击、右键点击；而触摸屏只有在屏幕上拖动的消息，没有指针移动事件，也无法区分左右键两个不同的点击操作。或许可以用手势来区分，比如用轻触和长按来分出两种不同的交互操作，但滥用可能会造成用户的困扰。鼠标手势属于高级玩法，一般不去教育初级用户使用；但触摸屏是反过来的，必须依靠手势完成更丰富的交互操作，而且用户已经被教育的很好。比如两指缩放，滑动， ...继续阅读 (88)