On 14 October a repository called ahwootech/BRUTAL appeared on GitHub. Three days later it has 1,700 stars and 88 forks, and it is the foundation under two shipping games you have probably heard of.
BRUTAL is a C# framework from RocketWerkz, Dean Hall’s New Zealand studio — Hall being the creator of DayZ. RocketWerkz built its spaceflight simulator Kitten Space Agency directly on it. Ludeon Studios built Waylith, the in-house engine it used to move RimWorld off Unity, on top of it.
The licence is described in the README as “an MIT-based licence.” Free for commercial games, no royalties, credit requested.
It is a framework, and it is aggressive about the distinction
The README does not bury the lede:
BRUTAL is not trying to be a general-purpose engine. There is no editor, no scene graph and no renderer, and we’re not adding them. We push back on efforts to add more, because adding everything is how the industry ended up with the kind of engines we don’t want to use. Pull requests that drift away from a clear purpose will be rejected.
That is an unusual thing to publish on day three of a project with 1,700 stars, and it is the most informative sentence in the repository. Most open-source game projects spend their first year accepting features and their second year regretting it. BRUTAL is pre-announcing the rejection.
What it does provide is the layer underneath a renderer. At the centre is a custom interop layer giving C# direct access to native APIs. Around it: mathematics, memory management, strings, allocation-free collections, a job system, logging, localisation, and bindings for Vulkan, GLFW, Dear ImGui, FMOD, RakNet, Jolt and Box2D. Each top-level folder is one library, published as its own NuGet package, and you reference only the ones you need.
The analogy the README reaches for is a kernel: “Think of the Linux kernel and something like Ubuntu.”
What is actually built on it
The README lists six, which is more than most frameworks can claim at launch because this one was not at launch — it was in production for about four years first.
| Product | Studio | Engine |
|---|---|---|
| RimWorld | Ludeon Studios | Waylith |
| Kitten Space Agency | RocketWerkz | Direct on BRUTAL |
| Torpedia | RocketWerkz | Direct on BRUTAL |
| Art of the Rail | RocketWerkz | Direct on BRUTAL |
| Gruntz | RocketWerkz | Direct on BRUTAL |
| Afterskies | Floating Origin Interactive | Direct on BRUTAL |
The RimWorld number is the one to check rather than take: Ludeon report 2 to 4 times the performance of the Unity build in their own tests, with the vast majority of existing mods still compatible, and they published that in a Steam announcement you can read yourself. Those are their tests on their game, not a benchmark anybody else has run — but “most existing mods still work” after an engine swap is a claim with a large and vocal population of people positioned to falsify it, which makes it a more interesting claim than the multiplier.
The argument
Hall’s framing is about dependency, not performance:
You are only as independent as your tools are.
And, from the README’s reasoning: “We’re not suggesting everyone should make their own game engine. We’re suggesting every developer should have the option to, without having to spend four years building the foundations first.”
That is a coherent position and it is not an anti-Unity position. Hall has been explicit elsewhere that Unity and Unreal remain the right choice for many projects and that BRUTAL is not meant to replace what they provide. The specific thing being offered is the four years.
It is also worth noting what “open source” is buying here beyond the code: “If one day we stop being accountable to developers, you can fork it and go your own way.” The fork clause is the actual product.
Getting a window on screen
Prerequisites are .NET 10, Windows or Linux, and a Vulkan 1.3 GPU if you intend to render anything.
dotnet new console -n HelloBrutal
cd HelloBrutal
dotnet add package Ahwoo.Brutal.Core
dotnet add package Ahwoo.Brutal.Glfw
using Brutal.GlfwApi;
using Brutal.Numerics;
if (!Glfw.Init())
throw new Exception("Failed to initialize GLFW");
Glfw.WindowHint(GlfwWindowHint.ClientApi, 0);
var window = Glfw.CreateWindow(new GlfwWindow.CreateInfo
{
Title = "Hello BRUTAL",
Size = new int2(1280, 720),
});
while (!window.ShouldClose)
Glfw.PollEvents();
Glfw.Terminate();
That opens a window with no graphics API attached. Everything after it is yours: Ahwoo.Brutal.Vulkan.Abstractions and .Vma for a renderer, .ShaderC or .Slang to compile shaders, .ImGui for debug UI, .Concurrency for the job system.
The honest caveat
Building from source does not work yet. The README says it plainly: “Project files, a solution and build scripts are coming. Until then use the NuGet packages, and use this repository to read and fork the code.”
So for now this is a NuGet-consumable framework with readable sources, not a buildable one. For a project three days into being public that is a reasonable place to be, but it does mean the fork clause above is aspirational until the build scripts land.
For creative coders, the appeal is narrower and more specific than “make games.” A Vulkan, ImGui, Jolt and FMOD stack in C#, with allocation-free collections and a job system, with no scene graph imposing a worldview — that is a good substrate for the kind of real-time generative work that usually gets wedged awkwardly into an engine built for something else.
Sources
- ahwootech/BRUTAL — GitHub
- BRUTAL
- Ludeon’s RimWorld engine announcement — Steam
- Rocketwerkz CEO says frameworks, not engines, are the future of game development — Game Developer
- DayZ creator presents BRUTAL, a free open-source development framework — 80 Level
- Kitten Space Agency
- BRUTAL Game Development: Without an Engine — NZGDC 2025