# Create Custom Messages for Your Checkers Blockchain
Make sure you have everthing you need before proceeding:
In this section, you will:
- Create a game Protobuf object.
- Create a game Protobuf service interface.
- Extend your unit tests.
- Interact via the CLI.
You have created your game object type and have decided how to lay games in storage. Time to make it possible for participants to create games.
# Some initial thoughts
Because this operation changes the state, it has to originate from transactions and messages. Your module receives a message to create a game - what should go into this message? Questions that you have to answer include:
- Who is allowed to create a game?
- Are there any limitations to creating games?
- Given that a game involves two players, how do you prevent coercion and generally foster good behavior?
- Do you want to establish leagues?
Your implementation does not have to answer everything immediately, but you should be careful that decisions made now do not impede your own future plans or make things more complicated later.
Keep it simple: a single message should be enough to create a game.
# Code needs
- What Ignite CLI commands will create your message?
- How do you adjust what Ignite CLI created for you?
- How would you unit-test your addition?
- 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?
Run the commands, make the adjustments, run some tests. Create the message only, do not create any games in storage for now.
# Create the message
- Your game objects have been defined in storage.
- You prevented a simple CRUD to set the objects straight from transactions.
Now you need a message to instruct the checkers blockchain to create a game. This message needs to:
- Not specify the creator: this is implicit because it shall be the signer of the message.
- Not specify the ID of the game, because the system uses an incrementing counter. However, the server needs to return the newly created ID value, since the eventual value cannot be known before the transaction is included in a block and the state computed. Call this
- Not specify the game board as this is controlled by the checkers rules.
- Specify who is playing with the red pieces. Call the field
- Specify who is playing with the black pieces. Call the field
Instruct Ignite CLI to do all of this:
# Protobuf objects
Simple Protobuf objects are created:
When compiled, for instance with
ignite generate proto-go, these yield:
Files were generated to serialize the pair which are named
*.pb.go. You should not edit these files.
Ignite CLI also registered
MsgCreateGame as a concrete message type with the two (de-)serialization engines:
This is code that you probably do not need to change.
Ignite CLI also creates boilerplate code to have the message conform to the
sdk.Msg (opens new window) type:
This code is created only once. You can modify it as you see fit.
# Protobuf service interface
Ignite CLI also adds a new function to your gRPC interface that receives all transaction messages for the module, because the message is meant to be sent and received. The interface is called
service Msg and is declared inside
Ignite CLI creates this
tx.proto (opens new window) file at the beginning when you scaffold your project's module. Ignite CLI separates different concerns into different files so that it knows where to add elements according to instructions received. Ignite CLI adds a function to the empty
service Msg with your instruction.
The new function receives this
As an interface, it does not describe what should happen when called. With the help of Protobuf, Ignite CLI compiles the interface and creates a default Go implementation.
# Unit tests
The code of this section was created by Ignite CLI, so there is no point in testing it. However, since you are going to adjust the keeper to do what you want, why not add a test file? Add
You can test this with:
setupMsgServer (opens new window) function was created by Ignite CLI. To call this a unit test is a slight misnomer because the
msgServer created uses a real context and keeper, although with a memory database (opens new window), not mocks.
# Interact via the CLI
Time to see which new CLI command was created by Ignite CLI:
Among other things, this informs you of the following:
You kept the two accounts created by Ignite CLI.
alice start a game with
Instead of having to copy and paste the addresses each time you need them, you can store these as variables:
You will have to redo this for every new shell, and for every use of the
How much gas is needed? You can get an estimate by dry running the transaction using the
It is hard to assess how much gas that represents. In any case, keep gas on
You can query your chain to check if the new game was saved to state:
It appears that nothing changed. Ignite CLI created a message, but you have not yet implemented what actions the chain should undertake when it receives this message.
# Next up
Ignite CLI separates concerns into different files. The most relevant file currently is
x/checkers/keeper/msg_server_create_game.go, which is created once. The creation of the game is coded into this file:
You need to code in it the creation of the game properly. This is the object of the next section.