Information Visualisation utilising
3D Computer Game Engines

Case Study: A source code comprehension tool

By Blazej Kot; Project supervised by: Burkhard Wuensche, John Hosking, John Grundy

Evaluation

Evaluation of the Source Code Comprehension Tool

The implemented tool met all the major functional requirements listed in the design section: source code files are represented as physcial, movable 3D entities in a 3D world. They can be navigated via a web browser like interface which displays the files with syntax highlighting and hyperlinks. Users can see each other, and can customise their appearance to be unique using the normal Quake 3 model choosing system. A player can lock their view with another player, so that giving guided tours is possible. Users can "draw" on the source files, thereby indicating important parts of the code to other players also viewing that file (the "drawing" fades over time to reduce clutter). The chat functionality is not completely implemented yet, as it does not work correctly for users who are viewing contents of files, however it does work well in the normal 3D view.

There was no real usability trial done. However, during debugging, the help of several people was enlisted, and the following observations were made:

• Since everyone was in the same room, no-one bothered using the chat functionality.

• Sometimes in a place where there were lots of files, the file name labels would overlap, being difficult to read. One person came up with an interesting use of the Quake 3 ‘zoom’ function to overcome this. By holding down the ‘Ctrl’ key, the player’s view is magnified, showing less files, and separating the filenames labels more, making them easier to read.

• An unplanned feature was discovered: a player who is currently carrying a file can run up to another player, and drop the file onto him. The other player’s view will then show the contents of that dropped file. It is interesting to note that this feature arose by itself due to basing the tool on a 3D physical world metaphor. In the future, this sort of interaction could be used, for example, for a 3D interface to a source code version control system: a user walks up to a "vault," where the checked-out files are dispensed, picks one up, carries it to their virtual workplace to work on it, and then carries it back and "drops" it into a chute leading back tot he vault, to check-in the changes.
• In an early version of the tool, the lock view feature was only implemented within one source file view as soon as the tour guide clicked on a link, the other participants’ views became unlocked, and they did not automatically follow the tour guide to the destination of the clicked link. The participants found this annoying, so the lock view feature was changed in the current version, to allow groups to follow the leader between files automatically. Unfortunately, this seems to have had the effect of turning the players who are being guided around into "zombies" all that they do is look at the screen, and have no control of what they are looking at. This may lead them to losing attention quickly. Perhaps an intermediate solution could be implemented, where if the leader clicks on a link, that link is highlighted on the other player’s screens, but then they have to click on it. Whether this is a good solution should be investigated in the future.

Evaluation of Quake 3 Game Engine Suitability

Quake 3 was good choice for the underlying implementation platform. Since other game engines were not tried, no conclusion can be drawn about whether it was the best one available. There were some minor problems encountered with using this engine, listed below.

• There seems to be a bug in the game engine itself, whose source code is not currently available to the public. This bug manifests itself when a large number (more than 8000) of triangles are drown from within the UI QVM. See the Implementation section for details. This is an important example of how using the engine for what it was not designed for (displaying lots of text in the UI) may test the engine in ways that a normal game wouldn’t, revealing hidden bugs. Since Quake 3 should be open-sourced soon, this bug should be able to be fixed.

• Learning to modify the game engine took a lot of time, and was mostly done through trial and error. There is no documentation of the code provided by idSoftware. There are some basic third party resources [20,21], and these serve as a good introduction to the basics. However, it was often necessary to walk through the existing code by hand and figure out how it worked and how best to modify it.
• The game code which runs on the VMs is written in C. This has the usual side-effect of having the implementation of a particular entity split across many different files. This is not necessarily a bad thing in itself, but sometimes this leads to subtle bugs where some other part of the code in another file unexpectedly alters the state of an entity.

• The lack of dynamic memory allocation in the VMs is a limitation, but can be easily worked around. Either a large static array can be used and memory allocated out of that by hand (as was done in the cgame.qvm modification), or once the game engine source code is opened, this functionality may be added. However, such an addition would need to be carefully planned, since presumably there was a good reason for not including this functionality in the first place. Another way to work around this issue, which is not optimal, is to compile the game code as a win32 DLL. This can be loaded by Quake 3, and can make use of all native win32 functions such as dynamic memory allocation. However, this solution is non-portable, and removes the security barrier which is provided by executing the code in a QVM.

• Another result of the game engine code being, for the moment, closed, is that the network protocol is fixed. New character string messages can be added easily, but these need to be assembled at one end, and parsed at the other. In addition, these messages are not associated with any particular entity (other than, in the case of client-originating messages, which player sent them). This was a problem in the implementation of the tool since the new itemid field of sourcefiles had to be communicated from the server to the client. Fortunately, a field in the existing packet structure was found which was rarely used, and so was reused to transmit the itemid. While this worked for this particular tool, the available space is very limited, and may not be sufficient for other visualisation tools. A workaround based on sending the extra information via text messages and storing them in a look up table at the destination could be implemented, or, better, the network protocol could be made more flexible once access to the game engine source code is available.

• The last significant problem encountered was the limited capability of the UI system built into the game, specifically that it did not have a text scroll box element. However, all functions needed for implementing such an element were easily accessible, so there were no problems with coding this by hand (other than the mysterious 8000-triangle limit mentioned above.)