project screenshot 1
project screenshot 2
project screenshot 3

Desert Wars

In a quest for intergalactic expansion, humanity has found ways to further its journey on a dry alien planet. In this world, strategy and intellect win over repetitive effort. The only hope for survival is to correctly predict the scorching weather. Enter the Desert Wars

Desert Wars

Created At

BuildQuest

Project Description

This project combines Smart Contracts on Ethereum with Chainlink VRF for determining random events in a risk-like board game where players battle for survival.

Each player owns a NFT that is composed of an army of 10 soldiers and game round they must make decisions on what the correct weather will be and to which place they will move their army.

The last player standing at the end wins.

Winners can craft battle shards. These NFTs can be burned during a game session to allow for successful weather predictions, overriding the randomness element of Chainlink VRF.

How it's Made

Our project was created with a combination of Hardhat, Chainlink VRF, The Graph Subgraph's with IPFS under the hood, as well as Pinata for NFT metadata management:

  • Game.sol acts as the go-to layer of the game sessions, allowing players to create sessions, join sessions and leave sessions.

  • A session is started with Chainlink VRF determining the random positions of the players in the grid, in order to foster different gameplay strategies.

  • Randomness is also used in a player battle, where each player throws a dice to determine the chance of winning the army fight

  • Lastly, Chainlink VRF callbacks are also used as a way to control the Game Session’s flow, allowing the game to unfold between different phases in the battle, such as Player Movement, Combat between Players and Weather Predictions.

  • Pinata is used as our framework to connect to the IPFS layer to store off-chain metadata of the Army and Home bases NFTs. Each one of our NFTs uses "Blueprints", which are pinned to IPFS and the encoded CID is used as the blueprint identifier. We then store the blueprint identifier (CID) in the smart contract, in order to keep track of the mappings between each blueprint and its NFT counterpart.

  • We build a custom Subgraph for the Game so that our frontend client can easily detect the movements of the players and the session flow in game as well as the different Chainlink VRF callbacks.

We can highlight the usage of Chainlink VRF as the greatest benefit to our project. Since the players actions are sequential, battles and weather are triggered by one of the players and resolution is solved by Chainlink VRF callback without any centralized intervention from our part. We believe Chainlink VRF can be used for more solutions that rely on this need.

background image mobile

Join the mailing list

Get the latest news and updates