Game Development Tools

(Note: The whole point of this post is to get you to join the IGDA Tools SIG, but I don’t get to that until below the fold, so I’ve decided to just push it up front here for those of you that don’t feel like reading my long tools rant. So, instead, please just go join here)

I’m a firm believer in tools.

I actually believe that good tools, provided both internal (from actual tools departments) and externally, are key to the success of any software development company, but especially game companies. I would go so far to say that 80% of any programmer’s job in a game development company is, or at least should be, making tools that make artists, designers, and other programmers happy. These are your engine programmers. They do good work, and they’re very important.

However, there should also be a good number of your programmers who’s *only* job is to keep your artists, designers, and programmers happy. These are your dedicated tools programmers, who do nothing but code and fix tools and process all day. If you don’t have these people, you’re missing out. Why? Think of all the places tools touch, or should touch, in game development and process that don’t actually involve working with your engine.

First, everyone benefits from a good build pipeline. Whether you’re doing continuous integration or not, having fast turnaround on art and code changes is always a good thing. Additionally, if everyone can grab changed assets quickly from central servers, that means work can get underway faster in the morning. The tools to do these types of things are usually available, but if you think an engine programmer (or worse, a producer) is going to go find them you are sorely mistaken. Of course, having that good build pipeline means also having good source control, and usually means having good integration between your source control and your tools for creating and exporting assets. And here, there aren’t usually tools available to you. You have to make them yourself, but the jump in productivity from this type of integration is enormous.

Additionally, programmers need tools themselves, but only the select few will think to make them, and usually only for themselves, on an ad-hoc basis. Deployment scripts, revision / code review change scripts, Visual Studio / WinMerge integration; these are all tools I’ve seen created by fellow programmers at game studios that never get passed around. But even then, there are tools that are incredibly useful that an engine programmer might never get around to. Memory inspectors, automatic bug reporters (and potentially bug collators), output filtering systems, external debug consoles, formal logging / metrics. All of these things are useful for programmers (and, in the case of formal logging, designers), but very few have (or will take) the time to really look into them as possibilities. Not My Job Syndrome.

Lastly, dedicated tools programmers have the time and ability, to keep up to date with the latest tool releases and technologies that people are using for tools in the game industry. This is key, because new concepts (like monkey testing, automatic crash reporting, formal logging / metrics, uses of XML / XSLT) pop up every day, and sometime lead to enormous gains in productivity. Without the time to look into them, engine programmers tend to lean on old technologies, with the “It’s not broke, don’t fix it” mentality. This is dangerous to your productivity, since sometimes it is broke, and your programmers just don’t realize it.

Now, if you feel like I do, or you want to learn more, I highly recommend joining the new(ish) IGDA Tools SIG. The SIG is dedicated to staying on top of best practices for tools development, posting about new tools that are becoming available, and hopefully (eventually) being a great educational and discussion resource for tools developers. If you are interested, I urge you to join. You will not regret it.

Tools of the Trade

So, the official Orbus Gameworks blog, Measuring Gameplay, had a post yesterday about some work I’ve done with integrating metrics into GtkRadiant. Something Darius mentioned, but I don’t think he made a big enough deal about, is my commitment (and, really, Orbus’s commitment) to making sure that our APIs and utilities are easy to integrate into existing pipelines and tools, no matter what language or system they’re running on. The GtkRadiant stuff is just a starting proof of concept of how that might work, and how people might want to do metric integration with current tools.

For me, making integration APIs easy just makes sense, for a number of reasons. First of all, from a practical perspective, there’s absolutely no way that Orbus could support loading all of the various pieces of game data (including map files) for every single game our clients would want to metric. It’s just not feasible. I even felt that writing our own Quake 3 map loader, though simple (and there are many tutorials and example code on how to do it), didn’t make sense. It was easier (and more productive) simply to learn GtkRadiant’s plugin system and work through that. I can’t even imagine how hard it would be to make loaders for closed level formats.

Second, and actually more importantly, if you want your designers to look at, analyze, and act on your metrics (which is the whole point, right?), you need to be ale to display them in something they’re already comfortable with. This means integrating into the toolsets that your designers use every day, which are usually your level editors. Additionally, integrating into the tools that actually caused the phenomenon in the first place alleviates the need for your designers to task switch between the metrics tools and the tools that will fix the problem. This holds as true for deaths locations being shown in your level editor as it does for pick up and use metrics being shown in your spawn and power tables.

In my opinion, this show why making the metric gathering system easy to use is just as important as making the analysis and integration systems easy to use. Gathering the data is just the first step. Putting it somewhere you can use it is just as important, and it’s our job to make absolutely sure that doing that is as quick and painless as possible.