In this post, we’re going to highlight the benefits of creating tools and their importance to the game development process.
Firstly, let’s establish what we mean by a ‘tool’. By definition, it’s “A program that is employed in the development, enhancement, or otherwise support of other programs’. Examples of this in game dev are “Big Level Editors” to help create vast terrain or “Small text helpers” (Find/Replace) to search your code for functions.
At Payload Studios our flagship game, TerraTech, has been developed using Unity. One of Unity’s key features is its tool editor which has allowed us to develop and implement our own custom tools. A simple automation tool, for example, means you don’t have to do the same thing over and over again. Repetitive tasks are mundane and a time sink, so people get bored and lose focus which is where mistakes can creep in. Something like following a guide or step list can be condensed into the click of a button. This has the added benefit of reducing the need for other team members to learn the internal steps of a process if instead, they can click a single button to accomplish something.
A good example of this is a build script. A typical build in Unity might include baking level data, building asset bundles and maybe even setting options and define symbols for different configurations. The naive way to approach this would be to start by making a build by hand, manually going through the steps, one by one. This is easy because it usually starts with a single step. Quickly that one step can turn into a list of, on their own very simple instructions, but missing a single one is likely to result in a complete build failure.
Eventually, someone will need to make another build. This is the part where you hope you documented the process in the first place. No one wants to play the guessing game and debug why their build process isn’t working – especially since they could have avoided it by writing down a few simple instructions.
But even with a step by step guide, there is a lot of manual work and with it room for error. But perhaps more importantly – documentation is notorious for getting out of date. Unless you are lucky to have someone on your team that regularly writes and updates documentation, more often than not it’s out of date. It may even be missing that crucial step someone added 3 months ago that no-one remembers.
That’s where build scripts come in! The single purpose of a build script is to make your life easy when creating builds, and it typically does this by collecting all the individual steps under a single ‘build’ command. That way, as long as you chose the correct configuration option your build will always do exactly the right step, or present you with clear error output in case something went wrong. A script is also less likely to go out of date, as it often has direct dependencies on the project. And because we all write clear, self-documenting code we don’t have to worry about maintaining a separate step by step guide! It also makes it easy for anyone on the team to create a build which increases the use of the tool.
Or
Custom Tools aren’t without their downsides though. There are some common pitfalls that are easy to fall into, such as being over-engineered and become too big and require more resources than it’s worth to maintain or are not user-friendly. But as long as you follow these basic rules you shouldn’t go far wrong:
- Determine what the problem is – Keep your requirements in-sight so you aren’t tempted to write redundant functionality.
- Long Term Maintenance – Prepare to maintain your tools with updates to prevent it from becoming obsolete.
- Smaller is Better – The smaller and more robust your tool is the more cost-effective it will be to use.
- Use it! – The most important thing is to use the tools yourself! No one is going to be able to use your tool if you can’t.
- Collaborate – If working in a team of any size talk to whoever will be using the tool in the future and learn about what their requirements are and how they would like to work.
One of the most used and valuable tools we’ve created during the development of TerraTech has been our localisation importer. It’s by far one of our most used tools and saves us a ton of time. All our in-game text starts off in a Google Sheet. We then save out a *.CSV file from it that gets imported into the game via a TerraTech tool. This generates multiple language text files that the game uses and also identifies whether any texture atlases for Chinese, Japanese, Korean and Thai fonts need updating.
Django Verbaant – Coder