Node.io

A cross platform multiplayer game
for android, iOS, web and desktop, using RabbitMQ for communications.

Demonstration

Description

Control your player and catch others to gain more zones. But watch out: players will try to catch you too. Survive and catch them to be the one with the biggest number of zones!

Implementation

Our game is implemented using the Model View Controller pattern. To achieve this, we use the Observer pattern proposed by Java.

• The Model:

  • The map is represented by Zones. Each Zone is represented by Cells. Players can move from one cell to another at a time.
  • When connecting, the player appears with an associated Zone. Each player is identified with a unique ID which is the name of her/his communication queue (given by the RabbitMQ server).
  • All the things that the player can do is represented with a dedicated Action.
  • When a player wants to do something, she/he sends an Action to a special player; the host. The host validates it (checks if it is possible) before sending it to all the players.
  • The host if the first player to connect. She/he initiates the game. When she/he disconnects, we use an election algorithm that choose a random player among the connected ones, to give this role to another player.

• The View:

  • There is a view associated to each one of the model classes. They are Observer of them.
  • A special view is dedicated to the background.
  • And all the remaining views are used to depict the HUD, and GUI.
  • Also, the access to the model is synchronized between the rendering and updating threads using a lock.

• The Controller:

  • Only one class that handles the inputs of the player and updates the model accordingly.

Here is the architecture of the game:

RabbitMQ

As said before, we use RabbitMQ to handle communications between players. Also, we use a hosted server on CloudAMQP.

• The host uses a dedicated queue to receive Actions from users.
• The players are all connected to a fan-out exchange using a queue. The host publish the validated Actions in this exchange so that every player receives and plays them.

Here is the complete architecture:

Theoretical Limits

Most of the limits of our game are related to the host. Here are the most important:

• Host is the bottleneck of our game. If processing (computation capacity) or sending (network speed) an Action takes too much time for her/him, the game will be slowed down for every player.

• In the same way, if too much players are connected and are playing at moment, the host will need more computation speed to keep the game smooth.

• The game is not fair, the host is advantaged: when sending an Action every player should wait for host validation to update their model (i.e. to receive back an Action from the host), while the host sees her/his model updated directly during the validation process. Thus there is no delay for the host. To avoid this we could update the model of the host by also sending validation messages to her/him like every other player. But during this time lapse, host could validate actions from other player with a non-updated model. This could lead to collisions. To avoid this we could add a Lamport timestamp system, and enqueue the Actions received too early on the host side. However this approach would imply a lot of modifications and efforts to make it work, this is why we chose to make the host unfair.

Instruction

To run and test Node.io, you can either:

• Load the project using Android Studio (or Intellij), Gradle tasks should load automatically.

• Launch gradle tasks using CLI (not detailed).

• Download the app on the PlayStore here.

• Execute directly the app using the .jar file in the Node.io/desktop/build/libs/ folder, for the desktop version.

Attributions

• Background made by Enjl.

• Tiles made by Ajay Karat | Devil's Work.shop.

• Character made by Gamekrazzy.

• Bush made by Dreammix.

• Footstep sound made by GleenM.

• Speak sound made by Juaner_.

• Music "Blob Monsters on the Loose" and "Analog Nostalgia" made by Eric Matyas.