Building An Ethereum Simulation Game – Part 2 – Playing Tennis Matches
Tags: ethereum, blockchain, dapp, dapps
Published: 2020-03-30 17:53:26

---
title: Building An Ethereum Simulation Game – Part 2 – Playing Tennis Matches
published: true
date: 2020-03-30 17:34:24 UTC
tags: Ethereum,blockchain,dapp,dapps
canonical_url: https://blog.coincodecap.com/building-an-ethereum-simulation-game-part-2/?utm_source=rss&utm_medium=rss&utm_campaign=building-an-ethereum-simulation-game-part-2
---

### Recap

In [part one](https://blog.coincodecap.com/an-ethereum-simulation-game-part-1/), 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.

> [Building An Ethereum Simulation Game – Part 1 – Inception](https://blog.coincodecap.com/an-ethereum-simulation-game-part-1/)

<iframe title="“Building An Ethereum Simulation Game – Part 1 – Inception” — CoinCodeCap Blog" sandbox="allow-scripts" security="restricted" style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" src="https://blog.coincodecap.com/an-ethereum-simulation-game-part-1/embed/#?secret=aF2gwxogAd" data-secret="aF2gwxogAd" width="600" height="338" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>

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

{% gist https://gist.github.com/alexroan/89625c26d17cc7566df1c49a2e90fb35 %}

[view raw](https://gist.github.com/alexroan/89625c26d17cc7566df1c49a2e90fb35/raw/d55a4e290df3663ef03d6e780655602310f5b1ee/TennisPlayerBase.sol)[TennisPlayerBase.sol](https://gist.github.com/alexroan/89625c26d17cc7566df1c49a2e90fb35#file-tennisplayerbase-sol) hosted with ❤ by [GitHub](https://github.com)

  

The following code shows the _TrainableTennisPlayer_ smart contract.

{% gist https://gist.github.com/alexroan/aad076127ba7229d3766e32b6e306db6 %}

[view raw](https://gist.github.com/alexroan/aad076127ba7229d3766e32b6e306db6/raw/cbda2338be7c1aa0639e62bb92e531d4c21315b4/TrainableTennisPlayer.sol)[TrainableTennisPlayer.sol](https://gist.github.com/alexroan/aad076127ba7229d3766e32b6e306db6#file-trainabletennisplayer-sol) hosted with ❤ by [GitHub](https://github.com)

  

* * *

### Playing Matches

I mentioned [sundayleague.com](http://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.

### Code Structure

Figure 3 shows a rudimentary diagram of how I’m envisaging the structure of the first few contracts.

![](https://cdn-images-1.medium.com/max/1600/1*ceduZH88V49HvAMxNk2k4w.png)<figcaption>Figure 3: Initial Contract Structure</figcaption>

_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.

### Smart Contract

Figure 4 shows the _CompetingTennisPlayer_ Smart Contract.

{% gist https://gist.github.com/alexroan/d9a45c43f71263c7c73bf221dff4c95c %}

[view raw](https://gist.github.com/alexroan/d9a45c43f71263c7c73bf221dff4c95c/raw/7cb04bfe637d70d6d61034668cf918936064dd64/CompetingTennisPlayer.sol)[CompetingTennisPlayer.sol](https://gist.github.com/alexroan/d9a45c43f71263c7c73bf221dff4c95c#file-competingtennisplayer-sol) hosted with ❤ by [GitHub](https://github.com)

  

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.

## Next Steps

_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](https://github.com/alexroan/tennis-manager)

#### Also, Read

- [What are Dapps? (An ultimate guide)](https://blog.coincodecap.com/what-are-dapps-an-ultimate-guide/)
- [A Beginner’s Guide to DeFi (Decentralized Finance)](https://blog.coincodecap.com/a-beginner-guide-to-defi-decentralized-finance/)
- [Best Smart Contract Wallets (DeFi Wallets)](https://blog.coincodecap.com/best-smart-contract-wallet/)[  
](https://medium.com/blockcentric/blockchain-development-resources-b44b752f3248)

The post [Building An Ethereum Simulation Game – Part 2 – Playing Tennis Matches](https://blog.coincodecap.com/building-an-ethereum-simulation-game-part-2/) appeared first on [CoinCodeCap Blog](https://blog.coincodecap.com).