In part one, I outlined the idea for a Tennis Manager simulation game on the Ethereum Blockchain. I created the ERC721 Token and the TrainableTennisPlayer contract which enables owners to increase their player stats by training or resting.
Since that article, I’ve written some unit tests and made a few small changes to those contracts. Events have been added to TrainableTennisPlayer to emit when players are trained or rested. Some utility functions that were initially written in TrainableTennisPlayer have been moved to the TennisPlayerBase.
At this stage, our Ethereum Tennis game can create new players, and the owner of the player can level up attributes and conditions by training and resting.
The following code shows the TennisPlayerBase smart contract
The following code shows the TrainableTennisPlayer smart contract.
I mentioned sundayleague.com as an inspiration for this game in the previous article. The way it works is by playing matches every day at a set time, I believe it’s 3 am GMT, so every player needs to have their tactics set for the upcoming game before that time.
If mimicked on the Blockchain, the system itself would need to pay gas costs for simulating the matches. The more players competing, the more gas needed.
(alternatively, each game could have a stake by each player, some of it contributing to gas and the rest going to the winner?)
We don’t want that. Instead, we want the players to be able to compete against others when they have enough resources (XP and condition). That way matches can be played as soon as the attacker submits the transaction (forwarding gas cost for the match of course). The winner is then calculated as soon as the block is confirmed.
Because matches cost player condition (they get worn out), players who aren’t in match condition can’t play. They need rest, hence the TrainableTennisPlayer contract.
If the game allows any player to play a match against anyone else, higher-level players would obliterate lower level players over and over rinsing the lower level player’s condition.
To combat this, I’m going to use a registration system, where players enlisted to compete can be challenged and can challenge others. They can be delisted by their managers at any time. They’ll also be auto-delisted if they complete a match and are subsequently below the minimum condition required.
Figure 3 shows a rudimentary diagram of how I’m envisaging the structure of the first few contracts.
TennisPlayerBase and TrainableTennisPlayer were coded in the previous article. CompetingTennisPlayer is where our match logic exists.
It enables players to enlist and compete against other enlisted players. I’m not worrying too much about the match mechanics just yet, other than a simple comparison between stats. I’ll work on that later.
Figure 4 shows the CompetingTennisPlayer Smart Contract.
There are three public functions:
enlist(): Adds a player to the enlisted players so long as the caller of the function is the owner of the player, the player is in good enough condition and is not already enlisted.
delist(): Removes a player so long as the caller is the owner and the player is currently listed.
playMatch(): Plays a match between two players providing they are both enlisted, the caller is the owner of the attacker, and both are in match condition. It then delists if either of the players is no longer match condition after the match.
I haven’t yet fully tested this contract, so that’s the next piece of work. I’ll likely need to change some of the code, but in terms of premise, I think most bases are covered for now.
This project is in active development. At the time of writing, the current state of the code is as described in this article.
I need to make sure what’s there is working as expected, which means lots of unit tests before moving on to the next piece of the puzzle.
After that, I’ll look to add the SomethingHere contract in Figure 4, yet to be named. Once that’s in place it should act as the main entry point for the game, and a front end can be built up around it. I’ll use React and Redux for that.
I’m already looking forward to being able to interact with our Ethereum tennis game despite its basic state right now. It’ll be great to see it working in the browser no matter how clunky for the time being.
The code repo is on Github so it’s public and open to pull requests. If you’re interested in helping out please to contribute! Here is the repo
- What are Dapps? (An ultimate guide)
- A Beginner’s Guide to DeFi (Decentralized Finance)
Best Smart Contract Wallets (DeFi Wallets)
The post Building An Ethereum Simulation Game – Part 2 – Playing Tennis Matches appeared first on CoinCodeCap Blog.