Download

https://github.com/simatic/ZebroGaMQ [1]

Features

ZebroGaMQ provides an easy and reliable way to publish and consume messages in the context of mobile multiplayer games. A prototypical game involves:

• A Python server
• Android applications
• Java J2SE applications
• JavaScript applications

Here are the most powerful features of the middleware:

• Clients of ZebroGaMQ don't have to handle low-level details of reception of messages, they just need to define a behaviour on the consumption of these messages.
• Disconnection management of Android devices: you just have to focus on publishing your messages, the middleware handles for you the loss of network connection inherent to mobile networks.
• Game instances management: you can create several instances of your game, and let players use those instances in parallel.

Entities

 The use case for ZebroGaMQ includes:

• A gamelogic server (Python proccess), which creates game instances
• A logging server (Python proccess), which logs all relevant events
• A master (Android/Java J2SE/Javascript application), which manages (start, terminate...) a game instance
• Several players (Android/Java J2SE application)
• Several spectator (Android/Java J2SE/Javascript application), which are informed about events of a game instance

Logging in

The login step is as follows:

• When a master logs in, a game instance is created, and the master joins it.
• When a player or a spectator logs in, it joins a game instance.

  Here follows a figure depicting the architecture during the login phase.

  

Exchanging messages and executing game actions

Once clients are logged in a game instance, they can exchange messages and execute game actions on all the available entities.

The use of a state machine and actions on both clients and game logic server sides considerably facilitates the use of the ZebroGaMQ:

• Whether on the clients and/or on the game logic server sides, you describe a list of actions and the corresponding required behaviour on the activation of those actions.
• Then, you register this list of actions.
• Finally, you just publish messages to a recipient with the action name as a parameter, and on the reception of this message, the recipient executes the action.

Notice that the recipient can be either:

• a client,
• the game logic server,
• all the clients and the game logic server (message broadcast).

  The following picture shows the architecture for exchanging messages.