GDC 2004 Trip Report Day 4

[walbourn]

Roundtable: "Technical Issues in Tools Development"
Due to scheduling conflicts I was unable to attend the previous two roundtables in this series, so I only have notes for this third and final roundtable. The second roundtable focused on implementation languages for tools, and the consensus from that session was that most people were using C# or Python with a GUI toolkit for developing their tools.

There was a lot of variety in how people approached tools development. It was generally agreed that tool UI should be kept separate from tool systems functionality for flexibly and longevity. A number of teams were developing full stand-alone level editors. While most teams were using Maya or MAX as a source for art, few were using it as the basis of their level editing-which is the approach my previous project took. Concerns about being locked into a given tool, limitations on end-user distribution for the mod community, and even a desire to be 3D editor neutral seem to discourage many people from taking this approach. Personally I think trying to do full stand-alone level editor tools to be very time intensive, often involving duplication of things already well covered by existing 3D editors. One team was doing the 'editor built into the game' approach, which can work but can cause serious issues with usability, stability, and development requirements. It was pointed out that this approach is required to some extent for MMP games.

The roundtable wrapped-up with discussion of various live-content update techniques and the pros and cons of creating UI editing tools.


Roundtable: "By the Books: Solid Software Engineering for Games" (part 3 of 3)
This final roundtable focused on development tools and tools to support s/w engineering approaches. The discussion covered implementation languages, asset management/version control, documentation, code visualization, bug tracking, and unit testing.

Implementation languages: C++ was being used to almost everyone, but there was variety in terms of UI toolkits for tools. C# was generally seen as not practical for game engine use, but very good for tool development. A few were using Java for both development and tools since they targeted mobile devices, and a few were even using it as an in-game scripting solution.

Asset management/version control: alienbrain was being used by a few teams and focuses heavily on the art process, but its support for source code was a bit limited compared to other tools. Most everyone thought Perforce was one of the best version control solutions out there right now, and works well for binaries as well as code although its UI was a bit basic for artists & designers. Some were using CVS, and they felt the Tortoise UI tool was the best interface for CVS available. Many were using Visual Source Safe, but it has many issues with database corruption (particularly with large binaries) and weak merging capabilities. Some lesser-known VCS tools were being used or evaluated as well.

Documentation: The Doxygen/JavaDoc tools which create HTML from code comments is in use by several teams. The general feeling was that such tools are less useful with Intellisense editors, but was nice for documenting code from third-parties. Wikis (i.e., shared team editable websites) are very useful for keeping track of decision history, and design and standards discussions. Robohelp was also in use for creation of CTM help files. A few groups are using webcam shots of whiteboards and printing whiteboards to capture diagrams from meetings for future reference.

Code visualization: A number of code visualization tools are in use to help understand older code or third-party tools: Doxygen, Understand C++, TogetherSoft, and Rational Rose. Some of these tools can be quite expensive, but can be very useful for automatic creation of class hierarchies and other visual aids.

Bug tracking: Solutions for this were varied. A number were using publisher-supplied bug tracking solutions to integrate with their QA process, while some were using custom shared databases tools. Bugzilla was in use by a large number of attendees, but the views were considered a bit 'ugly' for non-technical people. Fogbugz is another good tool and very lightweight, but has limited reporting capabilities and might therefore be of less use for large-scale testing groups.

Unit testing: There are a number of unit-test frameworks available, such as N-unit and CPP-Unit. A more lightweight version of CPP-Unit, called CPP-Unit Lite, seems to be more useful as a basis for game system/tool use. Again, automatic execution of unit/smoke tests as part of an automatic build was strongly encouraged.


Lecture: "Deferred Shading on DX9 Class H/W and the Xbox"
This talk presented an alternate method of rendering images in real-time: deferred lighting and shading. In this technique, the scene is 'rendered' to the frame-buffer but instead of writing final pixel color, attributes are stored. Additional passes are used to convert the attributes into final pixel color. The results of this technique are very impressive and detailed lighting and works well with shadowing techniques, but has a number of issues. First, the frame-buffer fidelity limits the amount of attribute data that can be stored, although texture lookup techniques and other encoding schemes can help. There are also issues when trying to do high dynamic-range lighting. Second, traditional alpha-blending is impossible since final computed colors are not available until after deferred shading/lighting is complete. This can be addressed using stippling or other techniques. Finally, this technique is bandwidth/memory intensive and uses up a lot of fill-rate.

Demonstrations of this technique on DX9 h/w and the Xbox were discussed at length. There was also a PS2 demo, and this technique achieved per-pixel lighting not possible directly with the PS2.