我第一次认真工作的游戏。六个月过去了，网页版已经上线，iOS版本已经发布到应用商店，桌面版正在早期测试阶段。

去年我在Ask HN上发帖寻找游戏开发资源，因为我之前从未开发过游戏。这个项目中的一些内容都是从那里获得的。

我在早期做出的最重要的技术决策是共享引擎，而不是前端。

渲染器仍然是平台特定的。网页版使用Three.js和WebGPU，iOS版本使用Metal，桌面版使用wgpu和Slint。但是， voxel mesh 的代码是使用Rust编写的，并且在三个平台上编译。

这部分是正常的。

我低估了让其在所有平台上保持可预测性的成本。

一个CI门控将 mesh 输出字节的哈希值在Linux、macOS和wasm上进行。 如果一个块在一个目标上 mesh 不同，PR就会失败。目标是让在iPhone上构建的块和在Chrome上构建的块具有相同的字节。

一些东西比我预期的要早就打破了这个目标。

HashMap 的迭代顺序改变了输出字节。

当顺序改变时，浮点数减少产生了不同的结果。

LLVM/vectorization 重新排序打破了字节身份。

激进的优化设置必须被回退并固定。

平台特定的假设不断地渗透到应该共享的代码中。

这些并不是无法解决的问题。 但是，每一个都变成了一个多天的陷阱。

我将从下一个游戏中吸取的教训是：

跨平台共享引擎架构可以在长期内是正确的，但仍然是错误的首要决策。

如果我重新开始，我会先只发布网页版，证明游戏循环和玩家之间的互动后，再添加iOS和桌面。工程基础是值得的，但我在游戏循环被证明之前就已经为此付出了代价。

一个公共测试版本可以在这里看到，如果有人想看看跨平台一致性的玩家体验：

https://0.space

接下来的阶段是终于减少引擎，更多地关注游戏： procedurally 生成的生物群系，探索和采集。

任何人考虑这个路径的人都可以从中得到的教训：

  1. 一台引擎跨平台并不意味着一个前端。
  2. 可预测性成为一个产品要求，而不是一个nice-to-have。
    3.字节相同的CI可以捕获真实的错误，但也会带来很多工作。
  3. 在输出字节路径上禁止未排序的容器。
  4. 在支付整个跨平台税之前证明玩家循环。