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.
The tools people were using for asset management were:
- Visual SourceSafe: 40%. Horror stories of constant database corruptions, but it seemed to work (more or less).
- Alienbrain: 40%. People weren’t thrilled with it. Felt too heavy weight. Only good if you use some of the more advanced features.
- CVS: 8%. They were using a small amount of data.
- Perforce: 5%. Artists were happily using the default GUI without any trouble.
- No management at all: 5%. Considering switching to an asset management system.
The amount of data people had in their asset management systems varied between 2GB all the way up to 20 GB. One handheld developer only had 300 KB of assets total. Ah, the old times!
Source code version control
The breakdown for source code was very different than for asset management.
- Perforce: 40%. Most people here were using branching.
- Visual SourceSafe: 36%. Hardly anybody used branching (not a surprise).
- 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.
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).
The majority of the participants were using a bug-tracking program. Some of the ones mentioned were:
- Bugzilla: Ugly but effective and free. Hard to convince management though.
- FogBugz: Simple, lightweight, but limited reports.
- Plain databases
- Many publisher-specific bug-tracking
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.
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.
Previous GDC roundtables