Code Quality in Video Games

Video games have a reputation of running on messy spaghetti code. That may be true, given that games are extremely complex systems that are often trying to push the state of the art forward. Plus, noone really knows what they are doing, which doesn’t help.¹

But we shouldn’t just be content with low quality code. In this day and age of LLM code, I feel like this topic is hotter than ever.

“Diablo 2 had a terrible code base. (…) It’s worth Billions today. Maybe it doesn’t matter if vibe-coding produces crap code.” - Grummz on X

Man. I hate this take with a burning passion.

Good code never goes bad

That’s the thing with code. If you are smart about it, it never goes bad. A solid system with well defined inputs and outputs will serve you well for as long as you want. So put some effort into it! Treat it as an investment! It will later allow you to go very fast. ❤️

My most recent example happened while working on our game called Manabies. I spent quite some time setting up various systems on the project - save system, online features, scene manager, popups helper, just to name a few. That was a lot of work. But recently it all paid of when I rewrote our entire startup flow in one afternoon, when the estimate was ~week. That was just delightful.

On the contrary, bad code slows you down like crazy. We all know the feeling of having to work in a bad part of a codebase. Each little change you need to do is agonizing, the system is brittle and lends itself to hacky solutions that don’t exactly help. Avoid this like the plague, because it is.

Survivorship bias

Some games achieve greatness despite the horrible state their codebase is in. One famous example is Undertale and its dialogue system. Sometimes the Diablo series is brought up (as in the quoted tweet above). Or Minecraft and it’s curious server-side light calculation.

These are the exceptions, not the rules!

Don’t be so sure you can manage to finish a game whose code is garbage. Not everyone has the mental fortitude to do so. You don’t see all the games that never saw the light of day, because their author was too disgusted to even open the project.

Making games takes a long time and I find this advice very helpful:

My tips for better systems

This is obviously a work in progress - I’m learning a lot every day. But these things I feel strongly about enough to share.

1. Don’t overcomplicate things. Don’t create a result class if you can return a tuple. Avoid inheritance. Enjoy pure functions.²
2. Don’t over-automate. Don’t let one action waterfall into a 100 other actions. There will come exceptions later and you will regret being too smart. One extra line per usage is worth the flexibility.
3. Have knobs to turn. Think about what parameters a system has and leave them exposed. Obviously don’t hardcode magic numbers.
4. Reset state reliably. If your game has a centralized source of truth, make sure that you can erase it easily.³ Don’t store pointers to data that may change.
5. Understand your lifecycles. Your code should react to events as they happen. Avoid arbitrary delays. This goes for async too.
6. Clean up after yourself. Don’t commit commented out blocks of code. Remove unused functions. Obliterate unnecessary variables. If you have an opportunity to simplify, do it now.

Hope this helps and thanks for reading!