OpenAstra is mainly composed of a server side engine, where the game behaviours, algorythms and logics are executed, and a game frontend from which players can interact with the game.
The game engine and the game client interact by exchanging JSON messages over TCP/IP using an efficient MSGPACK binary format.
JSON is used extensively on the engine side to define all the game rules, objects behaviours and player commands. JSON schema validation is also enforced to ensure coherence and solidity. JSON has been also choosen as data exchange language between engine and client to ensure that any client platform supporting JSON could be used in the future. The client, when first connect to the engine, will be sent a full copy of the game rules (in JSON format) so that the client itself can adapt if needed.
Modularity concept of plugins is enforced on the engine so that any specific behaviour is coded outside the engine specifics and can be extended easily by adding the plugins as new capabilities and commands, and spcifiing them in the JSON rules.
To build and run the engine, you need a Linux operating system (the engine can be easily adapted for Windows, but some rewrite of core OS APIs is required before that can happen) with the basic development tools and libraries installed. A C++17 compiler is also required, but nowadays any version of the most common Linux compilers are supposedly compliant.
First of all, clone the game repository then, from a terminal, run:
make
This will create a run folder that will link the executables and plugins, as well as the rules of the game.
There are two executables in the run folder: openastraserver and openastracli. The first one is the actual game engine, the second is a simple CLI executable to properly shutdown the server and create new users. The CLI doesn't let you interact with the game like the GUI client at this time.
The engine is built around the GameObject class, which implements an object with the following features:
Currently supported GameObject categories are:
A dataitem is a specific data needed by the game. It's owned by an object and must be defined in the game rules JSON files somewhere to exist. All and every dataitem must be defined beforhand in the game rules, and must have the following details:
Dataitems can be registered in any game rule JSON file in a register_dataitems section which follow this schema, and a good example can be found in the general dataitems file here
Inside the engine, dataitems are instances of the DataItem class. Each GameObject can have only one instance of a dataitem with the same name. Of course, two dataitems with the same name (in two different objects) also share the same type.
If you need to have multiple dataitems with the same name in the same object, either you need Modules or Capabilities instead.
The engine supports the following data types:
for an updated reference, see this schema
Unsigned integer are not supported by choice.
StarCoord, Quantity and Id are specific classes under the game engine utils.