This is part one of a series of blogs exploring the optimal UX for Web3. It focuses on games, but should offer useful ideas to products more generally. After chatting with dozens (hundreds?) of Web3 game builders over the past couple of years, I’ve heard consensus that onboarding has too much friction. But how do we get out of Metamask morass and into UX utopia?

About me: I’m a core contributor to Alliance DAO, a startup accelerator and founder community. I hold a PhD in Game Design. For those of you who haven’t read my previous pentalogy on scaling Web3 games, you can check it out here.

For anyone looking to apply to our programme, you can fill out an application at alliance.xyz.

Progressive Onboarding Done Right

Despite being a popular concept in the UX community, the first time I saw the term “progressive onboarding” used in Crypto was in this Privy.io blog. It’s a simple idea:

new users should only feel friction as necessary and as late as possible.

Too often, crypto products request “Wallet Connect” and signatures up front, before they are needed. But before we dive into applying best practices to Web3, let’s start with a brief analysis the onboarding experience of a AAA mobile game: Marvel Snap (henceforth Snap). It is a contemporary game with exceptional retention that effectively introduces complex game mechanics, and a unique progression system, through progressive onboarding

Lesson 1: Let People Try Your Product First

Design: Players starting with Snap are confronted with a choice: “Play as Guest” or “Already Linked Your Account?” Surprisingly, the screen is laid out to nudge the user into playing as guest. This means the player will experience the entire tutorial without ever making an account!

Lesson: Snap offers a valuable idea before the user presses a button: let people try your product first. By eliminating points of churn in the account creation process, you can retain more early users.

Lesson 2: Simplify Play

Design: Once you are past the initial screen, the game railroads you through a simplified version of a round, featuring only 50 percent of its full set of mechanics. This tutorial round is designed to be impossible to lose. Take a quick look at what it highlights (vs. hides).

• Play a card each turn. (Don’t introduce Energy yet)
• Each card has a numerical strength. (Don’t introduce Abilities yet)
• There is one valid location to put a card. (Don’t introduce Location Effects yet)
• Win the game by having more strength than your opponent. (Don’t introduce the idea of winning two of three locations)

Lesson: You do not need to teach everything at once. The Snap team effectively designed a new game jut to keep the user from becoming overwhelmed in their first few minutes. Your goal as a game designer is to get players from Apathy to Flow by increasing their Skill Level and the game’s Challenge Level in tandem. Too much challenge, relative to skill, and your users feel Anxiety, Boredom or Worry, and leave the game. The hot take here would be to suggest the same for products more generally.

Lesson 3: Introduce Progression

Design: After beating the Snap tutorial, you earn your first reward: a visual upgrade for a card. Cosmetics are excellent early-game rewards because they do not impact gameplay and yet give the player something nice. But the game does something unexpected: Upgrading the visuals of your cards unlocks new cards for use in future game rounds. This creates a loop: beating a round unlocks resources for players to alter their cosmetics, and unlocking cosmetics gives the players resources (new cards) to win future rounds. To cement this loop, Snap guides the player through a second, more complicated tutorial, and another round of upgrades.

Lesson: Giving players a meta-level motivation is powerful. Think of it as a second game played alongside the first. The rewards of the first game can be the resources of the second, and vice versa. By doing this, the systems mutually justify each other’s value.

Lesson 4: Securing the Bag

Design: After completing a couple more tutorial rounds, and unlocking more progression, the game returns you to the lobby. Only now does a pop-up window request that you name yourself! Wait a few more rounds and it will prompt you to connect with social login. At that point, you enter a fully unlocked lobby, rife with missions, resources, and news. Play long enough and you’ll discover a surprisingly cost effective “first purchase” bundle for only a few dollars.

Lesson: Only bother the player with administrative chores once they have tested your product. Furthermore, break these up as much as possible, so that they never take more than a few moments to complete. Now that they are committed, players will sign up without churning.

And remain laissez-faire about monetization! Giving you their number doesn’t mean they want to go home with you. As they play, and their identity becomes tied to the game, players will start buying in-game assets.

How Does This Translate to Crypto Games?

Snap has revealed that crypto onboarding should only occur when it is first needed. Which means, in almost all cases, it probably isn’t needed yet. I’ll take Primodium (ALL9 cohort) as an example, a pre-alpha project with a small team trying to build a viral on-chain strategy game.

Applying Lesson 1: Let People Try Your Product First

On the plus side, unlike many of its peers, Primodium does not ask you to connect your wallet. Instead, your private key is kept in the browser’s cache. If the player accidentally clears their cache, progress will be lost. This is the same risk that Snap takes before having the player add Social Login. Being able to play without the friction of wallet management is an excellent choice by the Primodium team.

However, when you first connect to Primodium, it takes two minutes to load the world state. Game over. This is already a deal-breaker for snappy onboarding. Primodium mistakenly wants players to jump into a multiplayer environment, but, as we saw with Snap, this isn’t necessary right now. Reduce the complexity of onboarding by making the first hour of gameplay player-vs-bot. That way, players can try the product before having to wait on the chain.

Applying Lesson 2: Simplify Play

At the start of Primodium, we run into a mine-field of complexity. If you were ever at risk of Anxiety, prepare for a nervous breakdown. The developers hide nothing from the player, displaying rank, score, six buildings, a star-map, three mine-able resources, a main base, 8 icons on the top right, and 15 (!) empty resource trackers. Keep things understandable by hiding whatever isn’t necessary for immediate play.

Primodium’s saving grace is a tutorial box, which lists a set of quests, following Snap’s example of an unlosable first tutorial. However, the player cannot claim their rewards until the blockchain transaction has been executed. Ideally, the client would progress “optimistically,” as though the transaction were confirmed, eventually re-synchronizing with chain state. This kind of front-end “cheating” is necessary and not at all unique to Web3. Games have had to rely on clients progressing states faster than the backends can keep up for years.

Applying Lesson 3: Make Progression Fun

Since Primodium’s core loop centers on constructing an alien factory, there is inherent progression that is visualized to the player. And every time the player upgrades their base, they gain access to new buildings. These not only help to introduce complexity more slowly, but are rewards for past success. And since you control the layout of your base, it is rewarding to see your base become more aesthetic.

On top of in-game progression, Primodium displays meta-level progress through global rank. As current rounds are small, a new user can climb the leaderboard quickly. The dopamine hit of seeing that number go up is a crucial part of retention. Over time, it will be important to close the loop, and leverage that leaderboard score to output cosmetics and other in-game rewards to the player.

Their loop ought to look like: Play with assets to score, score to get more cool assets, play with new cool assets to score more (or, in a balanced game, differently).

Lesson 4: Securing the Bag

Primodium excels here, because it doesn’t try to secure a bag at all! The developers know they haven’t found product market fit and that they aren’t building a sufficiently recurring user base (yet). Instead of finding ways to monetize, they are spending engineering time making the game better.

Because of their decision to ignore monetization, they inherit a second order benefit: no need for wallet connect. The only time the player is prompted to sign anything is if they wanted to connect their game-state to their personal address for some bragging rights. Here, we see a new crypto-native pattern emerging, the separation of hot and cold wallets in games and apps more generally. Play with a burner, but store your reputation (and maybe one day NFTs) in something safer.

Takeaways

Web3 user flows and onboarding should not be significantly different from those in Web2. Focus on letting users try the product quickly, in a simple format, while immediately linking successful interactions to progression. Introduce administrative tasks, like account linking and wallet connect, once you have buy-in. And make monetization available to the players who love your product and look for it between value-creation.

If you are a founder building something in crypto, we’d love to learn what you are up to: Apply to Alliance.xyz

Special thanks to 0xHank for reviewing this article.

Removing Web3’s Friction: Pt.1 Progressive Onboarding and Games was originally published in Alliance on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

About me: I’m a core contributor to Alliance DAO, a startup accelerator and founder community. I hold a PhD in Game Design.

Summary

In this post, I propose a game design pattern that scales web3 games by processing game loops off-chain in a permissionless and trustless way. This requires representing game logic in a zk-circuit anchored to a blockchain. I’m calling this design pattern a “bat-channel*”. With bat channels, we enable a sustainable, large player-base by magnifying the number of concurrent state changes. The primary trade-off is the segregation of competing players. Massively multiplayer games where thousands of people touch the game state at any time would be impossible. Instead, the theoretical limit is closer to 30, with simplification for single-player and co-op games. In order to justify the trade-off, I propose a compelling game design that leverages the scalability of bat-channels, while also enjoying the benefits of running on a blockchain. Following posts will include more technical explorations of the design.

Introduction

In 2021, Galcon was ported to the blockchain under the name Dark Forest. Over the course of a year, hundreds of players competed on a handful of maps that persisted for about a week. Players built front-ends, scripts, and smart contracts on top of the game because of the affordances of open-source blockchain game design. Many of the greatest Solidity researchers and engineers tested themselves and explored this new form of play. They built community marketplaces, where players began trading resources and even information in order to progress towards their in-game goals. Similar games popped up around the same time, such as Conquest.eth and Mithraeum.io. In each, all players competed on the same map at the same time.

Unfortunately, these games were hampered by the throughput of the blockchains they were built upon. For instance, Dark Forest ran on Gnosis Chain, which allowed 30 game-state-altering transactions per second. Since expert players automated tasks, a single account could approach 30 moves on their own!

In an earlier post, I discussed ways to scale game design without improving or altering the cryptography they use. But even in a game that uses a quarter of a block, where players move once, very carefully, every three minutes, there is still a maximum of 1440 concurrent players (180 seconds/moves * 8 moves*players/second). Builders must either believe the total lifetime value of these kinds of players is 100 times more than Web2 users, or this is an unacceptable number, given that successful games today boast over 100,000 concurrent players. While we may see 10x scaling in the coming years, we are going to need 1000x scaling to support a handful of successful games.

Scaling with Bat-Channels

The naive scaling solution could be to create more side-chains like Gnosis or Polygon PoS. But side-chains do not inherit the security of the chain they run on. Instead, they generally rely on their own set of validators, which stake assets to guarantee good behavior in exchange for proportionate block rewards. They are called side-chains because they often re-use the same virtual machine, maintain a bridge, and post snapshots of their state to the primary chain (for some kind of socially coordinated emergency recovery). With 1000 of these, we could accommodate a sufficient number of players. The problem becomes player fragmentation, liquidity fragmentation, securing bridges and the undermining of security.

To more closely match the security assumptions of major blockchains, many developers have opted to use Optimistic and zkRollups. These offer similar scalability to side-chains, but they must each post transactions to their L1. However, there is not enough block space on Ethereum to accommodate 1000 additional gaming rollups and the rest of the ecosystem.

A third construction for scaling are state channels. Lightning Network is a popular implementation on Bitcoin, used as payment rails between two parties. Each party locks funds into a smart contract and then writes messages off-chain that update the state of their balances.

For instance, Alice and Bob each lock 0.1 BTC. Alice sends Bob a message every minute, signing away 0.00001 BTC. Every once in a while, Bob pays Alice for something and returns some BTC. After a year, the final balance is Alice’s balance is 0.05 and Bob’s is 0.15. Alice exits the channel and posts the latest state on chain. Bob has a window to contest with a more recent update, after which the smart contract releases the funds to Alice and Bob.

State channels, like Lightning, allow for orders of magnitude more transactions because none of the interim states need to be on chain. For two players in a game, a state channel might be appropriate. WHY? The trade-offs would be a massive reduction in the total number of players who can interact with each other at the same time. Instead of 1000 people on the same map, you would only have two (maybe a couple dozen if you use some sci-fi crypto). You’d also need players to be able to contest both cheating and non-responsiveness. In a later post I hope to address these issues; however, for the sake of brevity, this article focuses on a cooperative construction. In the case of co-op, all players are aligned and the game is positive-sum. The threat model is not that the players cheat each other, but that they cheat the game.

Proof of Game

To prevent fraudulent play, the game itself must be programmed in a provable way. Current solutions may include using Cairo and the Cairo VM or Solidity and the various zkEVMs. It is possible to build what looks like a zkRollup without a third-party sequencer. Since players are not worried about the ordering of their moves being compromised maliciously (because they are friends and no one else is inside the rollup), they can agree on the order themselves. It is scalable because there can be an arbitrarily large number of moves while only needing to commit a single proof and state differences** to the chain.

Game Design

Using the bat-channel architecture (a shared blockchain state and parallelized gameplay sessions), let’s consider what games are most appropriate to port. I have chosen the legendary massively multiplayer online role-playing game, World of Warcraft, as an exemplary choice. While most people think of WoW as an antagonistic shared-state game, I argue that it is largely a small-group co-op experience. And from the game theoretical/security assumption perspective, it is therefore a single-player game. While millions of concurrent players have enjoyed WoW, they are broken up over hundreds of servers. And these servers are broken up over dozens of zones, which are broken up into hundreds of dungeons called instances. This is how millions of players can fight the same monsters in parallel. Two different teams can walk into the same cave and never see each other. The larger meta-world, including the auction house, is used for trading, repairing gear and managing character development.

For a web3 game, I propose a similar construction be the first target of design. That is, the main chain is a place to do commerce, character stats and reputation, and core gameplay loop exists outside it. Players spin up their own instances, bringing in their characters and gear, only to provably exit those instances with more gear and exp. While this removes composability, as gameplay details are missing, we instead get player privacy. No one gets to know how beat the dungeon. And, if you want to bring back composability, you could, for instance, offer a special NFT to players who kill a hundred rats in the dungeon. Players can go through their backlog of moves and create a proof that this is something they accomplished. Data availability can be pushed onto the players because there is no risk for them.

Next Steps

The project that is closest to building bat-channels is Dojo. This game engine is built for the Cairo VM and proves that games have been played correctly. As of yet, the system has not been used to create a game system where an economy lives on one layer, while the game loops live in separate bat-channels. The team says live demos should be coming soon.

If you are a founder looking to start a bat-channel related project, my DMs are open. I’d gladly introduce you to the long list of people excited to meet you. And please, don’t forget to apply to Alliance.xyz, we’re very excited about trustless Web3 games.

Special Thanks

Yonada — Lattice, Ramon Canales and Rich Kim — Matter Labs, Tarrence Van As and Sylve Chevet — Dojo, Mohamed Fouda — Alliance, ycryptx, guiltygyoza — Topology, Feltroid Prime — Herodotus, Baz — Aperture Labs, Henry Caron.

End Notes

• *The name was inspired by both Yonada’s Battle Rollups and the way in which the Lightning Network scales Bitcoin through state channels.
• **At the time of this writing, it appears that Polygon’s zkEVM is unsuited to this approach as it compresses all transactions and posts these to chain, rather than only posting state differences. That said, this tradeoff offers additional composability, which may be suited to games with fewer moves that still need somescaling.

Unblocking On-Chain Games Pt. 5: Bat-Channels was originally published in Alliance on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

About me: I’m a core contributor to Alliance DAO, a startup accelerator and founder community. I hold a PhD in Game Design.

Food Chain Magnate

Last month, I presented at ETHDenver on the five major problems facing fully on-chain games. The last, and perhaps thorniest is in finding game design patterns that are appropriate for blockchain’s as a medium. In the first post of this series, I mentioned a few games that might be particularly suited to being built on-chain. In this post, I dig deeper into one of them, Food Chain Magnate (Doumen & Wiersinga 2015). You take on the role of a fast food franchise founder, inspired by the likes of Ray Kroc. Your goal is to convince suburban homes that they want fast food, and then sell it to them at the most affordable price in the most convenient location. You are going to need to carefully choose where to open restaurants, how to advertise and, most importantly, whom you hire and train.

The best games are unintuitive. That is what makes them meaningfully challenging. I find it easiest to describe a game by the ways you may misunderstand its rules. Here are some notable mistakes I made in FCM that cost me sweet sweet victories.

1. I spent a lot of time advertising hamburgers and ensuring that I could supply them at great prices. However, my opponent convinced my customers that they wanted to drink lemonade alongside those burgers. I was caught with my pants down, as I had no beverage distribution network. Even though their burgers were more expensive and inconvenient, they got to sell and I couldn’t make payroll.
2. I hired nearly every waitress under the sun to generate early cash flow (my restaurants were more like Hooters than McDonalds I guess?). With this cash I hired more expensive talent to outpace my opponents. Unfortunately, I neglected to train up my managers, who were eventually overwhelmed with staff. I was not able to field all of my hires, causing my workforce to become game-losing-ly inefficient.
3. I decided to compete with my opponent on generating profit through pizza sales, but had not considered the ramifications of the bonus he received for being their inventor. With every sale of a pizza, he would make an additional $5, regardless of the price. My own bonuses allowed me to out-scale him (offering pizza at three times as many locations) but he quickly realized that he could undercut my pizza by 80% and still be profitable. Even though I was all over the map and pumping out pizzas en-masse, all the suburbanites were willing to travel to his distant joint to save a couple bucks. By the time I got around to slashing my prices, it was too late.

Why Port it to Chain?

This game has a few key features that make it an ideal candidate for an on-chain game:

Player Quantity Agnostic

First, Food Chain Magnate can be designed to support any number of players. There are two reasons for this:

1. Because the scoring phase “a.k.a. Dinnertime” affects all players simultaneously, they do not need to wait for each other to finish their turn. Some phases do have sequential play, but you could parallelize them with some quick changes. Then players could commit their moves simultaneously. Instead of having to wait your turn (which is standard in older games like Clue, Monopoly, or Risk), players can move in parallel.
2. The map grows with the number of players, as do the number of bonuses for achieving early milestones. For instance, the first person to hire a waitress makes $2 more per waitress employed. But everyone who hired a waitress on the turn where the first waitress was hired also receives the bonus. While the game is normally set for three to five, it could be set for dozens or even hundreds.

No Mid-Game Randomness

Second, there is no random chance during gameplay. While the board is randomly generated each game, and while the game length is dependent on when the bank runs out of money, there is no deck of cards needing shuffling or dice to be rolled. Without the need for fairly generated randomness, the game does not need to pay for outside oracles or ruin UX with awkward randomness generating structures.

Lots of Thinking, Batched Doing

Third, the game is heavy, meaning there is a lot to think about. This is in part because moves require lots of nested decisions. Boardgamegeek rates it at 4.21 out of 5 for weight, making it the 6th heaviest game in the top 50. A two hour game usually has 10 rounds, where each round could require at most three state changes from each player. That is one move every four minutes. A 40 TPS chain could handle nearly 10,000 concurrent players.

Guaranteed Fun

Fourth, the game is hecking fun, albeit unknown. Splotter Spellen famously does not advertise and their boxes are ugly (for instance, the backs of their boxes are just white cardboard). They cater to a very small niche of gamers who do not mind spending $150 on a great game. Instead of putting their efforts into visual design and marketing, they build novel game mechanics and balance the heck out of them. So while their competitors have mass Kickstarter campaigns, short learning curves and target big box stores, Splotter Spellen just looks to have a couple thousand people fall in love. I suspect that their other flagship games, Roads & Boats, as well as Indonesia would be suitable for blockchain too.

But what makes this particular game fun? Here are a few mechanics worth highlighting, as each leads players to enjoy deep thinking (think of this as leveraging off-chain computing 😘):

1. It is costly both to build the market, advertise to it and then supply it. A player who spends too much time growing demand for goods (either by lobbying to develop suburban dwellings or through ad campaigns) will be beaten by a player who focuses on an agile production line, looking to reap the rewards sown by their opponents. Conversely, a player who exclusively focuses on manufacturing will never be able to shape their market to their will.
2. There are too many things to do and nowhere near enough actions to complete them. Players need to hire, train, market, cook, deliver, develop suburban areas, open new restaurants, reprice, and so on. Each of these things is critical for a player's success, and yet only a fraction of them can be accomplished by any given player. Ruthlessly poring over opportunity costs is exhilarating.
3. Variable strategies progress in varied ways. Since there are so many things to do, and because Splotter spent so much time balancing them, there are lots of great ways to try and win the game. But on top of that, the first person to complete some milestone, such as launching the first add campaign or cooking the first burger, each strategy will be inflected part way through with player specific bonuses.

Conclusion

Building on-chain games remains extremely hard. However, since my last few posts, notable improvements have been made on the tooling level, the community has grown (the secret Telegram group I am in has gone from 17 to 105), and new examples of fully on chain games are being playtested. I’d like to also make a shoutout to 0xhank (my fearless editor) took my last post to heart and has started building Dark Seas, a naval battle game which has captured the hearts of the on-chain gaming community. So far, it has been a delight to playtest. To give it a try, join the Small Brain Games discord: https://discord.gg/FDvGVgFN.

And remember, if you want to talk about building fully on-chain games, or if you are already working on them, please please DM me on Twitter at @DangerWillRobin.

Unblocking On-Chain Games: Part Four — Food Chain Magnate was originally published in Alliance on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is Part Three of a series exploring constraints at the intersection of blockchains and games. The objects of inquiry 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.

The Context for Dogfighters

While there have been several aerial combat boardgames, the branch that interests me here stems from Wings of War: Famous Aces (Angiolino & Paglia, 2004). Set in WWI, two sides compete to destroy the other’s air force. Wings of War was re-implemented as Star Wars: X-Wing Miniatures Game (Little, 2012) and then later re-rebalanced in a Second Edition (Little & Brooks, 2018). Not only did X-Wing reskin Wings of War, it cleaned the up the rules, explored more of the game design space and added recurring monetization. On this last point, players would continue to buy new models, pilots and weapons cards. These would come out a couple times a year and enable players to re-shape their armadas. While I think this IRL structure of buying new collectibles to add more gameplay is awesome, and totally in line with what web 2.5 gaming wants to do with its NFTs, monetization is not the focus of this essay. Instead, I want to talk about the core gameplay loop and how the “fun” created by this genre of dogfighters is adaptable to fully on-chain gaming.

To setup the game, you first need to a choose a fleet size. Each ship costs something between 10% and 50% of your fleet’s allowance, depending on the model, the pilot and the equipment inside. A medium-sized game could feature three well-equipped B-wings versus seven TIE Fighters, or a Squad of A-wings carrying Proton Rockets lead by the Millennium Falcon versus a pair of Lambda Shuttles and Darth Vader piloting a TIE Advanced x1.

With fleets determined, players then setup on their sides of the board, placing ships in what they feel are optimal formations. At that point, the game begins the following recurring loop:

1. Each side selects the flight paths of their ships.

Secretly, each player commits to an arc that each of their ships will take. Some of these manoeuvres are stress-inducing, such as the U-turn. Others are stress-relieving, such as drifting slowly forward. Each ship has its own mobility. In the diagram below, you can see that Y-wings are terrible at moving quickly and even mid-ranged movements cause them stress. On the other hand, TIE Fighters are great at turning and moving quickly. They even have a tighter U-turn available to them.

Because this piece of the core gameplay loop requires secretly selecting moves for each of your ships all at once, players ends up making several decisions in a single transaction. This appeals to what I described in an earlier post regarding “Multiplayer Solitaire” section 2.A and is a core component of the dogfight genre. You are playing cat-and-mouse with your opponent, guessing where they will fly to next, hoping to that your own manoeuvre puts you behind them. While some ships have 360 degree firing arcs, the majority have 90 degrees directly in front.

2. Both sides reveal and execute their flight paths.

After having committed to the paths of each of their ships, they move according to initiative. For example, TIE Fighters move before Y-wings. Their movement is determined by placing the corresponding path on the front part of the ship, lifting it and then placing the ship so its back is against the end of the movement path.

3. Ships with sights on their opposition fire weapons.

Once everyone has moved their ships, the game enters the firing stage. Here, ships can choose to fire on enemies in their firing arcs. Most will be able to use weapons on targets a few inches away. Some have longer range. In the image below, you can see an X-wing has successfully maneuvered itself to shoot a TIE Fighter at close range. It will get to roll three attack dice and have a good chance of blowing it’s enemy up. If it doesn’t, the following turn will see both ships blow past each other, giving an advantage to the more manoeuvrable TIE to end up on the X-wing’s tail.

To reiterate, the reason the above loop works so well is because the two players are moving up to 20 ships, but only making four transactions (Commit Empire, Commit Rebel, Reveal Empire, Reveal Rebel). This is because everyone must commit to every move at the same time. This kind of asynchronous play is one of the game design patterns I look for when thinking about what the future on-chain games will look like.

Since a competitive X-Wing game lasts an average of 45 minutes over seven rounds, we have (2 Rebel moves + 1 Rebel fire + 2 Empire moves + 1 Empire fire)*(7 rounds)/(45 minutes *60 seconds) = 0.02 moves per second. With 8 TPS, we could accommodate 800 concurrent on-chain players.

Additional Features of Dogfighters for On-Chain Gaming

Given the dozens of ships, pilots and equipment much of the game happens before it is even played. As with Magic: The Gathering (Garfield 1993) and its deck building elements, players need to design synergized collections of game pieces. This is yet another key feature that X-Wing brings to blockchain gaming. You can’t clog the chain if your moves aren’t changing a shared state. I’ve mentioned this kind of block-space-saving game design pattern before, where I recommended we look for games that are played without altering a shared state. I called these “Out-of-band moves” and I thank Justin Glibert for getting me there. At the time, what came to mind is diplomatic relationship management, but deck-building is an excellent alternative example.

Further, even once you have chosen your fleet, you get to also choose your formation. Do you position your pieces further back and play defensively or go aggressive? Do you spread out or clump together? Do you play out of the center or from a far side? And do even get me started about the impact on asteroids have on the battlefield. All of these decisions, much like fleet selection, happen before the game even starts. This means that it only takes a single commitment to the chain to concretize boatloads of game play.

Given that so much of the gameplay happens outside of the chain’s state, I think we could consider that the bandwidth is sufficient for three times the number of players suggested above, some 5,000 concurrent users.

Conclusion

While we are still painfully early in on-chain gaming, particularly because of scaling, games like X-Wing offer an immediate path forward. I also think that we are going to solve a lot of the scaling problems being felt now, particularly with solutions such as Lattice’s MUD on app specific rollups. Importantly, we do not need to take X-Wing’s design wholesale. The key take-away is to find games where players do a lot of actions alone and only reconcile their states later.

Unblocking On-Chain Games: Part Three — The Dogfighter Genre was originally published in Alliance on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unblocking On-Chain Games: Part Two — The 18xx Genre

This is Part Two of a series exploring constraints at the intersection of blockchains and games. The objects of inquiry 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.

The Context for 18xx

Francis Tresham was a brilliant, if oft forgotten, designer who pioneered the 4X genre and introduced the game pattern “technology trees.” Sid Meier’s Civilization (1991), despite its auteurist title, was actually an adaptation of Tresham’s board game, Civilization (1980). Tresham pioneered another category of games prior to Civilization:the “18xx” genre. In 1974, Tresham released 1829, the first 18xx game. In it, players compete to make the most money operating British railroad companies. Since then, dozens of train games have emulated its design. Funnily enough, Sid Meier took inspiration from Tresham again, launching a single-player video game version of 1829 called Railroad Tycoon (1990). However, the unique player interactions in Tresham’s work were lost in Meier’s single-player adaptation.

While there are over 150 18xx games, all cleave close to the original. When players discover a new title in the genre, they often skip the rulebook and read a few paragraphs which contain the rule changes from the original.

In this blog post, I set out to explain the 18xx genre’s unique ideas, not just because they are brilliant game design patterns, but because they are particularly suited to on-chain games.

So what is so special about 18xx games?

The 18xx genre adds a meta-layer to the traditional board game. In these games, companies lay tracks and buy trains. Each company comprises shares that players can own. The player with the most shares in a particular company at a given moment operates that company. There are several details that go into making this structure work, and I encourage anyone interested to start by reading the rules to 1846: The Race for the Midwest. For the purposes of this blog post, you need only understand that players use their funds to invest in various train companies in the hope of growing them as businesses.

For example, let’s say Alice owns 20% of the shares of Swansea and Mumbles Railway and 40% of Great Northern Railway (GNR). Bob owns 20% of GNR and 30% of Great Central Railway. Since Alice has the most shares of GNR, she decides which trains GNR buys, what tracks it lays and what dividends it pays.

If GNR holds 40% of its own stock and Alice decides to pay out £100 of dividends, then she receives £40, Bob gets £20 and GNR keeps £40 to go towards laying more track next turn. Bob is receiving passive income. He did not “do” anything other than purchase shares in a company Alice is controlling.

Importantly, if Alice needs GNR to gain operating capital, she needs to buy more shares from GNR itself. This is the twist that confuses new players. Just because you have money does not mean the companies you operate have money. Finding ways to get cash in and out of the various train companies is the name of the game.

Excitingly, the 18xx enjoys emergent behaviours such as hostile takeovers, rug pulls, and cartels. At the end of the game, it’s the richest player, not train company, that wins.

What is the Pitch?

We should replace on-chain game players with fictional corporations. This design pattern will add a proven and interesting layer of game mechanics. While I do not think this pattern could overlay every game, it would be particularly suited to those where players would normally compete over generating resources.

In Part One of this series, I wrote about the throughput limitations of on-chain games. I have since been looking for games that port best to a blockchain, based on the number of chained actions per second. My research has brought me to Tresham’s work. Here is why it works on a blockchain:

1. Thoughtful turns. Players need to ingest the complexity of the board, the intentions of their opponents, the valuations of the various companies and then make select strategic decisions. Players should be comfortable moving only once every few minutes.
2. Social interaction. Negotiations are an important part of 18xx, and since these are non-binding, they do not need to be recorded to the game-state. That entire layer of play can remain off-chain.
3. Composite turns. When operating a train company, players execute a series of moves at once. This means the game state is updated fewer times, reducing the tps. But better than that, since a train company always makes the most profitable move, an entire round, including each company’s moves, can be completed in one tidy transaction.
4. Getting Tech for Free. Since the 18xx genre is inspired by the physics of finance, it can leverage existing DeFi and DAO protocols. Prebuilt on-chain auctions, markets, and fractional ownership are ready to be composed with new game development. This is particularly exciting to me because it leverages an affordance as opposed to avoiding a limitation.

Someone needs to build this. It will be complicated to optimize, there will be rule-set tradeoffs, and there needs to be a focus on modularity. If you are that someone, hit me up in my DMs @DangerWillRobin, I’d like to help.

Special thanks to my reviewers

@0xHank

Unblocking On-Chain Games: Part Two — The 18xx Genre was originally published in Alliance on Medium, where people are continuing the conversation by highlighting and responding to this story.

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:

1. Orders of magnitude fewer players;
2. Fewer numbers of transactions required to keep track of game-state changes; or,
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).

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.

Unblocking On-Chain Games: Throughput was originally published in Alliance on Medium, where people are continuing the conversation by highlighting and responding to this story.

Non-Fungible Tokens are acting as deeds for artworks and other valuable objects (be they digital or in meatspace), but what would it mean for a token to itself be the object of aesthetic value? How do we imagine works born and living on blockchains in any meaningful sense?

Competing Definitions of Art in a Novel Medium

In grad school, I studied video games as artworks and video game players as artists performing them (like a pianist playing a composition). I tried convincing scholars who didn’t have handy definitions of art to recategorize a known human endeavour as artistic. Fast forward 15 years and I am at it again. My hope here is to talk about the definitions of art and how these might intersect with decentralized artworks and in particular, NFTs.

There are two competing definitional strategies for classing objects as art. The first is based on the object’s intrinsic properties. The second is dependent on actors with cultural capital calling it art. The former is an extremely unpopular view of art in a contemporary academic setting. The only field that actually supports the intrinsic view as far as I am aware is Analytic Aesthetic Philosophy (“AAP”).

Some scholars of AAP have proposed a disjoint definition of art, where some subsets of criteria are sufficient (but not necessary) for an object to be art. One sufficient set of criteria (that I would call the “Creativity Set”) that is widely accepted, even if it is not explicitly acknowledged is the following:

1. Unique
2. Valuable (e.g. shares relevant ideas)
3. Produced without a recipe (Or produced with what Berys Gaut calls Flair)

Without the third criterion, you end up with “paint by numbers” or other crafts, which look like art minus the risk of failure.

The alternative definition of art is called the Institutional Definition of Art (“IDA”). Essentially, an institution (like a museum, university, gallery, private collection, etc.) can transfer its cultural capital (a.k.a. street cred) into an object and as such that object becomes art. Marcel Duchamps’ Fountain is an excellent critique|example of the IDA. He placed a urinal that he did not make, signed by someone else’s name, in a gallery and called it art by virtue of the fact that it was in a gallery. Piero Manzoni canned his feces and did something similar decades later. These artists were famous for pointing out our discomfort with and acceptance of the IDA. However, these examples do not refute the first premise, as their works are actually unique, valuable (in the sense that they propose an interesting idea), and generated with flair (as in there was no clear method being deployed to create these objects).

Some AAPs believe their disjoint definition is clearly superior because the art institutions themselves need criteria to determine what they will imbue with aesthetic value. Otherwise it would be turtles all the way down.

The IDA folks believe that institutions have no such clear criteria and instead select based on political pressures, object availability, social networks, imbalances in cultural capital, etc.

Beeple’s 5000 Days as Example

Beeple’s 69m$ sale of Everydays: The First 5000 Days (“5000 Days”) became an artwork not because it was unique, valuable or produced without a recipe, but because sufficient political pressures were placed on Christie’s to include it in its auction. The IDA implies that since Christie’s is such an important art institution the Beeple becomes art by default.

An AAP might still reject the Beeple as an artwork under the Creativity Set. However, because the definition is disjoint, meaning the criteria are not necessary (only sufficient), the AAP will not be able to claim that it isn’t art.

In either case, 5000 Days is not an NFT, it is a work which has a set of humans agreeing that the ownership of that work is determined by the controller of a specific private key. In other words, the deed which manages 5000 Days is an NFT, but is not itself the locus of aesthetic value. I believe this element is often confused because 5000 Days was born digital as a file on a hard drive somewhere and has since be decentralized its in replication. But let me reiterate, the file is not itself an NFT and that file itself does not live on a blockchain in any meaningful sense.

What Will NFT Art Look Like?

From here, we already know that born digital objects like the infamous Beeple can be art under the IDA while perhaps failing to meet the Creativity Set of the AAP. However, my hunch is that some of the most valuable works in the world tend to also meet AAP’s definition.

Excitingly, the opportunity for Uniqueness and Flair with NFTs is quite high because these are new technologies. Cinema was able to stop remediating theatre and create novel experiences by the early 20th century as directors discovered medium-specific properties of film and used these to novel and valuable effects. 5000 Days does not leverage the properties of NFTs to bolster its aesthetic relevance, rather the NFT aspect seems to heighten its media-archaeological value. For instance, the first photograph might be interesting or valuable, but not because it is a work of art.

To my mind, the most interesting NFT artworks will leverage the trustless, permanent-yet-changeable, decentralized nature of the blockchain to produce effects that are themselves outside contemporary possibilities for standard artworks. The real value thesis should seek not only a Beeple that can pressure Christies to include it into the art canon, but something more medium-specific.

So then what should we look for? Unfortunately, if there were a recipe then it likely wouldn’t produce objects with Flair and likely would meet the creativity set, so it is actually hard to say. Going on a hunch, I would try to find:

1. Works with many artists (cinema and theatre have many artists, so this is not too new, unless the number is remarkably high)
2. Works that mutate while also remaining immutable (like a well-kept blockchain).
3. Works that leverage mechanism design (video games do this already, you’ll want to see financial incentives for something really different here)
4. Works that bring an actually novel idea about in a way that would be extremely hard in another medium

What to avoid? Again, nothing hard and fast, but there are some red herrings.

1. Pretty works (think of the difference between craft/design and art)
2. Works related to cyberpunk-fantasy-gothic and other geek cultures that feed off providing fan service to early cypher-punks
3. Works you understand (artists are generally having really difficult conversations about topics that are just too hard to simply wade into… these are professional thinker/makers who are experts in a field you likely do not grok)

Can an NFT be Art? was originally published in Alliance on Medium, where people are continuing the conversation by highlighting and responding to this story.