Communication API

The idea is to use a client/server architecture to permit any code in any language to seat on a game (i.e., connect to act as a player). For that we choose to use a high-level messaging library.

High-Level Message Queuing API

We do not require to address directly the TCP protocol while our need for network usage is very classical. A game process acts as a server, accepts and manages client-player processes. Then the game and players exchange game states and action description.

For that purpose tree solution was considered: MQTT - Mosquitto, ZeroMQ and ROS2

  • Mosquitto is a light implementation of the MQTT standard. MQTT defines protocols for process interconnection. a Broker server serves as a central point to connect all the other nodes. Topics are defined as pipes of data flow. Any process can subscribe (i.e. reads) or publish (i.e. write) in the topics. Wikipedia is a good entrance point for more details.
  • ZeroMQ follows its own protocols and propose a high-level interface to interprocess communication via difference communication architecture and different low-level protocols including in-procecus communication.
  • ROS2 is developed for robotic purpose. It is very similar to MQTT in its communication architecture. However, in ROS, messages in topics are typed and several types and algorithms are already developed to exchange, manipulate and visualize geometrical and temporal data. Also in ROS2 the broker process is removed.

For HackaGames use, ZeroMQ present the best compromise. It requires more implementation compared to MQTT - Mosquitto to permit processes to communicate but it allows the development of dedicated game/players communication protocols. This way, there is no need for a broker, and the game server can better address specific information to identified players.

ROS2 solution was removed from the candidates mostly because of the huge dependencies relying on this solution. Using ROS2 induces to install and use a heavy API for developing and for managing communicating processes. One of the core advantages of ZeroMQ resides in the fact that it is an open-source solution developed in C and so on, easily integrable in any other languages.

Appropriation of ZeroMQ

The philosophy is to make games and players interoperable whatever the technology used to develop them. That for HackaGames proposes 2 independent implementation of its core features. One in Python (hackapy) and one in C (hackalib - to come). In hackapy, interoperable API is developed in the (interprocess.py)[https://bitbucket.org/imt-mobisyst/hackagames/src/master/hackapy/interprocess.py] file.

The implementation includes two main classes: Dealer and Client. The Dealer aims to represent a game. It manages Client connection each one labeled as an identified player. A tweak class Local permits a game and players to run in the same process, if all of them are implemented with Python.

This way, implemented games and players are agnostic from the usage or not of interprocess architecture via ZeroMQ. Those elements can be running without any difference with a Dealer and Clients or with Local manager.