Unblocking On-Chain Games: Part One — Throughput
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.
This approach may seem backwards. After all, when a new technology emerges, you should ask: “what new things can I do?”, and not, “how can I contort what is already working into a new technological paradigm?” However, if we start with constraints, we’ll narrow the scope of what we can make (by a lot). And since this problem is horrendous to reason about, I find it best to start by simplifying it. That means you, the reader, need to have faith that it is worthwhile to make on-chain games at all (for now).
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. Once that limit is hit, users must auction for space in the block. 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.” People are expecting to execute valuable transactions on it. 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. That’s eight TPS with modest security and solid decentralization. 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:
- Orders of magnitude fewer players;
- Fewer numbers of transactions required to keep track of game-state changes; or,
- 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).
Since I am a game designer and not a protocol designer, I am going to ignore option three and assume that even if we do solve it, progress on options one and two will help.
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. On-chain games act as reliable reputation machines, in which wins demonstrate intellectual prowess.
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. Once again, most players, who aren’t playing for keeps, can just rely on centralized servers.
N.B. Chess is dominated by robots, making on-chain chess a contest between programmer/computer/player teams. Instead of being disgusted by this, think of how awesome Battle Bots or Robot Wars are as TV shows. I am always reminded of this inspiring commencement address from The Simpsons:
The wars of the future will not be fought on the battlefield or at sea. They will be fought in space, or possibly on top of a very tall mountain. In either case, most of the actual fighting will be done by small robots. And as you go forth today remember always your duty is clear: To build and maintain those robots.
-The Commandant in The Secret War of Lisa Simpson
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. Remember, this is not too much of a stretch when we consider games often have Ranked and Unranked modes. In the same way that Dota 2 lets you select whether your next game will count towards your rating or not, you can have the same on-chain game client point to Mainnet or some local fork. Now let’s see what else we can do.
Fewer Moves
Modern competitive videogames (e.g. Starcraft, Super Smash Bros., or Dota 2) famously require many actions per minute, with some reaching over 10 moves per second! We can’t have that.
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. For the latter, think of games like Pandemic, in which the player has four consecutive moves that cannot be interrupted (ignoring Event cards). There the player is allowed to batch their game state change. Although four actions are taken, they can be combined in one submission.
The most extreme solution is something like competitive Solitaire or Crossword in which players do not interact at all. All players need to do is prove that the sum of their moves results in valid state changes. Hybridizing games like these results in excellent designs that dramatically reduce transactions. In the industry, these games are called “mutliplayer solitaire.” If you search this term, you can explore and play excellent titles. For example, a design like Dominion’s could allow you to batch up to ten actions before altering the on-chain game state.
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. Chess is a good example of this. At any time, dozens moves and their long term impacts must be weighed. Modern European boardgames like Food Chain Magnate or Lisboa similarly provide that depth.
We can think of this solution as increasing the player’s “search space” for a good move. So long as a player is able to make an interesting move every minute, the game pattern will be viable. For instance, an average Chess game takes 40 minutes at that rate.
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 (especially in Blitz games), we do not expect them to move more often! Cap those moves or force players to take turns.
In Dark Forest, the impact of capping moves means undermining those spamming the chain with scripts and forcing everyone to optimize for the best moves as opposed to more. I remain a strong proponent of this unimplemented change.
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. While communities generally frown upon botting, bribery, back-channel deals, phishing, scripting and other malicious forms of play, the Dark Forest community has embraced these behaviours. Attacking the chain, the smart contracts, the social structures, the Discord, etc. are within the bounds of acceptable. This kind of “out of band” strategic thinking and the tactical implementation thereof make for great fun. The benefit here is that these actions do not require transactions. I won’t pursue this thought further here, but it is certainly an experimental line of thinking worth exploring.
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. One transaction per player per three minutes, instead of the two transactions per minute from the previous section means we can get six times more players.
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 100*180*8 = 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. Even if protocol designers fail to give us much more than five times more throughput, we should be safe to design a niche game on chain.
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. We should also look to BoardGameGeek’s games that enable solitaire play. These games showcase design patterns for multiplayer solitaire, allowing for fewer updates to the state.
Hopefully I’ve been able to inspire solace in those that think on-chain gaming is technically impossible due to throughput. If you happened to be working in this field and would like to chat, please DM me at @DangerWillRobin.
Unfortunately, we will still find that that boardgames enjoy certain affordances that are nearly impossible to replicate on-chain. Even something as simple as shuffling becomes a gargantuan task. That’s why I titled this post Unblocking On-Chain Games, Part One.
Special Thanks
Justin Glibert and 0xHank for brainstorming and clarifying some of these ideas with me.
