Infernux 已经有一套能跑通 2D/3D 游戏的基础能力了，但单靠我一个人维护，越来越吃力。即使有 AI 辅助，仍然需要人投入精力去讨论设计、做技术取舍、维护具体模块。所以我想找一些认同这个方向的人，一起把它继续做下去。
愿景：我们想做一个怎样的引擎？
我个人很喜欢把游戏引擎分成三个不同的类别。第一类是DOOM那个年代常见的、主要面向特定游戏的引擎，或者说叫技术框架。 先有一款想做的游戏，再围绕它的玩法、画面和性能需求构建技术。
第二类，是以 UE、Unity 为代表的通用游戏引擎。 它们不再只服务某一款游戏，而是为不同类型的游戏、不同规模的团队提供一套可复用的开发环境。
那Unity之后，下一类引擎会是什么样的呢？现在大家还没有形成共识。而Infernux希望在这里押注的是，面向 AI 深度融入游戏开发与运行生态的引擎。换句话说，是Agentic Gaming Runtime。
我并不想做什么类似于“嘿快来看，我的引擎配上随便几个SKILL再加上一点harness工程就可以一句话生成骑马与砍杀”的东西，因为我个人认为引擎还是需要人的审美、架构与设计，而非完全交由一句自然语言去把控。因此你不会得到一个有额外聊天窗口的翻版Unity，上面还写着你的昵称，有一个聊天框问你今天想做些什么。
我想要的是 人工智能能够自然地成为游戏的一部分，无论是大模型还是小模型。 开发者可以方便地在游戏里使用Torch或者其他可能的神经网络库，去做强化学习的智能NPC、神经渲染、动态生成的交互式动画。模型需要和其他资产一样，可以随游戏一起发布，不需要每个项目都重新搭建一套连接机器学习框架与引擎的管线。这也是引擎选择Python作为脚本层的原因之一，它拥有目前世界上最健全丰富的神经网络框架，github上随处可见各种形态各异的神经网络仓库，可以直接引入使用。也是同样的原因，这里不会去维护一份大家都习以为常的C Sharp绑定。
另一方面，引擎本身也确实应该适合大模型和 Agent 工作。但是我们不应该停留在聊天框层面，而是人和Agent可以围绕同一个项目协作去共同调试同一个项目，而不互相干扰。
Infernux 就是我对这个方向的一次探索。它长期仍然会是一款具备通用开发能力的游戏引擎，但我不想只把它做成另一个功能清单相似的 Unity。这种把代码、模型、游戏世界和开发工具放在一起重新思考的方式，很契合我个人的技术品味，也是我愿意继续投入这个项目的原因。
如果你也对这个问题感兴趣，欢迎一起来探索。我们不必先对所有答案达成一致，可以从具体的功能、样例和真实问题开始，一点点把这个方向做出来。
现状：我们有什么，现在正在做什么？
从基本功能的完整度来看，引擎基本已经有了一套2D/3D渲染、动画、材质、着色器管理、游戏逻辑、物理、状态机、粒子系统、音频、后处理与自定义着色器了，大概可以放心地进行一个游戏的开发了。你可以点击这个链接，看看我使用Infernux搭建出的一个游戏的PV：Changeable: 改变世界的魔法。这也是我和团队的小伙伴们会在后期长线开发的独立游戏。
目前，我主要在 GitHub 上 041/ 开头的开发分支里推进下一轮更新。这个阶段的重点，是补齐实际做游戏时遇到的缺口，同时为后续的神经网络接入整理好基础设施。
补齐通用游戏开发的基础能力。 包括世界空间的 UI 绘制、运行时可修改的物体网格，以及 OnMouseDown 等更方便的 Unity Style API。我希望引擎不只是能展示一些技术效果，也能让人顺手地把一个游戏做出来。这部分会尽量由实际项目中的需求推动，而不是单纯对着其他引擎的功能表打勾。
继续完善插件系统。 在现有 InxPackage 机制上，继续打磨插件的安装、更新、资源与脚本刷新，以及编辑器内容和运行时内容的边界。后续的模型能力、开发工具和平台支持，也希望尽量通过清晰的扩展接口接入，而不是什么东西都往引擎核心里塞。
更强的高性能计算，以及为神经网络的引入做准备。 我们引入了Taichi，将 CPU 上的 JIT 编译和 GPU Kernel 明确区分，分别通过 inx.jit.compile 和 inx.compute.kernel 表达。这里的目标还包括理清计算在哪里执行、数据由谁持有、什么时候需要同步，为后续模型推理与引擎资源的互操作打好基础。得益于Taichi带来的GPU高性能计算，我们现在可以以大约1000帧的速度渲染一个黏糊糊的软体：
更新依赖，清理该退休的旧代码。 后续接入神经网络，会涉及不少内存、显存、资源生命周期和同步问题。我希望先把已有的实现和接口整理清楚，减少重复路径和历史包袱，而不是让新的复杂度继续叠在旧问题上。
近期重点会做什么？
2026 年剩下这几个月，我希望主要围绕三个方向推进。具体的实现范围和节奏，会根据实际验证结果和参与维护的人力调整。
第一，打通模型从开发到游戏运行的完整流程。 逐步完善模型资产、输入输出绑定、推理执行和构建发布，让模型不仅能在开发环境里跑起来，也能成为游戏中可以配置、替换、调试和交付的一部分。开发时方便使用机器学习生态，发布时则明确目标平台需要哪些运行依赖，而不是把作者电脑上的整个训练环境打包给玩家。
第二，用具体的玩法和渲染案例验证设计。 围绕神经网络驱动的角色行为、交互式动画或神经渲染，选择范围可控的组件和样例，探索模型如何与场景数据、游戏逻辑及 RenderGraph 配合。比起先设计一套包罗万象的接口，我更希望先把几个真实案例做完整，再从中提炼出其他开发者也能复用的能力。
第三，让引擎更可靠，也更容易参与。 持续改善保存与加载、脚本和资源刷新、Play/Stop、插件生命周期、跨平台构建与回归测试，同时补充文档、样例和模块说明。既要让使用者少踩坑，也要让想参与开发的人，不必先读完整个仓库才能动手。
当然，我们不会为了加入神经网络，就放弃通用引擎应有的基础能力。场景、物理、音频、动画、UI、资源管理和发布流程，仍然需要持续建设。神经网络应该扩展开发者的选择，而不是让普通游戏开发变得更困难。
怎样参与
引擎本身是一个很大很大的工作，很难有人一下子就解决一整个宏大的命题，即使借助AI神力也不行，例如各种平台的适配等。因此，从一个问题、一处文档、一个测试或一份样例开始，都很欢迎。
尤其想强调的是：非常鼓励大家提 Issue，不会写引擎代码，也完全可以参与。 Bug、文档里讲不清楚的地方、不顺手的工作流，以及“我想做某件事，但现在不知道该怎么实现”，都值得讨论。你不需要先找到问题的根因，更不需要为了提一个 Issue，就先把它修好。
关于反馈！反馈问题时，尽量带上引擎版本、运行平台、复现步骤，以及预期和实际发生的情况。日志、截图或最小复现项目也会很有帮助。还没有整理清楚的想法，也欢迎先在社区里聊。一次清楚的反馈，有时比一个新增功能的 PR 更能帮助引擎前进。
如果你已经有明确的修改方案，欢迎直接提交 PR；涉及较大的架构调整或新模块时，建议先开 Issue 交流目标、范围和方案，避免大家投入很多时间之后才发现方向不一致。我会认真看，也会尽量及时回复和审查。
如果你希望长期参与，或者负责更具体、更核心的工作，也欢迎给我发邮件：
对于希望长期参与的小伙伴，我希望你至少深入了解了下图所列出的各种技术中的其中一种。 它有点大，你可能需要点开并放大才能查看到清晰的信息：
可以聊聊你做过的东西、感兴趣的方向，以及希望以什么方式参与。我们也可以交流彼此对架构、代码质量和技术取舍的想法，看看 taste 是否合拍，再一起确定适合推进的课题。没必要一开始就承诺长期投入，先合作解决一个具体问题，也是很好的开始。
我也在考虑，在个人能力允许的范围内，拿出一些预算尝试任务悬赏、贡献奖励，或围绕具体模块开展付费合作，甚至办一场由这个引擎引发的 Gamejam。 具体形式、预算和规则我还没有确定；但如果开始实行，会先把适用任务和奖励方式说明白。无论有没有报酬，有价值的 Issue、问题复现、测试、文档和持续维护，都会被认真对待。
欢迎使用 AI 辅助开发，但希望提交者能够理解自己的改动，解释关键设计，并提供必要的验证。比起一次提交很多代码，我更看重一个改动是否清楚、可靠，以及后续能否维护。
不管是来写代码、提问题、做样例，还是一起讨论某个设计，只要你也对这个方向感兴趣，都欢迎加入。
