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.

Bookmark the permalink.

Comments are closed.