Game

Short

• Maintains game state
• Simulates environment events
• Runs player actions

General Overview

Each game has its own instance of a game container. The game container is responsible for maintaining the game state, the worker avatars for the game, fetching the actions from each worker, and applying the worker.

The game interacts with the rest of the components as follows:

• It is created by the game creator.
• It creates workers and restarts them when a user changes their avatar's code.
• It exposes an API to provide the workers with the code.
• It fetches the game settings from the UI.

Once per turn it will:

• Inform all workers of the current game state and gets their actions.
• Perform conflict resolution on these actions and then apply them.
• Update the world with any other changes (eg move score squares).

Files for the game are stored in aimmo-game.

Internal architecture

The entry point of the micro-service is service.py. The service coordinates several internal components and provides an interface for the UI to communicate with it. The service coordinates the following components:

• Flask Micro-service - exposes through Socket.IO (more details here) the world state visible by a client
• Worker Manager - the room loop responsible for updating the user's code, user arrival and departure
• Turn Manager - the game loop that pools each worker for an action to execute and the updates the game environment

Worker Manager and Turn Manager are daemons that run in the back-ground asynchronously. The Flask Micro-service is exposed to the Django service through a reverse proxy(useful link here). The turn manger runs game loop much more frequently than the worker manager updates the room. (the current wait times are 0.5 sec. for turn manager and 10 sec. for worker manger).