Wombile, the fantasy game for mobile
Back in 2008, a bunch of past and present engineers from ´óÏó´«Ã½ R&D were inspired to take some time off and produce "something cool" for , a ´óÏó´«Ã½-supported event where "developers, designers, hackers and entrepreneurs" met to discuss, play with and create new mobile software and technologies.
We came up with , a fantasy game for mobile phones with receivers that you play in the real world. To make it work we chose to write our own platform for multi-player mobile games, and called it . (Blame the names on the difficulty of finding short words that are easy to pronounce and still available as a ".com" domain!)
For a simple game written in just a few days, Faebl was surprisingly fun to play. Players who downloaded the software to a compatible phone were thrown into a fantasy battle taking place in the real world. If they were physically near another player, they'd be given the opportunity to fight them. If the other player didn't want to be attacked, they had to physically run away. Different weapons made different noises (played through the phones' speakers), and defending players had to pick an appropriate weapon to defend with based on the sound they heard.
Now, we and our game weren't the stars of the event by any means, but enough people thought there was something to our approach for us to be able to persuade our managers at the ´óÏó´«Ã½ to let us spend a bit of our work time on the project, and perform a user trial. In particular, we wanted to test a couple of things. The first thing was simply to find out how useful location-aware mobile games could be as a fun way to convey educational material to children. The second thing was an idea we had called "overlapping universes". One of the issues facing any multiplayer game is how to get a critical mass of users and guarantee a good multiplayer experience. The problem is harder when your users can only interact in the game world when they interact in the real world - particularly if you want to integrate games into people's everyday lives, rather than have them meet up in order to play them. "Overlapping" universes incorporate players from one game into another: the player positions and actions in one game have correspondences in the other.
To test this, we wrote two games for the trial, with different themes and rules. Players of one game, "Feud", played the part of a celtic tribe trying to gather resources and face (or avoid) each other in battle. Players of the other game, "Pack", were members of a tribe of wolves, who had to cooperate in order to successfully hunt down prey. The universes overlapped: celtic tribes appeared as dangerous bears in the "Pack" universe, for example. The trial was carried out by giving two small groups of children phones with the game pre-loaded, and sending them out to a field to play it for fifteen minutes or so. We briefed them about the individual games, but we didn't tell them that the games were different. Of course, they quickly realised that the games were different and interlinked, and many of them had worked out how by the end of the trial.
We've published a more detailed paper on the trials and the games we wrote for it, and you can watch the video we made of it here. What we haven't done is published much about the architecture behind the game.
There are a vast number of different ways of writing software for mobile phones, but two main (but non-exclusive) philosophies: "client-side", where the processing is performed on the phone itself, and "client-server" where the phone communicates with a computer over the Internet to perform most or all of the application's functions. In the latter case, the software on the phone is often the phone's web browser, but this wasn't an option to us because there is no commonly adopted way to access GPS information from the phone's browser.
Nevertheless, we wanted to adopt a client-server model. For one thing, it enables you to write a single client that only needs to be installed once. Writing a new application only requires the server to be modified. Wombile currently uses a very light-weight client, a bit like a cut down web-browser: the server tells it what to display at any point in time, and the client just sends back any actions taken by the user (like pressing a button on the phone's keypad, or selecting a menu option), plus additional information needed by the game engine, such as GPS position fixes. The communication is implemented via a custom protocol that requires less bandwidth than sending the game displays to the phone as web pages, and also results in a much more responsive user experience without having to execute any application-specific code on the client. The client also tries to cache images and sound files on the phone, to minimise lengthy pauses at the start of or during games.
This all fits nicely with the current state of mobile phone technology: storage space for applications is often limited, installing new applications is a non-trivial task for many users, and mobile Internet access is often slow but increasingly affordable. From a developer's perspective, a big challenge to deploying a new application is choosing from the very wide range of mobile phones currently to support Should the developer create just one version that runs on some range of phones, or develop many versions (producing "ports") that allow for variations in the capabilities of the runtimes available across this wider range of phones. Each port needs testing separately. The client side of the Wombile platform, a J2ME MIDlet, is no different in this regard and has the standard considerations for J2ME discovery, deployment, and installation. However, applications created for the Wombile platform can be developed with no additional concern for per-mobile testing, deployment or installation, which is very attractive to developers. The Wombile server implementation currently is research quality - a production quality server would have to account for additional per-device concerns, such as image sizes to serve to the client.
Wombile isn't the only client-server platform of its kind ( has a number of similar features, to give one example), but it is particularly suitable for location-aware mobile applications where a simple but responsive user interface is desirable without the complication of client-side processing.
We released the original source code for both Wombile and Faebl back in 2008, but many of the features I've described were written for the ´óÏó´«Ã½ trials. However we have continued to tinker with this in our spare time, and we will be dusting of the latest source code and preparing it for release soon. Since the Wombile platform itself is not a ´óÏó´«Ã½ project, this does not include the ´óÏó´«Ã½ owned "Feud" and "Pack" games, but does include "Faebl" and a few other little experiments.
If you'd like to use it in your own software, you're welcome to do so (subject to the terms of the Free Software Foundation's ). Be warned though - it's research quality software, not fully-polished production code. It's not as well documented as we'd like, and although the client is standard J2ME, we've only tested it on various Nokia S60 phones with JSR 179 "Location API" support. Keep an eye on for the new release.
Matthew Hammond and Stephen Jolly are research engineers, ´óÏó´«Ã½ Mobile.
Comment number 1.
At 3rd Dec 2009, Anthony Nigel wrote:This sounds like an awful lot of fun to create and potentially a good platform for other location based games to be made. I would like to get into mobile phone software development a little more but all the different , platforms, etc make the whole market a nightmare to start out in.
What do you develop for? Windows, Apple, even with J2ME its a real headache.. Counting down the days for one of these companies to become dominant in terms of market share like Microsoft is with Windows on the PC.
Complain about this comment (Comment number 1)
Comment number 2.
At 12th May 2010, U14460911 wrote:All this user's posts have been removed.Why?
Complain about this comment (Comment number 2)