如果说过去十余年独立游戏的默认起手是先开 Unity 工程、再在场景树里摆东西，那么 2026 年十月中旬叠在一起的两则公开消息，把这套起手从侧面推了一下。十月十二日，Ludeon Studios 宣布 RimWorld 1.7 迁到自家 Waylith 引擎，测试里性能大约提升二到四倍。三天后，Ahwoo 与 RocketWerkz 把支撑多款自研项目的 C# 框架 BRUTAL 放到 GitHub，连同 NuGet 分包一并开放。
我把 GitHub README、Ludeon 官方博文、GameFromScratch 对 Dean Hall Reddit 长帖的转载，以及 Game Developer 十月十九日的报道对了一遍。能钉死的事实并不复杂。BRUTAL 自认是框架，自称不是完整引擎。它既没有编辑器与场景图，也不提供渲染器，并且写明不会补上这几样。Ludeon 对它的致谢措辞也很克制，原文写 Brutal framework "helped make Waylith possible"，也就是帮助 Waylith 成为可能。官方文本没有把整台引擎说成外包给 RocketWerkz。
贯穿本稿的意象，是故意不完整四个字。它听起来像产品文案，落到代码与许可证上，却是一组可核验的拒绝清单。
一、行业默认，引擎替你做完架构选择
很长一段时间里，独立团队和中小型工作室把选引擎当成选平台。Unity、Unreal、后来的 Godot，各自带着编辑器、场景图、资源管线、脚本模型和默认渲染路径。你打开工程文件，就已经进入别人写好的世界假设。摄像机怎么挂、Prefab 怎么实例化、物理在哪一层 Tick、GC 会不会在某一帧突然抬起头，这些问题往往先被引擎答完，再轮到你的玩法。
对大多数项目，这套默认合理。它把先有画面再有玩法的门槛压低，也让招聘与外包有共同语言。麻烦出在另一类游戏上。太空飞行模拟要按真实尺度算位置，殖民地模拟要在后期上千实体与模组同时挤进同一帧预算，铁路或百科式作品可能根本不需要传统场景图。Dean Hall 在 r/gamedev 的长帖里（由 GameFromScratch 全文转载）写得很直，当代通用引擎为平均案例调参，游戏离平均案例越远，开发时间就越消耗在迁就引擎假设上，而不是在弄清游戏需要什么。
RocketWerkz 自家的 Kitten Space Agency 正是这类离平均案例很远的项目。公开材料里反复出现的需求包括位置表示、渲染时机、内存分配节奏。BRUTAL 的生长路径，按 Hall 的说法，大约四年，从一小批库扩成可以支撑整款游戏或整台引擎的框架。起初对外甚至像红旗，团队内部也曾保密。到了 2026 年十月，它已经直接托住 KSA，也进入 Ludeon 的 Waylith。
默认逻辑与 BRUTAL 的分叉点就在这里。完整引擎会替你完成架构选择。BRUTAL 把选择权交回给你，同时把你必须先知道自己要做什么写进产品气质。Hall 自己也承认，对某些人这更难，对团队想做的那种游戏反而更快，因为他不必再花几周弄清引擎作者当初怎么想，然后再绕开那些假设。
二、拒绝清单，无编辑器、拒绝跑偏的 PR，以及按需引用的 NuGet
README 把 BRUTAL 不是什么写得比功能列表更醒目。它既没有编辑器，也没有场景图。渲染器同样不在交付范围，团队写明不会补上。他们会抵制内部再多加点的冲动。偏离清晰用途的 Pull Request 会被拒绝。理由写得很硬，把什么都塞进去，正是行业走到我们不想用的那种引擎的路径。
这不是姿态。它对应一套可核验的分包结构。仓库每个顶层目录对应一个库，各自发成 NuGet。`Brutal.Core`、`Brutal.Interop`、`Brutal.Memory`、`Brutal.Collections`、`Brutal.Strings`、`Brutal.Concurrency`、数学与数值、日志与本地化，再加上 Vulkan / OpenGL、GLFW / SDL、Dear ImGui、FMOD / OpenAL、RakNet、Jolt / Box2D、glTF 与贴图解码等绑定。你只引用需要的包。起步示例甚至可以只有 Core 与 Glfw，开一扇没有图形 API 的窗口，下一步渲染、调试 UI、任务系统、音频与网络由你自己接。
核心机制是自定义 interop 层，让现代 C# 直接触达原生 API 与高性能 C/C++ 库，其中包括 Vulkan。周围库强调减少分配与多余开销，在合适处使用非托管内存与 unsafe。README 的前置条件写明 .NET 10 SDK，若要渲染则需要支持 Vulkan 1.3 的 GPU，当前公开列出的平台是 Windows 与 Linux。
故意不完整因此有两层意思。功能边界上，它不替你画场景，也不替你排节点。渲染器同样留给你自己写。工程单元上，它把能力拆成可拣选的包，拒绝做成必须整舱装载的巨石。Hall 用 Linux 内核与 Ubuntu 的关系做类比，承认不完全精确，但足以说明意图。BRUTAL 提供基础，发行版形态的引擎由各团队自建。Kitten Space Agency 直接建在 BRUTAL 上。Ludeon 则在其上造出 Waylith。
Ahwoo 工程负责人 Rian Drake 在通稿里把名字来源说死了。叫 BRUTAL，是因为用起来有时确实粗暴，他们想事先讲清楚。没有护栏。你为自己搭的系统与犯的错负责，也有权改到对。GamingOnLinux 等二次报道转述了这段话。Drake 同时强调，他们不认为人人都该用这个工具做游戏。
三、Waylith 场面，帮助与整引擎外包之间的措辞差
Ludeon 十月十二日的博文，是这篇技术新闻里最需要抠措辞的一手材料。更新 1.7 把 RimWorld 从 Unity 迁到 Waylith。Waylith 写明是 Ludeon 自家引擎。游戏观感与玩法保持一致，测试中性能提升约二到四倍。晚期殖民地压力测试相对 1.6 约 2.2 倍。一千五百个模组的包，加载从十四分钟降到六分钟。存档可在 1.6 与 1.7 之间往返。绝大多数模组无需作者改动即可运行。文末致谢写的是 thanks to RocketWerkz, whose Brutal framework helped make Waylith possible。
helped 这个词很要紧。公开叙事里，Waylith 仍是 Ludeon 的引擎决策与实现产物。BRUTAL 提供的是底层 C# 框架能力，帮助把 Unity 最后的依赖抠干净。Ahwoo 通稿（多家媒体转载）也采用相近口径，写 Ludeon used BRUTAL to help extract the last bits of Unity out of RimWorld to create their Waylith engine。把它说成 RimWorld 整台引擎外包给 RocketWerkz，与现有官方文本不符。资料观察上，更稳妥的说法是，Ludeon 自建 Waylith，BRUTAL 是被致谢的底层框架之一。
对模组作者，Ludeon 还列了几条变化。可以使用更新的 C# 语言特性。写复杂模组时更不容易拖垮性能。大型视觉改动与自定义特效更容易做。超过二十位模组作者参与了 Waylith 上线前的测试与反馈。这些细节说明，迁引擎的代价并不停在换渲染后端。它还把后期殖民地加上海量模组这条 RimWorld 最贵的路径，重新钉进可维护的 .NET 栈。
README 的项目表把使用关系摊开。RimWorld / Ludeon / Waylith。Kitten Space Agency、Torpedia、Art of the Rail、Gruntz 由 RocketWerkz 直接建在 BRUTAL 上。Afterskies 来自 Floating Origin Interactive。Ahwoo 通稿另称，框架当前支撑三个工作室的六个游戏项目。通稿还提到 Felipe Falanghe（Kerbal Space Program 创作者）与 RocketWerkz 合作 KSA，并在下一款游戏里使用 BRUTAL。他对从 Unity 转到 BRUTAL 的形容是起初有点吓人，一旦进去，你就拥有自己造的一切，并清楚它们如何运转。
四、许可证、独立性口号，以及故意不完整怎么用
BRUTAL 对商业游戏免费，无版税，不抽成。许可证基于 MIT，另加署名要求。游戏或产品须在制作人员名单或等价处放入版权声明，开局前展示 BRUTAL logo，并随产品附带 NOTICE.txt。不想满足这些条件，可另谈商业许可。非营利项目，以及展示 logo 会损害用途的场合，README 写明可豁免 logo。许可证尚未提交 OSI 审批，团队表示打算提交，并愿按社区反馈修订。部分二次报道因此更愿意称它为 source-available。一手 README 仍自称 open source，并以 MIT 系文本与可 fork 为论据。正文里我按 README 自述写开源，同时把 OSI 状态放进来源说明，避免把未批准说成已批准。
Hall 给整套叙事钉了一句口号。You are only as independent as your tools are。你的独立程度，取决于工具是否仍听你的。他同时补了边界，不主张人人都该自研引擎，主张人人都该有这个选项，且不必先花四年从零砌基础。Game Developer 报道还回扣了 2025 年 Unity 许可纠纷的公开背景，以及 Hall 更希望看到别人做出更简单的同类框架，而不是把 BRUTAL 捧成行业单一标准。
对独立开发者，这句口号很容易被听成励志。落到 BRUTAL 的实际形态，它更像一份用工合同。你得到的是 interop、无分配集合、任务系统、Vulkan 绑定，以及一排你可以自己接线的原生库。你得不到打开就有可玩原型的编辑器体验。公开 README 也写明，从源码构建的工程文件、解决方案与构建脚本仍在路上，现阶段以 NuGet 为主，仓库用来阅读与 fork。Indie Tooling 等二次整理还指出，文档站在上线日未必对公众开放，macOS、主机与移动端亦不在当前 README 的明确承诺里。这些边角要当作资料观察，写进选型清单，而不是写成已经成熟的全家桶承诺。
于是故意不完整对独立团队的可执行含义，其实很具体。先判断你的游戏是不是离平均案例很远。若只是常规 2D 或 3D 内容向作品，Godot、Unity 或更完整的框架往往更省命。若你的瓶颈明明在内存分配、任务调度、原生库互操作或必须自写的渲染路径，BRUTAL 的分包才开始值钱。先用 Glfw 或 SDL 包开窗，再只加 Concurrency、Memory、Collections 里最吃痛的那几包，比一上来幻想自研引擎全貌更接近它的设计。读 LICENSE 与 NOTICE，把 logo 与署名排进构建清单。Waylith 的公开数字可以当激励，却不能直接当成你的项目预算表。Ludeon 有现成玩法、现成模组生态与多年 C# 代码，你的团队未必有。
收束，独立在先知道要做什么里被重新计价
把 BRUTAL 放回 2026 年秋天的制作现场，它首先打击的是一种隐蔽的制作惯性。大家默认先有引擎再有游戏，默认架构选择可以被编辑器向导代劳，默认离引擎只会发生在巨头工作室。RimWorld 1.7 与 BRUTAL 开源叠在同一周，把另一条路径摊开。有人用框架直接做游戏。有人用框架自建引擎。两边都要求你先写清需求，再往下接绑定。
Hall 在 Reddit 长帖里说，最重要的决定之一，是什么东西不放进 BRUTAL。这句话可以反过来读。独立开发者最贵的决定，往往也是什么东西不引入。少一个默认系统，就少一份你看不懂却必须绕开的假设。多一份自建责任，就多一份出问题时能改到根上的权限。两边都粗暴。BRUTAL 至少把粗暴写在名字上。
可执行的提示很短。
- 先写三张清单。游戏必须自己决定的架构、可以外包给现成引擎的部分、团队吃得消维护的原生边界。三张对不上，就还没到碰 BRUTAL 的时候。
- 用 NuGet 做最小实验。Core 加窗口包开窗，再按痛点加 Memory、Collections、Concurrency 或 Vulkan 抽象，用一周末验证自写栈是否真比迁就引擎更快。
- 读完 LICENSE 再立项。署名、开局 logo、NOTICE.txt 要进发布检查表。需要豁免就走书面许可，不要上线前才发现。
- 读 Ludeon 致谢时盯住 helped。自研引擎仍是你的产品决策。框架只降低从零砌四年的成本，玩法与内容仍要自己扛。
十月的这两则消息不会让通用引擎消失。它们只是把工具是否仍听你的重新标了价。愿意付这价的人，现在至少有一份可读的源码、一组可拣的包，以及一句已经写进 README 的警告。它叫 BRUTAL，不是客套。
来源与延伸阅读
ahwootech/BRUTAL，GitHub README（抓取自 main）
Tia Young，Ludeon Studios（2026-10-12）Announcing the Waylith Engine and Update 1.7
GameFromScratch（2026-10-15）BRUTAL C# Game Framework Now Free（文中转载 Dean Hall r/gamedev 长帖要点）
GameFromScratch（2026-10-14）RimWorld Dump Unity Game Engine
Dean Hall，r/gamedev 公告帖（约 2026-10-15，正文 WebFetch 403，事实以 GFS 转载与一手 README 交叉）Introducing BRUTAL…
Liam Squires-Hand，GamingOnLinux（2026-10-16，二次报道与通稿转述）BRUTAL… releases its source code
Indie Tooling（2026-10-16，二次整理，许可证与边角）BRUTAL is free. Read the licence before you build on it