In previous articles, I've started to lay out the some of the pain points we've experienced developing CryptoFights in the Ethereum world, and how Bitcoin SV provided the solutions we needed. In this article, I'm going to go a little deeper into one approach to game development of a fully peer-to-peer game on BSV and hopefully illustrate the power we have ready and waiting right now.

Let's play a game

Take the game of chess as an example. Two siblings, Alice and Bob, love to play a friendly game, but they are a competitive sort. As such, they want to maintain an immutable history of their game to ensure bragging rights are properly bestowed.

There are 6 different piece types in chess (pawn, bishop, knight, rook, queen, and king), and each one can move and attack in its own fashion. Every turn, a player moves a single piece. For each piece type we'll implement a state transition function. A state transition function takes the current game state data and a player action as input, validates the action, and returns a new game state.

The game of chess consists of an 8x8 grid where each square can contain 0 or 1 pieces. The game state can be stored as a simple array representing the squares of the board, and a boolean to tell if the game is completed. Each element of the array holds the ID of a Bitcoin transaction which defines the properties of the piece currently on that square (or null if the cell is empty). These properties include an icon to represent the piece on the game board, and Javascript (or WebAssembly) code containing the state transition function for that piece.

Game Challenge

Each player has a game client on their mobile phone with a built-in Bitcoin wallet. This game wallet is constructed specifically to play turn-based games which are played on a chess board and hold the public key of the the developer who created it.

Each game the wallet supports has game definition data stored in a bitcoin transaction, signed by the game developer and including the game's initial state and other metadata. (Chess Def Transaction)

Alice decides to challenge Bob to a game of chess. To do so her game wallet sends a bitcoin transaction which contains the following outputs:

OP_RETURN GAME_PROTOCOL <Chess Def Transaction ID> INIT Micropayment of dust amount (currently about $0.0003) payable to Bob's Bitcoin address

Alice's game wallet initializes game state by downloading the initial state from the Chess Def Transaction, and stores it locally associated with the transaction id she just sent to Bob.

When Bob's game wallet receives the transaction, it recognizes GAME_PROTOCOL in the OP_RETURN as a game, downloads Chess Def Transaction, verifies the developer signature, initializes game state, and notifies Bob of the challenge. He accepts and takes his first turn.

State Transitions

Bob starts the game off by selecting the action of moving his knight from cell B1 to C3 (note: I'm addressing squares like spreadsheet cells because ignorance). His game wallet loads up and calls the knight transition function (the piece he is moving) and passes in the initial state and Bob's action. This will validate that Bob's action is legal and then update his copy of the game state.

Bob then sends a Bitcoin transaction spending the UTXO Alice's previously sent to him with the following outputs:

OP_RETURN GAME_PROTOCOL <Chess Def Transaction ID> < Knight TxnId> B1 C3 Micropayment of dust amount payable to Alice's address

Bob's game wallet then stores the resultant game state associated with the transaction id he just sent.

When Alice's game wallet receives the transaction, it recognizes the source UTXO she previously paid out, and loads up the game state associated with it. It then loads up and calls the knight transition function and passes in the loaded state and Bob's action to update her copy of the state.

Alice then takes her turn (i.e. move pawn from D7 to D6), updates her copy of the game state, and repeats the steps above. This pattern continues back and forth until a transition function marks the game state as complete.

A Fun Twist

I used Chess because the rules are well understood and also, it uses the same board as other games. Also, I intentionally made this example game more complicated than in needs to be to illustrate a few points.

The game publisher could easily release a version of checkers with no changes to the game client at all. It would simply require a new Game Def Transaction which contains a different initial state where the pieces point to new transition functions. Other game wallets could be released which trust the rules from the same game developer and implement the same rules, but do so with a different UI or other alterations. These other game wallets could also trust signatures from other game developers allowing for an initial state which is a game of checkers that also includes chess Bishops from the first developer's game, and a teleporting gecko who swallows all adjacent pieces every 10 rounds.





This is SUPER powerful as it allows completely extensible games and ushers in a true multiverse of gaming awesome. This is how Oasis happens, and the plot completely falls apart if it would have been built on Bitcoin.

Notice that every bit of source code, data, and player actions are stored immutable in Bitcoin and cryptographically signed by its creator. The game state itself is never stored, yet it can be easily recreated by simply following the unbroken chain of transactions.

The last thing I want to point out here is so simple and yet incredibly profound:

The above game literally costs $0.0003 per turn to play.