如何评价游戏引擎 The Machinery? 第1页

先说优势：

1.这款引擎的代码是用 98.9 % 的 C 和 1.1 % 的 C++ 来写的（实际上 C++ 除了第三方的插件占了4 个文件，真正属于引擎自身的只有一个 jobsystem 用到的 mpmc queue 用了 C++），所以有 C 语言的一大优势：编译速度很快。30s 内就可以编译出来。相比其他的引擎这点就很让人感激涕零了。

2.从 2017 年开始迭代到现在，基本上给出了一套如何用 C 语言来实现一个接近商业化的引擎的最佳实践，包括编辑器的部分，用 27k loc 的代码（不包含渲染部分）实现了一套 imgui，并在 2020 的 GDC 上予以了讲解:

回顾了之前 bitsquid/stingray 用到的各种编辑器 ui 技术栈，从 winform/wpf/Qt 到 Web 相关的技术都用过，最后到了 TheMachinery 决定自吃狗粮撸一个 imgui 的心路历程，选择 imgui 是因为 ui 的代码和逻辑在一起易于阅读和查错；每帧实时刷新不需要专门的布局系统，大概是这两个主要原因。不过具体这套 imgui 的实用度如何还有待研究。然后整个引擎是 plugin based，通过 dll/so 来进行模块化，就架构的解耦来说这样做让模块之间的 api 关系变得很清爽（不至于有一堆 singletons/managers 来指点江山激扬文字）。

3.对 Asset 的管理有一套 uuid 和 path 的 hybrid 方案，结合 CreationGraph，如果哪一天达到完全的形态应该能解决一些 2U 的 Library/DerivedDataCache 的问题。

4.实现了一套基于 TheTruth 为数据中心，fiber based jobsystem 进行调度的 ecs 系统，可以让引擎在 cache friendly 和 multithreading 方面达到最高效。

再说劣势：

1.最大的问题在于引擎的开发团队并没有用这个引擎来做游戏，所以实际上把这个引擎用来做游戏的时候，就会发现距离 Unreal/Unity 这样的久经沙场的引擎而言差距很大，无论是易用性还是稳定性，很容易崩溃。引擎的开发者是站在做游戏引擎而不是站在做游戏的引擎的角度来开发引擎的，至少现阶段如此。

2.完成度还是比较低的，缺少很多必要的功能，比如脚本语言，虽然有一个名为 EntityGraph 的可视化编程，但是实用度还远远不够。

3.现阶段只支持 windows/linux， 因为 render backend 只有 vulkan，记得有一次看 issue 上说的因为代码偏好的原因也不准备用 MoltenVK 来支持 Metal 这种方式，所以短时间是没法支持 OSX 的，至于 mobile 的支持好像还远远没有到考虑的时候。

4.生态比较难以建立，主要还是因为人少，最开始就两个大哥，开发了三年加入了一个大哥，然后又来了三个小弟，所以开发的进度和力度都不太够。需要更多的时间。

总而言之在技术方面是个不错的引擎，让我学到了不少 C 语言里面有用的东西（比如 Struct and union initialization(designated initializer) + compound literals ）。但是用来做游戏还是为时过早。

官方正在逐步的把文档汇集到一起： Tutorials · Our Machinery 里面包含一些使用实践。

这份 coding/designing guidebook 有许多 practical guidelines ，从 c/c++ 代码规范，设计准则到 git 的使用，网页版没有及时更新，可以下载引擎 然后到 ourmachinerydocguidebook.md.html 里看最新的

另外 7月7日开启了早期采用计划：Early Adopters Program · Our Machinery 可以花 50 刀获取到代码（GitHub private repo 的 access 权限），可以配合官方 博客 食用。虽然有代码也不代表着引擎可以用，但值不值就看各人了。