Skip to content

The Game Processor

Ryan edited this page Mar 8, 2019 · 1 revision

Step 2: High-level Overview of the Game State Processor and libxayagame

In First Steps we explained xayad and the blockchain part of the system. In this second tutorial we look at the Game State Processor (GSP).

The GSP consists of 2 main parts.

  • libxayagame
  • Game logic

2 parts of the GSP

libxayagame reads all the relevant game information from the blockchain through xayad's RPC and in conjuction with the game logic (which you write), calculates the state of the game. The state of the game could be the position of players on a map, how many gold pieces they have, what armour they are wearing, or whatever is important to your game.

Relation of GSP to xayad

It can store the game state in memory or in a database, such as SQLite or LMDB.

Data storage for libxayagame game states

The GSP runs autonomously and processes new blocks as they come in, in real time.

It also records "undo data" that is used to backtrack through game states should a fork or reorg occur in the blockchain.

The GSP can run independant of a front end (GUI), but requires the blockchain to receive the data to compute.

GSP relation to front end

Front ends talk to the GSP to receive the state of the game. This could be all at once, or the front end could request only specific amounts of data at a time.

Now you're ready to build and work with libxayagame in simple C++ Hello World and C# Hello World tutorials.

Clone this wiki locally