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.
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/board.proto and 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:
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 MustAddWonGameResultToPlayer(...).
To achieve this, first you need to write those functions. Create a x/leaderboard/keeper/player_info_handler.go file with the following code:
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:
Copy
import(
leaderboardTypes "github.com/b9lab/checkers/x/leaderboard/types")type CheckersLeaderboardKeeper interface{MustAddWonGameResultToPlayer(ctx sdk.Context, player sdk.AccAddress) leaderboardTypes.PlayerInfo
MustAddLostGameResultToPlayer(ctx sdk.Context, player sdk.AccAddress) leaderboardTypes.PlayerInfo
MustAddForfeitedGameResultToPlayer(ctx sdk.Context, player sdk.AccAddress) leaderboardTypes.PlayerInfo
} modular b9-checkers-academy-draft ... types expected_keepers.go View source
Add this keeper interface to checkers, modify x/checkers/keeper/keeper.go, and include the leaderboard keeper:
Copy
type( Keeper struct{ bank types.BankEscrowKeeper
+ board types.CheckersLeaderboardKeeper
cdc codec.BinaryCodec
storeKey sdk.StoreKey
memKey sdk.StoreKey
paramstore paramtypes.Subspace
})...funcNewKeeper( bank types.BankEscrowKeeper,+ board types.CheckersLeaderboardKeeper, cdc codec.BinaryCodec, storeKey, memKey sdk.StoreKey, ps paramtypes.Subspace,)*Keeper {// set KeyTable if it has not already been setif!ps.HasKeyTable(){ ps = ps.WithKeyTable(types.ParamKeyTable())}return&Keeper{ bank: bank,+ board: board, cdc: cdc, storeKey: storeKey, memKey: memKey, paramstore: ps,}} modular b9-checkers-academy-draft ... keeper keeper.go View source
Make sure the app builds it correctly. Look for app.CheckersKeeper in app/app.go and modify it to include app.LeaderboardKeeper:
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 x/checkers/types/errors.go:
Copy
ErrWinnerNotParseable = sdkerrors.Register(ModuleName,1118,"winner is not parseable: %s")
ErrThereIsNoWinner = sdkerrors.Register(ModuleName,1119,"there is no winner")
ErrInvalidDateAdded = sdkerrors.Register(ModuleName,1120,"dateAdded cannot be parsed: %s")
ErrCannotAddToLeaderboard = sdkerrors.Register(ModuleName,1121,"cannot add to leaderboard: %s") modular b9-checkers-academy-draft ... types errors.go View source
With the helper functions ready, you can call them where needed. Add the call for a win in x/checkers/keeper/msg_server_play_move.go:
Copy
func(k msgServer)PlayMove(goCtx context.Context, msg *types.MsgPlayMove)(*types.MsgPlayMoveResponse,error){... lastBoard := game.String()if storedGame.Winner == rules.PieceStrings[rules.NO_PLAYER]{ k.Keeper.SendToFifoTail(ctx,&storedGame,&systemInfo) storedGame.Board = lastBoard
}else{ k.Keeper.RemoveFromFifo(ctx,&storedGame,&systemInfo) storedGame.Board ="" k.Keeper.MustPayWinnings(ctx,&storedGame)+// Here you can register a win+ k.Keeper.MustRegisterPlayerWin(ctx,&storedGame)}... modular b9-checkers-academy-draft ... keeper msg_server_play_move.go View source
Add the call for a forfeit in x/checkers/keeper/end_block_server_game.go:
Copy
func(k Keeper)ForfeitExpiredGames(goCtx context.Context){...if deadline.Before(ctx.BlockTime()){// Game is past deadline k.RemoveFromFifo(ctx,&storedGame,&systemInfo) lastBoard := storedGame.Board
if storedGame.MoveCount <=1{// No point in keeping a game that was never really played k.RemoveStoredGame(ctx, gameIndex)if storedGame.MoveCount ==1{ k.MustRefundWager(ctx,&storedGame)}}else{ storedGame.Winner, found = opponents[storedGame.Turn]if!found {panic(fmt.Sprintf(types.ErrCannotFindWinnerByColor.Error(), storedGame.Turn))} k.MustPayWinnings(ctx,&storedGame)+// Here you can register a forfeit+ k.MustRegisterPlayerForfeit(ctx,&storedGame) storedGame.Board ="" k.SetStoredGame(ctx, storedGame)}... modular b9-checkers-academy-draft ... keeper end_block_server_game.go View source
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 x/leaderboard/types/board.go:
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 x/leaderboard/types/errors.go:
It is time to look at how you can forward the player information via IBC.
Remember, you created the module with the --ibc flag.
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 MsgSendCandidate itself:
The last step is to implement the logic to fetch and send the player information in x/leaderboard/keeper/msg_server_candidate.go:
Copy
func(k msgServer)SendCandidate(goCtx context.Context, msg *types.MsgSendCandidate)(*types.MsgSendCandidateResponse,error){ ctx := sdk.UnwrapSDKContext(goCtx)-// TODO: logic before transmitting the packet+// get the Player data+ playerInfo, found := k.GetPlayerInfo(ctx, msg.Creator)+if!found {+returnnil, types.ErrCandidateNotFound
+}// Construct the packetvar packet types.CandidatePacketData
- packet.PlayerInfo = msg.PlayerInfo
+ packet.PlayerInfo =&playerInfo
...} modular b9-checkers-academy-draft ... keeper msg_server_candidate.go View source
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.
