每个人都好！我的名字是伊利亚·朱尔本科（Illia Zhurbenko）。我是来自基辅（Ukraine）的独立开发者，目前就读于基辅航空学院的软件工程专业。过去两年，我一直在工作于一款名为Beyond The Cupola: ISS Simulator的游戏，以及构建其自定义引擎。

当我开始这个项目时，我做出了大多数开发者会认为疯狂的决定：从零开始编写一个C++引擎。这篇文章是关于我为什么选择了这个路径，项目的结果，以及我在路上遇到的意外事件。

我不知道这会有多难 — 而这就是问题所在

两年过去了，回头看，我终于可以看到我经过了多少次的学习、阅读和实践。它让我想起了乔治·丹茨格（George Dantzig）的故事 — 这个学生只是因为迟到了，误以为两个统计学问题是作业而解决了它们。有时，不知道某件事有多难是件好事。两年过去了，还是只是刚刚开始。

我的背景和为什么不使用现成的引擎

我经常被问到的问题是："为什么不使用Unreal或Unity呢?" 但要理解这个选择，需要一些背景。

我的游戏开发和编程之旅始于Minecraft的模组开发。 我喜欢建造复杂的模组包，这逐渐发展成我想写自己的模组并把自己的想法带到生活中。 这是如何学习Java和Forge架构的起始点 — 这是我的编程之旅的开始。 有趣的是，我最喜欢的游戏是S.T.A.L.K.E.R.系列和Minecraft — 两者都是基于自定义架构和专有引擎的。

我一直想做游戏。当这个愿望足够强烈时，第一个问题出现了：哪个引擎应该使用？ 之间UE4和Unity，选择似乎显而易见 — UE4似乎更容易使用，并且拥有一个庞大的社区。

所以我开始了一个游戏。 设置很有趣，但问题很快就堆积起来：多人管理很糟糕，开放世界优化很差，引擎感觉很臃肿。 伟大的AAA项目，看起来和感觉都很相似 — 不太适合构建一些真正新颖的东西。 不论引擎多么现代，如果它有一个悠久的历史，它就会带来遗留的决定，这些决定会悄然影响每个新的特性。

这个项目停滞了。 我更深入地研究了代码级别的模组开发。 随着时间的推移，使用自定义渲染器 — 包括基于OpenGL的渲染器 — 开始感到受限。 我想要更多的多边形，现实物理，干净的网络代码。 我也开始感到受限于每个自定义引擎的本质。

这就是我想法的形成：结合我在Unreal Engine中所爱的东西，以及我对Minecraft内部架构（我从内部很熟悉）的了解，结合我的技术愿景，建造一个引擎 — 每个决定都是我的 — 编程语言，图形API，架构。 没有来自外部的任何妥协。

我也深受X-Ray引擎的哲学的启发 — 尽管它具有单线程结构（这并不总是有害，尤其是对于输入延迟），但它仍然技术上强大，至今仍然具有独特的气氛。 有经验的模组开发者继续推动它，甚至在没有大型团队或预算的情况下，竞争水平仍然很高。 这种做更多事的精神已经影响了我对引擎开发的思考。

所有这些都使我自然而然地，几乎是不可避免地，建造了自己的引擎。

自定义引擎的实用优势

安全性。 如果你正在构建一个多人游戏，并关心公平性，不存在现成的欺骗工具或内存扫描器，专门针对你的引擎。 攻击者没有熟悉的表面可以利用。

自由选择库。 你可以选择物理，音频和网络库 — 没有预装的依赖关系，没有过时的中间件，没你没要求的。

完全的图形控制。 天花板只有你的知识。 写OpenGL今天，明天移植到Vulkan。 没有被锁死。

没有公司依赖。 没有 royalties， 没有许可证焦虑， 没有服务条款的意外。 Unity Runtime Fee争议在2023年9月几乎使独立开发者和小型团队在经济上不再可行。 自定义引擎意味着这种外部冲击根本不会发生在你身上。

精确调节。 引擎是围绕着游戏设计的，而不是相反。 这解锁了设计可能性，需要与通用引擎进行斗争才能实现。

最小的脚印。 引擎中的每个部分都有原因。 运行时非常瘦削，发布的游戏也一样。

干净的工具。 没有累积的遗留UI。 编辑器和工具恰好是项目需要的。

真实的妥协

建造自己的引擎意味着承担整个责任 — 没有技术支持， 没有Stack Overflow的特定问题， 没有教程系列覆盖你的特定架构。 当2点钟时，引擎出现问题，你是唯一一个足够了解代码库来修复它的人。

这个妥协对我来说有效。 相反于支付公司来建造工具，他们的方式，希望他们的专家最终会帮助你解决特定问题，你自己建造它 — 并且你和你的团队理解引擎的每个部分，没有需要外部专家的帮助。

了解每个人

自定义引擎的一个未被重视的好处是每个参与其开发的人都理解它的内部。 级别艺术家使用自定义渲染器知道什么会杀死帧率，什么会改善它 — 不是因为教程告诉他们，而是因为他们参与了建造他们使用的工具链。

Beyond the Cupola — 游戏的诞生

经过两年的封闭式引擎开发，我需要一个真正的压力测试。 NASA Space Apps Challenge 2025的基辅分站的48小时hackathon提供了完美的机会。 将未经测试的自定义引擎带到一个48小时的hackathon是一个巨大的风险 — 但空间主题是测试我的物理和渲染工作在压力下的一次机会。

hackathon产生了很多想法，但在两天内无法完成。 但它们成为了之后的基础。 这个紧张的时刻是一个转折点。 一旦它结束，我看了看原型，决定把它开发成一个完整的商业游戏。

这就是Beyond the Cupola诞生的 — 一款游戏，游戏中你和你的队伍在ISS上生存，发生了各种事情。 你的任务是尽可能长地保持它完整，完成任务目标，体验空间站的内部和外部 — 包括在开放空间进行EVA。

在开发过程中，游戏有一个俄语本地化，但最终决定在发布前完全移除。

如果你想知道引擎在行动中的样子，游戏在Steam上。

结论

编写自己的引擎是一个漫长的道路，可能并不适合每个开发者 — 心理上或实际上。 你会经常遇到欺骗感。 任务列表总是比可用的小时数长。

但如果你投入真实的时间和关注，不在第一次障碍出现时放弃，并且持续不断地和有条不紊地改进，目标是可以实现的。 读到玩家对你所建造的东西的反馈，知道这个复杂的系统确实按照你设计的方式工作 — 没有什么可以比这更有趣的了。

这篇文章只是对我的哲学的介绍。 在下一篇文章中，我将解释引擎的内部结构，为什么我做了特定的技术决策，什么困扰了我，以及为什么你应该真正关注数学和物理课。

感谢阅读。如果你也在建造一个自定义引擎，或者有强烈的意见认为这是一种可怕的想法 — 我很想在评论中听到你的想法。