P2P Semi-Autonomous Games [Part 3]: Block Battalion
Block Battalion! A functional p2p blockchain based game using timelock encryption
Read part 1 and part 2 of this series. In part 1 we discuss the technical feasibility of using ETF network in the context of semi-autonomous p2p games. In part 2, we realize this as a game of bit roulette as a smart contract. This is a mostly non-technical overview with some technical nuances.
Overview
Block Battalion is an experiement in building a multiplayer, p2p game, semi-autonomous game on the ETF Network. It is a proof-of-concept of the ideas expounded in parts 1 and 2. It leverages the ETF Network and timelock encryption to construct an in-game event clock, allowing participants to compete for resources through a game of bit roulette. Players earn resources that they spend to conquer other cells on the grid. There is no win condition at present, however, the game logic can be quite easily expanded or modified to develop a more engaging experience.
With Block Battalion, we demonstrate:
how to build and use game-event-clock contracts
usage of the etf.js library to participate in p2p semi-autonomous games
To quickly recap, a p2p semi-autonomous world/game is a persistently online, peer-to-peer game that is driven by the players itself. That is, the game’s event clock(s) must be manually updated by the players of the game, and there is no external force driving it. In part 1 we discussed the feasibility of building this on the etf network, and in part 2 we demonstrated this by building a ‘bit roulette’ contract. In this third installment, we bring together all of the pieces to construct Block Battalion. We won’t go very far into the technical weeds here or discuss the implementations of the contracts and user interface in depth. We may work on generalizing these ideas much further, in which case we will produce robust documentation detailing usage, functionality, and implementation.
The game demo is currently live at https://blockbattalion.idealabs.network. Hop into our discord faucet channel and request some tokens by calling `@etf-faucet-bot !drip <your-address>` to get started. It is still incomplete and under active development. We guarantee no stability of the network or the game at this time.
etf.js
etf.js is a typescript library that makes integration with the ETF network easy. In particular, it provides timelock encryption capabilities as well as allows for transactions to be signed and submitted. We will take advantage of this library to create our timelocked commitments.
Block Battalion
Block Battalion is a single event-clock game. It is played on a 25x25 grid, where players must first create a base (a randomly chosen point on the grid) to be eligible to play. The event loop allows players to compete in a game of bit roulette. Winners of the round are given 5 resources. Subsequently, players can spend 1 resource to conquer cells on the grid. There is no major goal beyond this yet and no specific ‘win’ condition (yet), though this logic can be added later on.
The Resource Farming Phase:
In this phase of the game, players interact with their environment in order to discover resources. In our case, we will have a single, nameless resource. Players engage in a modified version of bit roulette. In this version, instead of guessing the parity of some value specified by a game master, participants win when they guess the parity of the sum of all inputs. Players guess a number `m` in {0, 1} and stake some amount of ETF. A player Pj, with bit bj, wins iff:
If their guess is correct, then they win a prize and successfully mine some resources. If not, they lose a portion of their stake (some small percentage), which goes to a game treasury. In our case, the resource clock distributed 5 resources to all winners.
From a game-theoretic viewpoint, in bit roulette no player has no dominant strategy, as an optimal move depends on the choices of all other players. Players could reach a mixed-strategy equilibrium but only by ensuring each player randomly selects 0 or 1. If all players choose 0, then everyone wins. In general, the chance of winning is |P|/2^|P|m were |P| is the number of players in the round.
In Block Battalion, we visualize bit roulette as a Farm/Harvest loop.
Coloring the Grid
The rest of the game logic is fairly standard and I won’t get into it too much. It, by itself, does not necessarily present anything ‘new’. The interested reader can check out the contract code for more details. The game is essentially a ‘color the grid’ game, where each player has a color and can conquer other cells in the grid by spending resources earned from the resource farming loop.
50,000-ft View
There are two contracts that power Block Battalion. Firstly, the core ‘game’ contract, which is called block battalion, and secondly the event clock, which is a contract deployed by the block battalion contract. Both contracts are implemented using ink! and deployed to our testnet running on GCP. You can check out the contracts here.
The BlockBattalion contract acts as a proxy to the resource event clock. While this is not a strict requirement, it lays the foundation for future work in which we will develop games with multiple event clocks. Players participate in bit roulette by calling the block battalion ‘play’ function, which proxies the call to the resource event clock’s play function. It works similarly for the advance_clock function. In relation to the game, this is the ‘farm’ and ‘harvest’ actions. You can check out the contracts here.
The user interface listens to the latest block headers produced by the ETF network and updates the UI’s behavior accordingly (i.e. to show farm vs harvest actions). It also enables timelock encryption, which players use to encrypt their inputs for bit roulette. The UI can be found here, and also hosted at https://blockbattalion.idealabs.network.
Playing The Game
Block Battalion currently is only compatible from browsers with the polkadotjs extension installed, and with at least one wallet available. Users must also have some ETF tokens. You can get 100 ETF every 12 hours from the discord faucet.
Game Options
After selecting an account, players can either create a new game, search an existing one, or continue the previous game (stored in your browser’s local storage). Searching and continuing games will allow you to join already running games. Starting a new game will then present the player with options to configure the resource event clock.
Configuring the Resource Event Clock
The resource event clock configuration requires two parameters. The event interval is the length, in blocks, between each event, and the start slot is the slot in the blockchain consensus when the event clock should begin. The displayed ‘current slot’ can be copied and used as a starting point. Adding ‘2’ to the current slot is roughly 10 seconds. Once ready, click on start game.
Create a Base
After a game is started, players can create a base to ‘register’ as a player in the specific game of block battalion. Without creating a base you cannot actually receive any resources for participating in bit roulette. A base is a cell in the grid owned by the player. The initial ‘base’ point costs no resources.
Farming and Harvesting
Once a player has a base, they can participate in the game. There are two phases, farm and Harvest.
The farm phase is active when the resource event clock’s next slot is after the current highest known slot (the one displayed under the title Block Battalion). When in this phase, players can click ‘farm’ to participate in bit roulette. This will open a panel underneath the grid where players can select 0 or 1. Once submit is selected, the value is encrypted with timelock encryption the resulting ciphertext is ‘played’ in the contract. Players can change their selected bit as many times as they like while in this phase.
After the event clock’s slot has passed, the ‘Farm’ button changes to ‘Harvest’. Clicking ‘Harvest’ results in the event clock being updated to the next slot (we track this with round numbers e.g. round 1, round 2, round 3, and so on). In the case that a clock is very far behind, this could require several successive updates. We aream working on a fast forward functionality for a more sustainable experience (since currently, if the clock is too far ahead it’s very annoying to catch up).
Conquering a Cell
By selecting a cell, you can see additonal details, such as its coordinates. If it us unoccupied, you can conquer the cell.
When the next block is produced in the chain, the state will update and all players will, nearly simultaneously, see that the player has taken ownership of another cell.
Contact and Additional Info
You can check out the source code for the contracts and the user interface here:
block battalion contracts: https://github.com/ideal-lab5/contracts/tree/main/examples/block-battalion
block battalion user interface: https://github.com/ideal-lab5/etf.js/tree/main/examples/block-defender
You can learn more by…
Future Work
Block Battalion is only a proof of concept of what can be done with the ETF network. It should be noted that we are working on implementing a delayed transaction framework, which would allow for the constuction of fully autonomous worlds which are driven by the chain itself. In addition, while we do not have an example of this yet, this same system can be extended to as many event clocks as desired, which give rise to multi event games. This can be used to design sustainable games based on some type of feedback emerging from event loop behavior.
MultiEvent Games
Recall the bit-roulette game we defined in the previous article. While it is a game that can be played, it isn’t particularly interesting by itself, since there is only a single event loop. Instead, we can use bit-roulette as a generic design pattern by modifying the advance_clock function to define custom logic to update the game event clock. We refer to this generalized interface as an event clock contract, or just clock when convenient. This interface looks like:
The contract storage contains the individual ‘event state’.
The game event schedule can be defined either statically or dynamically, such as “an event every 10 blocks” or ad-hoc event intervals defined directly or through some game mechanic.
The play function allows players to issue timelocked input for upcoming events. The exact implementation can vary from game to game. This controls the rules players must follow for participation. For example, timelocked moves could be allowed to be overwritten, or perhaps players can submit many moves.
The advance clock function contains the logic for advancing the game state given player inputs. It accepts decrypted player moves and uses player-issued timelock commitments to validate each move.
By deploying multiple event clock contracts and coordinating them through an orchestrator contract, we can construct a higher level game that uses each contract as a unique ‘event source’ for updating some specific slice of the game state.
Multi Event-Clock Games
Let’s start by looking at a very high-level idea of a 2-clock game event loop. In this game, we define two event clocks, each with their own, unique ‘slices’ of the game state. The first event clock, say C1, will be used to produce game events the allocate resources to participants based on their input. The second, C2, will be used to use resources to compete with other players. Winners are awarded some amount of token and their win is immutably encoded in the blockchain. With this, we can attempt to design a sustainable game ecosystem, where the game could potentially run forever.
The “Earn Resources” Event Clock
In this clock event loop, players compete for resources by choosing an input bit, 0 or 1, and staking some number of tokens. When players win this event, they earn a resource proportional to their stake. Resources are used in the compete phase.
The “Compete” Event Clock
In the compete phase, players use their earned resources to compete against one another. The winner of this phase is awarded tokens (the native ETF token).