Architectural Overview

Modules

Each game is divided into several modules. Those modules require different maps and might run on different servers. For example, your game might need a lobby module, which is the starting module and provides a countdown for the start of the actual game. During that time period, new players can join the game and vote for a map. Internally, they are transferred to the lobby start module. When the game starts, the original start module launches a second module called game with the voted map, transfers all players to the new module and stops itself. Now, game executes the actual game. When the game is over, it kicks all players and stops itself as well.

The above construct is just an example composition of two different modules. All modules are packaged and distributed in a game archive file, which is just a ZIP file with your modules, some global configurations, and some default resources (e.g. configs). If your server wants to use its own lobby, you can just replace the original lobby module with your own version.

If you haven't guessed already, a module is just a plugin which runs on a server. It is put there by the container. Each module must be able to coexist with other modules on the same server.

You might wonder: Well, that's nice, but what happens if the container decides to use a server for two processor-heavy modules? How is the container able to decide which configurations make sense? Actually, solving this problem is rather difficult. For GameSpec, we will probably introduce a number that specifies how processor-heavy a specific module is. Using that number, the container can try to keep all servers balanced.

API Overview

It is important to note that the maps a module wants to use must be defined when the module is launched. That is necessary so containers can select the server the new module instance will be running on depending on the maps it needs.

Moreover, each module is configured to use specific resources. Those resources might be configs, but they might also be schematics which are spawned in. They can be essentially anything. The game archive provides default resources which can be modified (configs) or overridden (others) by custom resources specified by the user. It is also possible to extract default resources into the custom user resource repository if they do not yet exist there. GameSpec might also support merging of updated configuration files (TO EDIT). Note that resources which are not absolutely required to be in the game archive as a default "fallback" should be supplied through a separate archive (e.g. default maps). That way, the main game archive is not polluted with content most servers don't need.

Finally, each module is able to store persistent key-value pairs either globally or only for itself. The values must be primitives, strings, or lists of primitives and strings.