Reinventing the wheel is a waste of time - Programming Lies
Preface
As you may or may not know, I offer a free game engine programming course on my YouTube channel: C Game + Engine from Scratch. The most common question I get in the comments is “Why not C++?” followed by “Why reinvent the wheel?” or “Why not use Unity?” etc. I have outlined my reasons a couple of times in videos, but let’s add some more context.
Introduction
A myriad of confused programmers - either through poor education, lack of experience, or indoctrination into one or more of the various gratuitous acronym-based programming cults - find themselves believing misconceptions about their chosen vocation.
An ostensible pearl of wisdom proffered by thought-leaders and cult-leaders alike is the phrase “don’t reinvent the wheel”. Occasionally, one may have the inclination to investigate the bytes beneath the tortuous tower-of-abstractions - the very tower upon which so much of our modern day programs are built upon - the “tech stack”.
The curious programmer, upon further investigation, may decide to delve into the labyrinthine halls of the tower, perhaps glimpsing a peek of the vaults below. He may experiment there - probing and perhaps even modifying some of the code.
“Don’t reinvent the wheel!” exclaims the indoctrinated programmer, compelled as if he was a CPU executing a stream of instructions.
Ridiculed and covered in bile, the curious programmer must be restored to their place on the assembly line of programmed automatons produced by modern “educational” institutions.
The supposition of the phrase makes clear, whether directly or by common inference, certain demonstrably false assumptions about programming.
The wheel is perfect.
Problem X already has a wheel.
The Wheel Is Perfect
The wheel, as we know it at in the present, is an incredible device that appears to be perfect at converting torque into linear motion. However, this depends on the context in which it’s applied.
For variations of context, we have variations of wheels. If the wheel was already perfect, we may still be using the solid stone wheels invented in Mesopotamia over 6000 years ago.
History of the Wheel. Source: malevus.com
The design of a wheel suitable for smooth asphalt is different from one designed for rugged mountain trails. If you need to go through the snow, snow chains or studded tires are required to provide extra traction. In deserts, wide wheels are used to prevent vehicles from sinking into the sand.
There’s functional aspects to consider as well. Truck wheels are larger and more robust because of the weight they carry.
I won’t belabour the point - wheels have been reinvented for different contexts for thousands of years.
Problem X Already Has a Wheel
Let’s talk about game engines. Unity, Unreal, and Godot are the big 3 game engines. They have advanced toolkits that make them appear to be the ideal solution for most games that you may want to make - and that’s true.
However, these game engines are certainly not the best solutions for all problems. Any game design that falls outside their general use-case will have the programmers and designers fighting the engine trying to get things to work.
14 FPS in a 2D game. Source: reddit
Look at Oxygen Not Included as an example. It’s one of my favourite games of all time. It has horrible performance issues if you play one save file for too long. The trade-off for Klei choosing Unity is that the world size has to be small to mitigate the lag - and they still can’t mitigate the lag.
For a new game developer, the big 3 may seem like the only viable options. They are popular and have extensive resources available to learn them. As I always say, this may be true for you and your games - but it’s not true for everyone.
Someone has to create the next Unity. Someone has to create something bespoke that the big 3 just cannot do well enough. That someone may be you.
When The Big 3 Don’t Fit
The big 3 are designed to fit the general case - they must cater to a wide variety of genres and platforms. This is fantastic if your game fits within the scopes of these engines, and this broad scope means that they are inherently generic. For some projects, overheads of these engines - in terms of memory usage, performance costs, or even learning curve - can be too much.
Moreover, when you use a pre-built engine, you’re also confined to its architecture and limitations. While these engines provide flexibility, there’s a ceiling to how much you can modify or extend their core. For games requiring a unique mechanic, more simulation computation - as with Oxygen Not Included - or a different approach to rendering, this can become a significant barrier.
You Don’t Have to Build Everything
There are many battle-tested libraries available in a swathe of languages. If you cannot find something native to the language you choose - you can probably find a C version and most common languages have C interoperability.
Rendering engines like Magnum and bgfx allow you to draw complex scenes with all the features you could want. Physics libraries like Bullet and qu3e have most of the features you could want. These are just 2 examples of 2 areas that make up a game engine - there are many.
What’s the difference between using an engine and using a bunch of libraries? You control how these systems talk to each other. If you really need to, you can create custom solutions for the missing pieces - if nothing you find fits.
Conclusion
The phrase “don’t reinvent the wheel” holds merit in many scenarios. However, as I hope to have demonstrated by this article, there are many situations in which the wheel required reinvention. The context is vitally important.
I have been talking about games and game engines because that is what most interest me. However, you can extend this logic to all of programming. I don’t think we are close to finding a wheel in nearly any programming domain.
The next time someone questions the decision to build something from scratch - remember that without understanding, there can be no innovation. If we always stuck with the status quo, we’d still be riding on stone wheels.
Thank you for reading!
If you found this useful, join the mailing list for more!