Fully Onchain Games
Fully onchain games are the only "web3 games" that I find interesting or worthwhile.
Like many of you, I have always been a gamer and have spent tens of thousands of hours exploring in-game worlds. These days, I'm too busy with my full-time job (helping people build interesting products using blockchains) to play much, and I tend to spend more time consuming content about games than playing them. I barely ever beat/100% a game like I used to. I still find myself driven to the aura that surrounds a game, often comprising of lore, community, roleplaying, extensive multi-party discussion and the creation of adjacent media.
I understand that this opening statement might be controversial, but I have seen enough of the behind-the-scenes of web3 gaming (or its name-of-the-month; I'm glad we dropped GameFi) to ascertain with some confidence that it is rotten to the core. The only silver lining I have found is the fascinating experimentation currently happening in the world of fully onchain games.
It's hard not to relate with the criticism and downright hate that web3/crypto receives from the wider gaming community. I'm also convinced that if there was a clearly communicated and defined value proposition (like in the case of many fully onchain games), this attitude could shift dramatically.
Dark Forest
Let's start by discussing Dark Forest, a real-time strategy (RTS) multiplayer online/onchain space conquest game.
It was first announced in February 2020, following key improvements in the cryptography making the project feasible (specifically in-browser zk-SNARK proving and verification).
One of the most intuitive examples of an interactive zero knowledge proof is presented in the first lecture (about 15min in). Check it out.
What the fuck is a zk-SNARK?
The cryptography matters here. Blockchains are extremely public and transparent by default, which becomes an issue with hidden information games.
In a complete information game, all players are informed of all other players payoffs for all possible action profiles. This is a different from a perfect information game, which refers to games where all aspects of the game (events, actions) are visible to all players.
- Perfect information games: Chess (all players can see all pieces on the board at any time), Tic-Tac-Toe.
- Imperfect but complete information games: Includes many card games like Poker, where each players' cards are hidden but objectives and payoffs/outcomes are known.
- Incomplete information games are admittedly a lot less intuitive. They refer to games where players do not have common knowledge of the game being played (payoffs, who the other players are, possible moves, outcomes, knowledge of each participant etc.). A potential example of this could be a sealed bid auction.
Blockchains, without a layer of cryptography (what Dark Forest dubs a Cryptographic Fog of War), can hardly accomodate incomplete or imperfect information games. This is less of an issue for commit-reveal games where the information is eventually made public (eg. Poker), where the limited private state of public blockchains can be utilized (public key signature schemes).
Efficiently verifiable zk-SNARKs allow Dark Forest to post each action on a public blockchain, such that the game doesn't require any servers and each user communicates with the blockchain directly. Players store their private state locally but can submit verifiably valid actions and positions to the blockchain.
Instead of submitting coordinates of planets they conquer to the smart contract (meaning all the users would be privy to that information), they submit a hash of planet coordinates along with zero-knowledge proofs that the hash is valid. In order to make a move, they can submit a hash of the origin and destination planet, along with a verifiable proof that the move is valid.
Why?
I just explained HOW Dark Forest was able to run a space conquest RTS game on a blockchain. But why would they, and why should you care?
I see Dark Forest as an important turning point in blockchain development more generally, as it shows how broad the scope of fully onchain applications can be. As opposed to other game worlds, Dark Forest doesn't rely on a central authority that hosts the servers and can arbitrarily change the rules of the game. No one, except the users, controls the outcome of the game once it starts. This is effectively a blueprint for what some tried to call "The Metaverse", where a complex in-game world, with defined rules and interactions, can exist autonomously and potentially be fully immutable.
Anyone is free to introduce new elements on top of the base game, be it marketplaces or tools or even expansion content. It is up to the community (and the clients/front-ends) to opt into any changes. Dark Forest made the idea of user-owned and governed games (and eventually worlds) less remote than it once was. In turn, it led to the creation of 0xParc and its autonomous worlds initiative and network.
I was first introduced to Dark Forest when it was forked on an Avalanche testnet. It was a good example of the importance of time-to-finality, which made the entire experience a lot smoother and closer to what you'd expect from offchain games.
We have come a long way since, and I'm excited for Avalanche's HyperSDK potential for creating blockchains purpose-built for fully onchain games (with custom virtual machines). This comes along significant performance improvements through Firewood and Vryx, paving the way for extremely high throughput blockchains (100k TPS benchmark) that still benefit from Avalanche's instant finality and its potential to be highly decentralized (guaranteed by Avalanche/Snowman Consensus).
Community-Based Play
Community-based play is an interesting phenomenon that could be of some relevance to the topic at hand.
It (maybe) started with Twitch Plays Pokémon (TPP), a little over 10 years ago, and it certainly had a lasting effect, with entire documentaries dedicated to that first run of TPP that only lasted 16 days.
The novelty here came from the fact that inputs were taken from the live Twitch chat, where an algorithm would aggregate multiple replies from different users to single out a specific input. This meant that users needed to work together to steer the character in a specific direction, leading to what many recognize today as a clear example of the wisdom of crowds.
It might in part due to the fact that Pokémon Red is a game many are familiar with, but it was extremely impressive to see the level of skill displayed by a chat on Twitch. Twitch Chat was somehow able to navigate correctly (not without hiccups) and beat notoriously hard gym leaders in surprisingly few attempts.
There is something eery, almost uncanny, about a fully autonomous game, running in perpetuity, based on mass-input from community-based play. You can imagine a setup similar to TPT, where all inputs and outputs are handled by a blockchain, with many custom front-ends instead of a laggy twitch stream and chat. As long as there's a single user, it can keep going forever. Does it all become bots eventually? Can you add a financial component to it? A community prize of sorts? Maybe pit different communities against each other, with some element of competition, reminiscent of flag battles on r/space? The possibilities are endless and even very simple games can provide very robust rulesets for mass-scale social experiments.
Procedural Generation and/or Distributed Content Creation?
Procedural Generation can pair very well with fully onchain games. It is commonly used for generating terrain and loot (sandbox games, roguelikes, survival/exploration) and can sometimes even be applied to textures/graphics and animations (..krieger, rainworld).
It plays an important role in enabling onchain/autonomous worlds to achieve the scale required to justify their immutable nature and inherent longevity. Perlin Noise is commonly-used procedural generation algorithm, and has the advantage of being lightweight enough to be executed and stored onchain.
While in theory, such techniques can allow onchain games to be infinite and even infinitely replayable, scale and size alone hardly makes a game world interesting. Procedural generation merely provides a baseline that is opinionated and can be fine-tuned to achieve desired outcomes, but it doesn't entirely eliminate the need for content generated by humans. What is a Minecraft world without the wealth of items, mobs and game mechanics?
Despite technically being infinitely replay-able, most games relying on procedural generation still rely on continuous expansion content which often introduces new mechanics and items. Modding could be a solution to this, as it is extremely compatible with the permissionless nature of fully onchain games.
Dwarf Fortress is a perfect example of a base game where almost everything is procedurally generated and rendered in barebones ASCII characters. Over the years, the Dwarf Fortress community has created countless tile-sets that drastically alter the look and feel of the game. The same can be observed with games like Minecraft (texture packs) or Skyrim (arguably incomplete without its mods). With fully onchain games, this can be turned up a notch, where individual front-ends have full control over how the game is rendered and which version/upgrade of the game they run. Modders are free to monetize that content however they want, and it's up to individual users or platforms to decide whether it gets adopted.
One can hardly imagine a more open environment for game development: anyone can contribute or decide to opt-out/opt-in from upgrades and newly introduced content.
Designing Around Latency Restrictions
Blockchains might be getting faster, but we're not anywhere close to playing Super Smash Bros or League of Legends onchain. Or are we?
Your Only Move is Hustle (Yomi Hustle) provides a blueprint that could open up the possibilities for onchain games.
Yomi Hustle essentially deconstructs fighting games, giving players more time to enter their inputs, thus creating more of a turn-based strategy game that can still be replayed as a fast-paced fighting game. This same concept can be applied to any fast-paced game dependent on low-latency inputs. The end result will be markedly different from the base game, but lends itself very well to co-op or competitive community-based play.
This type of experimentation can open up the design space for fully onchain games. Blockchain latency might introduce pacing constraints, but they aren't nearly as restrictive as they once were, with modern blockchains realistically achieving 500ms to 3s latency while processing thousands of transactions per second.
Such restrictions can seem too prohibitive at first glance, but I would argue that they can lead to more interesting games. The idea that game designers thrive when working with limitations and often get lost when the options are endless has been validated countless times throughout the history of gaming. Just compare your average GBA game with the average modern Unreal Engine game. There's a reason Game Jams almost always introduce restrictions or themes.
Onchain Games to Play
For any reader that got this far, the only thing left to do is to try some onchain games. It should give you a clear sense of the current state of this extremely niche sub-set of gaming, maintained by a relatively small community. If one thing is apparent to me after the research and playtesting I've done, it's that we've barely scratched the surface of what is possible when it comes to onchain games, community-based play and autonomous worlds.
Note that some of the games listed above are fully onchain, yet fail at being egalitarian or community governed and owned in any way. They will often rely on speculation to drive fees for a single person or entity. I'm all for game developers getting remunerated, but putting profit above all else defeats the purpose. We should think of monetization models that are more sustainable, benefitting contributors more widely and over a longer period of time, as opposed to only rewarding the initial deployer for hyping people up.
If you got this far (appreciate it!), you might as well consider subscribing: