# Extend the Checkers Game With a Leaderboard
In this section, you will learn:
- How to make an existing chain IBC-enabled.
- How to extend your chains with additional modules.
# What you will be building and why
The checkers blockchain you have built has the ability to create games, play them, forfeit them, and wager on them (potentially with cross-chain tokens). A further optimization would be to include a leaderboard. This could be executed locally on the checkers blockchain to rank the best players on the checkers blockchain. You can see an example of this in the migration sections.
But what if there is more than one checkers chain? Or better yet, other game chains that allow players to play competitive games. Would it not be great to enable a standard to send the game data from the local game chain to an application-specific chain that keeps a global leaderboard? This is exactly what you will be building in the next few sections.
Remember the appchain thesis that is an integral part of the interchain philosophy - where every application has its own chain and can be optimized for the application-specific logic it executes. Then IBC can be used to interoperate between all the chains that have specialized functionality. This is the idea behind the prototype checkers and leaderboard chains you're building, enabling IBC packets to be sent between those chains to create cross-chain applications.
# Adding a local leaderboard module to the checkers chain
Currently, your checkers game contains the checkers module but is not IBC-enabled. It is now time to extend your checkers game with a leaderboard by adding a new module to make it IBC-enabled.
Let’s dive right into it.
Go to your checkers folder and make sure that you are checked out on the cosmjs-elements (opens new window) branch.
In the checkers chain folder, you can scaffold a leaderboard module with Ignite:
In order to create and maintain a leaderboard, you need to store the player information. Scaffold a structure with:
Now you can use this structure to create the board itself:
The structures created by Ignite are nullable types (opens new window) by default, but you do not want that. So a few adjustments are needed - especially because you do not have a null value for an address.
You need to make the adjustments in the Protobuf files
proto/leaderboard/genesis.proto. Make sure to import
gogoproto/gogo.proto and use
[(gogoproto.nullable) = false]; for the
PlayerInfo and the
Board (opens new window).
For example, for
proto/leaderboard/board.proto try this:
After re-compilation, you will also have to modify the
x/leaderboard/genesis.go. In it, look for:
Next, in the
x/leaderboard/genesis_test.go, look for:
x/leaderboard/types/genesis.go, look for:
Now, in its associated test:
Continue preparing your new leaderboard module.
The checkers module is the authority when it comes to who won and who lost; the leaderboard module is the authority when it comes to how to tally scores and rank players. Therefore, the leaderboard module will only expose to the checkers module functions to inform on wins and losses, like
To achieve this, first you need to write those functions. Create a
x/leaderboard/keeper/player_info_handler.go file with the following code:
For the code above to function, you need to define
x/leaderboard/types/keys.go. Add the following piece of code at the end of the file:
Now it is time to allow the checkers module access to the leaderboard module. This is very similar to what you did when giving access to the bank keeper when handling wager tokens.
Declare the leaderboard functions that the checkers needs:
Add this keeper interface to checkers, modify
x/checkers/keeper/keeper.go, and include the leaderboard keeper:
Make sure the app builds it correctly. Look for
app/app.go and modify it to include
You want to store a win plus either a loss or a forfeit when a game ends. Therefore, you should create some helper functions in checkers that call the leaderboard module. Create a
x/checkers/keeper/player_info_handler.go file with the following code:
Do not forget to add the new errors in
With the helper functions ready, you can call them where needed. Add the call for a win in
Add the call for a forfeit in
That will get the job done, and add the player's win, loss, or forfeit counts to the store.
If you did the migration part of this hands-on exercise, you may notice that, here, although the player info is updated, the leaderboard is not. This is deliberate in order to show a different workflow.
Here, the leaderboard is updated on-demand by adding the signers of a message as candidates to the leaderboard. Scaffold a new message:
Again, you can first create some helper functions in
The function that sorts players is rather inefficient, as it parses dates a lot. To optimize this part, you would have to introduce a new type with the date already parsed. See the migration section for an example.
If it cannot parse the date information, it will return an error that you need to declare in
Now you need to call what you created in
Also call the two new errors:
That is it! Now the checkers blockchain can keep track of player information, and create or update the leaderboard based on player input.
# Unit tests
You have created a new expected keeper. Have Mockgen create its mocks by reusing the
make command prepared earlier:
Update the checkers keeper factory for tests:
Because of the change of signature of this function, you need to adjust wherever it is called, like so:
You must also change where it is used. Mostly like this, when the leaderboard is not called:
Like this, when the leaderboard is called but you are not looking to confirm the calls:
This introduces a new function, so (as you did for the bank keeper mock) you add the missing helpers to define expectations. For instance:
Do not forget to add tests to check that the leaderboard is called as expected:
Do not forget to add some unit tests (opens new window) for your leaderboard keeper too.
# Forwarding player information via IBC
It is time to look at how you can forward the player information via IBC.
Remember, you created the module with the
You can scaffold an IBC transaction with:
How the message constructor was created makes the player information a parameter. However, you do not want arbitrary player information, but instead want to fetch the creator's player information from the store. To do this, make a small adjustment to
x/leaderboard/client/cli/tx_candidate.go. Look for the following lines and remove them:
You will also need to remove the import of
encoding/json because it is not used anymore, and you should remove the parameter
argPlayerInfo from the
types.NewMsgSendCandidate(...) call, from function (opens new window), and not least from
The last step is to implement the logic to fetch and send the player information in
You do not handle received packets, because this module is only meant for sending player information to a separate leaderboard chain, which you will create next.