# Keep Track Of How Many Moves Have Been Played
Make sure you have everything you need before proceeding:
- You understand the concepts of Protobuf.
- Go is installed.
- You have the checkers blockchain codebase with the game deadline. If not, follow the previous steps or check out the relevant version (opens new window).
In this section, you will:
- Implement a count of game moves.
- Extend your unit tests.
Previously, you added a winner and a deadline to games, with a view to implementing a forfeit mechanism for games that have become stale.
# Some initial thoughts
When the forfeit is implemented, it would be interesting to be able to differentiate games that have never been played on from games that have.
To be specific:
- If no moves are ever played, there is no point in recording a winner and a forfeiter. There is no point in keeping a track of the game.
- If the black player moved once but the red player never showed up, it is the same situation. After all, a malicious player could create many games that go stale just to tarnish the reputation of another player.
- If both players have played at least once, then this can be considered a proper game, where a forfeit is one of the legitimate outcomes.
# New information
To achieve this, the easiest way is to add a new MoveCount
to the StoredGame
. In proto/checkers/stored_game.proto
:
Run Protobuf to recompile the relevant Go files:
MoveCount
should start at 0
and increment by 1
on each move.
Adjust it first in the handler when creating the game:
Before saving to the storage, adjust it in the handler when playing a move:
This value is not emitted in events, because (as it stands) it will be only used internally for checks.
# Unit tests
You have to fix the existing tests by adding MoveCount: 0
(opens new window) (or more (opens new window)) when testing a retrieved StoredGame
.
# Interact via the CLI
There is not much to test here. Remember that you added a new field, but if your blockchain state already contains games then they are missing that field, so the default value of the underlying type will be applied:
Although this game was already played on, the default uint
value is applied:
In effect, your blockchain state is broken. Eventually examine the section on migrations to see how to update your blockchain state to avoid such a breaking change.
Restart your chain with --reset-once
, create a new game, then:
This contains:
To summarize, this section has explored:
- How to implement a new
moveCount
field and increment it on play. - How to test your code to ensure that it functions as desired.
- How, if your blockchain contains preexisting games, that the blockchain state is now effectively broken, since the move count field of those games is
0
by default (which can be corrected through migration).