Inside Job: Tools of the Trade II

Following up this month’s Inside Job rundown on the basics of game development tools, I asked game developers about their tools, starting with software development tools that streamline or otherwise enhance the development process.

Programming Tools

Programmers, likely because of the analytical nature of their profession, tend to be the most tools-focused. While they may have a love-hate relationship with its implementation, version control is paramount; but primary code-accessing tools come as a fast second.

I miss VisualStudio. The Microsoft monopoly bums me out because I’d love to use the VisualStudio IDE for every language (Java, ActionScript, etc.). Although, it seems like C++ has taken a backseat to C# in later editions of VS.

I’m in the process of setting up Subversion as that’s what all my colleagues use for source control now.
— Ralph Barbagallo, President and Owner, FLARB LLC; author of Wireless Game Development in C/C++ with Brew

Often, tool use does propagate within social networks: If your client uses a particular tool, you’d better learn to use it as well, or at least integrate it with your existing systems. Visual Studio is such a common software tool that it’s almost not worth discussing, but that it continues to improve is worth noting in the scope of process improvement across the industry as a whole:

If I’m coding C++, VB, or ASP.NET, Visual Studio is essential. The intellisense feature, which other apps mimic but in my opinion not as well, means I don’t have to go looking for the names of class members and parameters. It also gives me immediate feedback that I take for granted now on things like whether I’m working with a pointer and whether my variable is in scope. I would quantify this by the hours I save not searching and being confused. (I’m confused enough as it is.)

It’s also important to note that Visual Studio is constantly being improved. I’m citing a report that shows a quantitative productivity difference between VS 6 and VS 2005 that I think everyone who has used both can vouch for.
— Jeff Stanley, AI Engineer, Destineer Studios

Design Tools

Prototyping, whether for a larger game mechanic or a simple mathematical test case, is a concept that peaked around 2003 in development discussion, but hasn’t been picked up again, even though the tools for prototyping themselves have improved:

I’ll suggest something a little different … Flash! It might not be the technology you want to use to create your game, but in a lot of situations it is very suitable to develop quick prototypes that allow you to test your game-ideas.
— Simon Groenwolt, Senior Software Developer, Gamewise

In this case, “design” might not just mean “game design,” but software design at its core – one of the most difficult concepts to teach and enforce among programmers.

Whether technical or abstract, organizing design documents is an interesting problem in and of itself. With the iterative nature of game design, and alterations made to the design not just by the developers but in response to publisher or licensor feedback, the standard method of housing design documents in static word processing files isn’t always optimal. Many studios keep internal wikis or intranet websites updated with the latest design information; unlike word documents, webpages easily interlink and reference each other cleanly, without large blocks of text that might not apply to the specific issue at hand.

Ron Toland, from Brainstem Games, formatted his design documents into XHTML and then inserted them into a directory structure as part of his company’s Perforce repository for the project:

I basically decided to treat our design docs like a website. I came up with a directory structure for the “site” and added it to our Perforce repository, then populated it with web pages holding the design information (asset lists, level descriptions, etc.). Nothing fancy, but it made the docs a lot easier to update for me, and everyone else can always know they have the latest version just by syncing with Perforce.
— Ron Toland, Writer, Brainstem Games

This kind of basic flexibility in process represents a simple but important principle in the application of tools toward game development; not only did Ron’s solution make it easier for him to manage his own development, it impacted the team project-wide on the level of their reassurance of the current nature of the available design. It was one more thought loop that they didn’t have to execute before acting.

Indie Tools

Indie developers often wind up being the quickest to pick up on new tools because their margins are narrower than mainstream development’s; they need to make a little bit of developer power (and often no budget at all) go a long way.

Here is my take from an indie perspective:

– Version Control: Tortoise SVN + Subversion Server
– 2D Graphics: Adobe Suite
– 3D Graphics: Maya / ZBrush
– Terrain/Maps: L3DT/Leveler/Terragen
– Animation/Motion: Endorphin/Euphoria
– Programming/C++: MS Visual Studio
– Music/Audio: FL Studio (Fruity Loops)
– Game Engines: Torque Game Engine Advanced/Unity/etc..

Engine choice depends specifically on your game concept and game flow requirements, in addition to your budget.

The most valuable asset is going to be the developers working on the project. You’ll need a Lead Producer, Lead Programmer and a Lead Designer/Writer as your team nuclei, with modeler, artists, writers, programmers, audio, graphic and system engineers under their direct supervision.
— Max Taha, Founder, Lethal Concept

Freeware engines for specialized game niches also continue to improve:

In terms of a completely integrated IDE able to make a Windows EXE in no time flat and accessible to those new to programming and not only able to make its eponymous Adventure Games, but other types of game too, it’s hard to beat Adventure Game Studio. There is great community support, too.
— Andrew MacCormack, Module Builder, Wadget Eye Games

Valve, shaking up the scene as usual, made its Steamworks publishing and tracking suite available for free this past January. These news blips tend to pass quietly, but in the long run have tremendous impact on the gaming space. When major consoles like the Wii and Xbox 360 support low-budget indie games through their distribution systems, it becomes easier than ever for independent developers to reach a wide audience. Valve’s addition with Steam breaks similar ground on the PC, while protecting developers from piracy, a critical consideration for the indie developer that runs close to the redline.

All of these shifting tool dynamics change the way the industry works on a deep level, opening streams of innovation and much-needed new approaches and thinking. Live the dream, guys.

Tools Philosophy

Implementing a new tool, or even considering its implementation, is often a time- and energy-intensive process in and of itself. It’s also difficult to measure a tool’s effectiveness, when you don’t have a major publisher like Microsoft invested in funding research behind your methods. It can be difficult, therefore, to estimate what would improve your process, and what’s going to be worth the investment in learning curve and process change. Particularly with the speed and pressure already inherent in the development process, even thinking about a new method can seem a luxury, and introducing a new required tool midway through production can be destructive.

The important takeaway from the subject of tools is one of philosophy. If developers are staying focused on what’s important and taking time to analyze the effectiveness of their production – through Critical State Analysis or even post-mortem – the integration of new tools can make the development process smoother, more pleasant, and ultimately higher-reaching in the quality of its end product. As with all aspects of quality of life, the trick is to keep seeing the forest for the trees, and not get sucked into a deathmarch loop that keeps our eyes focused on our feet, on managing the next crisis instead of envisioning the future.

The other important element in exploring tools use is communication. Often developers come up with ingenious simple ideas that have great effect on their projects – and they keep them to themselves. With the exception of developer magazines, which tend to have a mild bias stigma due to their connection with professional tools advertisers and industry conferences, which are both intense and a narrow slice of time once a year at best, tools communication isn’t great around these parts. By sharing ideas and simple process tricks we can more rapidly iterate the evolution of development methodology and tools integration. And we could probably use a communication tool to get started…