ZebroGaMQ: Communication Middleware for Mobile Gaming






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.


 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.