On this page
AAA best practices for indie studios to maintain a healthy buildLast updated: November 2018
What you will get from this page: tried-and-tested practices on how to maintain a stable and flexible build pipeline to save yourself time and money. Topics covered include using version control, utilizing your changelists, clean cheat functionality and bug tracking.
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
- You’ll release more stable games with fewer bugs.
- You’ll save production time, due to fewer bugs and a cleaner codebase.
- The chance of ‘breaking the build’ is much lower.
- You can create demo versions and special builds a lot 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, the following tips will help you to maintain a better, more healthy build of your game.
Let’s get started and a take a look at the best practices and tips that will help you maintain a clean and stable build.
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.
Especially when you are a small team, you cannot afford to lose work. 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 offers free licenses for small indie teams, and Git or SVN are completely free as well. And, with Unity Teams built into Unity directly, things become even easier.
There is absolutely no reason to not have your game project managed in a version control system.
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.
A Perforce folder history showing all changes
Although most systems don’t force you to submit a description for a change you did, it is highly advisable to clearly describe the changes.
In addition, creating ‘patchnotes’ and similar documents becomes incredibly easy when you start using prefixes for your changes. Here is a set of recommended prefixes you can use to easily sort through your changes:
- !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 later run a script 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 have the discipline to keep all your check-ins clean and well described, it will be very easy to compile patch notes documents when you need them.
Manually going through your recent changes to identify things that should be listed in your patch-notes on the other hand, is time consuming and not fun at all.
Build Hygiene: keep your build clean
It is extremely important that everybody on your team is familiar with the basics of build hygiene.
Here are the top five best practices to keep a perfectly clean build.
1. No build-breaking code
Don’t check anything in 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 can be very convenient to add custom shortcuts for certain cheat or debugging functionality. "Just make the F12 key the money cheat key, no one is going to press that anyway, right?"
Hardcoding functionality like this to a key is dangerous because it is 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 will make it very easy later on to just search all your code for those tags and find and replace them easily.
(UI game code cleanly marking hacks and to-do code)
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.
If the console is so full with logs that important warnings and errors go under you will have a hard time finding out what is going on. 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. Keeping a clean naming convention is extremely important.
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 things like 'texturetestFinal01.png' or 'backup22.fbx' in your build, things will get very messy.
Routinely do 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.
Clean cheat functionality
While developing your game you will constantly need to debug and cheat. 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 is preferable to have a clean way to switch this kind of cheat functionality on and off.
Even for smaller projects it is 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 cheats and debug options.
The cheat menu of our in-development game Galactic Colonies
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 solid and is easy to extend.
Another benefit of this approach is that dev-cheating becomes much faster and you will save a lot of 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.
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 will assign the issues to your developers, who in turn will fix the issues and mark them as fixed. 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 really don’t need much to stay on top of your bugs.
Track your bugs
First of all, track your bugs. This is easy, really. Even if you are a one man team, setting up proper bug tracking is extremely easy.
Pick a bug tracking software (there is a plethora of free and semi-free ones out there) and set it up. If this sounds like overkill to you, go ahead and just use Excel or even the notepad on your desk, it doesn’t really matter. What is important, is that you have one central spot to collect and track problems.
Even a Trello board can be used to make bug tracking easy
Don’t let things get out of hand
Once you have a system in place to track your issues, it is 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. The idea is simple: At the end of the week, every Friday, instead of working on new features everybody is only allowed to work on items from the bug list. This approach will make sure that you start into the new week with a bug free and 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 keep on coming back all the time, you should investigate the reasons. Is a certain part of your level building pipeline always causing levels to break? Is the way 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.
Keep it clean
With all those 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 anything from the above list of practices and apply them to your indie production.
The bit of extra time it takes to keep your build in a good shape is always worth it and you will end up with a cleaner, better build.