I believe every game developer should be using whatever tools they can to improve their workflow, rather than doing everything by hand or from scratch. But what do I mean by tools? Level editors, debuggers, analytics...? All of those, and more! In this article, I'll break down the different types of tools available to game developers, and explain why you'd want to use each.
Why Bother With Extra Tools?
When you are developing a game, certainly the time will come when you have to start adding content to it. This might be an easy task at first: just set up some arrays and objects inside your code. But as your development progresses, I can almost guarantee you your content code will start to look messy.
Imagine you have ten levels of a platformer game laid out in code, with enemy spawn positions, objects, items, tiles, and everything else in it. As you're playtesting it, you notice you need to change the spawn position of an enemy. The content of the level is in that big file with all the information for all the levels. It sure sounds like a headache to go through all of the code looking for the exact line to change. And that's not even considering changes that may affect other changes - like the position of a platform which an enemy is standing on.
Of course, you may also want to visualize your level and be able to change it on the fly. This isn't possible looking at the code.
Writing tools to aid you on your game development process is a more complicated but more rewarding approach. You could write a tool that would translate all that content code visually into the level itself for you, and as you change it, the tool would change the content code. You could also write tools to help create more content for your game, help you debug your game and even help deployment to multiple platforms as well. Or you could go one level higher and release the tool to your players and let them create content for your game too!
This can even increase the success of your game, as you may note if you look around for recent games that have been doing that already.
The Different Types of Tools
Let's take a look at the different tools you can make, how each one can help you add and manage content to your game, and the difficulties involved in creating them.
This is the broadest section. A creation tool is anything that adds content to your game - items, characters, levels, music... These tools are the ones you'll spend the most time with, because finishing your game will revolve around them: creating the levels, items, and enemies; putting everything together; polishing every bit to its finest details. Any of these tasks might involve a creation tool.
Even if the level editor will only be used by you or your team, you must make its interface intuitive and easy to use.
Let us assume you have a level-based game. In order to create a good tool for editing your levels, the first task is to make the tool visually represent the level for you. That means it has to show you exactly how the level will look for your players. After that, it must allow you to edit the content somehow, so you can actually create the level. This is done through an interface. Read carefully now, because this is important: even if the level editor will only be used by you or your team, you must make its interface intuitive and easy to use. Why? Because nobody likes working with something that requires you to push a combination of buttons or click a bunch of buttons in order to add something as simple as an object in the screen. And that includes you and your team.
Even if you are the ones who created it and know everything about the editor, making an easy-to-use interface helps everyone adding content to the game. And if someone happens to forgets the shortcut of how to mark an object as "collidable", for example, then having an intuitive interface will be a huge help.
Here's an actual example - a simple level editor I created for a Windows Phone 7 chain-reaction game:
As you may have noticed, the entire level editor exists inside the Adobe Flash Professional software - I did not create a separate app. Flash Pro was a perfect environment: it required zero effort in creating something to handle drawing graphics on the screen for me, since I was looking at a simple tool to help me create the levels for the game. The only thing I had to do was create a very simple extension (as you can see on the video) to save all that level information somewhere for me (I used an XML file).
Everything else was handled for me by Flash Pro: I could set the screen size exactly to my game's screen size, I could place all the objects at their real size on the screen and insert guides to help me visualize where the shots would go after an object had exploded. The testing process was as simple as "compiling" the project in Flash, which would open up a window asking where to save the XML file; when I compiled my game again, it would read the updated XML.
Now, let's imagine you have a shoot-'em-up game. Have you ever tried to create one before? It's annoying (and complicated) to set up all those enemy movement and shooting patterns through code itself, and setting up the timing is also tedious.
Here's a shoot-'em-up level editor I created as another experiment:
This is an example of what not to do. Although my editor had the basic functionality of letting you set up enemy movement patterns as you liked and even included some helper functions (in that case mirroring the enemy I was editing to create a "mirror" effect when the enemies appeared in the game), the interface was a complete failure.
I didn't have a way to visualize all the level at the same time: all I could do was visualize wave by wave. Have you ever imagined how painful it would be to change something in the level that way? If, for example, I wanted to delay the spawn time between the enemies of the current wave by 400 milliseconds, I would need to go through all subsequent waves and add (
400ms * number of enemies changed) to all of the initial spawn times of the other waves. For this very basic reason, I ended up having to recreate the tool from scratch.
Creating creation tools is a very difficult task. Perhaps these are the hardest of all the other tools to create, since you'll be dealing with them on a daily basis in order to make your game. You need to make them as quick and easy to use as possible, and they must not get in the way of actually making the content for your game. If you find out you need to spend minutes or even hours changing things in your editor because you changed something else that had to be fixed, then you might want to rethink whether the tool is serving its purpose.
In-Game Editors (A Special Case)
An excellent approach is to create in-game editors. These tools allow you to change content while the game is running, and to test what you changed at run-time.
Tools like these push your productivity to the limit, because you have instant feedback on the changes you have made. Some editors allow you to change even the value of attributes as your game runs, allowing you to run commands in real-time and watch the results. You can also "bend time" and record the actions you did in the game, then change attributes in your game (gravity, for example) and see what the movement of the player doing the same actions would look like under that new environment.
Take a look at this example of an in-game map editor for a game in development, Concerned Joe:
These are probably a programmer's best friends. When something goes wrong with a game, debugging tools help you find out what it was. They can also show statistics about your game, examine the process time of every function being called in your code, provide memory dumps when something fails, create logs as long as the application is running, and more.
When programming a game, a programmer will often use many of these tools - particularly the development environment's own debugger, if it has one. However, many other tools can be written to aid with the game development process in this area.
For a very complex game, you often want to be able to recover the function call stack when something crashes (so you know exactly which lines of code caused the crash) and generate logs as often as you can. Of course, you need to be able to interpret these logs. Maybe a tool to help you analyze logs could come in handy...
For example, look at this tool created by Adobe, called SWF Investigator:
This tool, created to analyse SWF files, enables the developer to investigate a variety of things of their game, including code analysis (it's able to disassemble the SWF in order to examine exactly what the application is doing), which is very important to a game developer - particularly when optimising code.
The task of writing a debugging tool, however, is very difficult. Not because it must have a "perfect" interface like creation tools; often these tools are used only by programmers and the core development team, and the interface doesn't matter that much. (Of course, it must still be able to show everything of importance to you and allow you to manipulate things through it with ease.) No, it's difficult because of the huge amount of technical detail that must go into them.
These tools, though, could help you make your game run better on your players' platforms, which of course is very important.
Deployment tools are needed when you have a team working on different aspects of the game (maybe an artist and a programmer) and when you are developing for multiple platforms. When developing for multiple platforms, you need to take into consideration the screen size of every device (particularly for mobile games) and the technical limitations of every platform.
Imagine developing a game for a smartphone with a resolution of 1280x768 and a tablet with a resolution of 1920x1200. You will probably want to use two different sets of images for every device, because you don't want to use images for the smartphone and scale up them for the tablet - that would look ugly. Additionaly, your smartphone probably doesn't have enough memory and processing power to handle the big images that you're using for your tablet. Because of that, a deployment tool is needed to aid you in managing the assets for your game.
Talking about managing assets, suppose now that you're working in a team, which consists of an artist and a programmer. The artist will definitely create a lot of art assets, but how is the programmer going to handle referencing these art files in the game? The laziest approach would be to just change or add the name of the file in every place that the code uses it whenever the artist changes or adds art files. However, for big projects this is not possible, as it would take away good development time.
A good way to handle it would be to create a tool to manage art assets for the team: the artist simply specifies which art file refers to what, and the tool will automatically convert the files' names to a predefined name set by the tool itself. That way, the programmer doesn't need to worry about changing names in the code whenever the artist changes something.
These tools are easy to overlook, but you should definitely use them in your games. Post-release tools help you track how your game is doing out there in the market and how players are receiving it.
This is very important for viral web and mobile games, but desktop games can also benefit a lot from these tools. They'll let you track where the game is available and how many players have played your game. They can go even further: tools like Playtomic, Mochi Analytics and GamesAnalytics can track how many times a given level was played, how many times a button was clicked, how many players dropped your game (in the first minute, first five minutes, second level, and so on) and more. You could then use this information to infer that a particular level is too hard (based on the number of players who don't complete it) and then fix it.
There's more: you can also write tools to track the public reception of your game in the internet, using bots that gather information of Facebook posts or Tweets that include your game's name, show you which review sites have reviewed your game and so on. Let's also not forget about Google Alerts, a great tool that notifies you when a specified term appears on the web.
Do I Have to Write My Own Tools?
Although you really need to use tools to assist your game development process, sometimes you will find that you don't need to actually create them, as the game development community has created many tools already.
Many excellent game dev tools are out there online, available for you to use - it just takes a little time to find them. But use them with caution: if you feel a tool doesn't do exactly what you need, it might be better to write your own than to waste time twisting it to fit your game. This is often the case for game- or genre-specific tools.
Actually creating a tool is a huge topic that deserves several articles on its own, but I'll give you one tip here: you will often need to standardize the way that you handle your game's content. This means you need to come up with a way to store your game's information, be able to load it and save it. Most people use XML or JSON for describing information, but you may want to create your own binary format if you need a more specific way of describing things.
That's the end of my analysis of the different tools you can use to help you with your game development. I hope you enjoyed the article and learned from it! If you have any questions, please don't hesitate to ask.
Editor's Note: We're going to be compiling a list of great tools like Ogmo Editor, Tiled, and SFXR. If you have any suggestions, let us know!