DiceRoll

Inspiration

I play a lot of dice games in the physical world and dice games have been a part of blockchain gaming from the beginning. I wanted to build an engine for quickly spinning up new dice games that utilize the fairness and provability of the blockchain.

What it does

Dice Roll allows developers to very quickly create dice games with as little as one function to be written. Games can make use of any type of dice including any number of sides, and custom values of any kind. Dice default to values of numbers 1 - # of sides, but mappings are easily created for dice with custom labels. The Colors example game uses a dice with colors instead of numbers.

How we built it

Contracts were built with solidity, tested locally with hardhat, and deployed on Fantom testnet. Randomness comes from Chainlink VRF on Fantom and a mock randonmess provider on local testnets. Fantom enables cost effective and fast games to be run as well as the support of Chainlink VRF services, which are great for provable randomness. The UI was built with node.js and the "inquirer" package for and interactive command line interface.

Challenges we ran into

Local testing had to be setup just right so randomness was handled in a very similar way to contracts published on Fantom. I had to ensure the mock provider was behaving close enough to the types of VRF we would be handling with actual deployments. We also didn't have time to write automated tests so testing was a relatively manual process, which worked okay, but wasn't ideal.

Accomplishments that we're proud of

The engine actually worked for building 3 games very quickly. Most of the time and effort was put into the engine that powered the games, but the examples were fairly quick to get up and running. Very proud that it actually worked as intended!

What we learned

I had to really think about how to handle the delay between requesting a roll and receiving the response. Learned about better storing game data in structs to easily maintain that game state and be able to pass it between the various contracts. Also, the CLI was written without re-using the game interfaces. We could have built faster if the core interfaces were reused instead of accessing the specific interfaces for each game.