If the default indie start for more than a decade was to open a Unity project and place things in a scene tree, two public announcements in mid-October 2026 nudged that habit from the side. On October 12, Ludeon Studios said RimWorld 1.7 moves to its in-house Waylith engine, with about 2–4× performance in their tests. Three days later, Ahwoo and RocketWerkz put BRUTAL, the C# framework behind several of their own titles, on GitHub along with NuGet packages.
I cross-checked the GitHub README, Ludeon’s official post, GameFromScratch’s reprint of Dean Hall’s long r/gamedev thread, and Game Developer’s October 19 report. The facts that lock down are not complicated. BRUTAL calls itself a framework, not a full engine. It ships without an editor or scene graph, and without a renderer, and says it will not add those. Ludeon’s credit is careful: Brutal framework "helped make Waylith possible." The official text does not describe the whole engine as outsourced to RocketWerkz.
The image running through this piece is deliberate incompleteness. It sounds like marketing copy; on code and licence it becomes a checklist of refusals you can verify.
1. Industry default: the engine finishes your architecture choices
For a long time, indie teams and mid-size studios treated engine choice as platform choice. Unity, Unreal, later Godot each bring an editor, scene graph, asset pipeline, scripting model, and default render path. Opening the project already drops you into someone else’s world assumptions. How cameras hang, how Prefabs instantiate, which layer physics ticks on, whether the GC will spike a frame—those questions are often answered by the engine before your gameplay gets a turn.
For most projects that default is reasonable. It lowers the bar from “picture first, then play,” and gives hiring and contractors a shared language. Trouble shows up on another class of game. Spaceflight sims need positions at real scale. Colony sims must squeeze late-game thousands of entities and mods into one frame budget. Rail or encyclopedia-style works may not need a classic scene graph at all. In his r/gamedev post (reprinted in full by GameFromScratch), Dean Hall puts it plainly: contemporary general-purpose engines tune for the average case; the further a game sits from that average, the more development time goes into accommodating engine assumptions instead of figuring out what the game needs.
RocketWerkz’s own Kitten Space Agency sits far from that average. Public materials keep returning to position representation, render timing, and allocation rhythm. Hall says BRUTAL grew over about four years, from a few libraries into a framework that can carry a whole game or a whole engine. At first it looked like a red flag from outside; the team even kept it quiet internally. By October 2026 it already carried KSA directly and sat under Ludeon’s Waylith.
That is where default logic and BRUTAL split. A full engine finishes architecture choices for you. BRUTAL hands the choices back, and writes “you have to know what you want first” into the product’s temperament. Hall admits it is harder for some people, and faster for the kinds of games his team wants to make, because he no longer spends weeks learning how the engine authors intended something to work and then working around those assumptions.
2. Refusal list: no editor, reject off-scope PRs, NuGet only what you need
The README makes “what BRUTAL is not” sharper than the feature list. There is no editor and no scene graph. A renderer is also out of scope, and the team says it will not add one. They push back on internal pressure to add more. Pull requests that drift from a clear purpose get rejected. The reason is blunt: stuffing everything in is exactly how the industry arrived at the engines they do not want to use.
That is not posture. It maps to a verifiable package layout. Each top-level folder is a library published as NuGet: `Brutal.Core`, `Brutal.Interop`, `Brutal.Memory`, `Brutal.Collections`, `Brutal.Strings`, `Brutal.Concurrency`, maths and numerics, logging and localization, plus bindings for Vulkan / OpenGL, GLFW / SDL, Dear ImGui, FMOD / OpenAL, RakNet, Jolt / Box2D, glTF and texture decode, and more. You reference only what you need. The starter sample can be Core plus Glfw alone—open a window with no graphics API—then you wire rendering, debug UI, jobs, audio, and networking yourself.
At the core is a custom interop layer giving modern C# direct access to native APIs and high-performance C/C++ libraries, including Vulkan. Supporting libraries obsess over cutting allocations and overhead, using unmanaged memory and unsafe where it helps. Prerequisites in the README: .NET 10 SDK; a Vulkan 1.3 GPU if you render; Windows or Linux listed publicly today.
Deliberate incompleteness therefore has two layers. On the feature boundary it will not draw your scenes or arrange your nodes; the renderer stays yours. On the engineering unit it splits capability into pickable packages and refuses to ship as a mandatory monolith. Hall compares the relationship to Linux kernel and Ubuntu—not exact, but clear enough. BRUTAL supplies the foundation; each team builds its own “distro” engine. Kitten Space Agency sits directly on BRUTAL. Ludeon builds Waylith on top of it.
Ahwoo engineering lead Rian Drake nails the name in the press materials. It is called BRUTAL because it can be brutal to use, and they wanted that said upfront. No guardrails. You own the systems you build and the mistakes you make, and you also get the control to put things right. GamingOnLinux and other secondary pieces relay that quote. Drake also says they do not believe everyone should use this tool to make a game.
3. The Waylith scene: wording between “helped” and outsourcing the whole engine
Ludeon’s October 12 post is the primary source whose wording matters most. Update 1.7 moves RimWorld from Unity to Waylith. Waylith is described as Ludeon’s own in-house engine. The game looks and plays the same; tests show about 2–4× performance. A late-game colony stress test ran about 2.2× versus 1.6. A 1,500-mod pack loaded in 6 minutes instead of 14. Saves move between 1.6 and 1.7. The vast majority of mods run without author changes. The closing thanks: thanks to RocketWerkz, whose Brutal framework helped make Waylith possible.
That word *helped* matters. In the public story, Waylith remains Ludeon’s engine decision and implementation. BRUTAL supplies low-level C# framework capability that helped strip the last bits of Unity. Ahwoo’s release (relayed by several outlets) uses a similar line: Ludeon used BRUTAL to help extract the last bits of Unity out of RimWorld to create their Waylith engine. Calling it “RimWorld’s whole engine outsourced to RocketWerkz” does not match the official texts. As a materials observation, the safer reading is that Ludeon built Waylith itself, and BRUTAL is one credited low-level framework that helped.
For modders, Ludeon lists several changes: newer C# language features; complex mods that are less likely to crush performance; big visual changes and custom effects more reachable. More than two dozen modders helped test before Waylith’s debut. Those details show the engine move does not stop at swapping a render backend. It also re-nails RimWorld’s expensive path—late colony plus huge mod lists—into a maintainable .NET stack.
The README project table lays out usage. RimWorld / Ludeon / Waylith. Kitten Space Agency, Torpedia, Art of the Rail, and Gruntz sit directly on BRUTAL at RocketWerkz. Afterskies is from Floating Origin Interactive. Ahwoo’s release also says the framework currently powers six game projects across three studios. It mentions Felipe Falanghe (Kerbal Space Program creator) collaborating on KSA and using BRUTAL for his next game. His line on leaving Unity for BRUTAL: initially a bit daunting; once there, you own everything you created and know how it operates.
4. Licence, the independence slogan, and how to use deliberate incompleteness
BRUTAL is free for commercial games, no royalties, no revenue share. The licence is MIT-based with added attribution. A game or product must put the copyright notice in credits or equivalent, show the BRUTAL logo before gameplay, and ship NOTICE.txt. If you do not want those terms, a separate commercial licence is available. Non-profit projects, and cases where the logo would harm the app’s purpose, can waive the logo per the README. The licence is not yet OSI-submitted; the team says it intends to submit and refine with community feedback. Some secondary reports therefore prefer “source-available.” The primary README still calls itself open source, citing MIT-family text and the right to fork. In this article I follow the README’s self-description as open source, and put OSI status in the sources note so “not yet approved” is not written as “already approved.”
Hall nails the narrative with one line: You are only as independent as your tools are. Independence tracks whether tools still listen to you. He also draws a boundary: he is not saying everyone should build their own engine; he is saying every developer should have the option, without spending four years on foundations first. Game Developer also ties in the public 2025 Unity licence dispute background, and Hall’s preference that others build simpler frameworks of the same kind rather than crown BRUTAL as a single industry standard.
For indie developers that slogan is easy to hear as pep talk. Against BRUTAL’s actual shape it reads more like an employment contract. You get interop, allocation-free collections, a job system, Vulkan bindings, and a row of native libraries you wire yourself. You do not get an editor that opens into a playable prototype. The public README also says project files, solution, and build scripts for building from source are still coming; for now use NuGet, and use the repo to read and fork. Secondary write-ups such as Indie Tooling note that the docs site may not have been public on launch day, and that macOS, consoles, and mobile are not clear promises in the current README. Treat those edges as materials observations for your selection checklist, not as a mature all-in-one promise.
So the actionable meaning of deliberate incompleteness for an indie team is concrete. First ask whether your game sits far from the average case. If it is a conventional 2D or 3D content title, Godot, Unity, or a fuller framework usually costs less life. If your bottleneck is clearly allocation, job scheduling, native interop, or a renderer you must own, BRUTAL’s packages start to earn their keep. Open a window with Glfw or SDL, then add only the Memory / Collections / Concurrency packages that actually hurt, rather than daydreaming a full custom engine on day one. Read LICENSE and NOTICE; put logo and credit into the release checklist. Waylith’s public numbers can motivate; they are not your project budget. Ludeon has existing gameplay, a mod ecosystem, and years of C#. Your team may not.
Closing: independence repriced around knowing what you want first
Put BRUTAL back into the autumn 2026 production floor and what it hits first is a quiet production habit: assume engine before game, assume architecture can be wizarded by an editor, assume leaving an engine is only for giant studios. RimWorld 1.7 and BRUTAL’s release in the same week lay out another path. Some people make games directly on the framework. Some build their own engine on it. Both require writing down requirements before wiring bindings.
Hall says in the Reddit post that one of the most important decisions is what *not* to put into BRUTAL. Read that the other way. An indie’s most expensive decision is often what not to bring in. One fewer default system means one fewer assumption you do not understand but must work around. More ownership means more power to fix problems at the root when they appear. Both sides are harsh. BRUTAL at least writes the harshness into the name.
Short executable prompts:
- Write three lists first: architecture the game must decide itself; parts you can leave to an existing engine; native boundaries your team can actually maintain. If the three do not line up, you are not ready for BRUTAL yet.
- Run a minimal NuGet experiment. Core plus a windowing package to open a window; then add Memory, Collections, Concurrency, or Vulkan abstractions by pain point. Spend a weekend checking whether owning the stack is actually faster than accommodating an engine.
- Read the LICENSE before committing. Credit, splash logo, and NOTICE.txt belong on the release checklist. Need a waiver—get it in writing; do not discover it the week before launch.
- When you read Ludeon’s thanks, hold on to helped. A custom engine is still your product decision. A framework only lowers the cost of four years of foundations; gameplay and content remain yours to carry.
These October messages will not make general-purpose engines disappear. They only reprice whether tools still listen to you. People willing to pay that price now at least have readable source, pickable packages, and a warning already written into the README. It is called BRUTAL. That is not politeness.
Sources and further reading
ahwootech/BRUTAL, GitHub README (fetched from main)
Tia Young, Ludeon Studios (2026-10-12) Announcing the Waylith Engine and Update 1.7
GameFromScratch (2026-10-14) RimWorld Dump Unity Game Engine