Testing and Demonstrating Context-Aware Services with Quake III Arena

Testing and demonstrating context-aware services can be extremely difficult. Context-aware services inherently need information such as the position of their users, but it is complicated to gather and supply services with information of that kind. Obviously, one needs to do this when the services are up and running, but it may help to simulate the context information while the services are under development or for demonstration purposes. Even though the simulated context information is not real, the services and the routines that gather and receive the context information can be. This enables systems to be developed with less regard for constraints that stem from using actual sensor technology while also keeping the core functionality of services separate and ready for real-world deployment. One can image two types of simulation tools: those that simulate a set of values as a part of a test suite, and those that allow interactive testing of services in semirealistic circumstances. We have chosen the latter approach because it has the added advantage of allowing us to demonstrate services.

QuakeSim is a tool that interactively simulates context information in real time. It simulates the real 3D world and different kinds of context information. With QuakeSim, it is possible to test and demonstrate context-aware services without requiring users or objects to actually be located in and move around in the real world.

Requirements. In order to serve as a development and demonstration tool, we determined the following context simulator requirements:

It should provide a realistic looking simulation of real-world environments, complete with people and other complex objects (for example, buildings, animals, and water).
Multiple users, represented by avatars, should be able to share an environment and interact with each other.
It should be possible to create and equip the simulator with new environments, avatars, and objects.
Tools for building environments, avatars, and objects should be available.
Sensors that register information such as the position and altitude of individual users should be simulated.

While surveying available tools for implementing a simulator, we found the 3D game Quake III Arena (see idsoftware.com) provides functionality that meets requirements 14. The game engine of Quake is capable of rendering 3D environments with satisfying realism. It allows multiple users to interact in a shared environment via a network, and tools for authoring environments and designing objects and avatars are available at no cost. Requirement 5—that sensors for registering position and altitude should be simulated—can be achieved by modifying Quake. An alternative to using Quake III Arena, besides implementing the simulator from scratch, would be to build on Web3D browsers for Virtual Reality Modeling Language (VRML). However, our survey showed such tools generally display less realistic simulations while not providing any more support for simulating sensors than Quake does.

Modifications to Quake. For the purpose of implementing a context simulator, Quake III Arena can be seen as being composed of two main parts: one game engine that renders environments and avatars, and one part that controls how objects should behave within the environment. The game engine is proprietary and not open for modification. The second part, however, has been made freely available for modification on a source code level. This allows us to extract information such as the position and altitude of each user. Information about the speed and bearing of users as well as indications whether users are swimming or flying can also be extracted. This information can in turn be used to simulate different kinds of sensors.

Context Toolkit. Let us consider in greater detail the relationship of sensors, context information, and services. Sensor information and context information are not the same thing. Sensor information is raw data and as such it is not particularly useful to any service (or human for that matter). It is when the data is interpreted and made available as context information that it suddenly becomes useful. Clearly, data may be interpreted in numerous ways; for example, a temperature reading may be interpreted simply as the temperature of some location. However, if you add to the interpretation an extra layer, for example the significance of an extremely high value, it may be used to indicate the presence of fire. Furthermore, context information, to be useful, must be accessible to services. It is quite possible that several services will be interested in the same context information. And one service may very well make use of several different pieces of context information. It thus seems like a good idea to streamline the method for services to access context information. We use the Context Toolkit [1] for gathering, aggregating, interpreting, and publishing sensor and context information.

The Context Toolkit models each piece of sensor information as a widget that encapsulates sensor-specific details concerning gathering the information, and provides a common interface toward services that make use of the information. A widget also provides functions for communication with clients, updating sensor data, polling of data, subscription to state changes, and so forth. In effect, the Context Toolkit serves as an abstraction and interpretation layer between sensors and services and can thus provide context information. In QuakeSim we have encapsulated the modified version of Quake as a sensor in a Context Toolkit widget (see part b in Figure 1). A client can therefore connect to the widget and make use of the data that Quake provides through the widget’s API. It is also possible to interpret the data provided by Quake in a number of different ways. Similarly to the temperature example previously described, a location value may be interpreted simply as a location but also as signifying presence in a certain room (mimicking an infrared beacon) by correlating the location to a floor plan with coordinates for all the rooms. The Context Toolkit also makes it possible to combine real and simulated sensors. One of our first applications of the simulator was to demonstrate and test a service in a family context. The home of the family was easily modeled in a room equipped with actual sensors and actuators (for example, a door lock). The outdoor context of the family, such as the children’s playground, was more difficult to model. We therefore simulated it as a world in QuakeSim. The actual application that was demonstrated used input and generated output to the real sensors and actuators, as well as to the simulated ones.

GeoNotes—An Example

One of the most interesting pieces of context information, and also one of the most readily available using current technologies, is the user’s location. A person’s location may be deduced by any number of means: a personal GPS device, network-based GSM positioning, infrared beacons, radio receivers, and so forth. In the GeoNotes [2] system users annotate their present location with virtual Post-It-like notes. For example, to post a note in GeoNotes, a user enters the note text and his or her name or alias. The service then associates the note with the user’s present location in physical space. As another user passes this physical location (perhaps at a later time), the system retrieves and presents the note to the other user.

To test GeoNotes, we configured it to receive its positioning data from QuakeSim via a Context Toolkit widget (see part b in Figure 1). To receive data from a real position data source the QuakeSim widget can be transparently replaced by a widget representing the real sensor (see part d in Figure 1). The Context Toolkit Server (see part e in Figure 1) enables us to aggregate several sources of sensory information. The GeoNotes system (see part c in Figure 1) implements a generic interface for acquiring position information, which makes it easy to switch from one data source to another. Figure 2 and Figure 3 illustrate the use of QuakeSim and GeoNotes in conjunction. The location of the user is simulated by QuakeSim (Figure 3) and fed to the GeoNotes service. In this example, the user is presented with a selection of three notes (Figure 2) that have been placed in the introduction room of the first Quake III Arena game level.

Conclusion

The GeoNotes example illustrates the usefulness of QuakeSim; with QuakeSim we were able to test and demonstrate the GeoNotes system from a desktop PC in our office. For usability testing, and for full-scale system tests, it is necessary to use the real system deployed in its real setting. However, for demonstration purposes, and for small-scale testing during the development process, QuakeSim serves its purpose well.