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

Information Visualisation using a Game Engine

There are two main ways in which a FPS game engine can be used for information visualisation. One way is to modify an existing game and only add the features necessary for the visualisation, leaving the basic style of interaction with the 3D world intact. The other way is to totally rewrite the game logic, and only make use of the graphics, audio and networking functionality provided by the engine itself. This approach is more flexible with regards to what visualisations can be created, however it requires a lot more work on the part of the developer. In fact, this approach is similar to using a visualisation toolkit or engine, such as OpenSG[15]. In this project, only the former approach is considered, as this is the option that allows maximal reuse of the computer game implementation.

In an FPS game, there are two primary types of elements: a static, or almost static, map (layout of rooms) and dynamic, interactive entities occupying positions in this map.

There are many different ways to represent parts of an information visualisation by game elements. The particular mapping chosen obviously depends on the particular visualisation. For example, in a visualisation of a file hierarchy, the layout of directories could be represented by the layout of the rooms (that is, the map), while files are entities occupying positions within these rooms.

One thing to note that may affect this mapping is that in most current FPS games (specifically, Quake 3) the map can not be altered during a game session. This could be somewhat worked around as players can be moved between maps relatively easily, so that one map could be altered while the players are in another map, creating the illusion of a dynamic world. This has the disadvantage that the game will pause while switching maps, which may rule out this work around for certain applications. Additionally, Quake 3 maps are limited in size, which may also be worked around by splitting a large map into several smaller maps, but with the same problem of the game pausing between map changes.

Another issue is that FPS games are designed for relatively low amounts of entities Quake 3 only allows a maximum of 1024 entities in a map. With access to the game engine source code, this limitation may be worked around, but this may introduce a performance hit. The upshot of this is that in some cases it may make more sense to represent parts of the visualisation as dynamically generated textures (e.g. a diagram of a graph structure) rather than as separate entities (e.g. trying to represent each node in a large graph as a separate entity). Again, this could be worked around by using multiple maps, or by spending some time extending the engine.

Yet another peculiarity of game engines is that they are designed to only support one style of interaction, the one defined by the game logic. For example, in Quake 3 each entity usually has a fixed appearance, and a fixed behaviour throughout a game session. (It is actually possible to alter these programmatically during a game session in the game logic, if desired.) The problem is that the engine does not provide any "multiple view types" support. So, if the visualisation to be implemented relies on multiple view types (e.g. seeing files first as parts of a pie chart of disk usage, and then as entities inhibiting 3D rooms), one must be prepared to code a framework on top of the engine which will keep track of what view is being currently used, and tell the game logic which representations and behaviours to use for which entity.