Devlog #1: Init Game Managers

And it often becomes the first bottleneck when starting a new project using a new programming language and/or engine. Most of the beginner-level game developers’ tutorials cover topics such as adding functionality to game objects or demonstrating the game engine’s capabilities.

As a beginner-level developer, you are tasked with solving complex problems that senior system architects face, despite knowing that the architecture will require modifications in the future. It’s like you are trying to solve the challenges of a fishing ship that has yet to set sail.

Managers, and controllers system design

From a high-level architecture point of view, I like to think of a game (or app) system as it’s a corporate building with a lot of departments isolated in separate rooms.

Each department has its sole manager with two primary purposes in mind: to communicate with other managers and give internal orders to its controllers.

Where controllers primarily are in charge of a specific entity or a game object.

And to bring some centralised order to the system, there is also the manager’s manager, called the game manager (CEO of the whole game system design) that is in charge of the overall state of the game thus controlling other managers.

High-level, scalable game development architecture

And this is where the scalability comes from, the more complex the game gets, the more managers and controllers you are going to add to the game’s system.

It definitely adds some unwanted complexity at the beginning of the game development, but I believe it will pay off in the longer run.

Observer pattern in Defold game engine

Some would say: “communication is the key”, and they are right, especially when it comes to such system design. Defold engine provides a beautiful message-passing mechanism for game object communication which serves great when it comes to simple sender-receiver communication.

The downside is that when we add a new event to a system or a game object, we need to explicitly appoint all the interest parties. Solution: broadcast.lua module, that enables sending of a message to multiple receivers. In this case, managers can subscribe only to those events that they are interested in.

Here is my rule of thumb when it comes to the Defold’s communication between systems:

• manager-to-manager - use broadcast.lua module, where each manager subscribes to events that are only relevant to fulfil its purpose.
• manager-to-controller (and vice-versa) - use Defold’s message-passing mechanism (msg.post) to keep the higher-level communication channels clean. The GameManager doesn’t need to know what’s the rotation/angle of every spawned ship in the game, but the ShipManager does care about it.

Without further ado, let me introduce …

The Game Managers of the Next Space game

1. GameManager - the CEO of the Next Space system design. Manages the overall state of the game, and manages the other managers;
2. InputManager - detects the user input, and groups the user gesture by a selected action state;
3. UIManager - a visual representation of the game state provided by other managers, a strong relationship with InputManager;
4. WorldManager - overall game object manager;
5. ShipManager - spawns and controls the ship poll. A strong relationship with WorldManager;
6. CameraManager - responsible for render, viewport, and camera actions;
7. NetworkManager - (currently) loading gameplay basic data.

Next one in the hiring process, or to be implemented in the upcoming iterations:

1. SoundManager - sound effects and music in general
2. SystemManager - game objects based on the environment
3. GameplayOneManager - first gameplay loop manager
4. … other positions