Build the Game that Sells Itself

Hello and welcome back to Dark Tunnels, a newsletter dedicated to exploring the emerging ecosystem of fully onchain games.

Today, we dig into story generator games and how maximally onchain implementations of this genre might augment distribution efforts.

If you’re enjoying this newsletter, it’d be tremendously helpful if you shared it with your friends and colleagues. We still have a long way to go before fully onchain games reach a large audience and each additional reader brings us ever so slightly closer. Thanks in advance!

Hi friends,

Another deep read coming up this week, so I’ll keep the intro to just one update:

If you’re going to GDC this year, let’s meet up!

Let me know you’re interested by shooting me a DM on Twitter, Farcaster, or LinkedIn. Alternatively, you can send me an email at [email protected].

If there’s enough interest, I’ll investigate booking a dinner or similar sort of get together for us all to nerd out.

Looking forward to seeing you all there!

Build the Game that Sells Itself

When writing my last piece on distribution, I didn’t realize that Blake Robbins’ and Mitch Lasky’s excellent podcast, GameCraft, had returned for a second season with related topics right out of the gate.

In short, the hosts make the case that pure play games content businesses are not venture backable, as they present no meaningful competitive advantages or defensible moats beyond the qualities of the game itself. Given that shipping any fun, playable game is a minor miracle, relying on even the most highly pedigreed of teams to create an amazing game that tops the sales charts and returns a venture fund is an extremely risky proposition for most VCs.

With this context in mind, it makes sense that the few companies in the onchain games ecosystem that have managed to raise venture capital are not only making games, but also pursuing some sort of infrastructure play or UGC platform. Argus Labs, Curio Research, and Playmint all fit the mold here, for example.

Nevertheless, straightforward content plays abound in web3 gaming, both fully onchain and otherwise. And though building infrastructure or developing multi-sided UGC marketplaces are both valid strategies for growing enterprise value, they are not the only approaches.

To those companies still focused exclusively on building games, I propose rethinking your strategy with distribution in mind.

I’m not referring to distribution channels, per se (we dove deep on that topic in the last newsletter). Instead, before we even get to the point of choosing which platforms to release our games on, can we first build those games in a way that they distribute themselves? Games where the players do the work of spreading the word for you?

To explore this idea, I’m going to discuss three games that I believe are interesting case studies for fully onchain game developers to consider:

• Dwarf Fortress

• Rimworld

• Blaseball

If you’ve been following Dark Tunnels for a while, I suspect that none of these games will come as a surprise to you. Nevertheless, I believe that each has been criminally understudied in relation to what can potentially be achieved with fully onchain games.

The key shared element of these three titles is that they are all, in one form or another, story generators.

Through the course of gameplay, story generators spawn emergent narratives as a result of the collaboration between the players, the game’s developers, and the game itself.

Storytelling is a force multiplier for content distribution. It’s ingrained in our collective human DNA. It speaks to our emotions — a critical differentiator in web3, where nearly every project is trying to differentiate on the basis of logic.

Instead of appealing to high-minded ideals of decentralization or digital sovereignty…maybe just tell a good story first?

Below, we’ll explore a few games that do just that.

Putting the Story Onchain: Dwarf Fortress

Any discussion of story generators must necessarily begin with Dwarf Fortress, one of the true originators of the genre.

If you’re not familiar with the game, Dwarf Fortress is a complex, open-ended sandbox that simulates a fantasy world in extreme detail — all the way down to the individual limbs, circulation, and muscle strength of each character.

The game presents no specific goals, though players are implicitly tasked with “striking the earth” to create a home for their small band of dwarves.

I’ve written about Dwarf Fortress previously (DT #10: The Simulation Games Opportunity) in reference to the game’s unmatched ability to create compelling narratives for players despite its simple ASCII-based frontend. There are interesting possibilities here as it relates to the clientless nature of onchain games, but that’s not why I want to discuss Dwarf Fortress today.

I want to hone in on the storytelling aspect, focusing specifically on the idea of a simulated history.

When setting up a new game, players are guided through a series of world generation choices. Players then enter that game world at a particular point in time, with hundreds or thousands of years’ worth of pre-generated events having already taken place throughout its simulated history: the rise and fall of kings, the reign of megabeasts, the founding of cities, and so forth.

On its surface, this might seem like simple flavor text. Upon closer examination, however, we realize that the characters and historical events are all interconnected. The history is shared.

Consider the example below from “The Hamlet of Tyranny,” a popular story from the Dwarf Fortress community:

There are a few things happening here. The only flavor text here is the name of the monster, Ashmalice. Beyond that, we’re given plenty of meaningful information:

• Ashmalice is a fire demon, which connotes various stats, resistances, behaviors, and so forth.

• Ashmalice has racked up an astounding number of kills, each of which is attributed to a specific entity that also existed in the world alongside the fire demon before meeting its untimely end.

• Each of Ashmalice’s victims also has its own history and familial connections detailing how they fit into the world and with whom they associated. The death of a given dwarf at the hands of the demon has a larger impact on that dwarf’s spouse, siblings, and friends than it does on other entities in the world.

As mentioned earlier, Dwarf Fortress is insanely detailed — perhaps overly so. There’s a reason it’s been called “the most inscrutable video game of all time.”

But what does any of this have to do with blockchains?

Here I think it’s important to hearken back to another fully onchain gaming concept that we’ve discussed at length in this newsletter: the idea of the forever game.¹

The permanence of blockchains allow for a game’s history to be recorded immutably and verified through decentralized consensus. Over the time horizon of a forever game, this history can be considerably developed, remixed, and built upon — permissionlessly — by players and observers alike.

For session-based games, recorded history is ephemeral and meaningless. Most players don’t care about some hard-fought Call of Duty match from ten years ago or the results of the first DOTA International.

In persistent shared worlds, however, history and narrative can be much more powerful. That’s how we end up with legendary stories about the assassination of Lord British, the hubris of Leeroy Jenkins, or the bloodbath of B-R5RB.

Shared experiences in persistent worlds reverberate across time and impact future events in those spaces. They become memes that spread throughout the player base, potentially even leaving the game world entirely to enter other domains.

The reason we have such detailed and lovingly crafted tales from Dwarf Fortress is due in no small part to the dedicated fans of the game. These stories are recorded and embellished by the players who experienced them so that they may be shared with the world.

With the benefit of a shared onchain game history, these tales can persist longer, can be more easily accessed by anyone, and can be used as compositional building blocks in all manner of creative endeavors. Add on web3 payment rails and developers can even incentivize the creation and distribution of these histories to a broader audience.

If there is a game story worth telling, it will be more easily told with the support of blockchain technologies. And it is these stories that will attract new players to these worlds.

Putting the Storyteller Onchain: Rimworld

Though Dwarf Fortress may have been the first proper story generator to hit the market, I initially encountered the term in relation to Rimworld, a colony sim designed by Tynan Sylvester.

In Rimworld, like Dwarf Fortress, players are tasked with establishing a base for their small band of colonists in a hostile environment. If you’ve played other colony sims, the standard tasks of gathering resources, building defenses, and caring for your settlers will already seem quite familiar.

Where Rimworld diverges from other genre comps is in its explicit emphasis on the storytelling aspect.² Whereas a game like Dwarf Fortress has birthed countless player-generated stories as a result (and perhaps in spite) of its mind-blowing complexity, Sylvester and his team have instead handed Rimworld’s players a suite of “AI Storyteller” options that influence the events taking place in-game. These storytellers can make the colonists’ lives more or less difficult by introducing unforeseen elements such as raiding parties, ravenous animals, or outbreaks of disease at varying frequencies, depending on the presets selected.

While there are plenty of valid criticisms with this approach to storytelling, it makes for an interesting case study with regards to fully onchain games.

Consider an implementation that brought the storyteller AI onchain. For starters, this entity could be deployed in such a way as to be entirely independent, free to exercise influence over in-game events without the interference of any centralized body.

Additionally, this AI could be endowed with its own wallet, enabling it to trade currencies, pay out rewards, hold NFTs, and so on. Think of the banker in Monopoly or the rubber banding in Mario Kart — roles or abilities that should be applied (more or less) objectively and may be better fulfilled by non-player entities.

For an early taste of where this might be going, check out what the Realms team is doing with Blobert, an AI companion intended to assist Discord members in getting up to speed (with a heavy dose of personality):

I also highly recommend watching the Network States talk from the Autonomous Worlds Assembly, as it has a lot of overlap with these ideas:

In the future, one can even imagine interoperable onchain storytellers that can be swapped in or out at the whims of the players. Instead of relying on a modding community to provide alternatives to default storyteller presets, developers can be incentivized to create compelling alternatives. You might call this a sort of “God as a Service” business, as I discussed on the FOGDAO podcast with David Amor, Nico Vereeke, and Tim Cotten back in October.

The added benefit of bringing AI storytelling onchain is that it is extremely scalable. Development teams don’t need to ramp up a team of narrative designers or game writers to accommodate player growth. Game events can be generated, agreed upon, recorded immutably, further extended, and remixed by the community, all without a centralizing influence.

While this is obviously easier said than done, it’s not hard to imagine how powerful these permissionless mechanisms might be in evangelizing a game to potential new players and participants.

Fully Decentralized Storytelling: Blaseball

In the prior two examples, stories emerge from relatively abstract experiences that are augmented by complex simulation design (in the case of Dwarf Fortress) or bespoke storytelling mechanisms (in the case of Rimworld). Though these games are both designed as single player experiences, they provide interesting case studies for how inherently multiplayer fully onchain games might establish compelling narratives around similarly expressionistic gameplay.

For our final example, Blaseball, we will instead look to a multiplayer-first experience for lessons on what fully decentralized storytelling might look like in an onchain game.

It’s worth taking a few minutes to watch the video above just to wrap your head around Blaseball, because frankly, any explanation I attempt to provide here won’t do it justice.

Beyond the “idle browser game” description the video provides, we can also think of Blaseball as a type of massive interactive live event, or MILE. I’ve written extensively about MILEs in the past (first for Naavik way back in 2020, and again for Always Scheming last summer), but if you’re unfamiliar with the concept, think about it like Twitch Plays Pokémon: thousands of players take part in an interactive event, all trying to influence the outcome concurrently, but the logic of the game itself happens in the cloud on someone else’s machine.

Hopefully, you’re already starting to see the parallels to fully onchain games, which execute their logic on the “world computer” of Ethereum (or another blockchain).

As a “web2” game, Blaseball was not truly decentralized in the way that we might define the term in web3. The Game Band, Blaseball’s developers, exercised a lot of control over the core simulation logic and the narrative framework of Blaseball. Crucially, however, the team did involve the player base in key game-changing decisions through a sort of “governance” mechanism in the form of weekly voting.

Users were allowed to vote on “decrees,” “wills,” and “blessings” each week through the use of Blaseball’s in-game currency. The analogues to web3 are obvious: just replace the coins with tokens, bring the voting onchain, and — voila! — decentralized governance.

I’m obviously glossing over a lot of important details, but you get the idea. Some onchain games have already attempted similar efforts to incorporate their player base into governance and narrative development: the aforementioned Realms, for example, or the Citadel team.

The key takeaway here is the involvement of stakeholders outside of the initial development team in ongoing decision-making and world-building. For all the talk of “building in the open” and “community-led development,” very few game teams actually manage to pull this off effectively.

To be fair, it can be a tricky balance to strike: where does one draw the line between being too prescriptive and too open-ended?

Folks in the fully onchain games ecosystem like to talk about building a base set of “digital physics” and then turning the community loose to build out the rest of the world. This is a great idea in principle…but it’s also not an entirely new concept:

While it sounds exciting and contrarian to discuss these concepts as if they’re groundbreaking philosophical achievements, in reality games like EVE, Blaseball, and other similarly abstract games have always relied on players to expand their universes and extend their narratives.

The wrong way to go about something like this is to pay lip service to players by rewarding them with the ability to name some in-game object, or letting them vote on which character model looks the coolest. Rather, players should be trusted to influence outcomes and be granted the agency to make it happen.

Can this go wrong? Of course it can — and indeed, it often did in the world of Blaseball. Where The Game Band excelled was in rolling with the punches: instead of exercising their power as developers to reverse some community-led decision they may have perceived as a mistake, they instead found ways to turn bugs into new features.

A great example of this is the saga of legendary Blaseball pitcher Jaylen Hotdogfingers. To try and keep a wild story relatively short:

Jaylen was incinerated as a result of fan voting on a Season 1 decree (“Open the Forbidden Book”), which had the effect of replacing their former team with a null value. The Game Band was later forced to resurrect Jaylen after fans coordinated to keep the deceased pitcher at a specific ranking on the “Idols” leaderboard. This was done in order to take advantage of a blessing from Season 6 (“Lottery Pick”), which would “steal the 14th most Idolized Player in the League."

Hotdogfingers then reappeared in the following season (resulting in even more zany outcomes that I won’t go into) and would go on to pitch for 17 more seasons, becoming one of the game’s most beloved players in the process.

All this from an overlooked null value.

I told you my explanation wouldn’t live up to the insanity that was Blaseball.³

This is just a sampling of the absurdity, but I think you get the idea. The same community that conspired to resurrect a dead player would also create all manner of additional lore and fan art, conduct in-depth statistical analyses, form bands, and even raise money for a spin-off card game.

Importantly, Blaseball — like Dwarf Fortress and Rimworld — was not exactly a polished AAA experience. In fact, it was essentially just a series of menus, UIs, and game box scores. Yet it managed to sustain a ravenous fandom by allowing its community to exercise agency over the game world.

If a relatively simple menu-based game with humble beginnings as a side project can go on to achieve this level of community engagement, imagine what might be achieved with the added benefits of blockchain technologies to aid in its growth.

Notes:

1. For a deeper read on this concept of the forever game, check out DT #8: Finding Forever (Games) and DT#9: The Forever Games Framework.

2. There are obviously way more differences to mention here: the learning curve, the scale, the thematic choices, the level of control, and so on.

3. I say “was” because the game was sadly cancelled in June 2023.

In Conclusion

Thanks for sticking with me on this deep dive. You can probably tell that I nerd-ed out pretty hard on this edition.

Even still, after 3,000+ words, I think we’ve really only scratched the surface of the applications we can glean from these games as it relates to the world of fully onchain games.

For example, we can add interesting layers of complexity to all three of the examples above — onchain stories, onchain storytellers, and decentralized storytelling — by choosing to hide or reveal some parts of the story via zero knowledge circuits, multi-party computation, or similar hidden information tools.

For example, an onchain story might be entirely transparent, resulting in a shared history or lore, but the onchain storyteller might be obscured such that players are unable to decipher the code dictating its logic (and therefore incapable of gaming the system to achieve some desired outcome).

Similarly, bits of in-game information might be revealed only to the players directly impacted, leaving the choice to reveal said information up to the relevant individuals. Developers might even choose to hide game items or story events in the game code that they themselves do not have complete information about (e.g. items with randomized properties, battles with undetermined outcomes, etc.).

Additionally, in all three of our examples above, players actually don’t have a ton of direct control over the outcomes. Users can cast votes, give orders, or set task priorities, but are ultimately at the mercy of the simulation logic. As such, these games also make excellent case studies for fully onchain games that embrace the use of bots alongside human players.

Perhaps I’ll revisit these offshoot topics in a future edition (let me know if that sounds interesting to you!), but I’ll leave it there for now.

Thanks, as always, for reading.

Love this newsletter? Hate it? Fill out this brief reader survey and share your feedback. Thanks in advance!

Get in touch: [email protected].