-
Notifications
You must be signed in to change notification settings - Fork 0
How are there no servers
Games on the XAYA platform can run serverless and upstoppable. They are resistant to censorship. But exactly how that happens may seem like black magic to some. Here, the magician reveals his tricks!
Before examining how XAYA games run serverless, we must examine the traditional online game with a game server. The following diagram illustrates the relationships between the server and game clients.
This is a very familiar scenario.
The game server contains a database and processes all the important game logic. It then relays information to the game clients, who then run minor game logic and display the game for the player.
The main components of the server and client are:
- Game server
- Database on server
- Game logic on server
- Game client
- Limited game logic
- Front end or display logic
- The internet
The XAYA blockchain is a decentralised data store. There are 3 main components to a XAYA application or game.
- XAYA daemon
- Game state processor
- Front end
The XAYA daemon (xayad) is the software that interfaces with the XAYA blockchain. It has a JSON-RPC interface to create accounts, make moves in games, etc.
The Game State Processor (GSP) is where moves are processed and new game states are created.
The front end is where the game is displayed for players. It consumes game states. All the blockchain goodness is invisible to them and "just works".
For XAYA, instead of client-server relationships, we have P2P nodes interacting with each other.
The following diagram is analogous to the diagram above for a game server with the client-server relationship replace by nodes.
The XAYA "client" is a node that connects to the network via P2P and all nodes then relay information to each other. This happens incredibly fast and is near real time, just as the above network with a game server is near real time.
NOTE: Servers are generally on top of internet backbones and enjoy a speed advantage over P2P networks where additional node jumps may be required. Delays between fast servers at 10+ ms and P2P networks at 50~250 ms may be signficant in some games, but insignificant in other games. However, as the advantage/disadvantage applies equally to all players, the games are still fair.
This is how the server is replaced, i.e. with P2P nodes.
You can think of it this way:
- The XAYA daemon replaces:
- The server's network functionality with a P2P network and,
- The server's database with the XAYA blockchain.
- The GSP replaces:
- The server's game logic as all game logic is run by all nodes.
- The GSP gets data from the database/blockchain, i.e. through the XAYA daemon.
- The GSP processes all game logic that would be done on either the server or the client and passes that to the front end. (The GSP runs on the client/node.)
- The front end displays the game state, or more simply, it just displays the game for people to play.
You can visualise the role movement as shown in the following diagram.
It's really that simple.
While there's a truckload of code behind all of that, that's what happens.
Pure. Blockchain. Magic.
- Step 0: Blockchain Basics
- Step 1: xayad <⸺ start here
- Step 2: The Game State Processor
- Step 3a: libxayagame Component Relationships
- Step 3b: Compile libxayagame in Windows
- Step 3b: Compile libxayagame in Ubuntu
- Step 4: Run xayad for Games
- Step 5: Hello World! in C++
- Step 5: Hello World! in C#
- Step 6a: Mover Overview
- Step 6b: Mover Console
- Step 6c: Mover Unity