Hello and welcome to Dark Tunnels, a newsletter dedicated to exploring the emerging ecosystem of fully onchain games. Dark Tunnels is published by Always Scheming, a research consultancy focused on the future of interactive entertainment.

The following essay is Issue #5 of Dark Tunnels. It is also Part 2 of a four-part series discussing the application of business models to fully onchain games. Enjoy!

A natural place to begin our journey is in an area of software development that the world of web3 has relied heavily upon to get to where it is today: open source software (OSS).

“Open source software is software with source code that anyone can inspect, modify, and enhance.”

Opensource.com

Given our previous discussions around transparency, composability, and decentralization, the (abridged) definition above should immediately start to ring some bells.

Much of web3, including both the Bitcoin and Ethereum ecosystems, has been built on OSS. The transparent nature of an OSS codebase allows anyone to modify, fork, and improve the software. Sometimes, that work benefits all parties, as in the case of patching security vulnerabilities or reducing memory leaks. Other times, users might create their own versions for specific use cases that may or may not be open source.

As we’ll soon discuss, the benefits of OSS when utilized within gaming come with their own set of unique business challenges, too.

As mentioned, the transparency and open collaboration afforded by OSS make it easy for anyone to quickly replicate and improve upon an existing piece of software. This is true of fully onchain games, too.

However, when applied to an onchain games business, transparency can sometimes render typical competitive moats (design innovation, technical expertise, monetization efforts, etc.) entirely void. For a simple (albeit imperfect) example of this, just look at all of the “X-to-Earn” copycats that sprouted up after the early success of STEPN.

What this means in practice is that the first team to come up with an effective onchain games business model will quickly see it proliferate among competitor products.

On the one hand, this can be positive in a “rising tide lifts all boats” sort of way. On the other hand, it makes it more difficult to build a sustainable onchain games business and may even encourage closed source copycats seeking to scam or rug pull gullible consumers.

The ability to quickly clone existing designs in web3 is further complicated by users’ natural inclination to avoid paying. We have seen this play out with the controversies over NFT royalties, for example, and one could easily see this being replicated with transaction fees or other attempts to monetize game assets.

In a race to the bottom scenario such as this, how can fully onchain game developers continue to fund their projects – let alone make a living wage?

In traditional gaming, it’s much more difficult to replicate innovative game design or monetization schemes without first peeking under the hood. That’s not to say that it’s impossible, of course — it just takes more trial and error, giving the initial developer greater lead time to establish itself and build a robust audience around its title and IP.

In fact, copycats and fast-follows have long been a part of the games industry. As the saying goes, “imitation is the sincerest form of flattery,” and one need not look far to spot blatant rip-offs – many of which have gone on to become even more successful than their antecedents.

Some of the biggest games publishers in the world have made millions of dollars putting their own spin on someone else’s designs. Genshin Impact, for example, took the design innovations of The Legend of Zelda: Breath of the Wild and applied them to a mobile-first, gacha-driven F2P format. BattleBit Remastered shot up the Steam charts by putting a low-poly spin on the mil-sim sandbox of the original Battlefield games. Fortnite raked in billions of dollars by applying a more casual, mass market friendly wrapper to the hardcore battle royale formula of PUBG (…which itself started as a mod of ARMA 2). Examples abound throughout the history of gaming.

That the games industry is rife with imitation should come as no surprise to anyone that has worked at a large publisher. Innovation is inherently risky, and made even more so by ever-increasing AAA budgets, insatiable fan expectations, and bottom-line driven executives. Following proven formulae is a well-trodden path to de-risking new creative projects…which is why popular culture is inundated with countless superhero movies, boy bands, and first-person shooter games.

Given that building an onchain games business is already a massively risky proposition by nearly every measurement — technical risk, design risk, audience and marketing risk, and so on — operators must be prepared to have any and all successful innovations rapidly copied and iterated upon as competitors seek out opportunities to de-risk their own projects.

Critically, this doesn’t necessarily mean that onchain games are entirely indefensible, though. The competitive moat of a fully onchain game lies not in its smart contracts, but rather in its network of participants and stakeholders:

“[W]hile replication of code may be free, the social cost of coordinating all network participants to move to an empty room is non-zero. Add to that the trust and familiarity that come with brand, lindy effect, and smart contract integrations, and you have a recipe for entrenching an existing service, building its network effects, and generating switching costs.”

Jesse Walden, Variant Fund (ex-a16z crypto)

This brings us back to our discussion of OSS. Like smart contracts, open source software can be freely copied, redistributed, and derived. And, just like in free-to-play games, only a tiny fraction of OSS users ever convert into paying customers.

What makes the open source analogy particularly noteworthy is the fact that OSS has served as the basis for multiple $100M+ businesses. Successful ventures can indeed be built upon open source software. Well-known companies like GitHub, Databricks, Automattic (WordPress), and Red Hat all started off as open source projects.

Open source software exists in the world of gaming, too, though the applications are not as straightforward. Traditional OSS companies monetize users by augmenting the freely available tech in different ways: selling additional features, offering support services, fulfilling unmet customer needs, and so on. Games, on the other hand, have traditionally seen these potential monetization vectors occupied by an unpaid community of enthusiasts all too happy to write player guides, create mods, build quality of life improvements, and patch out advertisements, thus limiting the pool of monetization options available to developers. [1]

However, there is nuance around the types of licenses utilized and which parts of a game they cover. For example, a game engine might be completely open-sourced, whereas a game’s data and content (sound, artwork, graphics, etc.) may be restricted or limited in use. For readers that have been following along with earlier editions of Dark Tunnels, this sort of unbundling of games content from the game engine should sound familiar.

Unfortunately, with a few noteworthy exceptions, the list of open-sourced games is relatively unremarkable from a business perspective. However, one of those exceptions – indeed, perhaps the single most famous example of open source software in gaming – is Classic Doom, which was built on the open-sourced id Tech 1 (commonly known as the Doom engine), but licensed as a 

The openness and mod-ability of Doom is a fascinating topic in and of itself, but most relevant to our discussion around fully onchain games is the evolution of the id Tech engines over time. [2] The Doom engine eventually gave rise to the Quake engine (id Tech 2), which spawned a prolific family tree of successful gaming IPs, including franchises like Counter Strike, Call of Duty, Half Life, and Portal, among many others.

It is difficult to overstate the significance of this development on the establishment of the modern gaming industry.

This multi-decade transformation has important parallels to our previous discussions around the concepts of permanence and “eternal” games. Given that many of the teams building early onchain games engines (MUD, Argus Labs, Dojo) have all publicly stated their intentions to adopt open source development, it is not entirely unreasonable to believe that a similarly bountiful family tree of onchain interactive entertainment experiences might take root over time.

1. Web3 advocates often point to the possibility of incentive alignment via token economies as a means to encourage community ownership and collective contributions. This is an important concept to unpack, and is much easier said than done. We’ll return to the topic of token incentives in greater detail next edition, when we’ll cover crypto-native business models.

2. The world of Doom mods is absolutely insane. My personal favorite (for childhood nostalgia reasons) is Chex Quest, but by far the most impressive creation that I’ve seen is MyHouse.wad. I’ll let the YouTube comments explain: “[g]uys will create an impossible art piece in a 30 year old video game and release it like it is nothing rather than go to therapy.” Trust me, this is a rabbit hole worth falling down.

There are many parallels between the worlds of open source software and web3. The benefits and challenges associated with each bear several similarities and thus offer ample opportunities for onchain game developers to learn from.

Next edition, we’ll continue our exploration of gaming-adjacent ventures and dive into the rapidly evolving world of crypto-native business models — including a discussion of the ever-controversial subject of gaming tokens. I had initially hoped to include that in this week’s edition, but it’s a complex topic deserving of greater detail than I can reasonably squeeze into 1,000 words in the back half of this newsletter.

More to come soon! Be sure to subscribe so that the next entry comes straight to your inbox when it’s published.

Thanks for reading.

Hello and welcome to Dark Tunnels, a newsletter dedicated to exploring the emerging ecosystem of fully onchain games. Dark Tunnels is published by Always Scheming, a research consultancy focused on the future of interactive entertainment.

The following essay is Issue #5 of Dark Tunnels. It is also Part 2 of a four-part series discussing the application of business models to fully onchain games. Enjoy!

A natural place to begin our journey is in an area of software development that the world of web3 has relied heavily upon to get to where it is today: open source software (OSS).

“Open source software is software with source code that anyone can inspect, modify, and enhance.”

Opensource.com

Given our previous discussions around transparency, composability, and decentralization, the (abridged) definition above should immediately start to ring some bells.

Much of web3, including both the Bitcoin and Ethereum ecosystems, has been built on OSS. The transparent nature of an OSS codebase allows anyone to modify, fork, and improve the software. Sometimes, that work benefits all parties, as in the case of patching security vulnerabilities or reducing memory leaks. Other times, users might create their own versions for specific use cases that may or may not be open source.

As we’ll soon discuss, the benefits of OSS when utilized within gaming come with their own set of unique business challenges, too.

As mentioned, the transparency and open collaboration afforded by OSS make it easy for anyone to quickly replicate and improve upon an existing piece of software. This is true of fully onchain games, too.

However, when applied to an onchain games business, transparency can sometimes render typical competitive moats (design innovation, technical expertise, monetization efforts, etc.) entirely void. For a simple (albeit imperfect) example of this, just look at all of the “X-to-Earn” copycats that sprouted up after the early success of STEPN.

What this means in practice is that the first team to come up with an effective onchain games business model will quickly see it proliferate among competitor products.

On the one hand, this can be positive in a “rising tide lifts all boats” sort of way. On the other hand, it makes it more difficult to build a sustainable onchain games business and may even encourage closed source copycats seeking to scam or rug pull gullible consumers.

The ability to quickly clone existing designs in web3 is further complicated by users’ natural inclination to avoid paying. We have seen this play out with the controversies over NFT royalties, for example, and one could easily see this being replicated with transaction fees or other attempts to monetize game assets.

In a race to the bottom scenario such as this, how can fully onchain game developers continue to fund their projects – let alone make a living wage?

In traditional gaming, it’s much more difficult to replicate innovative game design or monetization schemes without first peeking under the hood. That’s not to say that it’s impossible, of course — it just takes more trial and error, giving the initial developer greater lead time to establish itself and build a robust audience around its title and IP.

In fact, copycats and fast-follows have long been a part of the games industry. As the saying goes, “imitation is the sincerest form of flattery,” and one need not look far to spot blatant rip-offs – many of which have gone on to become even more successful than their antecedents.

Some of the biggest games publishers in the world have made millions of dollars putting their own spin on someone else’s designs. Genshin Impact, for example, took the design innovations of The Legend of Zelda: Breath of the Wild and applied them to a mobile-first, gacha-driven F2P format. BattleBit Remastered shot up the Steam charts by putting a low-poly spin on the mil-sim sandbox of the original Battlefield games. Fortnite raked in billions of dollars by applying a more casual, mass market friendly wrapper to the hardcore battle royale formula of PUBG (…which itself started as a mod of ARMA 2). Examples abound throughout the history of gaming.

That the games industry is rife with imitation should come as no surprise to anyone that has worked at a large publisher. Innovation is inherently risky, and made even more so by ever-increasing AAA budgets, insatiable fan expectations, and bottom-line driven executives. Following proven formulae is a well-trodden path to de-risking new creative projects…which is why popular culture is inundated with countless superhero movies, boy bands, and first-person shooter games.

Given that building an onchain games business is already a massively risky proposition by nearly every measurement — technical risk, design risk, audience and marketing risk, and so on — operators must be prepared to have any and all successful innovations rapidly copied and iterated upon as competitors seek out opportunities to de-risk their own projects.

Critically, this doesn’t necessarily mean that onchain games are entirely indefensible, though. The competitive moat of a fully onchain game lies not in its smart contracts, but rather in its network of participants and stakeholders:

“[W]hile replication of code may be free, the social cost of coordinating all network participants to move to an empty room is non-zero. Add to that the trust and familiarity that come with brand, lindy effect, and smart contract integrations, and you have a recipe for entrenching an existing service, building its network effects, and generating switching costs.”

Jesse Walden, Variant Fund (ex-a16z crypto)

This brings us back to our discussion of OSS. Like smart contracts, open source software can be freely copied, redistributed, and derived. And, just like in free-to-play games, only a tiny fraction of OSS users ever convert into paying customers.

What makes the open source analogy particularly noteworthy is the fact that OSS has served as the basis for multiple $100M+ businesses. Successful ventures can indeed be built upon open source software. Well-known companies like GitHub, Databricks, Automattic (WordPress), and Red Hat all started off as open source projects.

Open source software exists in the world of gaming, too, though the applications are not as straightforward. Traditional OSS companies monetize users by augmenting the freely available tech in different ways: selling additional features, offering support services, fulfilling unmet customer needs, and so on. Games, on the other hand, have traditionally seen these potential monetization vectors occupied by an unpaid community of enthusiasts all too happy to write player guides, create mods, build quality of life improvements, and patch out advertisements, thus limiting the pool of monetization options available to developers. [1]

However, there is nuance around the types of licenses utilized and which parts of a game they cover. For example, a game engine might be completely open-sourced, whereas a game’s data and content (sound, artwork, graphics, etc.) may be restricted or limited in use. For readers that have been following along with earlier editions of Dark Tunnels, this sort of unbundling of games content from the game engine should sound familiar.

Unfortunately, with a few noteworthy exceptions, the list of open-sourced games is relatively unremarkable from a business perspective. However, one of those exceptions – indeed, perhaps the single most famous example of open source software in gaming – is Classic Doom, which was built on the open-sourced id Tech 1 (commonly known as the Doom engine), but licensed as a 

The openness and mod-ability of Doom is a fascinating topic in and of itself, but most relevant to our discussion around fully onchain games is the evolution of the id Tech engines over time. [2] The Doom engine eventually gave rise to the Quake engine (id Tech 2), which spawned a prolific family tree of successful gaming IPs, including franchises like Counter Strike, Call of Duty, Half Life, and Portal, among many others.

It is difficult to overstate the significance of this development on the establishment of the modern gaming industry.

This multi-decade transformation has important parallels to our previous discussions around the concepts of permanence and “eternal” games. Given that many of the teams building early onchain games engines (MUD, Argus Labs, Dojo) have all publicly stated their intentions to adopt open source development, it is not entirely unreasonable to believe that a similarly bountiful family tree of onchain interactive entertainment experiences might take root over time.

1. Web3 advocates often point to the possibility of incentive alignment via token economies as a means to encourage community ownership and collective contributions. This is an important concept to unpack, and is much easier said than done. We’ll return to the topic of token incentives in greater detail next edition, when we’ll cover crypto-native business models.

2. The world of Doom mods is absolutely insane. My personal favorite (for childhood nostalgia reasons) is Chex Quest, but by far the most impressive creation that I’ve seen is MyHouse.wad. I’ll let the YouTube comments explain: “[g]uys will create an impossible art piece in a 30 year old video game and release it like it is nothing rather than go to therapy.” Trust me, this is a rabbit hole worth falling down.

There are many parallels between the worlds of open source software and web3. The benefits and challenges associated with each bear several similarities and thus offer ample opportunities for onchain game developers to learn from.

Next edition, we’ll continue our exploration of gaming-adjacent ventures and dive into the rapidly evolving world of crypto-native business models — including a discussion of the ever-controversial subject of gaming tokens. I had initially hoped to include that in this week’s edition, but it’s a complex topic deserving of greater detail than I can reasonably squeeze into 1,000 words in the back half of this newsletter.

More to come soon! Be sure to subscribe so that the next entry comes straight to your inbox when it’s published.

Thanks for reading.