Consortium    Solutions    Middleware    Forge    MyObjectWeb 
ObjectWeb Consortium
Print

Advanced - Powered by Google






GASP - a middleware for mobile multiplayer games

Project Links
· Home
· News
· Downloads
· Documentation
· Mailing Lists
· Forum
· License

Project Components
· Online middleware
· Bluetooth middleware
· MooDS Protocol
· Demonstration Games

Events Participation
· UbiMob'06

Developers' Corner
· GForge
· Wiki
· Project Trakers
· CVS Repository

State of the art
· Domain news
· Existing platforms
· White papers

About
· Team

GASP Project Components: MooDS Protocol

Introduction

MooDS stands for Mobile optimized objects Description and Serialization and takes care of the J2ME multiplayer games specificities by minimizing the binarization of message objects during communication. MooDS manages the communication part of GASP middleware (HTTP and bluetooth). MooDS version 2 is available as an Ant task.

Protocol Description

In order to use MooDS, the developer has to describe the messaging data structures chosen for his multiplayer game using MooDS description syntax. Then these descriptions are parsed by the MooDS generator to obtain a serialization class version of the data structure. The principle is the following: Send the game message objects by values, thus authorizing only Java primitive type fields (boolean, byte,short, int, long, String and array).

During the game execution the message objects to be sent are encoded over the network using static encoder/decoder classes. Thus when an object is sent, the receiver decodes the binary stream with the decoder class and gets an object copy of the original message object. The figure below presents the MooDS message object serialization mechanism.

MooDS Protocol

History

  • 2006: MooDS v2.0 development
  • 2005: MooDS v1.0 released

Current work

  • MooDS v2.0: optimization before first release (coming soon)

MooDS v2.0

In order to use MooDS, the developer has to describe the messaging data structures chosen for his multiplayer game using MooDS description syntax. Then these descriptions are parsed by the MooDS generator to obtain a serialization class version of the data structure. The principle is the following: Send the game message objects by values, thus authorizing only Java primitive type fields (boolean, byte,short, int, long, String and array).

During the game execution the message objects to be sent are encoded over the network using static encoder/decoder classes. Thus when an object is sent, the receiver decodes the binary stream with the decoder class and gets an object copy of the original message object. The figure below presents the MooDS message object serialization mechanism.

MooDS Protocol

Messages Description

In MooDS 1.0 version we used a dedicated XML syntax but this approach required the developer to learn a specific syntax. Thus, MooDS 2.0 uses a basic XML Schema syntax in the description step. Figure 3 presents a description example, 3 different message types have been described: NewPlayer containing all the information (user name, initial position...) of a new connected player, UpdatePosition corresponding to a player's avatar position and Bomb corresponding to a bomb launched by an opponent player with position and speed information. We can see on this example the XSD primitive types corresponds to the Java primitives types.

The only imposed XSD element is the root tag. This tag includes a choice sequence for each different message type tag, in our example newPlayer, updatePosition and bomb tags. Then, this description is used by MooDS to generate static binarization code for the described message types.

MooDS Protocol message description

Encoder/Decoder generation

Once the message type descriptions are described, generator MooDSGenerator parses the message types and generates an encoding/decoding class, CustomTypes, which has two root methods, encodeData and decodeData. The encodeData method takes as inputs the output data stream and a hashtable containing several objects. Upon invocation, it calls specific methods to encode each described types. In our example, the process will generate the methods encodeNewPlayer, encodeUpdatePosition and encodeBomb. These methods encode each object fields on data output stream with the Java API dedicated methods. In the same way, the decodeData method takes as input the input data stream and returns a hashtable of decoded objects thanks to the call to decodeNewPlayer, decodeUpdatePosition or decodeBomb which decodes the data stream. To identify encoded objects in the binary stream, a short identifier is attributed to each objects and precedes the encoding of their values. The figure presents the CustomTypes class generated from the description introduced.

Encoder/Decoder generation

Message Classes generation

In addition, MooDSGenerator generates one classe per corresponding to each message object types (as NewPlayer.java, UpdatePosition.java and Bomb.java in our example) with the basic setter/getter methods.

Game Server Logic generation

First, specific annotations can be used to specify the communication model of each message type: Unicast, multicast or broadcast. This annotation impacts the CustomTypes and the server logic skeleton class generation. The figure presents this annotation specified with gasp:options and gasp:communication tags to specify the NewPlayer message type is a broadcast message.

Game Server Logic generation

Persistancy Services generation

An other annotation, sql:requests, provides services to access object data persistency service. It enables basic SQL requests to a distant HTTP persistency server: sql:select, sql:update, sql:insert and sql:delete annotation tags are available. The MooDS generator parses the types description and generates two related classes: a servlet that handles persistency requests and a class, named SQLStorageManager, that executes the SQL requests specified in the annotations on a MySQL database. The figure below presents the annotations and the generated code to access to a game player inventory persistent data.

Persistancy services generation

This persistency service generation can be used as a standalone service.

Towards interoperability capabilities

MooDS Protocol code generation has been primarly dedicated to Java based handsets. MooDS 2 provides to generate Flash code enabling Flash based clients to play on GASP. The next step will be to generate C++/C# code enabling larger interoperability on GASP middleware.

MooDS v1.0

Informations coming soon...


Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster | Last modified at 2006-11-29 06:20 PM