This is an idea I’ve been pondering for half a year, and I decided to organize it during the Chinese New Year. I want to express my gratitude to all my friends who have discussed game design and full-chain technology with me. While I may have contradicted some of my previously held beliefs here, I will continue to seek knowledge and understanding.
Through this article, I aim to argue one point:
I believe that fully blockchain-based games based on physical rules are not meaningful.
Let’s go back two or three months.
At that time, I was designing a full-chain game, trying to distinguish what sets apart all the games called “sandbox” or “open world.” I researched products including Minecraft, Roblox, Dwarf Fortress, and Screep: World. I have always believed that humanity has been misled by the names we invent. In fact, these games collectively referred to as “sandbox” have different underlying interaction logics, target users, and player UGC creations.
So, I categorized them based on player interaction methods and depth:
Editor (Roblox): Editors are used to build scenes, interaction logic, and environments, mostly referring to physical-level interaction logic, such as collision bodies, collision effects, gravity, friction, event triggers, event trigger sequences, and more.
Low-Fidelity Simulators (Minecraft): These only have the logic of physics and chemistry, with most interactions between objects following natural rules. For example, water flows downhill, elemental synthesis experiments, and so on.
High-Fidelity Simulators (Dwarf Fortress): These not only have the logic of physics and chemistry but also have human logic, and most simulation effects are implicit, happening over time. For example, a cat in a tavern dies from alcohol poisoning, and the generation of legendary stories in dwarf villages.
Game Reality Simulators (The Legend of Zelda: Breath of the Wild): They don’t rigidly follow all natural rules but enhance certain interactive reactions in the game engine, thus creating interactions that don’t exist in the real world. According to the creators of Zelda, this is called “deceiving the physics system.” Examples include time stopping, using a magnetic gripper, and the upcoming ability to walk through walls.
Game Reality Simulators and Editors (Screep: World): The passage of time, the execution of programs, the instructions available to players, and the cost of executing various instructions are all part of the “reality” of this game world. Players must adhere to this “game reality” and exercise agency to program various entities to achieve their goals. For example, designing robots responsible for building, defense, mining, and expanding territory, all while competing for server dominance.
These games’ highly combinable features and their ever-evolving UGC content ecosystems continually attract investors and producers of full-chain games. However, in the following sections, I will explain why I believe that replicating these games on the blockchain has extremely limited significance and present my ideas on full-chain game engine design.
1. Minecraft A Successful Native Computer Sandbox Game, but perhaps that doesn’t necessarily mean it can drive the gaming industry’s development and bring commercial success on the blockchain with the same impact.
If we take a step back and look at the era when Minecraft was created, at that time, there was no Unity or Unreal, no graphics cards, and no arms race in computer rendering capabilities. So Minecraft is a game that relies entirely on CPU for computation and rendering on the client side, where the computer handles all the logical calculations and rendering.
Furthermore, due to its fast computation speed and cost-effectiveness, with the feature of infinite resource generation, players building and destroying things in each other’s worlds is common. Experimenting with various element combinations in chemistry labs is also a common occurrence, even a core source of enjoyment. They can play with infinitesimal atoms and molecules, or they can create computers, artificial intelligence, and neural networks using redstone. Player motivation comes from a sense of self-achievement and showcasing on external social media, and they do not have anxiety about “this world being destroyed by centralized servers at any time.”
The core enjoyment of this game is not in its permanent existence, but in players’ ability to instantaneously destroy and rebuild anything on their computer client without worrying about computing power and cost. That is the essence of a sandbox game.
If you were to run Minecraft entirely on the blockchain, it would fundamentally be a comparison of blockchain’s computational speed, storage capacity, and computer’s CPU and GPU. It indeed makes for an interesting business showcase (demonstrating how fast a blockchain can be), but the blockchain’s advantageous features might not necessarily attract players and may not bring about a fundamental transformation in the entire gaming industry.
2.Dwarf Fortress What Does It Mean for Players If Countless Permanent Worlds Can Truly Be Created?
When Dwarf Fortress was in development, there was no mature physics engine available. This led to the creation of Dwarf Fortress, a game that blends natural and human-generated storytelling in a way that few developers would dare to attempt after the maturation of physics engines.
Over nearly two decades, the two developers integrated numerous intricate natural and humanistic logics into the game. If you carefully examine developer interviews and design manuals and compare them to “The Legend of Zelda: Breath of the Wild,” you’ll notice a stark difference:
Dwarf Fortress devoted most of its efforts to designing the logic that players cannot see, making the entire game a “passive experience” (where players cannot actively interact but can only passively accept outcomes or observe). For example, how atmospheric changes and water flow affect soil structure, further impacting the local natural terrain. Another example is the intertwining of cultural and natural logics, ultimately giving rise to a fascinating story: Dwarves love to drink alcohol, Dwarves don’t keep their environment clean — the tavern floor is soaked in alcohol — cats in the tavern get drenched in alcohol — alcohol is toxic to cats — cats always lick themselves — the poison accumulates in the cat’s body — the cat dies from alcohol poisoning.
In contrast, “The Legend of Zelda: Breath of the Wild” focuses on designing logic that players can see and interact with, creating an “active experience.”
From a game design perspective, Dwarf Fortress is a cultural legacy in the history of electronic gaming. However, this doesn’t imply that future game developers must follow the same logic to create great game works.
So, if we were to move the entire Dwarf Fortress onto the blockchain and turn it into an open-source logic library based on smart contracts, would it give birth to a greater and more successful creation?
All developers could write natural or human logic, and they could also call upon the logic contributed by other players, rather than just two people engaging in closed development. All novels and myths could become the materials of the virtual world.
At first, I was also very excited about this concept. However, an article titled “Dwarf Fortress Will Overwhelm Your CPU Because Creating History Is Hard” (https://www.polygon.com/2014/7/23/5926447/dwarf-fortress-will-crush-your-cpu-because-creating-history-is-hard) painted a different picture for me and made me realize that the overly complex logic behind the game might not be a good thing.
“… When a virtual world is generated, the game uses half the CPU power of a modern quad-core computer, and the game engine constantly occupies the maximum RAM, and it’s just the beginning.” The article also mentioned that from generating terrain to the rise and fall of civilizations in a world, the entire process involves complex logic interactions and computations, but it may not provide equal rewards (both economically and spiritually) and gaming enjoyment for designers and players.
“It can only make players sit down for a few hours, watching a virtual world like watching a movie. ‘Damn it. A world just popped up there’… This might be everything people feel when they see and play Dwarf Fortress.”
This reminds me that games are about the experience, and the experience comes from meaningful interaction where players can actively make significant changes, rather than passively accepting a randomly generated story, no matter how well-crafted.
Hidemaro Fujibayashi, the producer of The Legend of Zelda: Breath of the Wild, once shared: “We feel that action games = collision + character movement + object state, and the core of collision and character movement is physics. In games, we often need to make games more controllable, provide better feedback, and fully meet the needs of game design, so we don’t want real-world physics, but we need physics suitable for games, which we call game physics or deceptive physics.”
Therefore, if we were to place Dwarf Fortress and similar logic-generated worlds on the blockchain, it is highly likely that it would excessively use and waste the blockchain’s computing power and speed to meet the demands originally fulfilled by CPUs. Moreover, the interactive nature of gaming has not been considered. While it might attract a large number of programming enthusiasts, whether it can attract many gamers and provide a great gaming experience is questionable.
3.Screep: World Simplifying Interaction and Designing Logic Structures for Entertainment Games.
Based on the conclusions drawn in the previous section, I believe that blockchain-based games should not seek answers in simulation or sandbox games but should turn to programming games for inspiration, such as Screep: World.
Screep is a game about resource management and system optimization. Players must cleverly assemble their Creep army using eight body parts (eight action commands) to expand their colony as much as possible within limited time, energy, and computational capabilities.
When I first saw this game, I thought becoming a fully blockchain-based game would be perfect because it shares the same values as blockchain concerning public execution time and a single GPU.
Execution time or “tick” refers to the time required to complete all modules in a multiplayer server. It’s foreseeable that as the number of players and game activities increase, completing a “tick” will require more real-world time, slowing down the game’s execution time. Once a server’s execution time slows down, it may affect the player’s experience and prompt some players to move to a new server. If there were a multidimensional space tunnel (a user-created plugin, as we imagined before), there would be a lot of interesting uncertainties: who can leave? What can people take with them? How to handle those migrating to a new server? It could lead to some great science fiction civilization stories, like an Asian fleet officer hijacking natural selection in the battle of the world’s end, preserving a glimmer of hope for humanity in the dark forest.
The “GPU” is limited to avoid abusing execution time. This aligns well with the computational value of blockchain (mining blocks as PoW) and fits the traditional gaming monetization (“energy” priced in fiat currency). Based on this, the value of player activity can be quantified, with more time-saving and efficiency-enhancing plugins being more valuable.
However, Screep’s interaction logic is still based on simple physical rules, so the player’s programming basic unit (i.e., actions) can still be listed, staying within the realm of a physics engine, and still repeating what CPU and GPU can accomplish.
So, I tried to let players use some basic commands to build their smart contracts, engage in transactions, or more complex financial interactions, as this aligns better with blockchain characteristics and avoids going back to the old CPU path. But modularizing all possible financial activities is much more challenging than simple physical interactions because players’ motivations for generating financial interactions are diverse.
My friend @Curio encountered the same problem when building the “Treaty” system: prelisting all possible scenarios and people’s needs and designing the underlying architecture seemed impossible. (But it seems they’ve made some recent progress; I highly recommend reading @Curio’s research blog - https://twitter.com/0xcurio)
So, regarding the full-stack game engine, I have an idea that’s been brewing but hasn’t been put into practice yet:
- Firstly, deconstructing intangible value: units of calculating value, units of labor, and so on.
In the games we are familiar with, units of value may be items/weapons/character assets, but in single-player simulation games, players control an indicator of collective behavior, which is usually just a number. For example, in the Ice Steam Age, the population size, people’s happiness, steel production, construction, and mining efficiency, etc…
These indicators can actually be packaged as NFTs/FTs, representing the development status of a player. Just like cards, heroes, weapons, they are just packaged with different skills, attributes, and values on different carriers, becoming familiar virtual assets for everyone.
What’s even more important is that these indicators can be consumed, influenced, and changed at any time, giving their NFTs/FTs stronger volatility and consumption properties. For example, I bought an indicator representing the quantity of labor and productivity, but due to strict management policies I enacted, labor happiness decreased after a while, leading to a decrease in labor force growth rate and productivity. If I only purchased a production indicator at a certain moment, I cannot request a refund for it. But if I bought an indicator that guarantees the minimum productivity over a certain time period, then I can claim compensation according to the contract requirements… all of these can be reflected in the player’s custom contracts.
- Secondly, hide the rules and only provide players with items.
Zelda pioneered the physical and chemical engine of open-world games, but that doesn’t mean Nintendo tells players the detailed rules of magnetism and time. They certainly don’t expect players to write complex code about magnetism and time. What they do is turn these two possibilities of interaction into items: a timed bomb and a magnet. If players understand the rules behind them, they can use these tools to explore and experiment in the natural world.
Similarly, if we want to achieve the effect mentioned in the first point, there’s no need to invent or list financial rules. We just need to create items that allow players to interact with the underlying rules, and provide an environment that can support these rules (i.e., a realistic financial environment supported by numerous AI algorithms).
Let’s take a more vivid example: I have a rope that can package valuable assets, but each package requires cutting one-third of the overall package to tie a knot. Thicker ropes are more durable, but they wear out during use. Thinner ropes are easier to lose items when moving, and the lost items have a chance to be picked up by others and carried home with their ropes…
So, if we design these two core mechanisms, the rope and the basic value unit, and calculate the rope length and time required for each rope to package a certain volume unit of items, players will proactively package and sell items according to the principle of maximizing profit, creating contracts they need for trading with others. Or to simplify it a bit, they can package ropes + items into NFTs.
In fact, NFTs and FTs are both packages, just like heroes/cards waiting to be chosen, but I hope there’s a rope where everyone can decide what to put in their package.
- When we complete the first two steps, we also complete my vision for a time engine:
Almost all traditional games are based on a physics engine, and the physics engine leads to a chemical engine. However, few electronic games allow players to share the flow of time in the same world. The reasons for this are, on one hand, to consider the game experience and not require all players to synchronize the game; on the other hand, in the history of game storage, individual hosts correspond to individual game processes, and individual processes correspond to individual archives, so players can even manually save infinitely, controlling the flow of time and game progress on their own.
But based on the uniqueness and irreversibility of blockchain time, everything that happens in blockchain time has an irreversible effect. In addition, in game design, time, like space, is an important part of restricting the game environment and game rules. So, a “time”-based engine breakthrough might be similar to a physical engine.
Physical engine: Object 1 attacks Object 2, causing x points of damage;
Chemical engine: The chemical reaction between Object 1 and Object 2 can cause x points of damage to Object 3;
Time engine: Object 1, under the conditions of Object 2, after x units of time, if condition y1 has not occurred but y2 has occurred twice, then it causes x points of damage to Object 3.
A time engine can be well used in various simulation games, such as borrowing troops from neighboring countries before a guild war, or renting a piece of land for cultivation, and automatically returning a portion after harvesting to the landowner.
However, games are the art of going against human nature.
While the concept of a time engine is interesting and can solve many player conflicts in current SLGs, after discussing with traditional game designers, we all agree that making governance a game mechanism may not necessarily have a positive impact on the game.
Keeping promises or constraint mechanisms can actually be quite easy to implement, but designers deliberately avoid designing such supervision functions to strengthen social interactions. All supervision must be executed by collective leaders through external social interactions rather than directly in the game. Precisely because the mechanism is imperfect, conflicts and disputes are more likely to occur, creating social scenarios and active player communities.
So, I’ll leave the concept of the time engine here for now. When there is sufficient capacity (or time) to work on it, I’ll think about whether this innovation has had a real impact on the electronic game industry or if it’s just a small celebration for a few people.
Last but not least, if you’re interested in this topic and want to brainstorm together or share more new ideas, feel free to reach out on Twitter DM @0xAikoDai (https://twitter.com/0xAikoDai).