Unblocking On-Chain Games: Part One — Throughput

Will Robinson

Jul 27, 2022

Red Rover, a game where children chain themselves together in order to clothesline each other.

This is Part One of a series exploring constraints at the intersection of blockchains and games. The objects of enquiry are “crypto-native” or “on-chain” games, which maintain their game state trustlessly.

About me: I’m a core contributor to Alliance DAO, a startup accelerator and founder community. I’m a co-founder of @d_fdao (Dark Forest DAO) a group of on-chain game builders. I hold a PhD in Game Design.

Not Enough Space

Assuming a successful game has 20,000 concurrent users who change the game state every two seconds, on-chain games become woefully constrained. No blockchain can support those requirements.

To play games on chain, we need to rethink their design. The tail must wag the dog.

What does it mean to be hindered by transaction throughput? Since a game state is shared by all players on the blockchain, any time someone wants to change the state, they must submit a transaction. Since blockchains require the world to form consensus around their states, throughput is lower than a centralized database. Each block has to limit the number of transactions it can include. For example, in 2017, when the collectible cat game CryptoKitties peaked, the Ethereum blockchain was overwhelmed with demand. Transactions required dozens of dollars to process, causing unreasonably poor user experiences and a disillusionment with crypto gaming.

Vitalik Buterin recently explained that we can expect Ethereum to handle 100,000 transactions per second by the end of its roadmap. But today, it can handle less than 100, including the rolled up transactions. We cannot expect our game to take up too much of the “world computer.” Instead, we need to use a rollup or, if less security is tolerable, a side-chain.

Let’s take Dark Forest, which uses about 40 transactions per block every five seconds on Gnosis chain. To play a multi-day game of Dark Forest, competitive players spend between 20 and 200 dollars.

Returning to our assumption of 20,000 concurrent users, if we have eight TPS, each player can move every half-hour. That simply won’t work.

We need:

  1. Orders of magnitude fewer players;
  2. Fewer numbers of transactions required to keep track of game-state changes;
  3. Novel ways to increase transaction throughput because games do not have the same security requirements, as the financial dApps currently in operation (e.g. state channels).

So then how do we tackle these weirdo design problems?

Fewer Players

Option A — Only The Best:

Most chess games don’t count. They aren’t played in official tournaments, and therefore do not affect the players’ Elo (a.k.a. rating). We can imagine a similar structure wherein only the best players play on chain. The canonical game rankings exist on chain, but 99% of players use centralized servers that have forked the public chain logic. In this way they can process order of magnitude more transactions, without the lack of security causing much hinderance.

Option B — Only The Gamblers:

While chess players enjoy the game casually, many play for money. By adding financial consequences to the game, they can make a living or increase their enjoyment. If only the gamblers need to use the chain for its security, then we’ve reduced the scope of served players, while also benefitting from the payment rails built into blockchain tech.

If we agree that only professional players need to use the chain (i.e. the top one percent of a successful game titles), then the best 200 players online can make about two moves a minute instead of two an hour. Not great. Not terrible.

Fewer Moves

Option A — Multiplayer Solitaire:

If some of your moves do not affect other players, then you do not need to commit those moves to the game state. Obvious actions that fall under this category are: looking around, changing cosmetics or reading tool tips. Less obvious actions: upgrading your attack range, completing disconnected tasks, and “daisy-chained” moves.

The most extreme solution is something like competitive Solitaire or Crossword in which players do not interact at all.

Option B — Complicate the Decisions:

Many games make players choose from three options. It is easier to make this decision than choose between fifty options. Well too bad! For on-chain games, providing many options is one of the best bets for stretching TPS.

Option C — Throttle Moves:

When people play on-chain games they can find themselves pushing blocks to their limits. Players gain unfair advantages by paying for more transactions at higher auction prices. While we expect great Chess players to play faster than their opponents, we do not expect them to move more often!

Option D — Out of Band Moves:

Dark Forest’s game state is held on chain, but that doesn’t mean that all moves need to be recorded there. This is an experimental departure from standard game design.

Summary:

If a single move is sufficiently complex, players will be comfortable with one move per minute. If we batch moves before committing them, we might be able to submit a state change once every three actions.

Compounding our Solutions

  • If we accept that only the top one percent will play on chain;
  • that we can design a game that requires submitting one transaction every three minutes; and,
  • that we can have eight TPS without bankrupting players; then:
  • we can build a game that accommodates 144,000 concurrent players!

A game with 144,000 players would be the fifth ranked game on Steam within the past 30 days of this writing.

Where next? It is time to start mining the catalogue of games on BoardGameGeek.com that are considered to have a weight above 4.0. Weight measures complexity; by filtering along this parameter, we quickly find a targeted list of games to port.

Hopefully I’ve been able to inspire solace in those that think on-chain gaming is technically impossible due to throughput.

Special Thanks

Justin Glibert and 0xHank for brainstorming and clarifying some of these ideas with me.