# Fundamentals of Games on Holochain

Holochain is an ideal system for developing certain types of game protocols. The word 'game' can mean a lot of different things in different contexts. When we refer to a game we mean it in the simplest possible way.

- An interaction between two or more **players**
- The players take **actions/moves** which must abide by certain **rules**
- Through taking actions the game reaches a demonstratable **outcome**

Many types of interactions people engage in that we typically don't refer to as games can be framed this way (e.g. a cryptocurrency transaction, voting etc)

## What kind of games are suitable?

The simplest class of games that are well suited to Holochain are [sequantial games](https://en.wikipedia.org/wiki/Sequential_game) with [perfect information](https://en.wikipedia.org/wiki/Perfect_information). This includes the classical board games including

- Chess/Checkers
- tic-tac-toe
- Go
- Chinese Checkers
- [Reversi/Othello](https://en.wikipedia.org/wiki/Reversi) *great one to try
- [Dots and Boxes](https://en.wikipedia.org/wiki/Dots_and_Boxes)
- [Halma](https://en.wikipedia.org/wiki/Halma)
- [Nim](https://plus.maths.org/content/play-win-nim)
- [Hex](https://en.wikipedia.org/wiki/Hex_(board_game))
- [Racetrack](https://en.wikipedia.org/wiki/Racetrack_(game)) (Thanks Mike great suggestion)

These are the types of games we will focus on in this course.

As an aside Holochain can also be used for games that require imperfect/hidden information that must be committed to in advance and not changed. Examples of these types of games are

- rock/paper/scissors
- battleship

There is also the possibility of games that require randomness. Randomness cannot be generated internally but entropy can be supplied by each of the participants such that no subset can predict the outcome. This allows for games like

- dice games
- card games

These are outside of the scope of this course but will be entirely within your ability after the course is complete!

### Games that are NOT suitable

Anything that requires real-time or timing dependent interactions. Basically anything considered a modern video game is not suitable. Furthermore any single player game is not a good choice since this does not make use of the features of Holochain! Games with many players are possible but outside the scope of this course. It is best to keep the player requirements small.

If you have another idea for a game you want to implement be sure to check with us beforehand to ensure you have the best learning experience possible.

## 1. General game architecture

The fundamental building block of all of these games is an **action** or **move**. Given all the moves that have taken place in a particular game so far it should be possible to entirely determine the **game state**. Given moves made so far and a new move must be possible to determine if this new move is valid or invalid. Each move must also be cryptographically signed by the agent making it to prove that it was indeed authorized by them. Moves can be represented by **entries** in Holochain. This means they are automatically validated, signed, persisted to the local chain and possible pushed to the DHT as well.

### An example - Checkers


#### Moves

Lets look at the concrete example of a game of checkers. A move might looks as follows:

{
    game: "QmHashOfGame123",
    author: "QmMyAgentAddress000",
    previous_move: "QmHashOfPreviousMove"
    move_type: {
        MovePiece: { 
            from: {x: 0, y: 2}, 
            to: {x: 1, y: 3} }.
        }
    }
}

This would be some agent (QmMyAgentAddress000) playing some game (QmHashOfGame123) moving a piece diagonally. It is important to include all of this extra information (e.g. author, previous move) such that this move has a unique identifying hash.

#### Validation

What might the validation for this kind of move look like? It turns out a simple game like checkers has quite a lot of rules when it comes down to it:

- It must be the authors turn in this game
- The game must not have already ended
- All coordinates must be in bounds
- A piece belonging to the author must exist at the `from` coordinates
- The location of the `to` coordinates must be empty
- That particular movement must be allowed according to the movement rules of the game
- Can only move diagonally unless jumping an opponents piece
- Can only move forward unless piece is a king (has reached the other side)

If these rules are correctly captured and encoded into the Holochain validation callback for a `move` entry the DNA will reject any attempted moves that are not valid. It is fundamentally impossible to make an invalid move without hacking the validation process (after which other legitmate agents who validate your move can identify you as a cheater and block any further actions).

#### State

The game state for a checkers game could be represented in many ways. One possible way is to store only the location of the pieces for each player in a sparse array format e.g.

{
    complete: false,
    player_1: {
        pieces: [{x: 3, y: 2}, {x: 4, y: 1}, ...],
        resigned: false,
    }
    player_2: {
        pieces: [{x: 7, y: 2}, {x: 8, y: 3}, ...],
        resigned: false,
    }
}

Remember the state is not stored but only reduced from a sequence of moves. It is only needed for performing the validation of new moves.

Reducing the state from a sequence of moves may also be complex and account for things such as:

- Pieces captured
- Pieces reaching the other side to become a king
- If one of the players has resigned

### Exercises:

1. Write down what a move for your game might look like. Make sure that each move has enough fields to be totally unique.

1. List the validation rules for a move in your game. Be sure to capture everything even if it is obvious (Holochain doesn't know about object permanance)

1. Consider how to represent the state in your game. Write pseudocode for how you could reduce a sequence of moves into a given game state.