How We Built Our GoZ Tamagotchi Zone

How We Built Our GoZ Tamagotchi Zone: A Technical Overview

After telling the story of designing our Tamagotchi Zone for the Cosmos Network Game of Zones, we wanted to share something for our technical users. In this article, we provide a high-level overview of how we built Tamagotchi Zone, plus some notes on our general experience participating in the competition.

Tamagotchi Zone

Back End

What’s the point of Inter-Blockchain Communication (IBC)? The answer is simple: connecting blockchains.

The gameplay for Tamagotchi Zone is equally simple: Let the player relay packets between multiple zones. Relaying messages is how you play the game.

To make things more interesting, we added multiple evolutionary paths for our digital pets. Depending on the type and timing of the tokens relayed to the pet, it can evolve into three completely different species.

UI and UX

A game won’t draw in many players if it’s too difficult to play. Because our primary goal was to get as many people using the relayer as possible, we knew the instructions would be a very important part of the game.

We laid out the instructions in clear, simple terms, explaining how to go from zero to creating paths and sending packets between two completely independent blockchains. We even added special instructions for Windows users, who are often overlooked in the developer world.

Thanks to Chainapsis, playing the game is even easier using Keplr wallet.

We also wanted to add a hook to the gameplay. The bulk of the work for the player is setting up the relayer. Once a relayer has been set up and a path created, the player is asked to relay their first token between the two zones. The moment this is done, we “birth” the new pet, which will look happy and carefree for a couple of minutes before becoming hungry.

This is the first time the player gets to do something fun, giving their new pet a treat and watching the pet’s blissful reaction. Our idea here was that this first positive interaction would leave a good impression and make the player want to come back and keep playing.

Technical Bits & Pieces

• All of our UI and webpages are statically compiled and published on IPFS. As long as it stays pinned, you can visit the hash to access our game at any time.
• The pet state logic is implemented using an FSM (finite state machine) and can be consistently reproduced by replaying all transitions in order at any time. Because different tokens are sent at different heights, each pet’s behavior and evolutionary path is unique.
• We had to modify the faucet to send multiple tokens at a time. You can find our pull request here.

Future Plans

We promise to do the following with respect to the custom zones we made:

• Keep the game running for as long as it makes sense
• Open source the backend codebase

Game of Zones Tactics & Tips

Most Packets Relayed

We had our sights set on the Most Packets Relayed category before the competition even started. We experimented with many different approaches. To name a few:

• We tried very fast (sub-100ms) block times. We ran into a bunch of issues with this method and eventually settled on a 500ms block time for the majority of the competition.
• We started by running the command rly tx raw xfer-send multiple times, then relaying all at the same time to increase throughput. This worked well, but it wasn’t fast enough.
• We then modified relayers to create a custom send-alot command that allowed us to inject multiple IBC packets into each one of our transactions. This increased our throughput by at least two orders of magnitude and is described below in more detail.
• We created scripts to scan all team-submitted sites and ports to see which ones had both the RPC and the faucet open.
• We experimented with very low fees for each of the transactions to conserve the limited amount of tokens granted by the default faucet implementation. Our default gas fee was 0.0000000001 tokens.
• We created scripts that automate the setup of a working client, connection, and channel between any two zones. These scripts were very effective in Phase 2 of the competition.
• We spent a lot of time experimenting with transaction body size, because it’s very easy to exceed the default limit. We were able to use a custom gaiad to relay a transaction with more than 1,000 packets in it, but the overall speed and throughput of this strategy was unproven, so we decided to revert back to a more conservative strategy.
• We performed sensitivity analyses on the throughput for different packet sizes, leading us to find the bug the IRISnet team fixed when the time complexity for sending and relaying multi-packet transactions increased disproportionately.
• We started with our “send a lot” strategy right before Phase 1a started. This promptly brought down the network — oops. Sorry, everyone! We decided to stop the relay because it was making it impossible for teams to handle the primary Phase 1 objective, which was to maintain connection liveness. We dialed up the send rate near the end of Phase 1a when the network was more stable.
• In Phase 2, once we had set up the relay to the hub zone, we launched the relayer to nine other participant zones. We added more later when we saw in Datadog that other teams were able to sustain higher transaction counts. Even though each of our transactions was a multi-packet transaction, resulting in at least 200x more packets sent per transaction, we still wanted to push our transaction count higher.
• For Phase 1, we created a locking mechanism between our send-alot relayer and our client update logic. send-alot will always yield to client updates due to their time-sensitive nature.
• The biggest problem we encountered in the entire competition was getting a reliable connection to the main hub. Multiple times we had trouble finding peers that were synced to the hub validators. This resulted in many sleepless nights.

Relayer Code Modifications

The iqlusion relayer is well coded and supports different strategies for paths. We decided to create a custom strategy called “fish-strategy” that would support the creation and relaying of transactions containing multiple messages. We wanted to create an independent strategy because we didn’t want to risk the liveness of our channels with untested code, especially during Phase 1.

The code was very straightforward to modify.

First, we created a new command inside xfer.go called xfer-send-alot with the same structure as xfer-send but with an additional msg-number parameter. This integer defines how many times the same message is repeated in the transaction.

Next, we had to modify parts of the relayer strategy itself. Most of this took place inside the RelayPacketsOrderedChan function of fish-strategy.go. Looking at the naive implementation, there is a check on the message number when fetching transactions to relay from the source chain that will throw a more than one relay msg found in tx query error. We had to remove this check and make sure all the other functions still worked correctly.

For a closer look at the code, take a look at our repository.

We hope we’ve shed some light on our process for building Tamagotchi Zone and our overall Game of Zones experience. Don’t hesitate to reach out to us on Telegram if you have any questions!

Website: https://stake.fish

Telegram: https://t.me/stakefish

Twitter: https://twitter.com/stakefish

Instagram: https://www.instagram.com/stakedotfish

LinkedIn: https://b.fish/linkedin

Reddit: https://www.reddit.com/r/stakefish