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

Conclusion

It is possible to use a game engine as the basis for an information visualisation tool, and thereby save a lot of implementation time by reusing the functionality already implemented in the game engine. The biggest benefit is obtained when as much of the game engine functionality is reused as possible, i.e. in 3D, interactive, multi-user visualisations based on a metaphor involving physical entities.

In order to simplify the implementation process, it is important to choose a visualisation which uses a metaphor of there being several distinct dynamic entities in a static 3D world that the users can interact with. There should typically be much less than 500 of these entities, but this limit depends on the game engine chosen, the amount of modifications needed, and the performance and hardware requirements of the result. There typically is also a limitation on the maximum allowed map (3D world) size, although this can be usually worked around by stiching together several smaller maps.

Out of the two ways of reusing a game engine, that is either writing a new set of source code which uses the engine, or modifying an existing game to customise it for producing the desired visualisation, the second is much easier and was therefore used in this project. There is still considerable work involved in customised an existing game, especially as in this case, where there was very little documentation of the code available.

The tool which was implemented in this project seems to work well as a source comprehension tool, this observation being based on an informal trial. It closely resembles browsing a cross-referenced source code base via a web browser, with the addition of multi-user capability and the ability to use one’s spatial memory to remember the structure of the code.

The implemented tool may make a good basis for future software visualisation projects, wherein various graphical representations of information could be superimposed on top of the existing visualisation. If the user has already stored the basic structure of the source code files in his spatial memory, he could easily identify what parts of the source code the superimposed information related to.

Future Work

Major future research questions:

• Investigate the suitability of game engines of other genres (RPG, RTS) for information visualisation.
• Investigate using this tool for visualising other repositories of hyperlinked documents for example, using hyperlinks to show citations in a (small, due to the limit on the number of entities) digital library.
• Consider representing entities smaller than files in the tool perhaps source files could be represented by a stack of function definitions, which could either be manipulated as a whole, or individually moved around. This could be used for refactoring programs.

Major extensions to the tool:

• Automate the map generation, via an analysis of the source code, and with input from the user.
• Consider adding interactions with some software engineering tools, for example CVS.
• Consider superimposing other software visualisations on top of the visualisation generated by this tool.

Minor improvements to the current tool:

• Create better models to display the sourcefiles, perhaps modify them dynamically to show some attributes of the files other than size (e.g.: age.)
• Improve the scrollbar so it can be dragged like a standard windows scrollbar.
• Reuse an AI route-finding algorithm in Quake 3 for telesliding.
• Improve the chat functionality, so that it works even in the file view.
• Create a 2D overview map, so can see what files and players are where.
• When a user holds their mouse over a link, display the destination file and line number. Perhaps display this on a superimposed 2D overview map.
• Only draw trails for players who are looking at same part of code.
• If a player is carrying a file, display its name above the player. Decide what should happen if a player clicks on a link that leads to a file which is currently being carried by someone in the present implementation, the player will slide off to infinity.
• Improve the font used for file display it seems to be stretched vertically and is hard to read.
• Add VOIP support so that players can talk to each other in voice via the internet.
• If a player picked up a source file, display its name in the player’s view.
• Add search functions, to be able to search for text within a file or all files.
• Include ability to access doxygen generated documentation, not just the cross-referenced source code.
• Initially store all the source files on the server, and download them from there at game start or as needed currently, every client needs to get a copy of the files by hand.
• Add the ability to save the location of source files after they have been moved, and load them at game start.
• Once Quake 3 is open-sourced, create new maps and textures (or use freely-licensed ones) so that the whole tool may be freely distributed.
• Add support for carrying multiple files, if this seems necessary.
• Improve dox2html as described in the implementation section.
• Package the tool so as a proper Quake 3 Mod, and so that it can be loaded and unloaded via the in-game menus like any other mod, without needing a special batch script to start it.
• Test what happens when people arrive or leave part-way through a game session, some things like the lock view feature and the portrait drawing may fail fix accordingly.