Spurred by GPS and JSR-179, a new class of games unique to the mobile world is now possible. Peter Molettiere from Nokia’s SNAP Mobile reviews recent pervasive game implementations that left players clamoring for more, and analyzes how game designers used context aware technologies and networks to enable collaboration between multiple players and get information on the current environment of players. Code examples included.

Everyone has heard the calls for a new class of mobile games which take into account the unique features available on mobile handsets: cameras, microphones, nearly ubiquitous network access, Bluetooth, and location based services such as GPS. The idea has been to create a new class of games that offer a unique mobile experience, rather than providing mobile games that only offer a portable version of the PC and console based games we all know and love. But where’s the love?

Multiple games have implemented features using the microphone and/or the camera – blowing out candles in the game by blowing on the microphone, revealing hidden messages in secret parchments by holding the camera up to bright light. The success of the Wii has spurred such innovations as using the camera to implement motion tracking, as in Gosub 60’s Camera Phone Darts game. Public reaction to these developments has been mixed, though, with some reactions calling these developments gimmicky or embarrassing to use in public.

In any case, these new mobile features only scratch the surface of what’s possible with many current mobile devices. With multi-player modes only supported by the time tested pass-the-phone-around method, these games aren’t so different from traditional PC or console games. Camera-based motion tracking looks much like a mobile implementation of the Wii remote.

Download Source Examples The Sun Wireless Toolkit ships with the SNAP Mobile SDK, a set of tools provided by Nokia to ease development of multi-user games. Nokia also provides global hosting, reducing the amount of code and administration a game developers and publishers need in order to deploy multi-user games. Operators appreciate that a company known for reliability and scalability is hosting the server components for deployed games. SNAP Mobile provides all the features expected in a multi-user game: user authentication and profile management, instant messaging and presence services, rankings, an asset management system to allow games to upload and download user generated content, or to simply download new feature packs, and of course, matchmaking and game packet routing services. Once a user has created a SNAP Mobile account, she may log into any SNAP Mobile game using the same login credentials. Once she has set up her friends’ list by inviting other users, and having those invitations accepted, she will see which of her friends are online or offline, and be able to send chat messages, even if her friends are playing different SNAP Mobile games. The usual usage for SNAP Mobile is to create games that can be played head to head across wireless networks (both cellular and WiFi – any network connected to the internet which can be accessed by the device). Games may contain many players simultaneously, as the backend services were designed for console games, but the game developer needs to take mobile network bandwidth and latency constraints into account during the game design phase to ensure a high quality user experience. http://snapmobile.nokia.com

These can hardly be called uniquely mobile innovations, but the first steps of revolution are rarely recognized as such. The Wii has proven that new modes of gaming can be wildly popular, and can mobilize entirely new groups of players who would not be interested otherwise.

These games all tend to take the user out of the mobile context however. When out and about, the decision to play one of these games amounts to an escape from the current environment. We tend to think of mobile games as toys to occupy those times when we’re trapped in a place we’d rather not be: whether waiting for a bus or a doctor, or trying to escape boredom, games represent a more interesting alternative than whatever it is that we’re not doing while we’re playing.

What happens when we turn this relationship upside down? When the game immerses the player in the environment, enriching the environment, rather than providing an escape from it? The rest of this article looks at possibilities for connecting people to their environment, their social networks, and enriching those connections.

To illustrate the possibility, I’ll describe a game concept that uses three technologies found on many handsets today to provide a game play experience that integrates game play into the real world.

Consider a snowboarding game with a “reality mode” that allows the player to record her runs during the day. These runs can then be used in many ways. First, the game would allow the player to replay her runs, with ghosts for the two players ranked above and below her time for the specific run. Second, the collection of runs recorded can be used to create new player assets for virtual players. Third, others running the game simultaneously in close physical proximity can be signaled to allow both players to meet while on the slopes.

Such a game could provide in-game advertising opportunities for ski resorts willing to install a special client (implemented as a midlet, running on a low cost Bluetooth handset, maybe stored behind the counter in the pro shop) which would server advertising assets, as well as potentially providing in-game assets, such as graphics, or other feature packs for the game, such as additional cards for games like Magic or Pokemon.

This game concept would be implemented with three technologies already available on mobile devices. SNAP Mobile provides the multi-user gaming platform to connect the player with friends and to make new acquaintances, as well as the rankings engine, and the server storage for assets such as run data. Bluetooth provides the technology to remotely sense other players in close physical proximity, as well as the basis for location based advertising and asset distribution. The location API provides the tracking mechanism to obtain location, speed, and altitude information as the player rides down the slopes.

All three technologies are available via easy-to-use J2ME APIs. SNAP Mobile ships with the Sun Wireless Toolkit, Bluetooth is included on many handsets via JSR82, and Location API (JSR179) are increasingly available on handsets which either incorporate GPS or which make external GPS units available via Bluetooth.

Game developers must consider how their use of these technologies will play out when a specific device doesn’t support a technology that the game uses, either by restricting distribution only to those devices with all needed technologies available, or by designing a scheme to gracefully degrade the game experience. For instance, the Bluetooth method described here to exchange information based on physical proximity could also be implemented using GPS and server-side assets, but such a solution wouldn’t work for those handsets which don’t have that functionality. If the game simply disables features that can’t be used on a particular handset, instead of refusing to run at all, it can reach a larger audience.

These features can be implemented in different ways that I will describe.

The key to recording run information lies in the JSR179 classes Location, LocationProvider, and LocationListener. Location is the basic class encapsulating information returned from the underlying mechanism used to determine where in space the device was at a particular time. This information includes the time the sample was collected, the coordinates of the location (encapsulated in an associated QualifiedCoordinates instance, which also provides information about the accuracy of the measurement), and the speed and direction of movement of the device at the time the sample was collected.

LocationProvider is the class which encapsulates access to the underlying source of location information. The application uses the getInstance(Criteria c) static factory method on the LocationProvider class to obtain an instance. The Criteria instance passed is used to specify the accuracy, response time, power consumption, and information requirements supported by the returned LocationProvider instance.

Once a LocationProvider instance has been obtained, the application can either poll this instance by calling getLocation(int timeout), or it can implement LocationListener, and set a LocationListener instance on the LocationProvider in order to receive callbacks as new Location information becomes available. The LocationListener instance is set on the LocationProvider by calling setLocationListener(LocationListener listener, int interval, int timeout, int maxAge). The interval parameter specifies the frequency for the LocationProvider to measure the location, and the timeout indicates how long the application is willing to wait for a measurement. When the timeout has expired, the Location API will return an invalid location. The maxAge parameter tells the LocationProvider to expire any cached Locations to guarantee that a Location has always been measured within the specified number of seconds.

To record runs in the snowboarding game, the developer needs to get an instance of a LocationProvider, register a LocationListener to poll with the desired frequency, and implement logic in the LocationListener locationUpdated(LocationProvider, Location) implementation to store each location as it is received.

So far, the examples explained only use the Location API. SNAP Mobile multi-player functionality will allow sharing location information among multiple users by update the user’s friends with the user’s current location.

The updatePresence() method on Session in the SNAP Mobile API is the primary means of transmitting information about a user’s presence. In the enclosed example code, the Controller class implements the LocationListener interface, and receives location updates via the locationUpdated() implementation. First, check to make sure the LocationProvider is available, as the provider will continue to call locationUpdated() with a null Location parameter when it is unavailable, as long as a listener is registered. Then, send the current location off to the model for storage, and pass it off to the network via updatePresence(). Note the use of serialization to encode the location for network transmission.

Friends will receive these notifications through the SnapEventListener interface implementation of friendPresenceChanged(). Since friend presence usually indicates that a friend went online, offline, or became busy, first check for this state. Proper handling of these presence states is required by Nokia for Snap Mobile games to be hosted for deployment. Once the usual housekeeping is out of the way, extract the presence message from the friend update, which contains the location information. Note the use of deserialization to turn the network representation of the friend’s location into an instance of Location. Examples are included to show how to calculate the bearing and distance to the friend. With a little basic trigonometry, this can be easily displayed, but the UI portion of this example is out of the scope of this paper.

When the run is over, the list of Locations can be packaged as an asset and uploaded to the SNAP Mobile servers. SNAP Mobile assets may contain both a byte[] of data, up to 30720 bytes long, as well as XML formatted metadata to allow searching by other players. We will describe this use of the SNAP Mobile asset system in a future article.

In order to obtain physical proximity information, we will rely on the short-range radio protocol Bluetooth. Bluetooth is available on a wide range of handsets, from mass-market commodity handsets to many smart-phones. Often seen as a mechanism for ad-hoc personal area networks, Bluetooth has a hidden potential. With its device and service discovery APIs, Bluetooth can be used to scan the physical environment for objects of interest.

Since we need to both broadcast queries for other users of our game, and be able to service those requests, we will be implementing both a Bluetooth client and a Bluetooth server. We have encapsulated this functionality in the ProximityService class in the example code.

The basic idea in this implementation is that the Bluetooth client is always looking for other users of the game. When someone is found, we send our username and location to that user via Bluetooth. This location can be used to provide a bearing to another nearby user, although positioning accuracy issues will prevent this from being a very reliable feature. The server listens for these connections, and notifies the game Controller class when someone announces her presence. The Controller is then free to act on this information, for example, by vibrating the phone, so that the user has a tactile signal that another user is nearby, so that the screen doesn’t have to be constantly watched or frequently checked.

One of the first things to note is the use of UUIDs by the underlying Bluetooth system. “Unique Universal IDs” are meant to be just that – unique identifiers which can be used to ensure that specific users of the protocol can find other users of the protocol who wish to exchange data in the same format. You can generate your own UUID by using the uuidgen tool. See the man page for information on your specific implementation.

The Bluetooth API provides a simple stream-based interface for sending and receiving data that should be familiar to most Java programmers. Check out the sample code. Note that several issues should be handled, which are not shown in the examples.

Proper stopping of the Bluetooth service is not shown. As written, the service will never die due to the while(true) loop in the server’s run method. You may also decide you want to send different data than what has been implemented here.

This is just a start. By merging the capabilities of two easy to use APIs, you game can implement some very interesting new features to generate greater interest in the game and a better user experience, and more connection with the real world. Hopefully you have many ideas about how to go about adding pervasive and context-aware features to your own game.