游戏 UI 总是导致时间延误：在 Figma 中原型设计，在引擎 UI 系统中重建，审阅后再重建一次。Web 多年前就解决了大多数这些问题，因此我构建了一个运行时，能够将真实的 HTML、CSS 和 JavaScript 直接在引擎内渲染。不使用 Chromium，也不使用 WebView：运行时负责布局页面、执行 JS，并将绘制列表交给引擎。

我在这条路上学到的一些经验，供你在考虑使用 Web 技术做游戏 UI 时参考：

  • “HTML‑style” 并不是 HTML。大多数游戏 UI 库实现的是子集，通常只有 Flexbox。直到设计师使用 Grid、容器查询或 npm 包中的库时才会出现问题。支持真实规范的工作量最大，价值也最大。

  • 游戏中的 JavaScript 需要防护措施。主机和 iOS 不允许即时编译，所以脚本会提前编译为原生代码。每个 UI 还有脚本时间预算和分代垃圾回收，从而让 UI 不会阻碍游戏玩法。

  • 游戏玩法应该推送状态，而不是 UI 轮询它。一次 SetState("ammo", 25) 从 C#、C++ 或 GDScript 中调用，页面会响应，从而将每帧脚本工作量保持极小。

  • 游戏手柄导航必须自动完成。没人想手动为每个屏幕设置焦点：默认使用空间导航，必要时可覆盖。

  • 纹理内存会悄悄增加。UI 艺术体积大。按可见性流式加载图片并控制 RAM/VRAM 预算比任何布局优化都更重要。

  • 设计师都在 Figma 中工作。单向导入在第一次迭代后就没有用处：同步必须逐个属性合并，并保留设计师和开发者添加的绑定与导航。

  • 迭代速度是真正的收益。保存 CSS 并看到它在运行的游戏中，同时在真实游戏上使用 Chrome DevTools，这比其他任何东西都更改变了我们的 UI 构建方式。

我很好奇你现在的情况：
- 你现在的 UI 流水线是什么样子，哪里会出问题？
- 你会信任 Web 技术来实现已发布游戏的 UI 吗？你首先需要看到什么：性能、内存、主机还是可访问性？

免责声明：该运行时是 Mako UI，是面向 Unity、Unreal、Godot 和自定义 C++ 引擎的商业产品。我这里不放链接，以免打断讨论，但如果有人想看视频，我会在评论里放。