Why I Still Choose Custom Engines in 2026
A video version of this article is available on my YouTube channel:
There are many reasons I build my own engines from scratch, and one that’s not what you think... It has to do with the collapse of civilisation.
But first, let’s talk about the obvious stuff that made me quit game engines.
The Obvious
Why do most people stick with big engines like Unity even when they’re frustrated? I speak to developers that have successful games published that *hate* working in their engine.
For them, dealing with frustration feels safer than starting over, and much safer than going engine-free. But here’s the thing: much of what they are protecting is engine-specific trivia that never transfers anywhere else anyway.
I used to think that serialisation was difficult, because it was, back when I used Unity as my main engine.
Nowadays, with my knowledge of building custom engines, it’s not only trivial, but fun to write serialisation code for my games.
One of the reasons that serialisation was such a chore back in those days was because of Unity’s version control tool. It was rudimentary and had merge conflicts constantly that lost us hours or days of work.
And that’s not even to mention the compile times of these engines. Sitting around for tens of seconds, or sometimes minutes just to test a change is insane considering how powerful modern computers are.
When I’m writing my own game engine, 2D or 3D, if the compile time is greater than 1 second - something’s wrong.
Control
Beyond the day-to-day minutiae, it’s also about control.
What happens when something breaks in a 3rd party engine? You’re stuck waiting for a patch or workaround, and praying the patch doesn’t add more bugs.
In my world? I can dive in and fix it myself immediately - and, that forces higher quality. No excuses, no finger-pointing, because I’ll just be pointing in the mirror in that case.
I take full responsibility for any low-quality outcome.
My stat distribution heavily weighted toward programming. I care about software craftsmanship. This is my way to lead by example - proving you don’t need massive tools to make something great.
3rd Party Risks
If you want to take game development seriously and treat it like a business, you have to manage your risk profile. Using a 3rd party engine is a non-trivial liability. If at any point the incentives of you and the company that makes your game engine don’t align, they can cause serious damage. Here are some real stories to prove it.
Unity Runtime Fee Fiasco 2023
Back in 2023, Unity was the go-to engine for indies. That market share has been significantly eaten into by Godot since then - and this is one reason why.
If you somehow haven’t heard of the runtime fee fiasco, let me lay it out for you.
Unity announced a pricing change - adding a $0.20 fee, after a threshold, for the developer to pay to Unity *per installation* of their game. The kicker? It applied to games that were already published *and* to every instance of an installation - even the same user installing your game again after deleting it would incur a $0.20 fee.
As you can imagine, the game developer community was very upset about this - and, rightfully so. Many studios faced potential bankruptcy due to the way their games were priced.
Your free to play game that gets millions of installs per year, but makes no money? Pretty soon, you’d owe Unity 6-figures.
After massive backlash, Unity scrapped the per-install fee entirely in 2024, but the damage was done.
Many devs had their trust broken, and left Unity for other engines, or went engine-free.
Our Machinery License Termination 2022
Our Machinery was a game engine being developed by two ex-Autodesk developers starting in 2021. It was a promising extensible engine written in C.
It seemed like a reliable up-and-coming alternative without the bloat of engines like Unity or Unreal.
In 2022, the company shut down and terminated all licenses overnight, demanding that all studios using the engine delete their source code and binaries *within 14 days*.
There was no path for migration, and we still aren’t sure what happened.
One Hacker News user commented1 that a friend had been building a game using Our Machinery, and had started the painful process of porting it to Godot.
Arrowhead and Fatshark, the creators of the Helldivers franchise and Warhammer: 40K Darktide, respectively had invested financially into Our Machinery2. The engine’s failure meant that investment was wasted, though they weren’t developing games in it that we know of.
Unity Security Vulnerability 2025
Using new technology is generally riskier, but what about using something that’s been around for ages? Let’s take another look at a recent security vulnerability with Unity games published since 2017.
As indie game developers, we don’t want to have to understand everything about cyber security - so, we offload the responsibility to the authors of the tools we use.
But what happens when the people making the tools make a mistake? Everyone using them pays the price.
Any game made with Unity 2017.1 up until October 2025 - that’s 8 years - had to patch this vulnerability. Fortunately, Unity provided binary patch tools to apply the fix without doing full rebuilds and there is no evidence the exploit was used.
These aren’t hypotheticals that may *one day* happen. They have happened and will continue to happen.
With a custom engine? You don’t have that kind of risk.
Fun and Ease
Programming games from scratch is made out to be this Herculean task that only a few can accomplish. Maybe that’s true, maybe not. All I know is that if your stat distribution is over-indexed into programming, or you *want it to be*, then this path is not just possible, but *can be* easier.
I enjoy “low level” programming. Bit flipping, data packing, pointer abuse, memory management, all that kind of stuff. For me, it’s easier to create a small game engine that fits my needs than to learn and fight with a big game engine.
If you don’t want to start from scratch, working in a systems language like Odin or C means you can use pretty much any library out there easily.
From something like raylib, which handles windowing, input, sound, rendering, and even some collision detection, to something more bare-bones like SDL3 or Sokol.
I have no editor overhead. What I type is what compiles. And, it takes me less than 1 second to compile my game. My game, which, by the way, has a play test available on Steam, and also a web build playable on itch.io right now. If you are into Zachtronics style games, you’ll like LANE-4.
The Collapse of Civilisation
Finally, we get to the reason that may seem outlandish, but makes total sense - The Collapse of Civilisation.
As we move into this LLM-powered future, more and more developers are outsourcing not just their programming, but their critical thinking to idiot machines. Machines that are not conscious, cannot think, but can produce a simulacrum of what a human can.
The effect of offloading these skills is that less people understand how computers work at a fundamental level. This is an issue since almost all our infrastructure is built with computers of some kind - be that the tiny microcontroller in your air conditioner, or the high-powered CPU in your phone or computer.
It follows that if less people understand how to fix our infrastructure, that will create a skill-supply shortage. Increasingly, situations will arise in which nobody is available to fix the problem, and part of our civilisational infrastructure is left to degrade.
Knowledge is not automatically propagated forward, otherwise we would have a crystal clear understanding of the Ancient Egyptians, or the Mayans and Aztecs, or the Mesopotamians.
Instead, we have fragments to piece together a puzzle which can never be completely solved.
This loss of knowledge has happened in the distant past, and the very recent past. There are a couple of good talks on this, already, so I’d recommend you watch these if you are interested:
One is “Preventing the Collapse of Civilization” by Jonathan Blow
Another is “1177 BC: The Year Civilization Collapsed” by Eric Cline
Enjoyed this? I made Program Video Games for you.
Game Ideas -> Working Systems using first principles.