# Let Players Set a Wager
Make sure you have everything you need before proceeding:
In this section, you will:
- Add wager information (only).
- Update unit tests.
With the introduction of game expiry in the previous section and other features, you have now addressed the cases when two players start a game and finish it, or let it expire.
In this section, you will go one step closer to adding an extra layer to a game, with wagers or stakes. Your application already includes all the necessary modules.
Players choose to wager money or not, and the winner gets both wagers. The forfeiter loses their wager. To reduce complexity, start by letting players wager in the staking token of your application.
Now that no games can be left stranded, it is possible for players to safely wager on their games. How could this be implemented?
# Some initial thoughts
When thinking about implementing a wager on games, ask:
- What form will a wager take?
- Who decides on the amount of wagers?
- Where is a wager recorded?
- At what junctures do you need to handle payments, refunds, and wins?
This is a lot to go through. Therefore, the work is divided into three sections. In this first section, you only add new information, while the second section is where the tokens are actually handled, and in the third section you add integration tests.
- Even if only as a start, it makes sense to let the game creator decide on the wager.
- It seems reasonable to save this information in the game itself so that wagers can be handled at any point in the lifecycle of the game.
# Code needs
When it comes to your code:
- What Ignite CLI commands, if any, will assist you?
- How do you adjust what Ignite CLI created for you?
- Where do you make your changes?
- What event should you emit?
- How would you unit-test these new elements?
- How would you use Ignite CLI to locally run a one-node blockchain and interact with it via the CLI to see what you get?
# New information
Add this wager value to the
StoredGame's Protobuf definition:
You can let players choose the wager they want by adding a dedicated field in the message to create a game, in
Have Ignite CLI and Protobuf recompile these two files:
Now add a helper function to
StoredGame using the Cosmos SDK
This encapsulates information about the wager (where
sdk.DefaultBondDenom is most likely
# Saving the wager
Time to ensure that the new field is saved in the storage and it is part of the creation event.
Define a new event key as a constant:
Set the actual value in the new
StoredGameas it is instantiated in the create game handler:
And in the event:
Modify the constructor among the interface definition of
x/checkers/types/message_create_game.goto avoid surprises:
Adjust the CLI client accordingly:
That is it. Adding just a field is quick.
# Unit tests
Some of your unit tests no longer pass because of this new field. Ajust accordingly.
When creating a game:
When checking that it was saved correctly:
When checking that the event was emitted correctly:
Go ahead and make the rest of the changes as necessary.
# Interact via the CLI
With the tests done, see what happens at the command line. All there is to check at this stage is that the wager field appears where expected.
After restarting the Ignite CLI, how much do Alice and Bob have to start with?
Create a game with a wager:
Which mentions the wager:
Confirm that the balances of both Alice and Bob are unchanged, as expected.
Was the game stored correctly?
This confirms what you expected with regards to the command-line interactions.
To summarize, this section has explored:
- How to add the new "wager" value, modify the "create a game" message to allow players to choose the wager they want to make, and add a helper function.
- How to save the wager and adjust an event, modifying the create game handler.
- How to minimally adjust unit tests.
- How to interact via the CLI to check that wager values are being recorded.