Conquest's Beta on Gnosis Chain is Coming! ​

Hello everyone.

Our last update on this devlog was in October and a lot have happened since then. Time for a recap and an overview of what is to come. You can also find some of the updates on our company's wide blog on medium.

The 2nd alpha ​

In December, we launched our second alpha with 5,000$ worth of prizes, of which 3,000$ were provided by our sponsors: Xaya, Defi Alliance and Pocket Network. A huge thanks for their support!

The alpha run for a bit more than 2 weeks this time. The goal for that alpha was to run our new code (we made a huge refactor after the first alpha) and test some game mechanics changes and additions.

The alpha was a great success. Players were active during the whole session and the end game was super interesting to watch with the leaderboard moving constantly. Like in the first alpha, the addition of sponsored planet added an interesting twist and allowed some players to get home with some prizes even if they did not end up in the leaderboard.

Watch the leaderboard here :

We also generated some statistics graph that you can explore here.

The alpha game experience was a big improvement compared to the last. Let's dive in some of the updates and what we would like to improve further.

The System Of On-Chain Alliances ​

The second alpha introduced the concept of alliances and friendly spaceships, which allow players to get advantages by publicly joining forces together.

It is a truly uniqe feature of conquest.eth in the crypto-native gaming space and it proved to be a feature players used to great advantages. The winner (Congrats Kilari!) and its alliances did not use it initially (to remain hidden as an alliance) but switched to use it later, probably for the benefit it gave (no burn tax on sending friendly spaceships and no risk of attacking each other when capturing the same enemy planet). Their alliance moves were probably quite visible at that time anyway.

What was missing in the alpha though, was an easy way to customize the alliance smart contract. For our next release, we would like to write enough documentation for players that are also smart contract dev to make unique alliance systems. We would also like to fund initiative from the community to help this. Reach out if you are interested.

The game does not actually dictate anything about these alliances and players can code different mechanism. This is factilited by the core game which for example, allow anyone to prove a particular attack had happened. Players can thus setup slashing mechanism against trahison for example, but the possibilities are endless. We are eager to see the community building upon this.

The "Production Cap" Mechanism ​

The production cap is a mechanism that limit the number of spaceships a planet can produce after a certain number of spaceships is stationed there. And it has been proven to work in this alpha. It removed the risk of inactive players waking up with great power. The latter was an issue in the previous alpha as inactive players could not be disloged.

Having said that, the system needs some modifications. It can for example easily be circumvated by sending spaceships around. While this was already a common strategy in the first alpha, to basically ensure you have spaceships around all your planets at any time, the issue here was that you were also avoiding the production cap.

We are exploring different ideas for the next release.

The Frontend Refactor ​

As alluded above, our main work between the first alpha and the second was our code refactor and it was well worth it. We experienced a lot less issues in this round that in the previous. The refactor also improved the overall game experience. The game can for example zoom out further than before while avoiding the constant loading of planet at every scroll (which was a big pain in the first alpha).

This was achieved with 2 different mechanisms:

• the use fo thegraph for fetching smart contract state, instead of the slow log calls.
• the use of html/css instead of canvas for rendering planets and the map. We could even cram in some paralax background 😃

Another important improvement was also the full use of pending transactions and optimistic UI to let players knows the number of spaceships / token they can actually use at any time. There was still few bugs identified on that matter and we will improve on them but overall we are very happy with the new architecture.

The Agent Service ​

The Agent Service allow players to send fleet without worying about whether they will reach the destination in time.

In conquest.eth, fleets require 2 transactions to move from one planet to another. The first transaction is performed at the departure planet to launch fleet into space. This is done without revealing the destination allowing players to secretely attack other players.

Then, the fleet take real time, ranging from couple hours to multiple days, or even more, to reach the destination. When the fleet is supposed to arrive there, a new transaction need to be performed.

Without the agent, the player need to perform it itself. And because the time of arrival can be inconvenient, having a mechanism that can automate it, is of course very helpful for players.

In the previous alpha, the agent was actually running in a player's browser tab. The player had to keep its computer on for the agemt to do its job. The advantage was that there was no one to trust. The disadvantages are multiple but most players do not want to have their computer running all the time. There was also several issue with browser/operating system going to sleep or Metamask timing out.

In the 2nd alpha, we decided to provide a service that run all the time. The advantages are clear. The main disadvantage though is that player have to trust us that we do not reveal their strategy or use it for own benefit.

In the future, we plan to help anyone running such service.

What's next ​

We are working toward a new release with the improvement mentioned above. We would like to have something by end of March!

Wen Token ? ​

At the beginning of this year we spent a lot of time thinking about mainnet release and started to rethink our stratgey regarding our token economics, including player staking mechanism and incentives. We even dived in CadCad modeling.

Our initial plan (which is still on the table) is to have Etherplay token simply be a stable token backed by DAI. The DAI would sit on ethereum mainnet while the Etherplay token would be played on whatever network the game conquest.eth run on. This would allow Etherplay to get yield on DAI via something like Yearn. An interesting aspect of that strategy is that we can run multiple games using the same mechanism and benefit from the shared DAI staked. We actually love the concept and did not expect to change our mind on this until this year.

While the use of a stable token allow players to remain unaffected with any fluctuation of price, except that of USD itself, it also do not scale very well. A signicant amount of token need to be put in the system for the yield to have any significative impact on the development of the game. It also make the system dependent on both DAI and Yearn.

With the current community size we have, it is unlikely to get the game achieve enough DAI staked for the system to have sustainable growth, at least initialy (assuming 10% interest, we would need 100,000$ staked to get 10,000$ in a year). While conquest.eth could be running as it is and self sustain the infrastructure cost (Which is actually minimal, yeah decentralisation!) with even less token staked, we have bigger plan for conquest.eth and such low yield for the community would not help make that a reality. The current version of conquest.eth is just one of many possible mechanics. There are lots of ways conquest.eth could be expanded and we would love for the community to have the resources to do that.

As such we have been thinking of different token economics. We won't go in the details here yet as we are still figuring things out. It is also difficult to predict how things are going to play out in the end. Regardless we think it is important to spend some time on this. We will keep you posted.

Time For A First Beta! ​

As mentioned above, we would like to release a new version by end of march and we hope to make that version as close as possible to our first true release comming this year. That is why we decided to run our first Beta on a non-testnet network!

One question that have always haunted us is: "what network conquest.eth should run on?". It also a question many have asked us. Our traditional reply was : all of them. But in reality, we would have to pick one first.

So we decided to look closer at the various alternatives. Our initial plan was to make conquest.eth run on L2s. But it also became clear that while conquest.eth has been optimized so far to run with as little gas as possible, it still require a significant amount that the cheaper the network, the better it is. It is also worth pointing out that our initial investigation for new token dynamics will most likely have a big impact on gas cost.

It is true that in the case of conquest.eth we could always increase the staking amount on planets to make the gas cost worth it. But this would also means that player not willing to stake that much would not even participate in. Actually with that same logic we could run conquest.eth on ethereum mainnet. This is obviously not practical.

Our 2nd alpha showed that we need the gas cost to be around 10,000 cheaper than on ethereum mainnet (Assuming 100 gwei and 4000$ ETH). Current L2s like optimisim and arbitrum would not make it, at least not in the immediate future.

As for other l2 (starknet, zksync), these are not ready yet. Starknet made a lot of progress, but is not there yet to allow project made for the EVM to run on it. Not to mention thegraph support, wallet, etc... It is worth mentioning that a port of conquest on cairo could be an interesting approach that we might consider later.

So looking at what could be used today with 10,000 gas cheaper than mainnet, we found that Gnosis Chain (a.k.a xdai) was the best candidate overall. xdai was actually our initial bet back in 2019 when we started to experiment with fully on-chain games with Ethernal.

The xdai ecosystem have grown significantly since then. The merge with Gnosis is also promising, not to mention their roadmap and their plan to make Gnosis Chain a testbed for ETH 2.0.

Furthermore, while many blockchain games have chose other chains, it is great for us to know that Gnosis Chain is also the home for Dark Forest, a game that share similarity with conquest.eth.

I am sure that their existing players base will be happy to know that there is a new game in town!

We will be at devonnect! ​

Talking about Dark Forest, we will be joining them at devconnect on April 18-25. You can even see "conquest.eth" mentioned on ethereum foundation announcement and on the schedule for April 19th.

We will be showcasing conquest.eth there! We hope to have good documentation ready for it as we plan to offer cool stuff to work on for smart contract devs!

OxParc the foundation behind Dark Forest, have given us a grant a while back and our plan is to use these fund to help the conquest community build tools for the game. We hope to release more info about the game on that front soon.

Really excited for conquest.eth upcoming beta!

In the mean time, do not hesitate to join us on our Discord