Paradigm's thoughts on open issues in blockchain gaming: player experience over technical details
TechFlow Selected TechFlow Selected
Paradigm's thoughts on open issues in blockchain gaming: player experience over technical details
For users, all costs are transaction costs, and all gains are transaction gains.
Navigating Web3 tides with focused insightsWritten by: Ryan Berckmans
Compiled by: TechFlow
Paradigm recently published an article on open problems in on-chain gaming. I worked on game and virtual world development prior to Ethereum and wanted to share some thoughts in response to Charlie and Doug’s piece. In what follows, “you” refers to Paradigm.
Four Fundamental Types of On-Chain Game Chains
There appear to be four fundamental types of blockchains, though one may be purely theoretical:
(Public, Private) × (Centralized, Decentralized)
-
Centralized public chains such as BSC. Depending on who you ask, this may or may not include Solana.
-
Public decentralized chains such as Ethereum or sufficiently mature L2s.
-
Private centralized chains such as federated chains running within a consortium's VPN. Or zk L2s on Ethereum that keep data off-chain and restrict participant lists but settle on Ethereum.
-
Private decentralized chains are an interesting concept, possibly purely theoretical. Monero? Encrypted EVM?
These chain types provide a lens through which we can explore the potential of pure on-chain games:
-
Why put a game on a private, centralized blockchain? What capabilities does base-layer blockchain architecture offer that might be unrelated to publicity or decentralization? For example, for a closed, centralized game, perhaps the EVM architecture, infrastructure, and tooling could provide a platform with superior functionality or cheaper operational costs compared to existing solutions.
-
Why put a game on a public, centralized blockchain? What benefits do public chains have over private ones? Are there cases where decentralization becomes a drawback and centralization is preferred?
-
Why put a game on a public, decentralized blockchain? What advantages emerge when starting from a public chain and then adding extremely strong property rights, resistance to censorship, and expectations of permanent existence?
To what extent are reasons for putting games on blockchains due to core blockchain technological capabilities rather than the chain's publicity or decentralization? This seems like an interesting research area.
Is It a Mod or an API?
I agree with your point that mods are a great example of how on-chain games can become 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 inside the game.
Compared to Web2 mod platforms, on-chain games can offer better structural separation—and thus composability—of data, assets, core algorithms, identity, etc., creating opportunities for arbitrary downstream architectures, integrations, and experiences.
Of course, Web2 game APIs already provide "downstream freedom," such as the extensive third-party tools available for EVE Online and League of Legends.
So, what’s the difference between a mod platform and an API?
Certainly, in Web2 games, APIs are typically separate products decoupled from core data, so technically they often differ from the underlying engine in both data and reduced functionality.
On-chain games can deliver both mod functionality and API-like freedom, along with all other benefits of being on-chain.
For the question “What’s the difference between a mod platform and an API?” the answer for on-chain games might simply be “Who cares?”
By providing superior foundational building blocks—public smart contracts, open data, etc.—we enable the market to deliver whatever it wants, transcending traditional classifications of off-chain mods and APIs.
In product economics, combining N capabilities (each valuable independently) into one surface often makes the whole greater than the sum of its parts. This intuition may help explain our high hopes for the synthesis of mods, APIs, payments, etc., in on-chain games.
For example, if we make player guild data and algorithms public, the market can leverage them to provide relevant downstream experiences for any interested stakeholders. Examples include dashboards for investors or power users, management tools for guild leaders, secret productivity tools for top-tier guilds, loot distribution tools (a common pain point), or entirely independent games using the guild member list (team-building activities).
Of course, these downstream experiences could support arbitrary crypto-financial components—payments related to the core game or native to the downstream experience—and could be embedded directly into the player’s primary experience (i.e., the game client) or delivered via third-party websites, apps, data feeds, Times Square billboards, etc. Do these qualify as mods? API clients? The answer is “Yes.”
It appears on-chain capabilities blur the line between game mods and APIs, much like modern wallets and account abstraction blur the line between transactions and operations.
Am I paying someone or voting on a social post? Am I initiating a video call or minting an NFT representing that call as composable art integrable into Web3 social? The answer is “Yes”—both.
I agree with the importance of users choosing to opt into mods by selecting their client interpretation (rather than administrators deciding for them).
Of course, giving users control over active mods helps form a market. This market, among other things, drives superior user experiences through competitive pressures (applicable to both on-chain and off-chain games) and the emergence of combinatorial, permissionless innovation—unique or relatively powerful for on-chain games, less so for off-chain ones.
Open Economies on L2/L3 May Always Be Close to DeFi
Regarding the idea that on-chain open economies benefit from proximity to DeFi, one research area I’ve explored is the concept of distance metrics between any two chains.
How far apart are two L1s? Any two L2s? Two L3s within the same family?
For users, all costs are transaction costs, and all gains are transaction gains.
This isn’t about straight-line distance—it’s about user experience.
An advertiser once joked they shouldn’t spend $1 billion shortening train travel time to London, but instead spend $50 million providing better WiFi and more engaging staff on the train.
As you know, there’s ongoing evidence that soon, cross-chain or inter-chain swaps may become as simple, fast, easy, and relatively cheap as today’s L1 swaps.
If DeFi operations across L2s become “good enough,” this could impact the practical benefits of integrating a game’s open economy with mature DeFi/liquidity rather than placing it on an app-specific chain or another isolated chain.
For example, suppose a certain chain successfully becomes a valuable, moated platform hosting open economies for a suite of independent games. The factors making this chain ideal for on-chain economies may have nothing to do with DeFi or liquidity.
What If More Players Mean More Ticks?
Regarding the technical open problem of Ticks, I appreciate your suggestion of modifying the rollup’s state transition function to include a time-delta game loop since the last Tick.
(TechFlow note: Tick refers to the number of server frames per second delay.)
Another research direction might involve varying the number of Ticks based on player activity, with Tick size being constant or dynamic.
For instance, consider a world where time speeds up or slows down depending on the game’s popularity. Or time doesn’t speed up, but resolution increases.
We could imagine a zero-knowledge proof-based “Tick World Chain,” where anyone can permissionlessly submit the next Tick of the world as long as they’re willing to compute it. In early stages, the world chain might run 5,000 Ticks per day, slowing to just 20 Ticks per day years later when only a loyal group of nostalgic players remain.
Of course, in this PoW world chain example, managing the relationship between Tick volume and hardware performance might require something like Bitcoin’s difficulty adjustment.
Limiting Incentive Compatibility Maximization by Introducing Artificial Transaction Costs
I agree that composability is inherently financializing, leading to increased economic efficiency and pushing systems toward the limits of incentive compatibility—a phenomenon I call “incentive compatibility maximization.”
As to why composability produces this effect, a 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 get better, cheaper, and novel goods and services.
In other words, by reducing transaction costs—friction—composability helps expand the scale of the transaction network in on-chain games.
A large-scale transaction network enables specialization, enabling inherent financialization, creating high economic efficiency, thereby pushing the game toward its incentive-compatibility extreme.
Conversely, if transaction costs are high, inherent financialization may be hindered, causing the game to stabilize in economically inefficient states where players only partially respond to incentives.
Since lowering transaction costs pushes toward economic efficiency and incentive-compatibility extremism, on-chain games could intentionally introduce artificial transaction costs to limit market scope and find solutions.
You gave the example of permissions acting as transaction costs that can suppress inherent financialization.
Let me explore permission controls and their relationship to introducing artificial transaction costs to limit incentive compatibility maximization:
Interesting research questions might include: Are all possible transaction costs introduced to weaken or limit inherent financialization merely instances of permission control? What are the fundamental strategies or components for reducing inherent financialization?
My intuition is yes—any transaction cost introduced to limit inherent financialization seems likely to be a form of permission control, and there may exist diverse orthogonal permission control primitives.
Examples of permission controls that limit inherent financialization and economic efficiency might include:
-
Use of passwords/authentication. Like all passwords, this can be (i) what you are, e.g., a level 90+ mage; (ii) what you know, e.g., a code discovered in a dungeon; or (iii) what you have, e.g., the Jian Mo sword.
-
Rate limiting. This could be one operation per identity per time period. Or, say, ten opportunities total across the entire game world per cycle, perhaps all claimable by one person.
-
Whitelisting, including authoritarian whitelists run by developers, on-chain governance-based whitelists, or lotteries. There’s an interesting intersection with passwords—technically, every form of permission control is a whitelist. We could generate a whitelist listing everyone who completed this week’s team raid, obtained this week’s special item, met at least five players recently in the city tavern, or once held a specific legendary item.
After constructing permissions, there’s a separate question of how to handle them.
You mentioned controlling who can play the game and who can deploy code. These can be further broken down by different player roles and varying code privileges (e.g., access to social systems but not combat).
We can control who can transfer in-game assets. Account abstraction transfers that bypass our controls can be mitigated in general ways—for example, reducing property rights through modified taxes, automatic asset recovery upon provable violations (in-game penalties), or restricting who can initially acquire assets (which may differ from who can play the game).
The key point is that the degree of incentive compatibility maximization depends on the practical feasibility of transaction costs.
Therefore, incomplete permission controls may suffice to keep the economy interesting.
For example, over the years, Path of Exile steadily reduced friction in in-game trading, yet famously required characters to physically meet in-game to manually exchange items in the trade window.
Path of Exile’s developers disallowed automated item transfers because they understood that minimal transaction cost friction was necessary to keep the economy engaging. Automated transfers would create “too much” economic efficiency, disrupting the game’s pacing and exploration.
Another example is Diablo III’s real-money auction house—an excellent case study on the dangers of unintended economic efficiency.
Within less than a month, players rapidly cleared the entire game—months faster than developers anticipated.
During this era of Diablo III, farming items yourself was foolish—anything worthwhile was cheaper on the auction house. Why spend 50 hours grinding gear when you can buy a great item for 30 cents? Why remain the worst player in your friend group when others can spend $3 to become invincible?
The opportunity to regulate incentive compatibility maximization by introducing artificial transaction costs seems like a fascinating research area—especially in relation to differences between established patterns in successful on-chain and offline games regarding problems and tools.
On-Chain Meta-Game Dynamism Seems Easily Manageable
Regarding the issue of meta-game stagnation, I appreciate your suggested research directions involving seasonality, automated feedback, and novel governance mechanisms.
The concept of seasonality is deep and multifaceted.
Does a new season mean a fresh instance of most or all game content, with players restarting from zero? Is a new season primarily about rewards and leaderboards, or physical concepts? Is a new season mandatory? Can veteran players opt out and continue playing the old season? How would being on-chain affect these decisions or possibilities?
On-chain may enable new seasonal or dynamic models—for example, leveraging digital scarcity or zero-knowledge privacy capabilities.
Take Augur, for example, which uses a voluntary fork model where users must make mutually exclusive choices among N target forks.
Perhaps players could fork their own player groups based on seasonal preferences (fire season vs. water season?), mod sets (which randomly selected subset of mods will activate next season?), or narrative outcomes (did the prince kill the dragon, or did the dragon kill the prince?). Then, unlike Augur, these forks might later re-merge to preserve community integrity.
What exactly does immutability mean for a game or world? This is a rich theme in virtual worlds, with deep literature going back decades. Early virtual world designers were well aware of the critical points and structural implications of immutability and persistence.
We might tend to view immutability and persistence as similar concepts, but in on-chain 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 changes endure and whether or why a return to some baseline or next generation might occur.
An interesting empirical finding from older virtual worlds is a positive correlation between permissionless mutability and the types of mutations that persist.
That is, in older virtual worlds, the more people able to change things (e.g., anyone, only non-newbies, experienced players, trusted players, trained moderators, developers), the wider the range of persistent changes (e.g., only character changes persist, or also object categories, objects in physical locations, entire worlds, or functional/custom algorithms).
It turns out this correlation isn't merely due to product economics ("allow more people to change things, and more things can be changed"), but stems from the game's positioning or value proposition:
Games allowing only a few to make limited-persistence changes often treat player experience in a cinematic or prescriptive way. “You’re playing our world.”
Games allowing many to make highly persistent changes are often sandbox-style and highly social in player experience. “Our world is created by you.”
Whether this historical correlation will persist in on-chain games seems like an interesting research area.
Perhaps a game can be played repeatedly by any number of people but cannot be modified or extended by anyone. Such games perform exceptionally well off-chain—Tetris, for example. Or imagine how many people would still play League of Legends or Dota even if updates stopped. Could similar games succeed on-chain?
In short, immutability and persistence—and their relationship to meta-game stagnation and on-chain game opportunities—seem like a rich design space and research field.
Now turning to the issue of meta-game stagnation:
The key is that meta-game equilibrium is a function of net opportunity cost across the entire game—or even across a sufficiently connected system or network of games.
Usually, refreshing the meta-game only requires adding new content that breaks the opportunity cost balance—without modifying old content.
Note that a game accepting only data extensions can still receive new code by embodying algorithms as data. This is a popular pattern in Web2 game engines, especially to enable advanced creator tools.
You mentioned automated feedback to help refresh the meta-game. Of course, automated feedback can take countless forms.
Personally, I’m particularly interested in two forms of automated 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 players from the last season become team leaders in the next season. In this case, popular builds from the last season determine challenges in the next season.
(ii) Genetic algorithms modify the game’s physics, data, rules, ability levels, assets, etc., between seasons—including classic components of semi-predictable genetic traits and random mutations.
Perhaps mutations could be oracle-driven or crowdsourced. Imagine a zero-knowledge machine learning + data pipeline submitting seasonal mutations—provable transformations output by private prompt models written by players.
For example, as an advanced player interested in shaping the next season, I might open the game’s downloadable admin app and input prompts suggesting procedural inputs for boss generation (“a boss that frequently reflects player spells back at them”), economic environments (“a supervolcano erupts in the center of the plains, triggering a catastrophe and global food shortage”), or any other type of game domain.
Classic Player Motivations: How Do They Apply to Blockchain Games?
The Hero’s Journey from “The Hero with a Thousand Faces” and fundamental gamer motivations are important concepts that cut across some of the highest-level questions—such as why put games on-chain, why financialization might enhance or undermine fun, and whether open economies will or won’t drive game success.
There’s abundant experiential and theoretical evidence supporting the argument that players generally want to re-experience the hero’s journey in each game—thus, for example, the ability to transfer powerful items earned in old games into new ones tends to undermine the value of the gameplay experience.
Does this mean on-chain games must be limited to a subset of motivations unrelated to the hero’s journey—such as competition, speculation, and social interaction? This seems like an interesting research area.
Nick Yee conducted years of research on gamer motivations—first through a series of studies with players in online MMORPGs, later through his Gamer Motivation company.
Raph Koster understands motivations for living in virtual worlds better than anyone else on Earth.
Both Nick and Raph would be fascinating research collaborators. But what questions would you ask them? How can we effectively communicate between Web3 and classic games/virtual worlds?
Virtual Worlds Are Places, Not Just Games
An axiom embraced by seasoned virtual world builders is that these worlds are first and foremost places—not just games.
For these experienced creators, the differences between Facebook, Twitter, and World of Warcraft are trivial compared to the fact that they are all places offering humans some notion of governance.
Experienced virtual world builders use the term “governance” broadly—like “the U.S. government”—not narrowly or functionally as in DeFi governance.
This important concept—that virtual worlds are places before they are games—is significant because it offers a high-level, general principle for driving success in games and entertainment products:
If you're building a world, then your game is actually something people choose to engage with after enjoying simply existing in your world. Therefore, before worrying about making your game fun, you should ensure your place is livable. How can on-chain games learn from—or even overturn—this timeless principle?
For example, perhaps a significant part of on-chain games ultimately fits better as “activities within internet worlds.” These games could be deeply embedded or easily accessible from other web experiences—hyperlinks, regular web pages, social media bots, etc.
Perhaps the internet’s social layer could eventually succeed in providing “external governance,” allowing on-chain games and worlds to require less governance or administration than their off-chain counterparts.
Perhaps one path to on-chain game success is relying on traditional social platforms for messaging and player connection graphs—not just for viral growth, but for core gameplay loops. Clearly, on-chain capabilities like open data, permissionlessness, embeddability, etc., may drive this.
In short, how does being on-chain affect games or worlds? Governance opportunities or obligations? Social features? Blurring boundaries between worlds, games, and the internet? These seem like fascinating research areas.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@ryanberckmans
