Solcery Game
Processing game state
Solcery Game is a primary protocol, handling the game process. It has several structures as entrypoints, each of which is represented by a separate Solana account:
Game State
Account storing a full description of the game state. Game objects are instances of the classes, creating in Soclery Engine.
Minimalistic game object structure looks like this:
  • id - unique object identificator
  • templateId - specifies object type
  • attrs - tuple of a predefined size with for all possible object fields known in advance
Initial game state is assembled once during the project compilation stage and is passed into all instances of the same game on start. All latter actions and events are handled inside the particular game and are recorded in its log.
Game Content
Describes everything required by on-chain game logic - all the existing game entities' classes, all the atomic behaviour that might be referenced from the runtime. All of it packed specifically with the runtime needs in mind.
Any metadata required by the client app to render the game state
  • Links for all the resources - images, sounds, effects
  • Mapping of game entities and resources
  • UI layout and behaviour configuration
Logged actions of players and any other entities or external protocols, having access to the game. All games on Solcery must adhere to a determenistic model. This allows to reproduce the full game state by just having the initial game state and rolling the log on it, which can be done both on- and off-chain in case of on-chain runtime malfunction or for additional client validation in case of game result consensus breach. Same format will be used for game replays when we need them.
Copy link