Community update - #1

Randomness, expanding the team & Pirate King elections

It has been super hectic since our launch and we feel it’s about time we did our first community update. The vision for what the Damned Pirates Society and the associated Pirateverse was conceptualised well before launch and bringing those ideas into reality takes time and effort. The following should give some insight into what’s been happening behind the scenes.

New team members

Not only are we progressing with the Voyage Contracts (more on that later), we are also looking to overhaul the site to become much more interactive. We want to set up a world where you will interact with your ships, voyages & more. To further this endeavour we have brought on two new members to the team, both working on the UI/UX side of things.

This brings the team up to 8 people now:

• Davy Jones - Lead
• Long John Silver - Balancing and Optimisation
• Benn Gunn - Developer
• William “The Ghost” Fox - Developer
• Anne Bonny- UX / UI
• CryptoRoad - DAPP developer
• Buccaneers - Artist
• Lost Bones - Artist

We look forward to building on this project together and will be constantly expanding as the Pirateverse grows.

Elections and community funds

Whilst adding people to the team is important, so is ensuring proper community relations. We have now completed two rounds of the Pirate King Elections, seeing Masterrulax and Adam Steeber take up those positions. The Kings are the liaisons between the team and the community ensuring that our users are properly represented in the decision making process.

They will also be signatories for the community treasury (which currently stands at 25 MOVR). The use of these funds is to be decided on by the community and could be invested, used to tip community members, or to further the project. Time will tell, but your votes will be important on whatever the Kings bring forward!

How do you solve a problem like on-chain randomness?

The quick answer is by using the Chainlink VRF oracle. It provides genuine (and non gameable) randomness needed for projects like ours. Unfortunately it has not yet been deployed on Moonriver. So until that happens we have tasked our devs with creating a pseudo-random solution that would be verifiable and as secure as possible.

On-chain randomness in general is prone to botting, especially where rare or valuable rewards are at stake. Even famous projects such as the Wolf Game can succumb to these attacks as explained here https://twitter.com/punk3155/status/1462073799281557509?s=20. With our planned future NFT drops we need to take randomness seriously.

Moonrvier (MOVR) is chain with PoS-like security, fewer transactions with a low number of collators. This means that the number of random on-chain “seeds'' we can safely use is also lower. This makes attacks potentially easier since people could use custom contracts and collator collusion to generate favourable voyages (yes yes, unlikely at the moment, but theoretically still possible).

To make things more complicated our idle style approach to our game requires our Voyages to last multiple hours. Since on-chain block values are only accessible for the last 250 blocks, we would have only been able to have a max voyage time of an hour or so (assumption being that MOVR is moving towards a block every few seconds). This made pure on-chain randomness impractical and so we developed a hybrid approach.

At time of minting or starting a voyage we decide which specific future blocks will be used to provide random values for interactions. Examples of interactions are things like an enemy encounter, a storm, or a chest reward.

Once the block with the specific number is produced, our api (which has access to a full archival node) returns info from that block that will then be used as a seed on-chain. We use values such as block timestamp, first and last transaction hashes and a few others. They are all then signed with a signing address so that the on-chain contract knows it was our trusted api that provided them.

This means that the values that this api provides to our random function all come from on-chain data and can be verified by anyone using Moonscan or other block explorers. This will enable players to check that we are not generating ‘secret’ random numbers which the team can exploit.

As randomness plays a huge part in how voyages work this was a big hurdle to overcome. Now that it’s solved for V1 we can move forward on to finalising the Voyage contracts.

Stack too deep and progress

When making an on-chain game, a lot of the time is spent making the concept fit within the limits of the Ethereum Virtual Machine (EVM). This requires expert coding and optimisation. The dreaded “stack too deep” error rears its head daily as we push the EVM to its absolute limits.

We have managed to overcome a lot of those limitations and have minted our first random Voyage.

Being able to do this is a huge step forward for us. We are now focusing on turning them into fully playable and deployed contracts. The first goal is to test them with direct contract interactions before making them easy to use via our dapp.

Exciting times ahead!

Summary

We hope all this gives you a good overview of what's been happening behind the scenes and where the team has focused their efforts. Stay tuned for our next update, and, until then, #BeMorePirate!