UPDATE: If you speak spanish please check my website for the entire thesis work on the design and construction of a framework for the development of mobile P2P games and its J2ME implementation. If you need information in english please get in contact with me by writing a comment in this article.

The title of this post is exactly the one of an IEEE article I got to read because is deeply related with my thesis and will be a great input for it. The article was written by Alf Inge Wang, Michael Sars Norum and Carl-enrik Wolf Lund as part of their research in building Peer2ME, a framework for P2P games over J2ME/Bluetooth (does it sound familiar to you?).

NOTE: Our thesis work tries to define a general framework in terms of building blocks and protocols. As reference platform for a reference implementation we chose to work with J2ME/Bluetooth, though we argue that the framework can be implemented in many more platforms. Thus the relation of this article with our work.

A classification framework for mobile games is presented where games are classified into categories and later the j2me/bluetooth platform is evaluated for each of these categories in terms of its suitability as a development platform. It’s bi-dimensional classification; the first dimension “groups games according how network users interact” and the second according to “how the peer-to-peer network is used”.

The first dimension has the following categories:

1. I1 Controlled: A master peer controls all the interactions (giving turns for example).
2. I2 User Interaction: The user explicitly triggers actions for interaction. Each action will cause the exchange of data and the connections will be closed.
3. I3 Automatic Triggered: The mobile device is monitoring the environment searching for other gamers. When a gamer is found it prompts the user for what to do.
4. I4 Automatic: The devices interact without user intervention. It’s all based in previously trained autonomous agents.

The second dimension has the following categories:

1. U1 Asynchronous: The data update is done whenever it’s possible but it’s not necessary to have fresh data to continue with he game.
2. U2 Synchronous: The peers require frequent update of data to be able to play the game. However the information to be exchanged is small.
3. U3 Real Time: The games require heavy exchange of data in order to have a good user experience.

As a result a matrix is obtained where, based on the tests, the suitability of J2ME has been evaluated:

• S (Suitable): The combination is the category fits very well with the way that bluetooth and j2me works.

• NS1: According to the test bandwidth for bluetooth connections is about 10Kbps or less depending on the number of devices connected. It could be OK for two devices exchanging small data packets for synchronization. However as the number of players or the amount of data to exchange grow “is unlikely to work well”.

• NS2: The limitations of the current implementations of the j2me virtual machines on multitasking (having a midlet running background or any kind of push registry mechanism) and bluetooth discovery response time, make it “unacceptable” for this kind of games.

The recommendations in the table are based in a set of issues found by the research team after building the Peer2ME framework and performing a set of experiments (test cases). The issues are:

1. Slow Device Discovery: This process can take about 22 seconds, with the extra problem is that when a new peer wants to join a game session all the peers would be stopped for those 20 seconds.
2. Bluetooth Transfer Speed: “The application cannot assume a higher transfer rate than 10Kbps in an environment of various Bluetooth devices and other radio transmitters“.
3. Topology of Bluetooth Devices: The devices can only belong to a single piconet and the implementations don’t follow the rule of allowing up to 7 connections to a master.
4. Extra Resource Consumption: The limited resources of mobile devices now have to be used for network management as well, thereof it’s important that the code is compact and resource efficient.
5. Not Running in Background Support: The applications cannot be run in background, thereof it’s impossible to detect other gamers at every time or trigger actions on any event.
6. Inconsistencies in the Implementations of the VMs and APIs: Every manufacturer implements the j2me virtual machine differently, not completely following the standard.

Finally, the research group classifies some of the genders that fall into the suitable categories for P2P games over J2ME/Bluetooth:

1. I1/U1: puzzle, strategy, turn based
2. I1/U2: simulation, sport
3. I2/U1: strategy, RPG
4. I2/U2: simulation, adventure

NOTE: There is not a single creation of mime in this post, this is just a brief of what the guys expose in their article.

I hope at least some of you find this article useful or at least informative. There is a bunch of good explanations for why this market has not really taken off.