Our industry is rotting from its core, outwards in every direction, and it has been for some time. Driven by greed, driven by a race to the bottom on price. It is my position that the games industry was already heading somewhere unsustainable before reverse-engineering and powerful agentic processes became widely available. These have pushed things over the edge.
But I think one of the biggest problems is something we don’t discuss enough. Developers have surrendered an extraordinary amount of control over their work to companies whose interests aren't necessarily aligned with their own.
So we're doing something about it. We're making the BRUTAL Framework publicly available, with its source code, and we’re making it free to use, including for commercial games, subject to an attribution requirement.
I'm Dean Hall. I originally made DayZ, and now run a New Zealand game studio called RocketWerkz, as well as a new gaming distribution platform called Ahwoo. Our games include Stationeers and ICARUS, among others. We’ve used BRUTAL to replace engines in several of our games currently under development. This is the same framework we've used to make Kitten Space Agency, and which Ludeon used as the foundation for their new Waylith engine for RimWorld.
The BRUTAL Framework
Four years ago our studio began developing our own custom framework. At the time, it seemed like the kind of thing that only a "crazy" developer would do. Something that would make people shake their heads. Making your own technology was such a "red flag" for a studio that it was even a secret undertaking internally. It started with a few libraries. But it gradually grew, and then rather rapidly became a complete framework you could use to make a game or your own game engine.
We called it the BRUTAL Framework.
It is important to explain that BRUTAL is a framework, not a game engine. You can make a game directly using it, like we have with Kitten Space Agency, or use it as the foundation for an entirely separate engine, like Ludeon have with RimWorld.
At its core is a custom interop layer, giving C# access to native APIs and libraries. We've built quite a lot of supporting libraries around this, including mathematics, memory management, strings, job scheduling, logging, localization, and other systems. We have an obsessive focus on reducing allocations and unnecessary overhead. We make extensive use of unmanaged memory and unsafe code where it makes sense. Our core focus has been on doing a few low-level things extremely well, using the latest versions of C# and Vulkan.
You can use the Vulkan bindings to make your own renderer, for example. But BRUTAL doesn't make all those decisions for you. You get to make them yourself. You can use whatever NuGet packages you want, including third-party packages. You get to write your own stack. In some ways this makes it much harder to use than Unity, Unreal, or Godot. In other ways, particularly if you're doing something unusual, it makes things considerably easier.
It's called BRUTAL for a reason.
Personally, I have found it much easier. But this comes with a forcing function. You actually have to know what you want to do first. In Unity or Unreal I would often spend days or weeks figuring out how the people who made the engine intended something to work, and then how to get around the assumptions they had made. Without all that, it is actually faster. At least for the kinds of games we're trying to make.
What BRUTAL is not
I do not believe this is the tool that everyone should use to make a game. We've aggressively pushed back against efforts internally to "add more". Our intention is to make a focused and efficient tool for "hard-to-make games". We are not trying to make something that can do everything for everyone. In fact, one of the most important decisions we've made is what not to put into BRUTAL.
This means we're going to be quite aggressive about maintaining its scope. Pull requests that drift away from a clear purpose will be rejected. That isn't because we don't appreciate contributions, but because adding everything is exactly how the industry ended up with the kind of engines we don't wish to use.
Think of the relationship between the Linux kernel and something like Ubuntu. It's not an exact technical comparison, but it gets across the idea. We provide a technical foundation, and developers build their own systems on top of it.
I'm not suggesting everyone should make their own game engine. I'm suggesting every developer should have the option to do so, without having to spend four years building the foundations first. And without having to surrender so much control over their own work.
RimWorld and the Waylith Engine
On May 1st, Tynan Sylvester, RimWorld's creator, approached me with a problem, and I pitched him the BRUTAL Framework. Since then, Ludeon have been able to leverage BRUTAL to help build their own game engine, called Waylith. You can see for yourself what incredible work they've managed to achieve, in a remarkably short space of time. From that conversation to the announcement was only about five months.
Their team amazingly extracted the last bits of Unity out of RimWorld to create their Waylith engine. Moving such an established game, with a huge modding community, off Unity without anything breaking is extraordinarily complex. I'm enormously impressed with what they've achieved.
I also think this is an excellent demonstration of what BRUTAL was intended to enable. An established studio with a very specific set of problems can take the framework and build an engine designed around their own game, instead of spending years building the underlying foundations.
You can read more about what Ludeon achieved in their Steam announcement.
They report performance improvements of 2 to 4 times in their own tests, with the vast majority of existing mods remaining compatible. The new engine is available right now through RimWorld's unstable beta branch. That's an extraordinary piece of engineering, and I'm very pleased BRUTAL could play a part in it.
Kitten Space Agency
Kitten Space Agency is our free spaceflight simulation game, and the first major project we've built directly using BRUTAL. The inspiration came from Kerbal Space Program, and our desire to take that kind of game further. We wanted to simulate spaceflight at enormous scales, with high precision, complex physics, without compromising what we wanted to do because of assumptions made by a general-purpose engine.
It's also brought together one of the most extraordinary groups of developers I've had the privilege of working with. Felipe Falanghe, the original creator of Kerbal Space Program, helps steer the direction of the project. Stefan Moluf joined us after spending nearly twelve years at SpaceX writing flight software for actual spacecraft. I find it somewhat absurd that we have someone who helped program real rockets now helping us program pretend rockets.
We also have some of the most influential people from the Kerbal modding community. Casper works on our terrain and planetary surfaces. Blackrack, who created Scatterer and helped transform what was visually possible in KSP, works on atmospheric rendering and related systems. Jamie Leighton (JPLRepo), a former lead engineer and QA manager on Kerbal Space Program, brings extensive experience both from developing KSP and creating some of its most important mods.
These are people who have already spent years pushing the limits of what is possible with a game like Kerbal Space Program. Now we're giving them direct access to the underlying technology to do things the way they actually want to do them.
The game runs a solar system at real scale, with complex orbital trajectories, enormous distances, and very different requirements around rendering, coordinates, and simulation. The important part for this announcement is that none of this is built around a traditional game engine. We use BRUTAL and develop the systems that KSA actually needs.
Kitten Space Agency is available as a completely free pre-alpha through Ahwoo. You can download it and see the technology yourself.
Felipe Falanghe, the Creator of Kerbal Space Program
I first met Felipe a long time ago while I was making DayZ, and there was an instant bond over how we felt about the games industry. We reconnected when we started making Kitten Space Agency. Felipe is, in my opinion, one of the most underappreciated developers in our industry. He made one of the most influential games of our generation, with scientists and astronauts referencing it. Yet I don't think he's received nearly the recognition he deserves.
He was also the first outside developer to use BRUTAL. Having his team as external users proved incredibly useful, ensuring the framework is truly agnostic from developer usage. Felipe and I actually spoke with Game Developer about BRUTAL late last year. He has this fantastic habit of being able to explain something very well, especially when I tend to explain things far too emotively.
He described working with BRUTAL as sitting on a bar stool while everyone else using engines like Godot was sitting on comfortable couches. I think that's a fantastic way of describing it.
Perhaps most interesting was how Felipe approached the framework itself. Rather than starting with how an engine expected something to be done, he could start with the problem itself. One example was using high precision coordinates in rendering. With his approach, he explained, "you get to use high precision numbers as far as you can into the game execution."
You can read our interview with Game Developer here.
Felipe is making his next game using BRUTAL. I'm deliberately not going into detail about it because that is his story to tell. And Felipe is the kind of person who is captivating when telling a story. I've seen what he's cooking, and I can't wait for everyone to see it. Having someone with his experience working directly with the framework, challenging our decisions, and approaching problems differently has been enormously valuable.
You are only as independent as your tools
I have watched Unity and Unreal consistently fail to be accountable to developers. And I think this problem could get much worse as agentic workflows begin undermining the competitive advantages that have protected established software companies.
My concern is that as those advantages erode, the companies involved will increasingly look to extract more revenue from developers who feel they cannot switch. Whether through royalties, subscriptions, or more restrictive licensing.
When I attend GDC I often go to the Tencent Summit, where Tim Sweeney, the CEO of Epic, has given keynotes. Tim was, for a long time, a hero of mine. A powerhouse of a programmer with a mind I admired growing up. But over time I became frustrated with how much of the discussion seemed to revolve around the latest buzzwords. The metaverse one year, AI the next. Meanwhile developers were struggling with performance, stability, and the practical consequences of decisions made by engine vendors.
At GDC 2025, during a Q&A, I asked Tim whether he thought Unreal was accountable to developers, particularly around performance and stability. His response was about making more demos and putting them on social media to counter people describing games as "Unreal slop". I interrupted and asked whether more demos were actually part of the problem, because they set expectations with customers about how easy it was to achieve those results. I was not satisfied with his answer, and I continue to believe Unreal is not accountable enough to developers. Particularly when it can take a 5% royalty on game revenue above its licensing threshold.
I don't think developers should have to simply accept that relationship without questioning it.
Unity has had its shares of public issues with developers, enough to warrant a whole essay on. Ironically, even as I write this, Unity developers are dealing with account suspensions related to a mandatory security change. Some have lost access even after following the required process. Unity business decisions have repeatedly sent troubling waves across the games industry.
Imagine your ability to work on your own game depending on a decision made by a company you have absolutely no control over. Now, I don't think any of this means developers should abandon Unity or Unreal tomorrow. For many projects they're absolutely the right choice, and I'm not pretending BRUTAL could replace what they provide. But I think we've created an industry where the default is to become dependent on a few enormous technology companies, and we've increasingly accepted that as inevitable. It isn't inevitable.
I think we're going to see many more frameworks like BRUTAL emerge in this environment. Not because everyone will abandon existing engines, but because the cost of making alternatives is going to fall dramatically. I hope those alternatives are free. BRUTAL won't solve all of the industry’s problems, but for some developers it might offer a lifeboat.
This technology is a small step towards changing the balance of power. If the tools are public, if you have the source code, and if you're free to build your own systems on top of them, you have options. And if one day we stop being accountable to developers ourselves, they should have the ability to fork the framework and go their own way. That's important to me.
You are only as independent as your tools are.
This is how we fight back.
Credit and Licensing
We initially wanted to do something simple, like MIT. But that made us realise that one of the many problems open-source projects now face is what attribution actually means in a world increasingly dominated by AI and agentic development. Credit is, to me, what matters most.
The team who made the BRUTAL Framework are world class. They have backgrounds from some of the biggest and most influential game studios in the world. They're experts in their fields, and they've spent years developing technology that most players will never even know exists. They made this. I want history to remember them. So we've drafted a licence based on MIT, but with additional attribution requirements.
You can use BRUTAL for free, including in commercial games. There are no royalties and we don't want a percentage of your game's revenue.
What we ask is that a game or product built with BRUTAL includes the BRUTAL copyright notice in its credits screen, shows the BRUTAL logo before gameplay starts, and ships the NOTICE.txt file alongside it. If you don't want to do that, we can arrange a separate commercial licence. We can also provide detailed support directly from our engineers. You can contact us about waiving the logo requirement, for example for non-profit projects or where displaying the logo would be detrimental to the application's purpose.
We're describing BRUTAL as open-source, although our custom licence has not been reviewed or approved by the Open-Source Initiative. We recognise there will be discussion about whether these attribution requirements meet everyone's definition of open-source, and I welcome that discussion.
There are already OSI-approved licences that allow certain forms of graphical attribution. We think there is room to explore how attribution should work in an increasingly agentic world, and we intend to develop the licence with community feedback, including exploring formal OSI approval.
I'm not particularly interested in fighting over terminology. I am interested in making the source code and the work of our engineers available for anyone to use, modify, and build upon, without paying us royalties. And I want to ensure the people who made it receive some credit.
Who built BRUTAL
I've talked quite a lot about credit, so I want to acknowledge some of the people whose work has made this possible. I can't name everyone, and I've already mentioned several contributors above, but I think it's important to put some names to all this work.
Our Enterprise team develops and maintains BRUTAL. They have achieved something I'm enormously proud of. Aaron Koolen-Bourke, Benoit Fouletier, Chris Howlett, Craig Warne, Eric Chiu, Hanan Finnerty, Jane Kim, Josh O'Hagan, and Max Johnson. Additional past or occasional contributions from Ghassen Lahmar, Daniel Southon, Simon Brown, Felipe Falanghe, Brogan King, Hadley Patchett, and Max Kooij.
Our Head of Engineering, Rian Drake, brings enormous experience from his work at Grinding Gear Games and has provided the technical leadership and vision behind much of this effort. He is truly extraordinary. Bobby Lever is the Senior Producer helping tie everything together, and Dr Zac Isaac is our Senior Mathematician.
Across the wider RocketWerkz team there are many others. Simon Brown stewards technical development generally, including leading Stationeers and Torpedia, the latter having migrated from Unity to BRUTAL. His talent, skill, and ability are impossible to ignore.
We also have new people joining us from some of the world's largest game companies, bringing their experience to this effort.
I know I've missed people. But I want everyone to understand that BRUTAL is the result of years of work by an incredible group of engineers and developers. I am humbled and proud to work with all of you. When I talk about wanting credit for BRUTAL, these are the people I'm talking about.
Managing submissions on the repo
As a team we've been agonizing over how to approach public contributions, particularly pull requests and issues, in the age of agents. Agentic tools can make individual developers extraordinarily productive. But they can also make it very easy to submit enormous amounts of code without understanding it, testing it, or considering how it fits into a project. This is already overwhelming even large, well-resourced open source projects.
We've come to the conclusion that we simply have to throw ourselves at the problem. So you will be able to submit PRs and issues, and we'll try to figure it out. We're a relatively small team, and maintaining a public framework is going to involve a lot of work. So please be patient with us. Our plan is to see what happens initially, assess the problems, and change our workflows as necessary. I'm more than happy to listen to feedback and change our approach.
What won't change is BRUTAL's focus. We are not trying to build another general-purpose game engine. We're trying to make it easier for developers to make their own.
How to get started
It is ready right now. Here is how you do it.
The source code, the README and the contribution rules are on GitHub: https://github.com/ahwootech/BRUTAL
You will need the .NET 10 SDK, and a Vulkan capable GPU with current drivers if you intend to render anything. Windows and Linux are supported.
BRUTAL ships as NuGet packages, one per library, so you reference only what you need. Create a console project and add Core and Glfw:
dotnet new console -n HelloBrutal
cd HelloBrutal
dotnet add package Ahwoo.Brutal.Core
dotnet add package Ahwoo.Brutal.Glfw
Replace Program.cs with this:
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();
Run it with dotnet run and you have a window with no graphics API attached. What you add next is up to you. The Vulkan packages give you what you need to write a renderer, the ImGui packages give you a debug UI, Concurrency gives you the job system, and Fmod and RakNet give you audio and networking. The full list of libraries, with what each one is, is in the README.
Questions about using BRUTAL go on the forums. Bugs go on GitHub, with a minimal repro. Read CONTRIBUTING.md before opening a pull request. It covers scope, what we expect from AI-assisted contributions, and the sign-off every commit needs.