There are essentially 3 main types of architecture in decentralized gaming. There may be other options, but those listed here are the main categories and are a useful way to classify all blockchain games whether they are decentralized or not. Many blockchain games are centralized, but have tokens sitting on Ethereum, such an architecture also be described within the categories mentioned here.
The main technical goal of decentralized gaming
The goal is to have decentralized verification of player actions.
The first approach to tackle this is to put everything into layer 1. Either directly in the chain, or into smart contract, but as we explore the possibilities we find that it isn’t necessary to all the computation done at Layer 1 (“on the chain”). It turns out that splitting the game logic from the functions of the blockchain into separate layers.
The main 3 architectures that exist are:
In this architecture the processing of the game logic is done entirely inside the blockchain client software. That is to say that the game logic is precompiled before the software is run. All actions are stored on-chain and therefore such games can be fully decentralized, providing the underlying blockchain is decentralized.
The user interface (UI), basically the game client, has two main functions:
- render the data that’s recorded on-chain.
- allow the player to record new moves on-chain
As the node software is performing the validation and storing of all player moves then everyone who has a copy of the software and the chain data will be able to agree upon the game’s state. The current state of any game is the aggregation of all historical moves.
Splitting up the data into layers also indicates that not all computation will be done on-chain (by the node software). There are two popular approaches to creating layers.
- One solution to this is to put only the game assets on-chain but to keep all of the game’s logic off-chain. This a centralized game with tokenized assets sitting on-chain.
- Another approach is to record all of the player actions on-chain but the node software doesn’t interpret those actions or verify their meaning. This is essentially a colored coins approach.
The blockchain ensures that all players have the same record of player actions. Assuming that all players have the same game client then each player can independently interpret and verify which of the actions stored on-chain are valid. Consequently, all players can independently derive the current game state and the game can be correctly categorized as fully decentralized.
- Taurion (current version) – fully decentralized game where the player actions are stored on-chain.
This architecture is also a layered approach except the upper-layers are split. Doing so provides an option of splitting the decentralized part of the stack from a (potentially) centralized part. Splitting the stack is a common method that provides some amount of scalability or convenience. It is also possible to move the centralized part of the stack onto decentralized infrastructure which provides a progressive approach to achieving a goal of full decentralization.
The decentralized part in the top right could also be fully centralized or even as an option for players who don’t want to run a full node. Some games will offer optional centralization as a form of convenience, while others will only offer a centralized solution but that is outside the scope of this site!
- Centralized: Forgotten Artifacts – “a hack-and-slash dungeon crawler which runs on Ethereum Mainnet via the Enjin Platform”.
- Decentralized: Taurion (upcoming version) – in a future version of the game it will be possible to have the option to host the game remotely, which could allow for many players to share the same blockchain node.
An older version of this article, with more details, was published to Medium, see here.
Even greater detail can be found in the upcoming book on Decentralized Gaming. This is an open-source resource that’s currently in a draft phase.