Make Any Game You Can Imagine - Programming Lies
You have been told that the first step of creating the game of your dreams is to pick an engine. And from the moment you accepted that framing, your dreams have been bound, inhibited, curbed, without you even realising.
The lie was implicit. It wasn’t intentional, but it was there nonetheless: You can make anything you want [with these engines].
Can you travel through your voxel world at 7,400km/h in real-time?
Can you “simply” carve a tunnel through a world built entirely from mathematical equations?
Most programmers never find out. They optimise for shipping quickly, take the common path, and never notice the walls.
These aren’t theoretical examples, these are games that exist right now, built by programmers who went a different way.
Engines don’t remove the hard problems—they only bury them. If you want to grow as a programmer, you must eventually run the gauntlet.
By the end of this article, you’ll see why:
Understanding lets you go where engines can’t follow
Your tools define your possibility space
The constraint isn’t only technical, it’s creative
Understanding Lets You Go Where Engines Can’t Follow
A Flock of Meese has been sharing his Minecraft-like game engine for the Gamecube and Dreamcast:
The Dreamcast is a console from 1998. It has a 200MHz CPU, 16MB of RAM, 8MB of VRAM and a 100MHz GPU.
The difference between the Dreamcast and a typical gaming PC in 2009, the year Minecraft was created is orders of magnitude.
The Dreamcast peaked at ~7 million polygons/sec. An average 2009 PC: 775 million/sec—110x more.
This Dreamcast example is only possible because the programmer understands the hardware and the problem space at a deep level.
It also means that Minecraft could have launched in 1998. There was no technical reason that it did not exist yet, only one of human ingenuity.
We must assume that right now there are game concepts waiting to be discovered, that use the constraints of our current hardware to their maximum, and likely won’t be discovered for decades.
Your Tools Define Your Possibility Space
Here is the PC version of the same engine. Movement at 7,400km/h with a 1KM draw distance, in real-time with no frame dips, at 60FPS:
So far the developer has been quiet about his methods, but I can say for certain that you don’t get these kinds of results without deeply understanding the problem space, and the hardware.
Contrast this with the industry standard high-performance game engine: Unreal Engine 5. With typical cell sizes of 256m^3, and loading ranges around 768m radius, you can’t sustain that speed without FPS drops (called “hitches” in their documentation).
With the engine A Flock of Meese has created, game design ideas that aren’t even possible in other engines are unlocked.
Want to create a game about an immortal cat piloting ICBMs across a vast voxel world in real-time? You can’t do that in just any engine.
The Constraint Isn’t Only Technical, It’s Creative
Mike Turitzin has been sharing his SDF-based game engine, and the results are something else:
A gun that opens a traversable tunnel through arbitrary geometry in real time, and then closes it again.
Mike calls it simple, because he built the tools that made it natural to think about this type of operation.
The engine-dependent programmer never arrives at this idea because nothing in their toolchain points towards it.
The limitations shape the imagination before the developer even sits down to design the game.
Conclusion
The programmers in this article didn’t find a shortcut. They worked through the hard problems and came out the other side with the capability to explore spaces other programmers cannot.
They researched how programs work, the hardware, the mathematics, and created their own unique possibility space.
That’s the gauntlet. It’s harder. It’s slower. But what’s waiting through the fire isn’t just better code, it’s a possibility space that’s uniquely yours.
Fire is the test of gold; adversity, of strong men,
— Seneca