Last updated January 2020, 10 min. read

Best practices for building stable games with fewer bugs

What you will get from this page: Tips on maintaining a stable and flexible build to save yourself time and money. Get pointers on using version control, utilizing your changelists, clean cheat functionality, bug tracking and more

After years of shipping large titles with even larger teams, typical AAA studios know how to keep their productions on track and maintain a clean and stable build. Sascha Gundlach, from MetalPop Games, highlights how independent game developers can adapt the AAA approach to their own production. 

With a clean build, it’s easy to change or add things, as well as maintain and debug features. Overall, you’ll be able to develop your game faster and more efficiently.

The benefits of a clean build

Maintain a clean and stable game build and you’ll reap the benefits in the long run:

  • Release more stable games with fewer bugs.
  • Save production time, due to fewer bugs and a cleaner codebase.
  • Lower your chance of ‘breaking the build’.
  • Create demo versions and special builds easier.

Not all AAA build practices are suitable for indie teams. But there are a lot of things you can do to make sure your build stays clean and stable that are free (or affordable) and can be implemented by teams of any size.

Even if you are a one-person operation, these tips will help you to maintain a better, more healthy build of your game. 

Use version control

Even today, with the availability of free version control systems (VCS), there are still teams out there working with shared folders or dropboxes to collaborate. Developing without version control is a bit like driving without a seat belt. Wearing a seat belt might not always be comfortable and will restrict you a bit, but once you crash full speed into that tree, it will save your life.

You can’t afford to lose work no matter the size of your team. A hacked dropbox account or a broken hard disk should not cause you to lose days or weeks of work.

There are plenty of free solutions out there. Perforce, Git and SVN all offer free versions. And, with Unity Teams built into Unity directly, things become even easier.

A Perforce folder history showing all changes

Utilize your changelists

In addition to the safety a VCS provides, another benefit is that you will get changelists, which will help you to keep an overview of the changes done. The image above is of a Perforce folder history showing all changes.

Although most systems don’t force you to submit a description for a change you did, it’s good practice to describe the changes clearly.

In addition, creating ‘patch notes’ and similar documents becomes easy when you start using prefixes for your changes, such as these: 

  • !B: A bug fix.
  • !V: A visual change or improvement.
  • !G: A gameplay change.
  • !X: A change that should be ignored in the patch notes.

When you submit changes to your VCS and describe them with leading prefixes, you can run a script later over every entry and sort everything into a nice and clean patch notes document.
A clean submission to your VCS would look like this:

“!V Made explosion particle effect bigger”

“!B Fixed crash when picking up a weapon”

“!G Increased amount of health in med-kits”

If you keep all your check-ins clean and well described, it’s easy to compile patch notes documents when you need them. It’s a more efficient approach than manually going through your recent changes to identify things that should be listed in your patch-notes.

UI game code cleanly marking hacks and to-do code

Practice good hygiene

It’s important that everybody on your team is familiar with the basics of good build hygiene. Here are the top five best practices to keep it clean.

  1. No build-breaking code
    Don’t check in anything that you know is broken. If the feature you are working on is not finished but you need to check it in, either disable it or shelve your changes so they don’t break anything for the rest of the team. The rest of your team should not be blocked by a broken build because you checked in non-working code.
  2. No hard-coded keyboard shortcuts
    It’s convenient to add custom shortcuts for certain cheat or debugging functionality. “Just make the the F12 key the money cheat key, no one is going to press that anyway, right?”
    But hardcoding functionality like this to a key is dangerous because it’s easy to forget. You might end up shipping it accidentally, or your testers might be unintentionally activating it and polluting your bug reports this way.
  3. Mark bad and missing code
    Sometimes you have to hack. No matter how much you would like to avoid it, you will at some point have temporary hacks in your code. When you are adding a hack or workaround make sure to mark them in the code with easy to find keywords. Mark a hack with //HACK or missing code with //TODO. This makes it easy later on to search through all your code for those tags and find and replace them.
  4. Log spam
    Logging things in your code is useful and can help you track down problems. However, it’s important to clean up the log spam now and then so that important warnings and errors don’t get buried. Unless you are actively working on a feature, your console should be as clean and empty as possible, so that if something pops up, you see it right away.
  5. File names and naming conventions
    The size of your build will eventually grow to hundreds or possibly thousands of files. So it’s important to keep a clean naming convention.

When you start a new project take the time to come up with naming conventions that make sense for you, and force yourself to stick to them. Once you have names such as texturetestFinal01.png or backup22.fbx in your build, things will get messy fast.

Do routine checks and clean up any dirty file names which made it into the project.
Here are a few quick tips:

  • Use descriptive names
    AttackButtonBehavior.cs instead of atkBtn.cs
  • Use camelCase or PascalCase
    notsocleanfilename.cs isn’t as readable as MyCleanFilename.cs
  • Use underscores to make things in filenames more clear.
    WoodenHouse_Blue, WoodenHouse_Green, etc.
The cheat menu of our in-development game Galactic Colonies

Keep cheat functionality clean

You will constantly need to debug and cheat when developing your game. You might want to jump to a different level, give yourself extra cash, make yourself invulnerable, spawn extra enemies, etc.

You could add those cheats wherever you need them and disable them after you are done but it’s preferable to have a clean way to switch this kind of cheat functionality on and off.

Even for smaller projects, it’s worth investing the extra time to build an easy to use debug/cheat menu. Something that can easily be turned on and off by your developers and provides access to all the usual cheat and debug options.

Doing it this way minimizes the risk of accidentally shipping cheats with your game. In addition, having your ‘cheat code’ in one central place also makes sure everything works and is easy to extend.

Another benefit of this approach is that dev-cheating becomes much faster, saving you time in everyday production. Just pressing a button in your nice and comfortable debug window is a lot quicker than hard-coding values in your scripts.

Even a Trello board can be used to make bug tracking easy

Manage and track bugs

Your game will have bugs. Every game has bugs and your game will not be an exception. The question is, how do you deal with bugs.

The workflow to efficiently handle bugs is pretty straight forward: your QA department finds and enters bugs in your bug tracking system. Then they assign the issues to your developers, who in turn fix the issues and mark them as such. Finally your QA team verifies the issues and marks them as closed. An easy three-step process, right? 

Wait, what? You don’t have a dedicated QA department? Your testers are also your developers?

Don’t worry, because you don’t need much to stay on top of your bugs. 

First of all, track your bugs. This is easy even if you are a one-person team.

Pick a bug tracking software (there is a plethora of free and affordable ones out there) and set it up. If this sounds like overkill to you, go ahead and just use Excel or the even the notepad on your desk, it doesn’t really matter. What’s important, is that you have one central spot to collect and track problems. Once you have a system in place to track your issues, it’s all about discipline. A buggy build slows down production speed and can even create more new issues.

Here a few quick tips to stay on top of your bugs:


Bug-Fix-Fridays are a great way to keep your build bug free. Every Friday, instead of working on new features everybody works on items from the bug list only. This approach ensures you start the new week with a bug-free, stable build.

Don’t put it off for too long

If you know your bugs are getting out of hand it might be a good idea to stop working on new features and focus on stabilizing the build until things are back on track. 

Don’t fight fires all the time

If you have a lot of bugs that reappear, investigate the root cause. Is a certain part of your level building pipeline always causing levels to break? Is the way you parse your gameplay values from your .xml files breaking down every other day?

If you identify a system that is constantly causing problems it might be worth the time to rebuild it instead of repeatedly fixing the issues it causes.


With all these best practices and tips in mind, it all comes down to discipline and how much attention you pay to the state of your build. You can mix and match these suggestions and apply them to your indie production. The time you use on keeping your build in good shape is always worth it.

Did you like this content?

We use cookies to ensure that we give you the best experience on our website. Visit our cookie policy page for more information.

Got it