Here’s another post in a series about the technical side of Mars Colony.
A while ago (in July '21) I started documenting some ideas, thoughts, solutions and technical scenarios, like: How we divide Mars territory
So, let’s continue.
Missions – how do they work and why is it impossible to cheat on xp? (spoiler – I don’t answer the last question directly, but you can share your guesses).
In our latest release, users take several steps while doing missions (not exactly in the current
coding mission – we have made a bigger architecture for future much more complex missions and games).
User signs a
Start mission message:
This message consists of a Mars Colony-specific header (Start mission), avatar id, land id, mission type and current timestamp. It is authorized in Metamask with your private key (of course nothing is disclosed – this is a standard Metamask mechanism) so our backend can be sure that the user who passes the mission is the true owner of the avatar.
A timestamp is used to verify that the signature is fresh (actually it can be reused within a small period of time, but I see no problem or vulnerability here).
To pass a mission, you play a game. Our
coding mission is just a first step to something much greater.
while playing the game, the frontend (the app) communicates with the backend like with any game server. The only difference – each message has also a signature from step 1 to maintain a session. So, and this is the main thing, now we can create and integrate any game into our app (of course, any which can be run in a browser).
Only the server shall decide when the game ends. The client (our app, the frontend) can either do regular checks or can get this information with another response (which can be designed for each game individually).
The backend also decides about rewards. The reward amount can depend either on gameplay, xp, avatar characteristics, other active users, bitcoin price, Moon phase, and many other factors (we keep some of them secret). The human-facing data™ then appears in the form of the rewards message and signature in the data from server.
- Human-facing data™ is used for the in-app dashboard, and informs what you see when you learn what rewards you’ve earned.
- What’s behind the message is more interesting: there are
- 32 random bytes
- 5 bytes with an avatar id
- confirmation of the previous 5 bytes (to easily check the validity of the message)
- 5 bytes with land id
- 8 bytes with earned xp amount
- next bytes are reserved for other reward types, which will be added later
- The signature. The backend has its own secret private key and signs the message
Note: used signatures are stored and can’t be reused
Collect and sends
finishMission transaction to our GameManager contract. Transaction parameters include a message with reward data (see above) and its signature from the backend™.
Then our smart contract (GameManager) checks if the signature is valid (the signer should be the backend™), does several additional checks to the message and distributes fairly the rewards.
So, what’s been released is not only one very easy mission, but a stable and reliable architecture that can handle much more complex things like skill-based and multiplayer games, which are going to be fit into our mission system.
Fun fact: the code you generate in this first mission is that of our deployed and audited smart contracts.