Game Code Sucks!

It’s a dirty little secret in game development. The actual finished code of most games sucks. It’s barely maintainable, often riddled with special cases, and the code authors are often embarrassed to have their code seen in public.

I’ve been a senior engineer for over a decade, I’ve mentored new programmers, I’ve written long articles about how to write good code. But I have to admit that a lot of my game code is crap. And I’m willing to bet that by the end of your project, your code will be too. Why is that?

  • The goals of a game are too vague to properly plan around. You can’t use a “waterfall” development model with any reliability
  • The “agile” development method with a multi-discipline team tends to focus less on code cleanliness and more on making a fun game, which is an incredibly hard task all by itself
  • Traditional refactoring approaches don’t work well because the GUI requirements are extremely detailed and intricate
  • Your time constraints are manic and often impossibly short

I’ve heard all the arguments for how to fix this problem; everything from “be a better programmer” to “use more extreme programming” to “just plan things better.” But these don’t reflect the reality of the situation. The reality is this: if you show me a game that has really clean and maintainable code, I’ll show you some other game that beat them to market and quite possibly took some of their sales.

This isn’t unique to indie gamers, either. Except for a few cases (the engine code at Turbine is reasonably clean), the game code I’ve seen everywhere has basically sucked. Even when the developers use Scrum. Hell, especially when using Scrum methodologies, because game functionality seems to win out over code cleanliness in those situations. Sure, it shouldn’t, yadda yadda, but it does.

So we have to live in the real world where game code sucks. But our code has to be maintainable! We have to keep this code working for years after the game ships. We will quite possibly want to use the code for a sequel. It can’t be entirely throw-away code. Where do we draw the line, and how? I’ll offer my thoughts on that next time.

3 thoughts on “Game Code Sucks!

  1. I try to keep my code nice and well-structured through development, but most of my problems come towards the end of a project when I assume that “since the project is closing and I will never touch this code again, I’ll just fix this problem with a quick hack”.
    And THEN the project takes longer to complete than anticipated and my little hacks are suddenly a big problem.

    IMO, the future belongs to managed code and programming environments with good refactoring support (Java with Eclipse, for example).

  2. > (the engine code at Turbine is reasonably clean)

    Wow, I felt quite the pang of pride reading that!

    Like many things, it’s about finding the right balance; how much future time am I going to save making this general and extensible, vs how extra much time is this going to take now? It’s always a guess, but you get better at it with experience. At Turbine in particular, we knew the engine code would be in use for many future years, so it often made sense to take the extra time.

  3. I agree with Jesper. A lot of the times I add hacks in at the end because it’s just not worth refactoring code for minor changes. Eventually you come to realize that when you’re near the end, you’re actually at the beginning of actually coding the game and past the point of fixing the core systems.

    There are some systems you can start adopting that really help development time. I found myself working with time a lot, procedurally generated animations or even timers for unit events. Instead of putting variables all over the place to save current time and compare vs. a max time just use something like a timer callback system.

    But with every game I put out, I’m also fine tuning the engine for faster development on the next game.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>