# Record the Game Winner

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 new events. If not, follow the previous steps or check out the relevant version (opens new window).

In this section, you will:

• Check for a game winner.
• Extend unit tests.

In a previous section you made it possible to determine the outcome of a game by declaring a winner. You also emitted it.

The next logical step is to also record this information in storage. That will assist you in discerning between games that are current and those that have reached an end by winning. As you will see in subsequent sections about forfeit, there are other ways for a game to finish.

Therefore, a reasonable 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 section a draw is not handled and it would perhaps require yet another value to be saved 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 on-chain 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

In the 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 full_game.go:

# 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:

1. Check that the game has not finished yet:

   Copy ... + if storedGame.Winner != rules.PieceStrings[rules.NO_PLAYER] { + return nil, types.ErrGameFinished + } isBlack := storedGame.Black == msg.Creator ... x checkers keeper msg_server_play_move.go View source

2. Update the winner field, which remains neutral (opens new window) if there is no winner yet, and adjust the board depending on whether the game is finished or not:

   Copy ... - storedGame.Board = game.String() + storedGame.Winner = rules.PieceStrings[game.Winner()] + + lastBoard := game.String() + if storedGame.Winner == rules.PieceStrings[rules.NO_PLAYER] { + storedGame.Board = lastBoard + } else { + storedGame.Board = "" + } ... x checkers keeper msg_server_play_move.go View source

3. Add the new attribute in the event:

   Copy ... ctx.EventManager().EmitEvent( sdk.NewEvent(types.MovePlayedEventType, ... sdk.NewAttribute(types.MovePlayedEventWinner, rules.PieceStrings[game.Winner()]), + sdk.NewAttribute(types.MovePlayedEventBoard, lastBoard), ), ) ... x checkers keeper msg_server_play_move.go View source

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:

This "*" 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 "b" and "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:

When checking the attributes, it only cares about the last six:

Copy event.Attributes[(len(testutil.Game1Moves)-1)*6:])

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. At some point, look at migrations to avoid falling into such a situation with a blockchain in production.

Start again:

Do not forget to export alice and 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 (as done here) or with a nice GUI. You will be able to partially test this with the CLI in the next section, via a forfeit.