Ethereum developer responds in detail to Paradigm's concerns about on-chain gaming: player experience outweighs technical details

Written by: Ryan Berckmans (Ethereum Developer)

Compiled by: Deep Tide TechFlow

Original Title: “Thoughts on Paradigm's Open Problems of Onchain Games”

Paradigm recently published “Paradigm's Latest Research: Unique Value and Development Trends of Onchain Games”, and having previously worked in game and virtual world development before Ethereum, I would like to share some thoughts in response to Charlie and Doug's article. In the following text, "you" refers to Paradigm.

Four Basic Types of Onchain Games

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

(public, private) x (centralized, decentralized)

• Centralized public chains like BSC. Depending on who you ask, this may or may not include Solana.

• Public decentralized chains like Ethereum or sufficiently late-stage L2s.

• Private centralized chains like federated chains running in industry organization VPNs. Or Ethereum zk L2s that keep data off-chain and restrict participant lists but settle on Ethereum.

• Private decentralized chains are an interesting concept and may be purely theoretical. Monero? Encrypted EVM?

These types of chains provide us with a perspective through which we can explore the potential of purely onchain games:

1. Why put games on private, centralized blockchains? What functionalities can baseline blockchain architectures provide that may not relate to openness or decentralization? For example, for a closed, centralized game, perhaps the EVM architecture, infrastructure, and tools could offer a platform with superior features or lower operational costs compared to existing solutions.

2. Why put games on public, centralized blockchains? What are the benefits of public chains compared to private chains? Are there situations where decentralization could be a disadvantage and centralization is preferred?

3. Why put games on public, decentralized blockchains? What benefits arise when you start from a public chain and then add the extremely powerful property rights, resistance to censorship, and the expectation that the chain will exist forever?

To what extent is the reason for putting games on blockchains due to the capabilities of core blockchain technology rather than the openness or decentralization of the chain? This seems to be an interesting area of research.

Is This a Mod or an API?

I think you are right that a Mod is a great example of how onchain games can be competitive. Typically, the problem with Web2 Mod platforms is that the Mod execution environment is internal to the game environment. That is, no matter how cool your Mod is, it usually has to run within the game.

Compared to Web2 Mod platforms, onchain games can offer better separation of structures like data, assets, core algorithms, identities, etc. (and the composability of the former), creating opportunities for arbitrary downstream architectures, integrations, and experiences.

Of course, Web2 game APIs have already provided "downstream freedom," such as extensive third-party tools for EVE and League of Legends.

So, what is the difference between a Mod platform and an API?

Of course, in Web2 games, APIs are typically separate products that are decoupled from core data, thus technically having different data and functionality reductions from the underlying engine.

Onchain games can provide the functionality of Mods and the freedom of APIs, along with all the other benefits of being onchain.

For the question "What is the difference between Mod platforms and APIs?" in the context of onchain games, the answer may be "Who cares?"

By providing superior foundational building blocks like open smart contracts and open data, we enable the market to offer anything it wants and transcend the taxonomy of offchain Mods and APIs.

In product economics, combining N capabilities (each of which has value in isolation) into one surface often results in the whole being greater than the sum of its parts. This may help inspire our high expectations for the integration of Mods, APIs, payments, etc., in onchain games.

For example, if we make player guild data and algorithms public, the market can leverage this data and algorithms to provide relevant downstream experiences for any stakeholders. For instance: dashboards for investors or power users, management tools for guild leaders, secret productivity tools for top guilds, tools for distributing team loot (a common pain point), and completely independent games using guild member lists (team-building activities).

Of course, these downstream experiences could support arbitrary crypto-financial components, such as payments related to core games or natively related to downstream experiences, and could be directly embedded into players' primary experiences (i.e., game clients) or provided as third-party web pages, applications, data sources, New York Times Square billboards, etc. Do these fit the definition of a Mod? An API client? The answer is "yes."

It seems that onchain capabilities blur the lines between game mods and APIs, just as modern wallets and account abstraction blur the lines between transactions and operations.

Am I paying someone, or am I voting on a social post? Did I create a video call, or did I mint an NFT representing the call as a composable piece of art that can be integrated into Web3 social? The answer is "yes"—both.

I agree that users choose to join Mods by selecting how their clients interpret them (rather than having decisions made for them by administrators).

Of course, giving users the choice of active mods helps form a market. This market, among other things, drives excellent user experiences through competitive pressure (applicable to both onchain and offchain games) and the emergence of composability, permissionless innovation, etc. (which is unique or relatively strong for onchain games, but not for offchain games).

The Open Economy on L2/L3 May Always Be Close to DeFi

Regarding the idea that the onchain open economy benefits from being close to DeFi, one area of research I am exploring is the concept of distance metrics between any two chains.

How far apart are two L1s? Any two L2s? Two L3s from the same family?

For users, all costs are transaction costs, and all benefits are transaction benefits.

This does not refer to linear distance but to user experience.

An advertiser once joked that they shouldn't spend $1 billion to shorten the train travel time to London but should spend $50 million to provide better WiFi and more attractive train staff.

As you know, there is ongoing evidence that soon, cross-chain/inter-chain exchanges may become as simple, fast, easy, and relatively inexpensive as L1 exchanges conducted today.

If DeFi operations across L2s become "good enough," this could impact the practical benefits of combining the open economy of games with mature DeFi/liquidity, rather than placing them on application chains or other chains.

For example, suppose a certain chain successfully becomes a valuable and defensible chain hosting a series of independent game open economies. The factors that make this chain so ideal for onchain economies may have little to do with DeFi or liquidity.

What If More Players Mean More Ticks?

Regarding the technical open question of Ticks, I like your mention of modifying the Rollup state transition function to include a game loop based on the time elapsed since the last Ticks.

(Note: tick refers to the number of frames per second of server latency)

Another area of research might be to change the number of Ticks based on player activity, where the size of Ticks could be constant or dynamic.

For example, consider a world where time speeds up or slows down based on the game's popularity. Or time does not speed up, but the resolution increases.

We can imagine a zero-knowledge proof "Ticks World Chain," where anyone can submit the next Ticks of the world without permission, as long as they are willing to compute. In the early launch phase, the world chain might run 5,000 Ticks a day, while in later years, when only a loyal group of nostalgic players remains, the speed might slow down to 20 Ticks a day.

Of course, in this PoW world chain example, the relationship between the amount of Ticks and hardware performance may require support similar to Bitcoin's difficulty adjustment.

Limiting Incentive Compatibility Maximization by Introducing Artificial Transaction Costs

I agree that composability is inherently financialized, leading to increased economic efficiency and pushing systems toward their limits of incentive compatibility, which I refer to as "maximization of incentive compatibility."

As for why composability produces this effect, one fundamental reason may be that composability reduces transaction costs, as Adam Smith explained: (i) transaction costs limit the scope of markets, (ii) the scope of markets limits specialization, and (iii) as specialization increases, we obtain better, cheaper, and novel goods and services.

In other words, by reducing transaction costs, that is, reducing friction, composability helps increase the scale of transaction networks in onchain games.

Large-scale transaction networks enable specialization, leading to intrinsic financialization, creating high economic efficiency, and pushing games to their limits of incentive compatibility.

If transaction costs are conversely very high, intrinsic financialization may be hindered, and games often stabilize in a state of economic inefficiency, where players only partially respond to incentives.

Due to the extreme nature of reducing transaction costs driving economic efficiency and incentive compatibility, onchain games can intentionally limit market scope by introducing artificial transaction costs in search of solutions.

You provided an example of using permission as a transaction cost that can suppress inherent financialization.

Let me explore permission control and its relationship with introducing artificial transaction costs to limit incentive compatibility maximization:

Interesting research questions may include whether all possible transaction costs introduced to weaken or limit intrinsic financialization and economic efficiency are instances of permission control? What fundamental strategies or components can be used to reduce intrinsic financialization?

My intuition is that yes, any transaction cost that can be introduced to limit intrinsic financialization seems to be an instance of permission control, and there may be diverse orthogonal permission control primitives.

Examples of permission control that limit intrinsic financialization and economic efficiency may include:

• Using passwords/authentication. Like all passwords, this can be (i) what you are, such as a level 90+ mage, (ii) what you know, such as a password discovered in a dungeon, or (iii) what you have, like a specific item.

• Using rate limiting. Of course, this could be one action per identity per time period. Or perhaps ten opportunities for the entire game world within each cycle, which one person can claim all.

• Whitelisting, including authoritarian whitelists run by developers, on-chain governance-based whitelists, or lotteries. There is an interesting intersection with passwords, as technically, every form of permission control is a whitelist. We could generate a whitelist listing everyone who completed a team battle this week, obtained a special item this week, recently met with at least five players in a city tavern, or has ever obtained a specific legendary item.

After building permissions, there is a separate question of how to handle them.

You mentioned controlling who can play the game and who can deploy code. These can be segmented through different game roles and different privileges of the code (e.g., access to social systems but not combat).

We can control who can transfer in-game assets. This can be mitigated in general ways to reduce the transfer of accounts we control, such as reducing property rights, like modified taxes, automatically reclaiming assets in cases of provable violations (in-game penalties), or by restricting who can initially acquire assets (which may differ from controlling who can play the game).

The key is that the degree of maximization of incentive compatibility depends on the actual feasibility of transaction costs.

Thus, imperfect permission control may be sufficient to keep the economy interesting.

For example, over the years, Path of Exile has continually reduced the friction of in-game trading, but it is well known that it requires characters to physically meet in-game to manually exchange items during trading windows.

The developers of Path of Exile do not allow automatic item transfers because they understand that this is the minimum transaction cost friction required to make the economy interesting. Automatic item transfers would create "excessive" economic efficiency, disrupting the game's pacing and exploration.

Another example is the real-money auction house in Diablo 3, which serves as a good case study of the dangers of unintended economic efficiency.

In less than a month, players quickly completed the entire game, months faster than the developers had anticipated.

In the era of Diablo 3, finding items yourself was a foolish endeavor—anything worth using was cheaper on the auction house. Why spend 50 hours grinding for gear when you could buy a great item for 30 cents? Why be the worst player in your friend group when others could become invincible for just $3?

The opportunity to regulate the maximization of incentive compatibility by introducing artificial transaction costs seems to be an interesting area of research, particularly regarding the differences in questions and tools between successful onchain games and established patterns in offline games.

Onchain Metagame Dynamism Seems Easy to Handle

Regarding the issue of metagame stagnation, I appreciate your mention of seasonal, automatic feedback, and new governance mechanisms as research directions.

The concept of seasonality is profound and multifaceted.

Is a new season an instance where most or all of the game resets, and players start from scratch? Is the new season primarily centered around rewards and leaderboards, or is it based on physical concepts? Is the new season mandatory? Can old players opt out and continue playing the old season? How would the onchain implications affect these decisions or opportunities?

Onchain may provide new seasonality or dynamism models. For example, due to digital scarcity or zero-knowledge privacy capabilities.

Taking Augur as an example, it employs a voluntary forking model where users must make mutually exclusive choices among N target forks.

Perhaps players can fork their own player communities based on seasonal preferences (fire season or water season?), Mod collections (which random subset of Mods will be activated in the next season?), or storylines (did the prince kill the dragon, or did the dragon kill the prince?). Then, unlike Augur, these forks could perhaps merge again later to maintain the integrity of the game community.

What does immutability mean for a game or world? This is a great example of a virtual world theme, with a rich literature dating back decades. Early virtual world designers were well aware that immutability and persistence have many critical points and structural implications.

We may tend to view immutability and persistence as similar concepts, but in onchain games or worlds, they are orthogonal.

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

Persistence is about how long content remains changed and the concept of why it may revert to some baseline or next generation.

An interesting empirical result from old virtual worlds is that there is a positive correlation between the permissiveness of mutations and the types of mutations that persist.

That is, in old virtual worlds, the more people who can change things (e.g., anyone can change things, or only non-newbie, experienced players, trusted players, trained administrators, developers, etc.), the broader the types of changes that persist (e.g., do only character changes persist, or do object categories, objects in physical locations, entire worlds, or functional/custom algorithms also persist).

It turns out that this correlation is not just due to product economics (i.e., "the more people allowed to change things, the more things can be changed") but also due to the positioning or value proposition of the game:

Games that only allow a few people to make limited persistent changes tend to handle player experiences in a more cinematic or prescriptive manner. "You are playing our world."

Games with highly persistent changes made by many people tend to be sandbox-like and have a very high social aspect in player experiences. "Our world is created by you."

Whether this historical correlation will continue to exist in onchain games seems to be an interesting area of research.

Perhaps a game can be played multiple times by any number of people but cannot be modified or expanded by anyone. Such games perform exceptionally well offchain, like Tetris. Or imagine how many people would continue to play League of Legends or Dota even if updates stopped. Can similar games succeed onchain?

In short, the relationship between immutability and persistence and their connection to metagame stagnation and opportunities in onchain games seems to be a rich design space and area of research.

Now turning to the issue of metagame stagnation:

The key is that the metagame equilibrium is a function of the net present value of opportunity costs of the entire game or within sufficiently connected systems, even the game network.

Typically, refreshing the metagame only requires adding new content that breaks the opportunity cost balance without modifying old content.

Note that a game that only accepts data extensions can still receive new code by embodying algorithms as data. This is a popular pattern in Web2 game engines, especially for enabling more advanced creator tools.

You mentioned automatic feedback to help refresh the metagame. Of course, automatic feedback can take countless forms.

Personally, I am particularly interested in two forms of automatic feedback:

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

For example, perhaps the most successful player from the last season becomes the team leader for the next season. In this case, the popular builds from the previous season determine the challenges for the next season.

(ii) Genetic algorithms modify the physical properties, data, rules, ability levels, assets, etc., of the game between seasons, including semi-predictable genetic traits and classic components of random mutations.

Perhaps mutations can be prophesized or crowdsourced. Imagine a zero-knowledge machine learning + data pipeline that submits seasonal mutations, which are provably transformed outputs from player-written private prompt models.

For example, as a high-level player interested in helping shape the next season, I might open a downloadable management app for the game, where I input prompts to suggest inputs for boss generation in dungeons ("a boss that frequently reflects players' spells back at them"), economic environments ("a supervolcano appears in the center of the plains, triggering a catastrophe and global food shortage"), or any other type of procedural input for the game realm.

Classic Motivations of Game Players and How They Apply to Blockchain Games

The hero's journey in The Hero with a Thousand Faces and the fundamental motivations of game players are important concepts that permeate some of the highest-level questions, such as why to put games onchain, why financialization may enhance or detract from fun, and why open economies may or may not drive the success of games.

There is much empirical and theoretical evidence supporting the argument that players often wish to re-experience the hero's journey in each game; thus, for example, the ability to transfer powerful items obtained in old games to new games often undermines the value of the gaming experience.

Does this mean that onchain games must be limited to a subset of motivations unrelated to the hero's journey, such as competition, speculation, and socializing? This seems to be an interesting area of research.

Nick Yee has conducted years of research on player motivations. Initially, through a series of studies with players in online massively multiplayer role-playing games (MMORPGs). Later, he conducted research at his player motivation company.

Raph Koster knows more about the motivations of players living in virtual worlds 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 effectively communicate between Web3 and classic games/virtual worlds?

Virtual Worlds as Places, Not Just Games

The creed accepted by experienced virtual world builders is that these worlds are primarily places, not just games.

For these experienced virtual world builders, the differences between Facebook, Twitter, and World of Warcraft are trivial compared to the fact that they all provide some governance concepts for humanity.

Experienced virtual world builders will use the term "governance" broadly, much like "the U.S. government," rather than in the narrow, functional sense of DeFi governance.

The important concept that "virtual worlds are places before they are games" is significant because it drives the success of games and entertainment products by providing a high-level general principle:

If you are building a world, then your game is actually something people choose to join after enjoying simply existing in your world; therefore, before worrying about making your game fun, you should ensure that your place is livable. How can onchain games learn from this eternal principle, or even subvert it?

For example, perhaps a significant part of onchain games is ultimately better described as "activities within the internet world." These games can be deeply embedded in or easily accessed from other network experiences, such as hyperlinks, ordinary web pages, social media bots, etc.

Perhaps the social layer of the internet will ultimately succeed in providing "external governance," allowing onchain games and worlds to require less governance or management compared to offchain.

Perhaps one path to success for onchain games is to rely on traditional social platforms for messaging and player connection. Not just for viral growth but for the core game loop. Clearly, onchain capabilities like open data, permissionless, and embeddable may drive this.

In short, how does onchain impact games or worlds? What about governance opportunities or obligations? Social functions? Blurring the lines between worlds, games, and the internet? These seem to be interesting areas of research.