# BRUTAL: a C# foundation that hands the architecture back to you

> BRUTAL is an open source C# framework that provides interop, memory, concurrency and native library bindings without an editor, a scene graph or a renderer. It suits developers who want to build their own engine stack, and it is a poor fit for anyone expecting a ready-made workflow.

**ahwootech/BRUTAL** — A free, open source C# framework for making games, or your own game engine. Direct access to native APIs and Vulkan, with the low-level libraries around them. The foundation under Kitten Space Agency and RimWorld's Waylith engine.

- Repository: https://github.com/ahwootech/BRUTAL
- Website: https://ahwoo.com/brutal
- Stars: 2,179 · Forks: 125
- Language: C#
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/ahwootech-brutal

## A kernel for C# game work, and what it refuses to be

BRUTAL describes itself as a framework rather than an engine, and the distinction is enforced in the project rather than merely stated. The README is blunt about it: there is no editor, no scene graph and no renderer, and the maintainers say they are not adding them. They also say they push back on pull requests that drift away from that purpose, because adding everything is how the industry ended up with the kind of engines they dislike. That is a governance position, not just a feature list, and it tells you what a contribution will and will not look like.

The stated problem is independence. The argument runs that developers have given up an extraordinary amount of control over their work to vendors whose interests are not necessarily their own, and that every developer should be able to choose to build their own engine foundations without spending four years on the groundwork. The analogy offered is the Linux kernel and something like Ubuntu: the foundation is provided, your own systems are built on top.

The audience follows from that. The projects listed as running on it are RimWorld through Ludeon's Waylith engine, and Kitten Space Agency, Torpedia, Art of the Rail, Gruntz and Afterskies built directly on BRUTAL. That is a list of teams who wanted a specific stack rather than a general-purpose tool, which is exactly the profile the project targets.

## The interop layer and the libraries wrapped around it

At the centre is a custom interop layer that gives C# direct access to native APIs and libraries. That layer is the reason the project exists; the rest of the box is built on top of it.

Each top-level folder in the repository is one library published as its own NuGet package, and you reference only what you need. Brutal.Core holds base types, attributes, platform detection, pointer helpers and Roslyn analyzers. Brutal.Interop is the interop layer itself. Brutal.Memory covers unmanaged memory management and allocators, Brutal.Collections holds collections that do not allocate, and Brutal.Strings handles string building and handling without allocation. Brutal.Maths and Brutal.Numerics supply vector, matrix and numeric types, while Brutal.Concurrency provides the job system and threading. Logging and localization live in Brutal.Logging and Brutal.Localization.

The native bindings are where the framework reaches outside .NET. There are Vulkan packages, including abstractions and the Vulkan Memory Allocator, plus OpenGL bindings. Windowing and input come through Brutal.Glfw and Brutal.Sdl, with SDL's image, audio mixing and font add-ons. Dear ImGui and ImPlot are bound on the docking branch, including a FreeType variant. Shaders are handled by Brutal.ShaderC and Brutal.Slang. Textures, KTX and compressed formats, image decoding and glTF loading each have their own package, and Brutal.MeshOptimizer sits next to glTF support. Audio is covered by FMOD and OpenAl bindings, networking by RakNet, and physics by Jolt for 3D and Box2D for 2D.

The design goal stated in the README is a small set of low-level things done well: interop, memory, concurrency, maths, strings and native bindings, on the latest C# and Vulkan, using unmanaged memory and unsafe code where that makes sense and avoiding allocations and unnecessary overhead. You can also pull in whatever NuGet packages you want, including third-party ones.

## Your first window: Core plus Glfw, nothing else

Prerequisites are a.NET 10 SDK, a Vulkan 1.3 capable GPU with current drivers if you render, the Vulkan SDK if you want validation layers while developing, and either Windows or Linux. The first project needs only Core and Glfw:

```sh
dotnet new console -n HelloBrutal
cd HelloBrutal
dotnet add package Ahwoo.Brutal.Core
dotnet add package Ahwoo.Brutal.Glfw
```

The package names carry an Ahwoo prefix even though the namespaces do not, which is worth noticing before you start guessing at package identifiers. Program.cs then opens a window with no graphics API attached:

```csharp
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();
```

The window hint sets the client API to 0, which is how the example deliberately asks for a window with no graphics context, and the create call takes a struct with a title and an int2 size from Brutal.Numerics. Run it and you should see a window appear and close cleanly:

```sh
dotnet run
```

What happens next is your decision. The README then points at the rendering path, naming Ahwoo.Brutal.Vulkan.Abstractions and Ahwoo.Brutal.Vulkan.Vma.

## The honest cost: you write your own stack

The project does not soften the trade-off. The README says BRUTAL is called that for a reason, that in some ways it is much harder to use than Unity, Unreal or Godot, and that in other ways, particularly if you are doing something unusual, it is considerably easier. The last clause of that sentence is the important one, and it comes with a condition attached: you actually have to know what you want to do first.

That shifts the failure mode. With an editor-driven engine, the failure mode is usually a project that outgrows the tool or fights it. With BRUTAL, the failure mode is a project that stalls before it starts, because the decisions a normal engine makes for you are now decisions you have not made. There is no scene graph to hang entities on and no renderer to submit a draw call, so the first playable frame is further away than the first window.

The trade runs the other way as well. The project frames itself as a foundation under Kitten Space Agency and RimWorld's Waylith engine, and 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. That is a studio's own measurement, published through their Steam announcement, and it is the strongest performance statement available for this project. It is also a single well-resourced case, not a general guarantee for any project built on the framework.

The indirect evidence in the tree is worth noting too. Beyond the rendering, input, UI, audio, physics and networking packages sit Brutal.Monitor.Common, Brutal.Monitor.Host, Brutal.RenderDoc and Brutal.RenderDoc.ImGui for runtime monitoring and RenderDoc capture integration, along with Brutal.NativeFileDialog, Brutal.NotCurses for terminal UI and Brutal.ZLib. The presence of frame capture and runtime monitoring in the box says something about the intended workflow: you are expected to be at the GPU and the profiler, not in a visual editor.

## Where BRUTAL sits against the engines it names

The comparison the project invites is with Unity, Unreal and Godot, and the difference is about where the architectural decisions live. A general-purpose engine decides the object model, the scene representation, the asset pipeline and the rendering backend, and lets you override some of that. BRUTAL does not make those decisions for you, per the README, and you write your own stack. In exchange you get direct native access, unmanaged memory and the ability to use any NuGet package you want.

The concrete alternative within the same lineage is that teams stay on their own stack but move off a licensed engine, which is what Ludeon did by building Waylith on BRUTAL to move RimWorld off Unity. The second alternative is a conventional engine and accepting its editor, its scene graph and its renderer, which is the right trade whenever the product is an ordinary game and the schedule matters more than the architecture.

The difference in approach is easiest to state as what you give up and what you keep. With BRUTAL you give up the editor, the scene graph and the renderer, and you keep control of the whole stack plus a set of native bindings that plug into it. With an engine you give up some control and keep the tools. For a game that runs on unusual hardware, needs a custom renderer, or has to be shipped without a per-seat licence fee, the trade can pay. For a team that wants to spend its time on gameplay rather than on plumbing, the same trade usually does not.

## Licensing, third-party notices and the shape of the repository

The framework is free for commercial use, with no royalties, and the project asks for credit rather than a percentage of revenue. The README describes the licence as MIT-based and points to a LICENSE.txt at the root of the repository, alongside NOTICE.txt. Repository metadata classifies the licence as a custom one that GitHub cannot categorise, so the operative text is the file itself, and anyone with a policy on licence approval needs to read LICENSE.txt and NOTICE.txt rather than rely on the label.

Third-party licensing is handled per library. The README states that third-party notices for each library live in its LICENSES folder, with Brutal.ImGui/LICENSES as the example. That matters because the box includes GLFW, Dear ImGui, ImPlot, FMOD, RakNet, Jolt, Box2D, FreeType, stb, and the Vulkan Memory Allocator, each under its own terms, and the aggregate licence story of the framework is the set of those notices rather than the root file alone. The per-library folders in the tree are the place to check before shipping.

Maintenance looks healthy on the surface, and the caveat is worth being precise about. The repository is not archived, and the last push was on 2026-10-18, which is recent. There are no GitHub releases, so versioning is handled through the NuGet packages and the repository history rather than through tagged release artefacts, and the repository has no release notes to read. The top-level listing also shows the usual governance files, CONTRIBUTING.md, CODE_OF_CONDUCT.md, CONTRIBUTORS.md and SECURITY.md, and a docs/ directory.

## Conclusion

Adopt BRUTAL if you already know what stack you want and can accept writing the parts a normal engine would hand you, especially for unusual hardware, custom rendering or replacing a licensed engine. Do not adopt it for a team that needs a scene editor, a scene graph and a renderer on day one. Before starting, check that your target machines have a Vulkan 1.3 capable GPU with current drivers, confirm you are on Windows or Linux with the .NET 10 SDK, and read LICENSE.txt and the per-library LICENSES folders to see how the MIT-based terms line up with the third-party notices for GLFW, Dear ImGui, FMOD, Jolt and the rest.

## FAQ

### Does BRUTAL come with a game editor or a renderer?

No. The README states there is no editor, no scene graph and no renderer, and that the maintainers are not adding them. Rendering is something you build on top, using packages such as Ahwoo.Brutal.Vulkan.Abstractions and Ahwoo.Brutal.Vulkan.Vma.

### What do I need installed before using BRUTAL?

The listed prerequisites are the .NET 10 SDK, a Vulkan 1.3 capable GPU with current drivers if you render, the Vulkan SDK if you want validation layers during development, and either Windows or Linux. Each library is published as a NuGet package, so packages such as Ahwoo.Brutal.Core are added with dotnet add package.

### Can I use BRUTAL in a commercial game and what licence applies?

The README says BRUTAL is free including for commercial games, with no royalties, and asks for credit instead of a revenue share. It describes the licence as MIT-based, with the full text in the LICENSE.txt file, and third-party notices for each library in its own LICENSES folder.

### Is BRUTAL a better choice than Unity or Godot for a new game?

The project itself says BRUTAL is in some ways much harder to use than Unity, Unreal or Godot, and considerably easier when you are doing something unusual, provided you already know what you want to build. It provides no editor, no scene graph and no renderer, so a team wanting those tools on day one has to look elsewhere.

## Sources

- [ahwootech/BRUTAL on GitHub](https://github.com/ahwootech/BRUTAL)
- [Issues](https://github.com/ahwootech/BRUTAL/issues)
- [Project website](https://ahwoo.com/brutal)
- [README](https://github.com/ahwootech/BRUTAL/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ahwootech-brutal