在马山攀岩的最后一天，异星工厂的太空时代扩展包发售了。回到家中就开始玩，肝了 300 个小时，前天晚上终于通关了。准确说是系统告诉我赢得了游戏，但我知道后面还有很多事情要做。和原版一样，虽然发火箭名义上赢得了游戏，但白瓶科技是在火箭之后才有的；这次抵达了星系边缘就告诉我赢得了游戏，但钷素科技包（黑瓶）的原料都没见到。不过，我得暂时放一放，最近在这个游戏上花掉了所有时间，都没做别的事情。先写一篇总结，最近的体验太多，需要记录一下。不然热乎劲过了就忘了。虽然太空时代最精彩的部分在五个风格迥异的星球，让玩家体验不同的方式玩这个游戏。但我想先谈谈 2.0 在基础系统上所做的工作。去年我们做 Red Frontier 时，我就想去掉玩家操控的角色，以上帝视角来玩游戏。虽然过去异星工厂也有 Brave New World 这样的 Mod ，去掉了玩家角色，但所有的操作都是通过无人机完成的。我试过一下，相比有玩家角色，它的操作并不舒服。虽然在游戏初期，操作一个 Player 在地图上跑来跑去有点烦，但真去掉了这个 Player 反而不知道游戏该怎么玩了。我觉得是因为通过无人机下达指令，反馈不够即时，这有点像 RimWorld 或缺氧那样控制工人间接完成任务，玩起来总有点别扭。而操控 Player 虽然有跑路的烦恼，但同时也限制了同一地点能做的事情。在同一时间，玩家的选择变少了，精力可以聚焦在有限 ...继续阅读 (1)

最近去了一趟南宁马山县。攀岩一周，身体很累，心里很舒服。这周除了爬石头，什么都没想，脑子全部放空了。“一款好游戏，胜过两款伟大游戏”…… 这世上最容易做的就是“多”，如果我们不小心，就可能会把三四款游戏都塞进一个游戏里。有时候，决定什么内容不该加到游戏里，比决定什么内容该加进入更加总要。—— 《席德梅尔的回忆录》这几天，读了本书《席德梅尔的回忆录》：《文明》是在陪产假中诞生的，它一开始更像是《铁路大亨》的延续，一个全球规模的《模拟城市》，一个实时模拟游戏。它开发了很久都没有找到正确的方向，一度项目被搁置。而重新继续这个项目后，经过了搁置期的思考，才试着将其改为回合制游戏。席德还有款失败的作品《恐龙游戏》，他从 1991 年开始鼓捣这款游戏的原型，到 2000 年第 6 届 E3 展后彻底放弃。一开始几个版本像是恐龙版文明，核心玩法是基因衍化，但随机基因突变并不好玩；其后简化了复杂的规则，却变得很无聊。“好像不是你在玩计算机，而是计算机在玩你。如果游戏要一下子表达太多东西，那简化游戏设计会有帮助；但如果你在一款回合制游戏上投入了足够多的时间，你就会希望能够控制所有有趣的决策”。回合制走不通，游戏原型转为了即时制。席德之前就有一款成功的即时制游戏《葛底斯堡战役》。但这个《恐龙争霸》却因为恐龙题材难以嫁接足够多的远程武器以至于无法平衡。然后，这款恐龙游戏又演化成了口袋妖怪，或是更接近恐龙 ...继续阅读 (7)

“首先，设计师创建了一些游戏机制。然后，他们把这些游戏机制用一些具有代表性的虚构元素包装起来。在游戏过程中，这些机制之间会产生一系列事件。这些事件会触动玩家潜意识中的触发器，从而激发出情感。最后，这些情感交织到一起，变成了一种综合的体验。” —— Tynan Sylvester 《Designing Games: A Guide to Enginerring Experiences》我非常认同 Rimworld 作者 Tynan 对电子游戏的定义：游戏是一种制造体验的人工系统。游戏用一种工程手段制造体验，目的是激发人类的情感。在《体验引擎》的书中论述，追踪情感的真正源头非常困难，因为情感的触发由大脑的潜意识处理，自动表达的。即使不知道为什么会产生某种情感，我们的理性还是会想当然的为之安排一个原因。这些想当然的原因往往是错的。这种现象被称为情感错位，因为情感错位的存在，想要了解游戏如何影响我们是十分困难的事情。我最近把游戏开发工作中的具体实现停了下来。因为我意识到，游戏核心固然是设计一些机制，程序实现可以把这些机制做出来并加以测试，但游戏机制只是手段而不是目的。我对游戏设计的理解还不够，所以还需要继续以设计游戏的角度去挖掘游戏深层次的东西。以游戏爱好者的角度去玩那些好评如潮的游戏体会游戏带来的乐趣是不够的，还需要多玩一些毁誉参半但制作者有自己想法的作品。当然，还需要回避一些仅仅是把已 ...继续阅读 (14)

这个月没有写什么程序。月初停下手头的开发工作，花了一周时间，作为 Indieplay 评委试玩了 200 多个参选游戏中的 100 多个。这个工作暂停之后，我就对前两个月对自己想做的游戏产生了许多疑惑。虽然写了不少代码，但仅限于基础玩法的外在功能：我实现了一整套类似边缘世界和缺氧里的工人系统，让小人可以在场景中活动起来，采集物资，建设建筑。让机器可以通上电运转起来，把原料加工为成品。但这些似乎只是一种模拟过程，而并非游戏。我感觉自己对游戏到底想展现怎样的游戏体验没有清晰的认识。虽然在这篇采访中也提到，（缺氧的最初设计是）“希望整个游戏运行在一个开放的（虽然简单的）模拟之上”。但我觉得模拟毕竟不是游戏，难以给玩家提供丰富的游戏体验。或者说，至少对于我这样的玩家，没有清晰的游戏目标和挑战是不行的。而且，实现一个丰富的游戏环境模拟面临的挑战我现在还无法评估，至少在当下，这不是我优先想做的东西。我给游戏定下的基调是基地建设加生存挑战类型，或许应该有一些资源管理和 Roguelike 元素。工人管理或自动化元素是我比较喜欢的，但玩过几千小时类似游戏后，我感觉这些元素只是给予玩家体验的一种手段，并非目的。单独玩某个特定玩法，或许也能有趣，但体验却会大相径庭。比如，我这个月花了不少时间玩 Shapez 2 。这是一个把自动化做到极限的游戏。玩家不再需要考虑能源、制造成本等问题，也没有敌对势力，只 ...继续阅读 (11)

我独自开发游戏已经有三个月了。这三个月里，我是 Ant Engine 唯一活跃用户，这是一个很好的机会来挖掘对于一个独立游戏开发者来说，引擎哪些地方有缺失。现阶段，我还是希望把精力放在游戏开发上多一些，所以引擎方面恰恰够用就好。虽然，完善引擎这件事做起来会更愉快，因为这些工作对于我比较顺畅，容易想清楚，游刃有余；而一个人开发游戏，更多的时候是手跟不上心而产生的烦闷。我还是想挑战一下自己，把游戏设计好，实现好。引擎方面的事情，把想到的东西先记录一下。或许完成手头的游戏项目，沉淀更多，再回头做引擎，愉悦感更强一些。首先，可视化编辑器对我来说不重要。所以暂时就不维护了。我更需要的是一些快速验证眼下游戏设计中想法的功能，这些就在游戏 demo 中顺带实现就好，看起来没必要放在编辑器里。这和现阶段没有美术参与也有关系。因为对我自己做独立游戏来说，我不在乎开发进度，先做美术还是后做美术，区别不是很大。本来我自己就喜欢传统 roguelike ，几个 ascii 字符就能脑补所有的美术表现。我想，游戏原型阶段就不需要美术在编辑器里做创作了，用一些几何体就够用。这也是为什么我在三个月前最先完善的就是Ant 引擎中预制几何体这个功能的原因。我在使用 Ant 引擎的时候，发现因为缺乏具体 API 文档而只能不断的阅读源代码（毕竟有很多模块不是我自己动手写的，无法全部了然于心）。而且并非每个模块的设计都 ...继续阅读 (43)

我在用 C 构建项目，尤其是和 Lua 混合使用时，一直很头疼 C 没有一个统一的模块管理器。Lua 的模块管理虽然简单，但毕竟有且够用。一种方法是把 C 模块封装成一个个 Lua 模块，让 Lua 帮助管理，每个 C 模块是独立的，相互不可见。但当 C 模块之间发生关系时，就比较麻烦。当然，简单的方法是通过链接器把它们都链接在一起，通过函数名前缀以区分。或是利用操作系统的动态库加载器来管理模块。最近有了一点有趣的想法，觉得一个最简的模块管理器其实复杂度并不高。花了半天功夫实现了一下，感觉还不错。https://github.com/cloudwu/cmod/我在设计时，刻意回避了使用 macro 魔法，让它的接口保持原始的 C 风格。而且，实现上也不依赖任何内存分配函数，整个管理器需要的内存是一开始由调用者分配好一大块传入的。这个管理器只管理函数指针，刻意没有去管理其它状态（比如类似事务、COM 管理的就不只是函数接口，还保留对象实例），但还是为每个管理器实例留有一个 userdata 指针，供使用者扩展。其中的 import 函数，也就是通过字符串查找对应的模块，使用的是简单的 O(n) 遍历所有已注册模块的算法。如果接下来有性能需要的话，我会再加一个 hash 表做一些简单的 cache 。 ...继续阅读 (25)

我倾向于在 C 程序里使用整数 handle ，而不是指针。尤其是需要做弱引用的时候。我认为，一个好的 handle 生成算法，应该满足：即使 handle 被销毁了，它这个数字也应该被保留，不应该被新的 handle 复用。posix api 里的文件 id 就不符合这一点。提供一个 api 可以判断一个 handle 是否有效，其时间复杂度为 O(1) 。从 handle 对应为对象的内存地址的时间复杂度应该为 O(1) ，不应该比指针有明显的性能问题。虽然 hash 表理论上可以满足 O(1) 的时间复杂度，但在糟糕的场景（hash 碰撞发生时）并不能保证这一点。构造 handle 时间复杂度也为 O(1) 。handle 的数字位宽最好不要超过 32 bit 。如是长期运行的程序，第一和第四个需求不能同时成立。但对于非长期程序，理论上 32bit 的数字应该是够用了。比较简单的实现方案是用一个自增 id ，然后用一张 hash 表来保存 id 到指针的映射。但 hash 表不是严格的 O(1) 复杂度。在 skynet 中，我使用了一个简单的方法：自增 id 后，如果发现 hash 冲突，就再加一，直到不冲突为止。这个方法不能满足第 4 点需求。当然，同时满足 5 点需求未必有多大的意义，但我最近想到一个有趣的方案，稍微实现了一下，感觉可以做到。前提是：为了让 32bit ...继续阅读 (39)

这两天思考了一下，基于工厂生产的基地建设类游戏给玩家提供的核心体验到底是什么？以及，我们去年被取消的游戏到底还差点什么。接下来我要制作的游戏的注重点应该在哪里。我玩的时间比较长的两个基地建设类游戏：异星工厂和缺氧，它们的玩法其实差异很大，但却给人一些近似的体验。对于这个问题，我想过很多次，得出的结论是，它们的确有一些共通之处：玩家在玩这两个游戏时的情感体验过程非常类似，大致是这样的：玩家开始了解基本规则。对于异星工厂来说，就是采集原料，生产加工，生产科技瓶，推进科研发展；对于缺氧来说，是建造设施用来提供小人的各种生存所需，不要让他们死掉。让玩家了解游戏的终极目标。这通常是建设一项宏伟的工程。异星工厂和缺氧的原版目标，不约而同的都选择了制作并发射火箭逃离所在星球。玩家根据完结游戏的目标和已经了解的游戏规则，在心里做出通关（或是解决阶段性目标）的计划。玩家在实施计划的过程中遇到挫折。这通常是发生了一些未曾预料的意外。这个意外并不是系统额外强加进来的，反而是在已透露给玩家的规则下合理发生的。所以，玩家会觉得是自己对规则理解的不够，而不是来源于设计者的恶意。玩家修正自己的计划，重新理解游戏系统。如果挫折时由游戏规则内在随机性带来的（缺氧中略微多见），玩家学会应对这些随机性，随之增强自己对抗游戏的自信；而异星工厂（尤其是关闭战斗后）是一个无危机的游戏。但还是会随着自己管理的工厂规模变大，需要 ...继续阅读 (28)

游戏行业从业 20 多年，一直在做底层开发，即使是帮助其他团队写上层游戏逻辑，也都是实现某些特定的功能模块。直到最近，我想单独开发游戏，才好好想想架子该怎么搭。从最初的原始 demo 开始，由于缺乏经验，写着写着经常有失控的感觉。好在一个人做，重构的心理负担不大。想改的时候，停下来花上两三天全部重写也不太所谓。最近总算顺畅了一点，感觉需要整理一下思路，所以写一篇 blog 记录一下。任何复杂的软件问题，都可以通过拆分为若干子问题减少复杂度。我认为，游戏的上层逻辑，即 gameplay 部分，主要分为三块：数据模型、外在表现和人机交互。“数据模型”是 gameplay 的核心部分，即把游戏的画面等外在表现以及图形界面、操作控制（鼠标键盘控制器等）等剥离后的东西。如何判断一个模块是否属于数据模型，是否有不属于它的部分没有拆分出去，最简单的方法是看它是否有直接调用游戏引擎的代码。拆分干净后，这块不应该包含任何与图形、界面、时钟、控制输入有关的接口。除了一些必要的文件 IO 接口（主要是用来读取 gameplay 相关的策划数据，写 log ，做数据持久化等），也不应该涉及任何 OS 的 API 。这样，我们就可以方便的对它进行整体或局部的测试。必要时还可以更换游戏引擎，甚至从文本 roguelike 换到 3D 表现都不会受影响。“外在表现”当然是指游戏的画面表现、声音声效等等，通常这 ...继续阅读 (23)

在矮人要塞 like 的游戏中，都有一套基于工人的任务分发系统。玩家通常不能像 RTS 中那样直接操作工人去工作，而是对要做的事情下达任务，等着工人自主去完成。由于任务数量通常远多于工人数量，这个任务分发系统中大多配有优先级设置，可以让诸多任务有条不紊的进行。调整优先级变成玩家主动操控的渠道。初玩这类游戏，会有点不习惯：感觉难以在微观层面直接做自己像做的事情。像捡块石头放进指定仓库这件事，无法像玩 RTS 游戏那样，先点选工人，再针对石头发出拾取指令…… 但习惯之后，恐怕又回不去了。比如我在玩 Ratopia 时，就对操控鼠王直接干活烦躁不已。这类游戏，我玩的时间比较长的有三个，按时长排序为：缺氧 (ONI) 、边缘世界 (Rimworld)、矮人要塞 (DF)。其它如 Songs of Syx 、Prison Architect 等很多也有所涉猎。其实，这些游戏在设计工人任务系统的细节上也有所不同。以我游戏时长最长的缺氧和边缘世界相比较，同样是提供玩家主动操控的能力：Rimworld 可以给工人的任务队列直接下达指令（这更接近 RTS 的玩法），而 ONI 则是通过给单个任务本身排优先级实现的。ONI 设计了警报级任务，可以越过一切优先级设定，强制立刻完成。虽然 ONI 也保留了指挥单个小人移动到指定位置，但实际游戏中几乎没什么用。对于拾取物品，Rimworld 可以封禁、解禁单 ...继续阅读 (28)

像异星工厂、缺氧、边缘世界都有大量的 mod 。可以通过大改游戏机制，把本体游戏改造成完全体验不同的游戏。这些好玩的 mod 几乎都是一个人完成的。所以我觉得，固然游戏的外层玩法决定了整体体验，但其实开发的总工作量并不大。而且，一旦玩法不满意，也容易修改。我的游戏开发计划是先完成一些底层基础系统，再考虑完整游戏的全貌。没有上层玩法支撑，光有底层系统可能玩起来一定寡淡无味，但我认为它们是设计和开发中最重要的一环。在进一步实现 demo 之前，我设计了一下飞船的建造系统。游戏世界中的物质分为三种：建筑，零件，原料。摆放在场景中（飞船）的是建筑，墙体、门、机器、家具这些属于建筑，一旦修建出来就不可任意移动位置。建筑是由零件构成，拆毁建筑会 100% 返还零件。建筑修建是可逆的。零件是由原料在机器中合成出来，这部分和异星工厂相同。并不一定存在逆向的合成配方。例如，铁板可以合成铁丝，但铁丝并不一定存在变会铁板的方法。所以和建筑不同，加工零件可能是一个不可逆的过程。飞船（场景）是由四边形网格构成。每个格子永远只能容纳一种物质，要么是建筑的一部分，要么是一种零件。而原料无法直接存在于场景格中，它们必须存在于容器里。建筑和工人都可以是容器。工人可以在场景格的过道中移动，工人之间不设阻挡。没有建筑的格天然称为过道，部分建筑会占据场景格，成为障碍物。有些建筑将所占据的部分场景格保留为过道。例如门。每种 ...继续阅读 (38)

在设计飞船建造的游戏时，我想做一个空气流动的模拟系统。这里有一个初步的方案，不知道好不好，先记录一下：空间是由二维的正方形格子构成的，有些格子如墙体会阻止空气流动。每个格子有温度属性及气体质量的记录。不同气体可以同时存在于同一个内，质量单独记录。温度传导系统另外设计。每个游戏 tick 对每个格子做一次独立计算，根据温度值给出一个概率，这个概率决定了该格气体向周围扩展的比例。温度越高，越可能将更大比例的气体平均扩散到最多邻接的 8 格空间。当格子因为建墙而导致空间变化时，把该格内气体全部扩散到临接格，当极端情况下无法做到时，空气锁定在墙体内，不会消失，等待以后满足条件后再扩散出去。为什么要做基于格子而不是基于舱室的空气模拟？例如， FTL 的氧气气压模拟就是基于房间的。因为，这个模拟需要结合游戏本身其它玩法的需要。预计之后会做气闸舱，真空室等设定。需要有一个更微观的空气流动模拟，简单的给船舱加上气压的数值是不够的。和 FTL 不同，我希望做一个基地建设风格的游戏，舱室的结构是动态的，难以以房间为单位计算。目前有气体流动模拟的游戏中，最流行是缺氧。为什么不直接使用缺氧的模拟系统?缺氧的基本规则是：每个格子只能有一种物质，这种物质可能有三态：固态、液态、气态。物质会因为温度发生三态转换。不同形态的物质属于不同的东西，每一格不能混装。特殊情况下，气体会直接消失。气体倾向于从高压格流向临近 ...继续阅读 (38)

Ant 引擎的角色动画系统还需要完善。之前我们用 Ant 引擎开发的游戏以机械装置为主，所以并不需要人型角色动画。对于人物角色动作的动画控制，最好有更多的引擎支持。通常，角色逻辑上的属性和动画表现存在一个映射关系。一个角色，它逻辑上的基本属性可能只有在空间中的坐标。我们编写代码控制它时，只关心它在哪里。但是，在做画面表现时，则需要根据空间坐标这组简单属性，转换为动画播放：如果角色静止不动，就播放 idle 动画，如果正在运动，就播放 walk 动画。在引擎底层，每帧只通过坐标这个属性来计算角色该播放哪个动画以及怎样播放，信息是不够的。通常还需要结合过去时间线上的状态变化来推算出当前状态；或是通过几个独立的逻辑属性的组合，得到动画需要的信息。例如，可以通过空间坐标的变化过程计算出速度；根据是否处于战斗状态决定是警戒行动还是自由行动……这种从逻辑属性数据到表现用数据的映射关系，一般使用状态机来实现。Unity 文档对此有一个很好的描述。通过这个状态机，可以生成动画系统底层每帧需要的数据，而开发者只需要简单修改逻辑上的基本属性即可。动画系统底层看到的是 Entity 当前状态下用于动画渲染的基础数据：一个动画片段的当前帧，或是几个动画片段的加权混合。而状态机只用运行当前帧的当前状态关联的转换逻辑去加工那些基本属性输入。因为状态机永远处于单一状态，但对于动画来说，从一种状态到另一种状态通常 ...继续阅读 (48)

因为玩了一些星舰或太空站建造类的游戏，找找灵感。每个游戏都能给我一些启发，因为玩的都不多，所以就不评价了，只做个列表记录，排名不分先后。有些还没有出，先加了个愿望单。CosmoteerSpace HavenStardeusThe Last StarshipFacteroidsAstro ColonyStarsectorRimworld mod : Save Our Ship 2Factorio mod : Space ExplorationFactorio mod : Warp Drive MachineOxygen Not Included DLC: Spaced OutSpace ArchitectStarship TheoryStationeersOstranautsStarmancerSpace SlogThe CrustDeep Space OutpostStarshop ColonyRionag: Survey FleetGeneration ShipAdaptoryFar SectorGeneration Nova ...继续阅读 (39)

我正在制作的游戏 demo 中，所有对象逻辑上都存在于二维空间，但在 Ant Engine 中通过 3d 渲染方式绘制出来。我希望有一组简便的 API 方便我控制这些对象的渲染，只是控制它们的位置以及在 Y 轴上的旋转量。Ant Engine 是用场景组件来控制 entity 渲染时的空间状态，但场景节点使用的是 3d 空间的 SRT 即缩放、旋转、位移。而我只需要控制其中的两个坐标轴上的空间位置以及一个旋转轴上的旋转量，直接修改 SRT 太不方便了。而且，使用引擎时，还需要每帧标记被修改过的场景组件对应的 entity ，这也很麻烦。在 ECS 结构下，最简单的方式是为这些 entity 创建一个额外的组件，里面有 x y r 三个值。通过一个 system 把它们转换到场景节点在 3d 空间下的 SRT 组件中。但如果每帧都全部转换一次显得多余，毕竟大部分 entity 不是每帧都会发生变化的。我用了一个简单的 Lua 技巧来方便开发，下面便是代码：local monitor = {} local function new_type() local changes = {} local function touch(obj, k, v) local raw = obj.__raw changes[raw] = true ...继续阅读 (52)

宅在家里一个月了。一直在想，如果不考虑迎合市场，不顾及销量，到底应该做一个怎样的游戏才能让自己在制作过程中得到满足。过年前曾经参加过一次老同事聚餐。组织者说，这屋子坐的都是做游戏的老人了，程序、策划、美术全齐了，还都是不差钱的主。大家要不要凑个局，想想做个啥游戏出来？接下来是一阵沉默，直到有声音说，“我没什么想法”，饭桌上的人纷纷点头，转移了话题。前段参加一个独立游戏活动，见了些老朋友。有位同学做游戏很多年了，说起这些年的经历，入行头几年是给老板打工，接下来开了家小公司自己做，没赔钱也没赚钱。但干下来感觉变成了给员工打工。为了可以持续发出工资，每次立项都很匆忙，结果还是在不喜欢的游戏项目上耗掉了太多时间。现在干脆把团队安顿好，一个人出来，好好想想到底要做什么。可见，想清楚做什么很难。单独一人的状态也很难得，没有太多的外界干扰，不为了做事而做，可以慢慢来。首先，我想做一款游戏，这毋庸置疑。玩游戏是我这些年最大的爱好。光在 steam 上这些年就花掉了上万小时，switch 上也有几千小时。我能在制作游戏的过程中获得我要的东西。其次，做一款游戏的目的不是为了收入。我对物质生活要求极低，不需要花钱满足欲望。除非需要雇人一起做游戏，不然制作游戏的开销只是自己家庭的日常开销，而我这些年的积蓄已够过完余生。我喜欢的游戏都不需要太复杂的美术资产，这方面并不需要额外的投入。另一方面，我也不需要用游 ...继续阅读 (33)

这两天着手做游戏 demo 时发现Ant 的 Asset管理模块之前还留有一些工作没有完成。那就是，当游戏程序加载 Asset 后，资源管理模块何时释放它们的问题。在 ant.asset 模块中，我们为每种 asset （以文件后缀名区分）定义了 loader unloader reloader 三个接口，分别处理加载、卸载、重载的工作。但在实际实现时，几乎都没有实现 unloader 。当时是偷懒，因为我们之前的游戏即使把全部资源都加载到内存，也没多少数据，并不需要动态卸载释放内存。而即使实现了 unloader ，管理器也没有实现很好的策略去调用它。只能靠用户主动调用卸载 api 。事实上，一个个资源文件主动卸载也不实用。考虑到占用内存最大的 asset 是贴图，我们又对贴图做了一些特殊处理：所有的贴图都可以用一张空白贴图作为替代。引擎有权在任何时候（通常是内存不足时）主动释放长期未使用的贴图，并换用替代。这个特性也可以很好的适配异步加载过程。所以，未释放的贴图并不会撑满内存。今天在查看引擎的预制形状相关的 API 实现时想起，我们对一些预制的模型，又有一些特殊处理。预制模型，例如平板、箭头、方块等，通常在调试或写一些简单 demo 时使用。它们不是从 asset 文件中加载而来的，而是通过一些代码直接填写顶点数据创建出来。所以，这样的网格数据（mesh）并不在 entity ...继续阅读 (62)

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

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

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

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

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

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

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

这两天在改 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 ...继续阅读 (76)

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 。看起来还是挺炫酷的。但仔细一看，项目不太活跃很久没更新了。翻了下实现，也就几百行代码，花了半个小时就懂 ...继续阅读 (69)

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

我们游戏 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++ 对象。这个对象可以方便的 ...继续阅读 (82)

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

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