Games built on the SpaceXpanse platform have several major components.

• SpaceXpanse daemon
• Game state processor
  • libspex
  • Game logic
• Front end

The SpaceXpanse daemon (spacexpansed) is responsible for querying the SpaceXpanse blockchain and sending data to it, such as with name_update. (See SpaceXpanse RPC Methods for more information.)

The game state processor (GSP) is composed of libspex and the game logic. It is responsible for computing the current state of the game.

The libspex library takes care of complex blockchain logic and provides an easy to implement interface for game developers.

Game logic is written by developers for their games.

The front end is the GUI where end users interact with the game.

Implementations may differ, but the first diagram described here mirrors the approach taken in the Mover sample game.

The relationships between the various components can be visualised as shown below. The red components are parts of the SpaceXpanse platform. The green components are written by game developers. The arrows represent the flow of information.

In this diagram, libspex is running as an RPC server, i.e. it is a "default" RPC server. However, if you wish to run custom RPCs you can do so in a custom main function, in which case information flow would be between the game logic and the front end.

As Mover is very simple, the above model is sufficient. However, complex games can benefit from using a custom RPC server. Whether the information flow is between libspex and the front end or between the game logic and the front end doesn't particularly matter; it's merely a design choice. Running a custom RPC server would then follow this pattern:

The custom RPC server may or may not be included in the game logic. How it is implemented is up to individual developers.

The general case of how the information flows can be viewed as interaction between the GSP and other components, i.e. front end and SpaceXpanse daemon:

The information below is for the first diagram above in order to align with the Mover sample game.

The daemon (spacexpansed) receives requests from the front end and returns responses. These are typically name_list (to find the names in the user's wallet) and name_update (to submit moves onto the blockchain) operations.

The daemon also receives requests from libspex and returns responses. These are "black box" operations that game developers do not need to worry about.

Further, the front end subscribes to libspex for game state updates. It then receives game state updates in a listener that runs on its own thread.

libspex sends information, such as new game moves, to the game logic which processes that data and returns the new game state to libspex.

The front end subscribes to updates from libspex (as mentioned above). When a new game state arrives, it updates the GUI for end users. Those end users can then make new moves that the front end submits to the daemon (spacexpansed), which enters those moves into the mempool where SpaceXpanse miners can mine them as transactions onto the SpaceXpanse blockchain.

Once those moves have been mined into a block, the black box magic of the SpaceXpanse daemon and libspex sort out what the game logic needs to know, get a response from the game logic, and then libspex sends that final game state to the front end.

The front end is also responsible for starting and stopping the GSP.

If you want to compile libspex, see the How to Compile libspex on Windows document or the How to Compile libspex in Ubuntu document.