Battle Knights

For this hackathon we have completed the Knight Generator which randomly creates knights rpg characters on the blockchain.

Names: Unique knight names are generated randomly on chain using a pool of names and titles that are specific to the selected race and gender. Race & Gender: The race and gender are also determined randomly on chain and rarity is determined by race - with male humans being the most common. Avatars: A random avatar is assigned upon minting that correlates with the knights selected race and gender. Attributes: Each knight is allocated 84 total attribute points. All knight attributes are rolled on chain using 3d6 for a possible range of 3-18 for each attribute score. Attribute distribution is influenced by race. For example, a halflings lowest attribute roll will always be size. Each knight has a total of 84 attribute points regardless of race or luck.

How it was made:

Development: I used hardhat to develop, test, and deploy my smart contracts. I chose the hardhat-deploy plugin to simplify deployment and verify my contract on etherscan.

Chainlink: I relied heavily on Chainlink VRF to provide random numbers on chain. Staying under the 200k gas limit on my callback function was a challenge but I was able to create a dispatcher and split my logic into multiple VRF requests.

Polygon: I deployed my contracts to the Polygon Mumbai testnet to save on gas fees while still being able to interact with Opensea and Chainlink VRF.

IPFS: I used IPFS via the web3.storage API to upload and store avatar images. I am also using the web3.storage API to upload and store the generated NFT metadata file on IPFS.

Challenges:

Names: I wanted to create unique knight names without allowing users to input data. I randomly select a name and title from a pool based on race and gender. I make a few attempts to find a unique name but fallback to adding a roman numeral suffix if necessary.

Attributes: Maybe the most difficult challenge of this project was getting random numbers to add up to a predictable sum, I needed both random and deterministic. I ended up solving the problem by biasing my 3d6 rolls based on the results of previous rolls. If the attributes stats are averaging high or low rolls the contract will roll a biased set of dice. Instead of rolling 3d6 it will roll 5d6 and take the highest or lowest 3d6 results based on bias direction.

Chainlink VRF: The minting and randomizing of knight stats cost around 500k gas while the VRF callback method has a 200k gas limit. I wanted the use to only interact once with the mint transaction so I engineered a VRF dispatching system to have the VRF callback initiate another random number request if needed.

Oracle: Since the knights are generated entirely on chain I needed a way to generate a metadata file from on chain data. I created a simple oracle that listens for the KnightsMinted(tokenId) event that is emitted once a newly generated knights stats are ready. The oracle uploads the generated metadata file to IPFS and updates the tokenURI for the specified tokenId on the Knight contract.