# Record the Game Winner
In this section, you will:
- Check for a game winner.
- Extend unit tests.
To be able to terminate games, you need to discern between games that are current and those that have reached an end - for example, when they have been won. Therefore a good field to add is for the winner. It needs to contain:
- The winner of a game that reaches completion.
- Or the winner by forfeit when a game is expired.
- Or a neutral value when the game is active.
In this exercise a draw is not handled and it would perhaps require yet another value to save in winner.
It is time to introduce another consideration. When a game has been won, no one else is going to play it. Its board will no longer be updated and is no longer used for any further decisions. In effect, the board becomes redundant. With a view to keeping a node's storage requirement low, you should delete the board's content but keep the rest of the game's information.
To keep a trace of the last state of the board, you emit it with an event.
# New information
StoredGame Protobuf definition file:
Have Ignite CLI and Protobuf recompile this file:
Add a helper function to get the winner's address, if it exists. A good location is in
# Update and check for the winner
This is a two-part update. You set the winner where relevant, but you also introduce new checks so that a game with a winner cannot be acted upon.
Start with a new error that you define as a constant:
And a new event attribute:
At creation, in the create game message handler, start with a neutral value:
With further checks when handling a play in the handler:
Check that the game has not finished yet:
Update the winner field, which remains neutral (opens new window) if there is no winner yet:
Handle the FIFO differently depending on whether the game is finished or not, and adjust the board:
Add the new attribute in the event:
And when rejecting a game, in its handler:
Confirm the code compiles, add unit tests, and you are ready to handle the expiration of games.
# Unit tests
Add tests (opens new window) for your new functions.
You also need to update your existing tests so that they pass with a new
Winner value. Most of your tests need to add this line:
"*" means that in your tests no games have reached a conclusion with a winner. Time to fix that. In a dedicated
full_game_helpers.go file, prepare all the moves that will be played in the test. For convenience, a move will be written as:
If you do not want to create a complete game yourself, you can choose this one:
You may want to add a small function that converts
"r" into their respective player addresses:
And another that applies all the moves. This could become handy if you have multiple games in the future:
Now, in a new file, create the test that plays all the moves, and checks at the end that the game has been saved with the right winner and that the FIFO is empty again:
When checking the attributes, it only cares about the last five.
Feel free to create another game won by the red player.
# Interact via the CLI
If you have created games in an earlier version of the code, you are now in a broken state. You cannot even play the old games because they have
.Winner == "" and this will be caught by the
if storedGame.Winner != rules.PieceStrings[rules.NO_PLAYER] test. Start again:
Do not forget to export
bob again, as explained in an earlier section under "Interact via the CLI".
Confirm that there is no winner for a game when it is created:
This should show:
And when a player plays:
This should show:
Testing with the CLI up to the point where the game is resolved with a rightful winner is better covered by unit tests or with a nice GUI. You will be able to partially test this in the next section, via a forfeit.
To summarize, this section has explored:
- How to prepare for terminating games by defining a winner field that differentiates between the outright winner of a completed game, the winner by forfeit when a game is expired, or a game which is still active.
- What new information and functions to add and where, including the winner field, helper functions to get any winner's address, a new error for games already finished, and checks for various application actions.
- How to update your tests to check the functionality of your code.
- How interacting via the CLI is partially impeded by any existing test games now being in a broken state due to the absence of a value in the winner field, with recommendations for next actions to take.