云风的 BLOG

这是个几年前在搭框架的时候就已被估算出来的限制。我们精力有限，一直没有去解决。毕竟用 Lua 快速开发更有优势，而如果在 PC 上做原型，又对性能不那么敏感。

大约 2022 年 5 月左右，我们开始着手把日常开发迁移到真实的手机平台上，性能问题才彰显，便开始实施一再被推迟的相关重构计划。

主要是把整个材质系统的数据结构搬到 C side ，Lua side 只负责创建和修改材质，渲染则完全放在 C side 。中间的桥梁还是 luaecs 。

一开始是整理 Lua 中的数据结构，让它们更平坦化，这样方便迁移到 C 中。然后我写了一个 C 版本的材质数据结构，主要是管理弹性的 Uniform 。于此同时，根据需要重构了数学库 。这个版本依旧保持了 Lua 和 C 都易于访问的接口。生命期管理还是放在 Lua 里，但 C 已经可以绕开 Lua 接口直接读取其中数据并调用对应的图形 API 。

然后，我们用 Lua 重写了应用材质的 system ，在重写过程中，提取出真正的热点：那些需要反复调用的函数。最后把核心部分用 C 代码重新实现。这个工作断断续续做了几个月。难点在于按 ECS 的思路做拆解，让 C side 的核心 system 只做非常简单，工作量又很大的事情。

上个月还做了最后一次调整，给数据结构增加了一点弹性：因为我们发现一个可渲染对象在不同的渲染流程中会用到不同的材质。比如有正常的渲染流程，也有阴影渲染，还有点选系统。这些固然可以固定在引擎中，但具体游戏还会有特殊的定制要求，例如半透明、沟边、以及各种奇特的视觉效果，都可能需要引入新的 Uniform 。

增加数据结构的弹性在纯 Lua 或纯 C/C++ 中都不是难事。但对于两边都需要访问时，复杂度的增加是让我警惕的。luaecs 这一年的发展中，我也时不时的增加一些花俏的特性，然后又删除，就是不想让结构变得过于复杂。

最终，我发现我们可以利用 Lua 的动态性更好的解决问题。即，在运行期间数据结构都是固定的。一共用几个 Uniform ，它们叫什么名字都是确定的。但是我们可以在启动时，充分利用 Lua 的动态性进行组装。最后在 C Side 看到的还是一个固定大小的数组，但大小本身并不编译到 C 代码中固定下来。

其实，即使不做这些优化，1K 左右的可渲染对象对于很多场合也还是够用的。但我们的游戏却是个例外，这驱使我现在就去解决这一系列性能问题。我们这个仿制 Factorio 的游戏，有着大量的细碎物件：在公路上奔跑的小车，除了车体外，我还希望车斗内不同的货物也能用模型直接表达出来；仓库里的货物也能直观的在场景上看到。

为了尽可能的合并同类可渲染对象，我们拓展了引擎的挂接系统。针对具体项目，小车被特殊实现了：车斗内的货物并不直接挂接在车的节点上。因为空车都是同一模型，而车内的货物却千奇百怪。货物和车平级对待更容易被优化。货物和车之间仅仅是空间上的平移、并不需要涉及复杂的 3D 变换。货栈内的货物也是一个道理。

对于建筑，我希望它们可以像 Factorio 里面那样生动。我们为几乎每个建筑都制作了生产动画。但 Factorio 是基于 2D 制作的，动画仅仅意味着更多的内存占用，在内存中存放更多的序列帧就够了。我们现在基于 3d 制作，动画是基于骨骼系统的。如果有 10K 量级的骨骼动画，在手机上运行也是不小的开销。尤其是带动画的模型很难做 instance 合并。

我考虑过把骨骼动画全部烘培出来，全部当成静态模型渲染。但经过一些（空间开销的）估算，我放弃了这个想法。

在 Factorio 中，工厂会根据生产效率不同让动画以不同的速率播放。本质上，Factorio 是基于内在 tick 逻辑驱动的，每个 tick ，工厂要就在运作，要就停工。而它本身就是帧动画，选择画哪一帧的图就够了。3d 骨骼动画无法简单的按帧驱动。但我们可以换个思路。

其实，玩家所关心的工厂工作状态无非四种，正常工作、缺点停工、原料供应不足停工、产出拥堵停工。这些状态只要用不同颜色的灯带形式体现在模型上就够了。比动画表现更易读。（Factorio 有个 Mod 就是进一步改进这一点的）而动画表现只需要体现全速工作、效率不足、完全停工三种状态。我们不应该局限在 Factorio 已有的思路中，遵循它 2d 表现的逻辑：工作效率越低动画播放越慢。而可以制作做最多三套不同的工作动画：全速、半速、停工。从制作层面，后两种动画可以通过调速直接从第一种生成出来，也可以单独制作。但我们最终保证动画周期是一致的，且第一帧是重合的，可以在一套动画播放完毕后衔接其它任意一套。

而游戏中，只需要统计最近一个动画周期工厂的工作状态，统一播放下一个周期的动画就可以了。虽然动画比实际工作状态滞后一个动画周期，但视觉上是可以接受的。所有相同建筑在同一工作状态下，播放完全一样的动画，也可以简单的把它们 instance 化，一次全部渲染出来。

游戏画面的流畅不仅仅在帧率。如果方法得当，30fps 足够让人感觉流畅。对于我们这款游戏，我认为核心在于两点：1. 玩家在移动浏览场景时要足够流畅。2. 场景中移动物件的移动过程要流畅。

而我们游戏逻辑，其实是跑在一个较低周期下的（以节约手机的运算性能）。以 Factorio 的视角看，在手机上我希望确保 30fps 但 ups 运转在 30 fps 以下。我们的具体玩法和 factorio 不同，应该 10 ups 就够了。也就是说，对于第二点中的移动物体即车辆在行驶时，其实它们的轨迹是离散的。但为了让视觉上保持流畅却不可以让它们在场景中跳动。这就需要做一些额外处理。

当游戏跑起来，场景中会有几十甚至上百的小车在公路上行驶。如果这些额外处理全部交给 Lua ，也有一定的性能开销。不过这可以很方便的在 C side 实现。我们还是允许视觉上的物体位置和逻辑上的位置有一个滞后，在 C 代码中，可以通过 ecs 把这些小车都拣选出来，根据历史和目标位置，插值出每个渲染帧。