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

...继续阅读 (120)

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

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

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

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

昨天做内部晋升评审时听到候选人介绍他即将开始的一个项目。大致是我们公司从韩国买过来一个游戏（有全部源码）打算自己运营。该游戏服务器全部用 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 数据库，那么一一对译应当问题不大。但我认为应该选择一条渐进的路线，让项目可以一步步推进，每步都能直接看到结果。据此， ...继续阅读 (129)

今天解决了一个问题，觉得很有趣。本来想发到推特，发现一两句话说不清。所以写一篇 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 。这个方法在很长时间相安无事。大多数小版本更新都没有破坏老版本的存档，偶尔的版本更迭导致存档失效也是可以接受的。我们 ...继续阅读 (134)

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

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

上周看到了 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 ，它们就有了固定的大小。我 ...继续阅读 (126)

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 中的对象的数据模型，但它对数据结构的实现有很大 ...继续阅读 (122)

今天是年前最后一天工作，我想对最近做的一些事情做一些记录。我们在使用自研引擎开发游戏时，遇到了不少和预期设计有距离的问题，针对问题再反思了原有的设计并做出改进。我认为、凭空设计一个通用游戏引擎是不可能的，必须结合实际项目，做许多针对性的实现。但同时应不断反思，避免过多的技术债。在最近一年，我参与的引擎具体编码工作很少，更多的是站在一个反思者位置，监督代码和设计的演变。我们的引擎主体框架是基于 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。这个库现在已经 ...继续阅读 (112)

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

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

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

绝大部分的基础数据结构都是定长的，很容易针对优化它们的内存管理。但字符串是一个例外。内存管理和其它资源管理有明显的不同。管理内存有点像切蛋糕，从整块蛋糕上切下需要的那块，但归还的时候却因为支离破碎难以合并起来满足后续用途。举个极端的例子：如果内存堆有 2G 大小，如果碰巧在正中间分配了几个字节而从未释放，这个堆就被永久的分成了两个不足 1G 的分片。之后再无可能从这个 2G 大小的堆中分配出 1G 的内存块。改进内存分配算法或许可以减轻内存碎片的危害，但即使是在此方面做了相当多努力的 jemalloc ，其表现也大大低于一般用户的预期。以我的经验，一个 16G 的内存堆，对于长期运行，需要大量反复分配释放内存的程序，通常能做到 10G 左右的峰值有效内存占用就不错了。这里说的有效内存使用，指你调用 malloc 传入的字节数之和。根据应用程序使用内存的方式不同，这个数字会有很大的不同。60% 的内存使用率其实已经很好了，但还是会有很多人问，我的内存都去哪了？尽可能的规范数据结构的大小，并针对它特别管理内存，提高内存使用有效率的方法之一。这相当于分层管理资源，而不是不问青红皂白全部放在一个全局堆中。等长的数据结构在回收之后可以直接再利用，这可以消除大部分的外部内存碎片。btw, 定长的数据结构对持久化也更友好。这篇 blog 想探讨的字符串类型， 指的是一串不变的、连续的、用以表达某 ...继续阅读 (110)

最近半个月，因为广州防疫政策，我一直居家办公。找了点时间，给 skynet 做了一年一度的 release 。这次的 1.6.0 版，相比去年的 1.5.0 版，没有太大的变化。主要是平时积累的一些 bugfix 。它所依赖的第三方库，例如 Lua , jemalloc 我都更新到了最新的版本。值得一提的是，mongo 的 driver 也更新了。因为 mongo 在最新的版本中已经淘汰了旧的 wire protocol ，如果再不更新，就无法连接新版 mongo server 了。具体讨论可以参看PR #1649。因为 mongo 自己的设计原因，我们无法给出一个同时兼容新老版本协议的方案。从这点来看，我个人认为 redis 的底层协议设计就稳定的多。 这么多年更迭基本不需要修改。这些年，我一直在追踪 Lua 的更迭。我认为 Lua 的源代码是最值得一读的开源代码。作者的编码风格相当严谨，几乎每处细节都严格准循标准，而不仅仅只保证在现有环境下正确。这份严谨也并非从一开始就固有的，是这二十多年来逐步形成的。我的硬盘上留有几乎所有 Lua 发行版的源代码，经常对比阅读。自从 Lua 在 github 上镜像了开发仓库后，我就习惯阅读它的每一个 commit ，经常能学到一些东西。比如最近的这个：把 stack 的扩展从 free / copy / alloc 改成了 realloc ...继续阅读 (546)

这几年我一直被干眼症和结膜炎困扰。疫情之前，每次洗澡后就双眼通红。但似乎并无其他影响，也没怎么在意。后来慢慢的，眼睛就容易发干，经常疲劳。严重的时候眼睛几乎睁不开。最受影响是在开车的时候，因为无法休息眼睛，特别难受。到晚上环境光线不足的时候，感觉远处看不清楚。然后，视力突然断崖式下降。三年时间，每年体检，从 1.2 直落 0.7 左右。而我在 35 岁之前一直是双眼 1.5 的视力。本来 2020 年就想约眼科医生看看的，因为疫情去看五官科不方便就一直拖着，直到 2021 年底才去看了医生。初步诊断结果是结膜炎、干眼症、视疲劳。另外，验光结果表明我有 150 度近视加 50 度散光。因为并不影响日常生活，便没有配眼镜。而且，我的视力是时好时坏。从办公室眺望珠江对面的楼顶招牌时，有时那些字清晰可见，有时则是重影。我感觉如果以后能解决干眼症和结膜炎的话，视力能稳定一些。在医院开的眼药水用完后，我便自己在网上网购一些进口的眼药水。尝试了好几种，最后觉得德国产的海露（Hylo Gel）最舒服，几乎不刺激眼睛；只要隔两个小时滴一次，便可以缓解视疲劳。所以就在家中和办公室各常备一瓶。不过，结膜炎似乎今年更严重了。现在每天早上起来眼镜都充满血丝。而且视线略模糊。需要滴过眼药水，休息大约半小时才能恢复正常。前两个月又尝试了日本参天的一种据说消除红血丝的眼药水（金色包装的 Sante FX V+）。 ...继续阅读 (97)

周末在家里折腾 BT 下载，发现 UPnP 无法工作，便去光猫那里看看是什么情况。我发现现在电信宽带默认已经是由光猫来拨号，家中的路由器是作为一个二级路由在使用，如果想让 UPnP 或 DMZ 工作起来，需要在光猫里设置。查看光猫设备上印的默认管理员密码登录上去，没有找到太多设置选项。在网上搜了一下，需要一个超级管理员身份才能看到全部设置菜单。一般的说法是打电话问一下装宽带的师傅，但天色已晚，不想麻烦人。转念一想，有这么多家宽带设备要管理，电信应该用的是统一密码，或是有一些简单手段可以拿到这个密码才对。否则建立一整套管理系统成本实在太高了。按 google 搜索结果，打开 192.168.1.1/cgi-bin/baseinfoSet.cgi 后，果然密码就写在这个 json 文件中。虽然不是明文，但和明文也差不多了。密码条目中写的数字就是 ascii 的变形。因为普通密码是已知的，很容易就能看出规则：偏小的数字就是 ascii 码，偏大的数字是 ascii 偏移 4 。用一行 lua 代码就能转换为密码的原文。拿到超级管理员密码进入管理界面后，便可以打开 DMZ 等端口映射功能。但是我发现现在电信已经不再给 ipv4 的公网地址了，即使做了端口映射也没啥用。按网上的说法，可以打电话给电信要求一个公网 IP ，一般都会爽快的给。但一是时间已晚，人工客户不在线；另外按最新的说法，最近 ...继续阅读 (116)

我们游戏引擎的 IO 模块其实一直在修改。最初的版本到现在有四年多了。一直没有定稿的一部分原因是因为我们给引擎设定了一个比较高的需求：引擎本身也是可以从网络自更新的。而更新引擎本身必然依赖 IO ，包括 IO 模块自身。而我们引擎又基于一个多线程版本的 Lua 框架ltask，ltask 本身也是需要依赖 IO 模块启动的。这些后续的设计要晚于最初 IO 模块的设计，反复重构也就是必然了。一开始我们为 IO 单独分配了一个线程，它负责和文件服务器通讯以及文件的读写。后来因为整合 ltask ，又花了许多功夫把它从独立线程变为 ltask 的一个服务。但这个服务又有点特殊：因为它还需要负责 ltask 自身的加载。所以它前生是一个 native os thread ，中途再转换为 ltask 的独占服务。最近，我反思整个模块的演化历程或许被引入了不必要的复杂度。重新考虑把所有的 IO 请求都放到一个单独的线程/服务 中是否是过度设计、似乎应该做一些退让，维护很少几个全局状态，似乎能简化很多的设计工作。这里需要解决的另一个难题是一些第三方库需要注册一个 IO 回调接口，再需要读写文件时调用框架提供的接口加载文件。这些第三方模块都是把文件操作看作是同步调用，而我们已经实现的 IO 模块本质上提供的是异步接口。如果一个模块本身是 Lua 实现的，那么同步接口和异步接口的差异很小；但如果回调 ...继续阅读 (92)

我们在制作一款类似 Factorio 以自动化为主题的游戏。在游戏开发中遇到了不少算法上的问题，解决过程都非常有趣。比如之前就写过一篇流体系统。和 Factorio 体验的最大不同在于，我们不使用传送带做主要物流手段，而是依靠公路网和货车。这种形式并不新，我在 20 多年前的凯撒3 （以及同系列的法老王、宙斯、龙之崛起等）中就玩到过。采用这种物流方式的游戏一直不曾间断，这几年我玩过放逐之城、缺氧、环世界、海狸浮生记也是这种。这类游戏的共性是需要靠城市资源供养一批工人，然后这些工人干活来供养城市，其中一个重要的工作就是物流。一般受资源产能影响，不会养太多工人，不然很难产生正循环。所以物流所占工作比例并不大。大部分工人的工作（在生产建筑中）从事生产。我们的游戏可能更贴近 Factorio 一些，不需要工人运作机器，物流更纯粹。供养货车的成本也不高，鼓励玩家尽可能多的增加货车，提高物流效率。和前面提到的系列游戏不同，我们的道路资源是有限的。车辆在道路上必须遵守交通规则，如果车辆太多会发生拥堵。所以限制物流效率的是道路而不是资源。我想给玩家的体验是：物流的运作会遵循一定的规则，玩家可以大概感知到规则的存在，并通过不同的布局和调整提高整体的效率。玩起来不如传送带规则那么明确，也不会像一个黑箱那样，无法精细控制。一开始我想设计成偏向铁路运输的逻辑，玩家自己规划路线，货车都严格跑在路线上，只接收 ...继续阅读 (98)

ltask是一个功能类似 skynet 的库。我主要将它用于客户端环境。由于比 skynet 后设计，所以我在它上面实验了许多新想法。最近碰到一个需求：我们的游戏引擎中嵌入的第三方 C/C++ 模块以 callback 形式提供了若干接口。在把这些模块嵌入 ltask 的服务中运行时，这些 callback 函数是难以使用全部 ltask 的特性。比如，我们的 IO 操作全部在一个独立服务中，引擎读取文件时，很可能是通过网络异步远程加载数据的。这些第三方模块通常没有考虑异步 IO 操作，都是以同步 IO 方式给出一个读文件的 callback 函数让使用者填写。那么，怎样才能在这个 C callback 中挂起当前任务，等待 IO 的异步完成呢？初看是不可能做到的。框架没有设计成支持异步机制，我们难以从 C 函数中 yield ，挂起当前任务。这样，同一个服务就不可能在 callback 结束前相应外部消息，也就无法利用 ltask 的调度器完成异步 IO 工作。Lua 虚拟机也并没有（也无必要）设计成多线程安全的，我们不能把这个 C 模块及其 Lua binding 的运行环境放在一个独立线程环境中。所以，callback 中阻塞调用 IO 请求，就意味着整个服务的阻塞。一个比较简单的解决方法是给 IO 服务额外开通一个 channel ，不走 ltask 内部的消息。在 C c ...继续阅读 (103)

我们正在制作的游戏中，交通和物流是基于公路网的。公路网其实是以路口为顶点，路为边构成的（无向）图。因为我们有大量的车辆行驶在这个路网中，所以，我需要一个空间高效的方法储存这些车辆的路径。在大部分情况下，我们的车辆都选择唯一的最短路径，也就是说如果从 A 路口到 B 路口存在一条制定好的路径的话，所有的车都会走这条路。基于这一点，我们可以对多条路径合并储存。我选择用当前路口 id 和目的地路口 id 做 key ，把下一站路口 id 作为 value ，保存在一张 hash 表中。这样，先用 dijkstra 算法求出起点到终点的最短路线后，再把每一段路线用该结构保存下来即可。当车辆到达某个路口，只需要用当前路口和它自己的目的地就可以索引到应该往哪个方向开。这个结构很适合保存在 Lua table 中，用元表触发尚未计算过的路径。而且这样一个路径表只是一个 cache ，随时可以清理重建。如果路网已经稳定，那么还可以选择一个内存更紧凑的结构保存它们。对于每个路口，连接的路是有限的。在我们的游戏中，其实只有十字路口（ 4 叉）和 T 字路口（ 3 叉）两种。我们可以对路口连接的路编号为 1-4 。我们用 4 个数组就能储存下所有的路径信息。驶向同一编号出口的路径可以储存在一起。比如，如果从 42 号路口去向 100 号路口的车需要在 42 号路口的第 2 出口驶出，我们就把 (42,1 ...继续阅读 (108)

今天同事给我转了一个帖子，说的是 golang 在处理大量并发 json / protobuffer unmarshaling 事务时，可能产生大量的 (10GB) 临时内存，无法及时回收的问题。我的观点是：如果一个系统的某个模块有可能使用 10G 这个量级的内存，那么它必然是一个核心问题需要专门对待。核心问题应该有核心问题的考量方法，这不是 GC 之错，也并非手动管理内存一条解决之道。即使手工管理内存，也无非是把内存块之管理转嫁到一个你平常不太想关心的“堆”这个数据结构上，期待有人实现了一个通用方案尽可能的帮你解决好。如果随意使用，一样有类似内存碎片无法合并之类的问题，吃掉你额外的内存。如果它存在于你的核心模块，你一样需要谨慎考量。在这个具体问题上，我认为还是应该先简化数据结构，让核心数据结构变得易管理。显然、固定大小的数据结构是最容易被管理的。因为如果你的数据结构大小固定，就不再需要堆管理，而是一个固定数组滚动处理临时数据。json 这样的弹性数据结构看起来不太好用固定大小的数据结构去描述，但稍微想点办法也不难做到。C 在这方面的库不少，我就不一一列举。核心想法一般是：用一个固定数据结构去引用编码数据中的切片。解码后的结构只保留元素的类型以及在原始数据中的位置。如果你能大致知道需要解码的数据元素的数量级，那么就可以用一个固定大小的结构去承载解码结果，不需要任何动态的内存分配。只 ...继续阅读 (105)

去年设计luaecs时遗留了一个问题：如何引用特定 entity。一开始，我认为可以灵活使用 tag 系统来解决大部分问题；或者用户自己构建一个 64bit ID 的 component ，采用二分查找的方法来引用特定 Entity 。今年初，我发现我们的自己的使用者和外部使用者都无法避免引用特定 Entity ，所以增加了一个非侵入式的引用方案。最近又围绕它做了一些讨论，让我重新考虑内置一个 Entity 引用的方案。原本关联同一个 Entity 的不同 Components 使用了一个 32bits id ，在过去的代码中我称之为 entity id ，这可能造成了一些误解。它虽然是一直递增的，但 32bit ID 在长期运行的系统上无法避免回绕问题，也就是新的 entity 可能会复用已被删除的 id 。我用一个叫 rearrange 的机制来解决这个问题，当 id 超过 31bit 范围后，在update 环节会重新排列系统中所有的 id ，让它们重新变得足够的小。如果这个 id 并不暴露给上层使用，那么怎么变化它们都无所谓。但如果把 id 暴露出去充当 entity 的引用就会有问题。一个简单的解决方案是换成 64bit ID ，这样就不会再有回绕问题了。但是，每个 component 都会增加 32bit 的 payload ，查找它们的效率也会随之下降。我认为是不值当 ...继续阅读 (98)

我们的游戏引擎的 GameUI 使用的RmlUI。我的想法是用成熟的 CSS 来描述 UI 的呈现，借鉴 web 前端开发的方法来制作游戏的 UI 。但我不想嵌入太复杂的 Web 渲染引擎，而且游戏的需求也会有所不同，所以我选择了轻量的 RmlUI 。同时，为了和游戏的开发语言一致，我们使用 Lua 而不是 javascript 来控制 CSS 。在使用 RmlUI 的过程中，一开始我们尽量和上游保持一致，修复了不少 Bug ，并合并到了上游。后来发现我们有很多需求和上游不同，需要大刀阔斧的做一些改动，所以就 fork 了一个自己的分支。最重要的两个改动是：第一，完全实现了 Lua Binding ，因为原有的实现非常低效和复杂，很多接口设计不合理。做大规模的接口变化必须破坏向前兼容，这是我们 fork 分支的主要动机。第二，废弃了 RmlUI 自己实现的排版模块，换成了 Facebook 维护的Yoga。迁移到自己的分支上后，我们陆续对 RmlUI 的代码进行了不少重构。最近，发现了 RmlUI 原有的一个 Bug ，有时修改了一个 css 节点属性后，会影响另一个不相干的节点的属性。仔细研究后，判断这是它固有的设计失误造成的。我们知道，css 非常灵活，每个节点的属性都可以被很多数据源影响。如果我们不做任何优化，推导一个节点上的属性会是一个相当昂贵的操作。所以，必须对其做一些缓 ...继续阅读 (87)

我们引擎中使用的数学库已经修修补补很久了。期间积累了很多想法。最近在对引擎做性能优化，把一些找到的热点系统用 C/C++ 改写，顺便就重构了一下数学库，让它更好的兼顾 Lua API 和 C API 。上一次对数学库的改进是三年前的事情了。这三年的使用，我们发现，基于一个栈的 DSL 虽然可以减轻 Lua 和 C 之间的通讯成本，但是使用起来并不方便。大部分时候，我们还是倾向更传统的接口：一次数学运算调用一次函数。而高复杂度的数学运算完全可以放在独立的 C 模块中完成。结合 ECS 系统，我们可以在 C side 集中批量处理相同但数量巨大的数学运算。我们在很早以前就放弃了原来设计的 DSL ，只使用数学库的部分功能。趁这次重构，我打算把这些已经废弃的部分彻底删掉，并重新设计底层的数据结构，让它能更好的适应其核心特性。我认为我们的数学库最核心的特性是：所有的数学对象，包括矩阵、向量、四元数都是不可改写的值对象，有一致的外观。我将它表达为 64bit 的 id ，这样方便 Lua (或别的语言）binding 。做 Lua binding 时，数学对象 id 是一个 lightuserdata 而非传统库用的重量级的 userdata 。这样用起来的代价和普通的数字相比，并无明显的额外负担。即使不在 Lua 中使用，直接由 C/C++ 运用时，一个 64bit 的 id 也好过更大 ...继续阅读 (102)

我们的游戏场景是由若干场景节点构成的，每个场景节点是一个 Entity 的 Component 。而一个复杂的场景可以在编辑器中生成一个预制件 Prefab，像搭建乐高积木那样堆砌已经做好的部件。关于预制件的设计，之前有过两篇 blog 讨论。分别是：游戏引擎中预制件的设计和预制件和对象集的管理。就目前的使用经验来看，几乎所有游戏中的 Entity 都是从 Prefab 实例化得来的。一个 Prefab 会实例化出 n 个 Entity ，但这 n 个 Entity 的生命期管理却很麻烦。最自然的想法是：所有的 Entity 都必须是场景树上的节点（拥有场景组件），当我们删除一个场景节点时，它所有的子孙都一起移除。这个做法有两个问题：如果一个 Entity 被间接移除（祖先被删除），持有它的引用该如何处理？传统的方法是，只能对 Entity 保持弱引用。一般用 Entity ID 作弱引用。我们在对 Entity ID 解引用时，应检查引用是否有效。有些 Entity 未必是场景节点，但也需要合理的自动化生命期管理怎么办？传统的方法要么让所有的东西都必须是场景节点，要么把这个东西变成场景某个节点的一个组件附着在场景节点上。我不喜欢上面提到的传统解决方案。因为：生命期管理和场景管理其实是两件事。场景管理是按树结构组织的，而生命期管理更适合用集合这种结构。所有需要被管理的东西不应该都必 ...继续阅读 (92)

前段时间我们给引擎增加了对象分组的功能。做这个特性的动机是当整个游戏世界中的对象数量远超同时需要处理（显示）的对象数量时，有一个快速筛选出待处理代码集合的机制。在使用过程中，我陆续发现了这个特性的其它用途。过去的某个游戏项目中，曾经遇到这么一个需求：游戏中需要为玩家生成一个头像，这个头像是由很多部分构成的。有玩家的肖像、名字、等级、修饰用的图标等等。这个头像可能同时在屏幕的很多位置显示。如果场景是一个简单的树结构，那么，每个出现头像的地方，都是一个构成头像元素的子树。这样，场景中就可能出现完全一样的多份子树。固然我们可以用一个通用接口构造这个子树出来，但是，一旦这个玩家的属性发生变化，就需要针对所有场景中出现的同类子树进行修改。这需要为每个玩家额外维护一个列表，引用所有头像在场景树中出现的位置。这无疑增加了数据结构的复杂性。一个自然的想法是，场景不再是一颗树，而是一个有向无环图。玩家头像在场景中可以出现在多处，但子树只有一份。这颗子树的根节点可以有多个父亲。这样，需要修改时，我们只需要改动一处。在 Ejoy2D 中，我实现了这个机制。但总觉得有些别扭，因为底层的数据结构还是变得复杂了。目前我们正在用新引擎开发游戏，遇到了同样的问题。我们在做一个类似异星工厂的游戏，里面有许多小细节。在许多场景元素（工厂、机械爪、运输无人机等等）中会挂接一些小元件。玩家可以看到这些小东西在游戏中的流动 ...继续阅读 (100)