Paradigm recently published The Open Problems of Onchain Games.

I worked in game and virtual world development before Ethereum and wanted to publish thoughts in response to Charlie and Doug’s article.

Below, the word “you” indicates Paradigm.

Onchain games on the four fundamental types of chains

There seem to be four fundamental types of blockchains, although one may be purely theoretical:

(public, private) x (centralized, decentralized)

1. A public centralized chain is eg. BSC. Depending on who you ask, this may or may not include Solana.

2. A public decentralized chain is eg. Ethereum or a sufficiently late-stage L2.

3. A private centralized chain is eg. a federated chain run in a VPN among an industry group. Or an Ethereum zk L2 that keeps data private offchain and restricts participation to an allowlist but settles on Ethereum.

4. A private decentralized chain is an interesting concept, perhaps purely theoretical. Monero? Encrypted EVM?

These types of chains give us a lens through which to explore the potential of purely onchain games:

1. Why put games on a private, centralized blockchain? What capabilities are enabled by baseline blockchain architecture that may be orthogonal to publicity or decentralization? For example, for a closed, centralized game, perhaps the EVM architecture, infra, and tooling might offer a platform that has superior functionality or is cheaper to operate than existing solutions.

2. Why put games on a public, centralized blockchain? What are the benefits of a public chain vs a private chain? Are there contexts where being decentralized can be a drawback and centralization is preferred?

3. Why put games on a public, decentralized blockchain? What benefits become available when you start with a public chain and then add decentralization's extremely strong property rights, censorship resistance, and the expectation of the chain living ~forever?

To what extent are the reasons to put a game due to the capabilities of core blockchain tech vs the chain's publicity vs the chain's decentralization? It seems like an interesting area of research.

Is it a mod, or is it an API? "Yes"

I think you're right that mods are an excellent example of where onchain games can be competitive.

Typically, web2 mod platforms suffer from the mod execution environment being endogenous to the host game.

Ie. no matter how cool your mod is, it typically has to run inside the game.

Compared with web2 modding platforms, onchain games can offer superior structural separation of data, assets, core algorithms, identity, etc (and composability of the former) from downstream, creating opportunities for arbitrary downstream architectures, integrations, and experiences.

Of course, web2 game APIs already offer "freedom of downstream", such as famously in EVE and League of Legends' extensive third-party tools.

So, what's the difference between a mod platform and an API?

Of course, in a web2 game, the API is typically necessarily a separate product from core data and, as such, is often a limited model of the underlying reality.

Ie. web2 game APIs typically have different data and reduced capabilities versus the internal engine that may be more directly exposed to a mod platform.

Onchain can offer the power of modding combined with the freedom of APIs, plus all of the other benefits of being onchain.

For the question "What's the difference between a mod platform and an API?" the answer for onchain games can be, "Who cares?"

By exposing superior primitives of smart contracts, open data, etc, we enable the market to ship whatever it wants and transcend taxonomies of offchain mods and APIs.

In product economics, combining N capabilities- each known to be valuable in isolation- into a single surface often results in the new whole being greater than the sum of its parts. That may help drive intuition that we can have high expectations for the synthesis of modding, APIs, payments, etc. in onchain games.

For example, if we expose data and algorithms for player guilds, it can be used by the market to make any relevant downstream experience for any set of relevant stakeholders. Examples may include: Dashboards for investors or power users. Admin tools for guild leaders. Secret productivity tools for top guilds. Tools to distribute gear from raids (a popular pain point). A completely separate game that uses the guild's membership roster (teambuilding activity, anyone?).

Of course, these downstream experiences may support arbitrary crypto financial components, such as payments related to the core game or local to the downstream experience, and can be embedded directly into players' main experience (ie game clients) or made available as 3rd-party webpages, apps, data feeds, New York Times Square billboards, etc. Would these qualify as mods? API clients? The answer is "yes".

It seems that onchain capabilities blur the lines between game mods and APIs in the same spirit as modern wallets and account abstraction do so between transactions and actions.

Did I pay somebody or did I upvote a social post? Did I create a video call or did I mint an NFT representing the call as a composable artifact eg. integrable into web3 social? The answer is "yes"- it’s both.

I agree that it's important that users opt-in to mods by choosing which their clients will interpret (rather than an admin deciding for them).

Of course, pushing the choice of active mods to the users helps make it a market. That market, among other things, helps drive superior UX due to competitive pressures (applicable to offchain and onchain games) and emergence due to composability, permissionless innovation, etc (unique or relatively strong for onchain games and not offchain).

An open economy on L2/L3 may be always proximate to defi

On the point of an open economy onchain benefiting from proximity to defi, an area of research I've dabbled in is the concept of a distance metric between any two chains.

How "far away" are two L1s? Any two L2s? Two L3s in the same family?

To the user, all costs are transactions costs, and all benefits are transaction benefits.

It's not about distance "as the crow flies". It's about the user experience.

An advertising executive once joked that instead of spending $1 billion to shorten the train ride into London, they should spend $50M on better wifi and more physically attractive train staff.

As you know, there's ongoing evidence to suggest that, soon enough, a cross/interchain swap may be as simple, quick, easy, and relatively inexpensive as an L1 swap is today for a whale.

If cross-L2 defi operations become "good enough", it may have implications on the practical benefit of colocating a game's open economy with mature defi/liquidity vs in an appchain or other chain.

For example, let's say a chain succeeds in becoming valuable and defensible in hosting open economies for a range of independent games. Whatever makes this chain so ideal for onchain economies, perhaps it ends up having nothing to do with defi or liquidity.

What if more players -> more ticks?

For the open technical problem of ticking, I liked your example of modifying a rollup's state transition function to include a game loop with a time delta since the last tick.

Another area of research may be to vary the number of ticks in proportion to player activity, with ticks having constant or dynamic size.

For example, consider a world where time sped up or slowed down based on the spot popularity of the game. Or time doesn't speed up, but resolution increases.

We can imagine a zk "proof-of-tick worldchain" where anybody can permissionlessly submit the next tick of the world if they are willing to compute it. The worldchain may initially run at 5000 ticks per day during launch hype and, in later years, slow down to 20 ticks per day when only a loyal core of nostalgiacs remain.

Of course, in this example of a PoW worldchain, controlling the number of ticks in the context of hardware performance may require support similar to Bitcoin's difficulty.

Limit incentive-compatibility maximalism by introducing artificial transactions costs

I'd agree that composability is inherently financializing, and that leads to economic efficiency and pushing the system to the limits of its incentive compatibility, which I'll call "incentive-compatibility maximalism".

As to why composability has this effect, a root cause may be that composability reduces transaction costs, and, as Adam Smith explained, (i) transaction costs limit the extent of the market, (ii) the extent of the market limits specialization, and (iii) when specialization increases, we get better, cheaper, and novel goods & services.

In other words, by reducing transaction costs aka net friction, composability helps to increase the size of an onchain game's trade network.

Large trade networks enable the specialization needed to deliver inherent financialization, creating a high state of economic efficiency, which then pushes a game to the limits of its incentive compatibility.

If transaction costs are instead high, inherent financialization may be prevented, and the game often instead stabilizes in a state of economic inefficiency where players et al respond only partially to incentives.

Since reductions in transaction costs drive economic efficiency and incentive-compatibility maximalism, onchain games may look for solutions by introducing artificial transaction costs to intentionally limit the extent of the market in certain directed ways.

You gave an example of permissioning as a transaction cost that can dampen inherent financialization.

Let me explore permissioning and its relationship to the introduction of artificial transaction costs to limit incentive-compatibility maximalism:

Interesting research questions here may include, are all kinds of transaction costs that may be introduced to dampen or cap inherent financialization and economic efficiency necessarily instances of permissioning? What are the root strategies or components available to reduce inherent financialization?

My intuition is, yes, every kind of transaction cost that can be introduced to limit inherent financialization seems likely to be an instance of permissioning and that there's likely a diverse array of orthogonal permissioning primitives.

Examples of permissioning to limit inherent financialization and economic efficiency might include

• using passwords/authentication. Like all passwords, this could be (i) something you are, eg. a level 90+ mage, (ii) something you know, eg. a rotating password discovered in a raid, or (iii) something you have, eg. the Sword of a Thousand Truths.

• using rate limiting, perhaps with sybil resistance. Of course, this could be one operation per identity per time period. Or exotic things such as ten opportunities for the entire game world per period, and maybe one person can claim them all.

• classic allowlists, including autocratic lists run by developers, onchain governance-based lists, or lotteries. There's an interesting intersection with passwords in that, technically, every form of permissioning is an allowlist. We might generate an allowlist of everyone who completed this week's raid, obtained this week's special item, recently met up with at least five players in the city tavern, or ever obtained a specific legendary item.

After constructing the permission, there's a separate question of what to do with it.

You gave examples of controlling who can play the game and who can deploy code to it. These could be thinly sliced with different in-game roles and different privileges for code (eg. access the social system but not combat), etc.

We might control who can transfer in-game assets. Account abstracted transfers to bypass our controls can be mitigated in the usual ways, eg. reductions in property rights such as modified harberger taxes, automatic asset clawbacks when violations are provable (ingame slashing), or by limiting who can acquire the assets in the first place (which might be different than controlling who can play the game).

Crucially, the degree of incentive-compatibility maximalism is shaped by the net practicality of transactions costs.

So, partial permissionings that are not bulletproof may be enough to keep the economy fun.

For example, for years, Path of Exile has adopted ever-decreasing levels of friction for in-game trading but has famously drawn the line at requiring characters to meet synchronously and physically in-game to manually exchange the item in a trade window.

Path of Exile's devs won't allow automated item transfers because they understand this is the minimum transaction cost friction required to make the economy fun. Automated item transfers would create "too much" economic efficiency and spoil the game's pace & exploration.

As another example, Diablo 3's real-money auction house was a fantastic case study of the perils of unexpected economic efficiency.

In less than a month, players speed-ran the entire game and were months ahead of where devs expected.

During this era of Diablo 3, finding your own items was a fool's errand- anything worth using was cheaper on the real money auction house. Why grind for 50 hours when you can pay 30 cents for an amazing item? Why be the worst player in your friend group when the others spent 3 bucks to become godlike?

Opportunities for onchain games to modulate incentive-compatibility maximalism through the introduction of artificial transactions costs seem like an interesting area of research. Especially as it relates to how these problems and tools may differ for successful onchain games vs established patterns in offchain games.

Onchain metagame dynamicism seems tractable

Regarding the stagnation of the metagame, I like your example of research directions of seasonality, automated feedback, and novel governance mechanisms.

The concept of seasonality is deep and multivariate.

Is a new season a new instance of most or all the game, where players restart from ~scratch? Is the new season primarily around meta elements like rewards and leaderboards and/or around physical concepts? Are new seasons mandatory? Can old players somehow opt-out and continue playing old seasons? How might being onchain affect these decisions or opportunities?

It's possible that onchain offers brand-new models for seasonality or dynamicism. For example, due to the onchain capabilities of digital scarcity or zk privacy.

As one example, Augur had a voluntary forking model where users had to make a mutually exclusive choice as to of N destination forks they wanted to opt into.

Maybe players can fork their own playerbases based on seasonal preferences (fire season or water season?), modsets (which of the following randomly drawn subsets of blessed mods will be active next season?), or story-based (did the prince kill the dragon, or did the dragon kill the prince?) And then, unlike Augur, perhaps those forks could reunite at a later time to keep the game's community whole.

What exactly does it mean for a game or world to be immutable? This is a good example of a virtual world topic with deep literature going back decades. Early virtual world designers were well aware that immutability and persistence have a lot of pivot points and structural implications.

We might tend to think of immutability and persistence as being similar concepts, but in an onchain game or world, they're orthogonal.

Immutability is what can be changed, why it can be changed, and by whom.

Persistence is how long it stays changed and why it may revert to some concept of baseline or next generation.

An interesting empirical result from old virtual worlds is that there was a positive correlation between the permissionlessness of mutation and the kinds of mutations that would persist.

That's to say, in old virtual worlds, the more people that could change things (eg. anyone can change things, or only non-newbies, experienced players, trusted players, trained admins, devs, etc), the broader the types of changes tended to persist/survive a reboot/season change/etc (eg. only character changes persist, or also classes of objects, objects in a physical location, the entire world, or functionality/custom algorithms).

It turns out that this correlation was not merely due to the product economics of "the more people you allow to change stuff, the more stuff it makes sense to allow them to change" but rather due to the positioning or value proposition of the games:

Games with limited persistent changes by limited kinds of people tended to be movie-like or prescriptive in their approach to the player experience. "You're playing in our world."

Games with highly persistent changes by many kinds of people tend to be sandbox-like and extremely social in their approach to the player experience. "Our world is what you make of it."

Whether or not this historical correlation may continue to hold with onchain games seems like an interesting area of research.

Maybe an immutable game is playable exactly once (by anybody) and then never again- a kind of one-shot singleton, like the recent Magic the Gathering Lord of the Rings global singleton physical card, The One Ring. The "game" for this card was to find the card. (Post Malone bought it for $2m.)

Maybe a game is playable as many times as any number of people want but not open for modification or extension by anyone. Such games have done very well offchain, like Tetris. Or, consider how many people would continue playing League of Legends or dota for years even if they stopped patching it. Can similar games do well onchain?

In short, immutability and persistence and their relationship to metagame stagnation and onchain game opportunities seem like a rich design space and area of research.

Turning now to metagame stagnation-

Crucially, metagame equilibrium is a function of net opportunity costs across the entire game or, in a sufficiently connected system, even a network of games.

Often, all that may be needed to refresh the metagame is to add new content that disrupts the balance of opportunity costs without a requirement to modify old content.

Note that a game open for extension with data only can still receive new code via the reification of algorithms into data. It's a popular pattern in web2 game engines, especially to enable higher-level creator tools.

You gave the example of automated feedback to help refresh the metagame. Of course, automated feedback may come in countless varieties.

Two forms of automated feedback that, personally, are particularly interesting to me are

(i) The next season of the game being modified by or based on the winners and losers of the previous season.

For example, maybe the most successful players in the previous season become the next season's raid bosses. In that case, popular builds of the previous season determine the challenges of the next season.

(ii) Genetic algorithms that modify the game's physics, data, rules, power levels, assets, etc. across seasons, including classic components of semi-predictable hereditary traits plus random mutations.

Perhaps mutations could be oraclized or crowdsourced. Imagine a zk ML+data pipeline that submits seasonal mutations that are provable transformations on model outputs of private prompts written by players.

For example, as a power player interested in helping to formulate the next season, I might open up the downloadable management app for a game, where I type my prompts to suggest inputs to procedural raid boss generation ("a boss where player spells frequently reflect back to the players"), or economic circumstances ("a supervolcano emerges in the middle of the Andaryl Plains, causing a massive disaster and a worldwide shortage of grain"), or any other kind of procedural input into the game's domain.

How may tried-and-true gamer motivations apply onchain?

The Hero's Journey (from The Hero With a Thousand Faces) and fundamental motivations of gamers are important concepts that crosscut highest-level questions, such as why to put games onchain at all, why financialization may be an enabler or detractor of fun, and or why open economies may or may not drive a game's success.

There's much empirical and theoretical evidence to support the thesis that what players often want is to redo the Hero's Journey from scratch in every game, and therefore, the ability to eg. transfer their powerful items from an old game to a new game could often be value destructive to the experience.

Does that mean that onchain games must be relegated to only the subset of motivations unrelated to the hero's journey, such as rivalry, speculation, and socialization? It seems like an interesting area of research.

Nick Yee famously did years of research into gamer motivations. First, through a series of studies with players in a live mmorpg. Later in his gamer motivation company.

Raph Koster knows more about virtual worlds and players' motivations to inhabit them than anyone else in the world.

Both Nick and Raph would be interesting research partners. But what questions would you ask them? How do we communicate effectively between the domains of web3 and classic gaming/virtual worlds?

Virtual worlds are places more than they are games

A doctrine accepted by veteran virtual world builders is that these worlds are first and foremost places long before they are games.

Depending on which veterans you ask, they may argue that these places benefit from governance, require governance, or come along with a moral obligation for their creators to govern them.

To these veteran virtual world builders, it's obvious that the differences between Facebook and Twitter and World of Warcraft are immaterial compared to the similarity that they are places for humans that require some concept of governance.

Veteran virtual world builders would conjugate the word "governance" in a broad and paternalistic sense, like "the US government", and not in a narrow, functional sense, like typical defi governance.

The reason that "virtual worlds are places before they are games" is an important concept is because it motivates the success of the game and entertainment product by providing a high-level general principle:

If you're building a world, then your game is effectively something people opt into after they're already enjoying simply existing in your world, and therefore, you should make sure your place is nice to inhabit before you worry about making your game fun. How might onchain games learn from this timeless principle or even turn it on its head?

For example, perhaps an important segment of onchain games ends up being better characterized as "activities within the world of the internet". These games may be deeply embedded or easily accessible from other web experiences, like hyperlinks, ordinary web pages, social media bots, etc.

Maybe the internet's social layer ends up successfully providing "exogenous governance" such that onchain games and worlds require net less governance or management vs offchain.

Maybe one path to success for onchain games is to rely on traditional social platforms for messaging and the graph of player connections. Not just for viral growth but for core game loops. Obviously, onchain capabilities such as open data, permissionlessness, embeddability, etc, might drive this.

In short, how may being onchain affect a game or world being a place before it's a game? What about governance opportunities or obligations? Social features? Blurring the lines between worlds, games, and the internet? These seem like interesting areas of research.