The underlying technology behind Rim World’s brand new Way Engine—the Brutal framework—has officially dropped as a free, source-available toolkit. I remember the nightmare of trying to build custom C# game engines from absolute scratch, fighting memory allocation bugs for weeks. This release completely changes that landscape. In this post, I will break down what Brutal actually is, who should use it, its specific licensing rules, and what is packed inside.
What is Brutal framework?
Brutal is the heavy-duty framework powering the Way Engine. The Way Engine itself is the custom engine built for Rim World, which originally ran on Unity. When Rim World migrated to this new engine, they saw a massive two-to-four times performance boost. I once ported a massive project off a commercial engine just to save a few frames, so seeing a jump that huge is mind-blowing.
Another heavy hitter using Brutal is Rocket Works, the studio founded by DayZ creator Dean Hall. They are leveraging Brutal in their upcoming title, Kitten Space Agency. Hall also runs the distribution platform Aoo, and the company is actively replacing their internal game engines with Brutal technology.
Framework vs game engine
To grasp what Brutal does, you have to understand the hard line between a framework and a game engine. On the surface, the difference boils down to the amount of tooling provided: does it hand you a visual game editor or not? Deeper down, it is about how many architectural decisions the tool makes for you. When a tool makes decisions for you, it is infinitely easier to use, but it becomes much harder to bend to your specific, custom needs. That is exactly where frameworks step in.
Some examples:
- Frameworks: MonoGame, SDL
- Game engines: Unity, Unreal
Brutal is absolutely not a game engine; it is a framework. You have to get your hands dirty with the code to make a game with it.
Approach of Brutal
The studio behind Brutal started crafting this custom framework four years ago. At first, they thought only a completely unhinged developer would try to build this from scratch. It was such a massive, risky undertaking that it remained a secret internal project—a total red flag for standard studio management. What started as a handful of libraries eventually snowballed into a highly complex framework capable of building games or powering entirely custom game engines.
Key features
- Interop layer: At its core sits a custom layer granting raw access to native APIs and libraries straight from C#.
- Support libraries: It handles math, heavy memory management, string manipulation, job scheduling, logging, and localization.
- Allocation focus: It is aggressively obsessed with reducing memory allocations and stripping out unnecessary overhead.
- Unmanaged memory and unsafe code: It heavily utilizes these where it makes sense. “Unsafe” sounds terrifying in the .NET world, but it basically just means native code executing efficiently where needed.
- Modern tech stack: It runs on the latest version of C# and relies on Vulkan.
- Freedom of choice: You can build your own custom renderer using the Vulkan bindings. Brutal refuses to make these decisions for you. You can pull in any NuGet packages you want, including third-party ones, and build your own stack entirely from scratch.
Why the name Brutal?
In some scenarios, Brutal is significantly harder to use than Unity, Unreal, or Godot. In other cases—especially when you are trying to pull off something highly unconventional—it makes things a breeze. According to the developer, it is incredibly easy to use, but with one massive caveat: you have to know exactly what you are trying to build before you start.
When working in Unity or Unreal, I used to spend weeks trying to decipher the engine creator’s original intent, just to figure out how to bypass their hard-coded assumptions. When you strip all of that away, the development process actually speeds up—at least for the specific types of games this framework was built for.
What Brutal is not?
The developers are very clear: Brutal is not a silver bullet meant for everyone. The internal team fought tooth and nail against attempts to bloat it with more features. The entire goal is to provide a razor-focused, highly efficient toolset for building demanding games, not a bloated engine trying to please everyone.
- Scope control: Deciding what not to put into Brutal is their most critical process. Pull requests that deviate from the core mission will be aggressively rejected. It is not that they don’t appreciate the help; adding everything everyone wants is exactly how the industry ended up with bloated engines they are trying to escape.
- The analogy: They compare it to the relationship between the Linux kernel and Ubuntu. It is not a perfect 1-to-1 technical comparison, but the philosophy fits. The team provides the hardcore technical foundation, and developers build their own custom systems on top of it.
- The goal: They aren’t saying every single developer should build a custom engine. They are just providing the option to do so without forcing you to spend four years building the absolute basics from scratch and surrendering control over your own game world.
One developer perfectly described working with Brutal as sitting on a hard bar stool, whereas using Godot feels like sinking into a comfortable couch. Brutal will never be as feature-complete as Godot. The creator isn’t telling you to drop Godot; if you need the high-level abstraction, visual tooling, and ease of use that Godot provides, you should absolutely stick with it. But if you want to build something custom on a rock-solid technical foundation without starting from absolute zero, Brutal is your answer.
Licensing terms
Brutal ships with a custom license based heavily on MIT, but with an added attribution clause. Because of this, it is not strictly open-source; it is considered source-available, similar to how Unreal operates, unlike Godot. This distinction is crucial.
You can use Brutal for completely free, even for commercial games. There are zero royalties and they do not take a cut of your revenue. However, your game or product must comply with these rules:
- Display the Brutal copyright notice prominently in the credit screens.
- Display the Brutal logo before the gameplay actually starts.
- Distribute a
NOTICE.txtfile alongside your game.
If these conditions are absolute dealbreakers for you, the team can arrange a separate commercial license. They also offer direct, hands-on support from their engineers. If displaying the logo actively harms your project—like in a non-profit application—you can contact them to waive the requirement. So, unless you get explicit permission or buy a commercial license, you can use Brutal commercially as long as you hit those three requirements.
How to get started with Brutal?
A massive chunk of Brutal’s documentation is currently missing online. If you click the documentation link right now, it leads to a dead page, though they promise content is on the way. So, if you rely heavily on step-by-step documentation, you might want to hold off for a bit.
Brutal is distributed entirely through NuGet. Here is the quick start process:
- Spin up a new console app.
- Add the Core and GLFW packages.
- Run the sample program.
The sample program is bare-bones. It initializes, checks for fatal failures, generates a window, pops open a 720p display, monitors if it should close, polls for events, and exits. The window itself does absolutely nothing, but it hands you a working Vulkan package so you can immediately start writing your own custom renderer.
Platform support
Brutal officially targets Windows, Linux, and macOS. It is currently unknown how well it handles consoles. However, since it runs on Vulkan, theoretically, with some elbow grease, you should be able to get it running on almost every modern console.
What is inside Brutal?
The repository is written 100% in C#. Here are the core components, each split into separate NuGet libraries:
- Brutal Core: Basic types, attributes, platform detection, pointer helpers, and Roslyn analyzers.
- Interop layer
- Memory management: Unmanaged memory management and allocators. This is arguably the most critical bottleneck to master when building games in C#.
- Allocation-free collections
- Allocation-free string building and processing
- Vector, matrix, and numeric types
- Job system and threading
- Logging and localization
- Vulkan: Bindings, abstractions, and a Vulkan memory allocator.
- OpenGL: Bindings and shader compilation.
- Windowing and input: Handled via SDL, complete with image, audio mixing, and font add-ons.
- Dear ImGui and ImPlot bindings: Including the highly requested docking branch.
- Mesh utilities: Texture loading, KTX and compressed formats, GLTF (3D model formats), and heavy mesh optimizations.
- Font rasterization
- Audio
- Networking
- 3D and 2D physics: Handled via Jolt and Box2D.
- Runtime monitoring and RenderDoc capture
- Native file dialog, terminal UI, and compression
How the dependencies actually wire together isn’t totally clear yet. It is safe to assume Brutal Core is a hard requirement for most of the other libraries. The collections will likely be pulled by other modules as well. Because of this, it is unclear how easy it will be to rip out a single component and use it in isolation.
There is no renderer
The most glaring omission is that Brutal does not ship with a renderer. You cannot just call sprite.draw to throw an image on the screen; you have to write the rendering logic yourself. However, all the low-level tools you need to pull that off are sitting right there. If Brutal gains traction, a community will undoubtedly form around it, and we will start seeing plug-and-play renderers popping up on NuGet built entirely on top of Brutal. I’d bet money we will see 16 different community renderers within a month.
Who is Brutal for?
Brutal is strictly for veteran programmers who demand total control over their architectural decisions and are fully prepared to build and maintain the deep systems their games require. The scope is intentionally bottlenecked. The team prioritizes low-level functionality for hardcore games, and all contributions are judged heavily against that mission.
- Not suitable for: Developers looking for a visual editor, an all-in-one environment, built-in animation rigs, or drag-and-drop asset importers.
- Suitable for: Developers looking to build custom tools that rival those features, or those who want to construct the pipeline entirely themselves.
Its closest rival isn’t Unity or Unreal right now. Brutal is best described as a high-performance, low-level framework heavily optimized for C# game development. In a way, it acts as the foundation that MonoGame sits on. MonoGame had to build a lot of this heavy lifting itself, but theoretically, a massive chunk of MonoGame could be rewritten entirely on top of Brutal. It wouldn’t shock me if someone does exactly that: Brutal handles the brutal low-level execution and raw performance, while MonoGame provides the friendly, high-level features.
The ecosystem that could potentially sprout around Brutal carries massive potential.
