Published

GDC 2004: Software Engineering Roundtable Summary – Session 3

It is true that no tools are necessary to apply good software engineering techniques, but they can often be a big help. The third and last session of “By the Books: Software Engineering in the Games Industry” concentrated exclusively on languages and tools, and participants shared their favorite tools and warned others about potential duds.

Friday 26th: Languages and Tools

The vast majority of game developers seem to be using C++. Some reasons cited for using other languages were better integration with their environment (especially for Java and mobile gaming), faster development time with a higher-level language, or the availability of a refactoring browser. C# this year had several people using it for tools development. Some people claimed very positive experiences, but others said that doing managed C++ wrappers around their C++ code was much too cumbersome.

CVS: 20%. Tortoise GUI apparently is very good, although several people were using it through the command line only.

Accurev: 4%. An interesting two-step check-in is the main difference of this tool.

Unfortunately, nobody was using Subversion, but several people had looked into it in the past. They just released version 1.0 so hopefully next year someone will have tried it.

Documentation

Doxygen was mentioned as a good documentation tool. It creates documents from specially-marked comments in the source code as well as the structure of the source code itself. However, not many people referred to the documents that were generated for the code they were working on. It seems that Doxygen’s primary use was to explore other people’s code or a third-party API.

Nearly 50% of the participants were using some version of Wiki in their development, which is much more than in previous years. People were using it for design documents, coding standards, and tool documentation. Some were even using it with their artists and designers, so it’s not limited to programmers only.

The main advantage of Wiki are that it is a permanent but interactive collaborative medium, so it has more structure than an email thread and it stays there permanently. It makes bringing new people in the team much easier. Some of the most popular Wikis are: Wiki (the original), TWiki, OpenWiki, MoinMoin, and of course, ScrumWiki gets a special mention.

A participant found a plugin for Microsoft Word to create chm (help) files very useful to go from Word documents to online help for the tool. Some other people used Robohelp to create the help files instead.

Some of the tools mentioned to explore the relationships between classes were:

Finally, a simple yet very effective tool was a simple whiteboard plus a cheap digital camera to capture the output and put it up on an internal web site (either that, or the fancy whiteboards with built-in printer).

Bug Tracking

The majority of the participants were using a bug-tracking program. Some of the ones mentioned were:

Some teams reported having conflicts between their own internal bug-tracking system and what the publisher wanted. Some people ended up duplicating entries on both, or only starting to use the publisher one after code complete.

Testing

Many people were doing unit tests this year. Most of them were using some form of XUnit (CppUnit, JUnit, or NUnit mostly). A few people were using CppUnitLite or another, lightweight custom unit-testing framework.

Several teams did some sort of higher-level test on their games. All of these tests were driven with custom scripts in Perl, Python, or some other high-level language. Some of the tests were done with scripting languages internal to the game itself. Some people were playing back input (including random input, aka, the monkey), and some were even using doing networking tests as part of their automated testing.