The AO testnet has been running for nearly six months now, with an increasing number of applications and a continuously flourishing ecosystem. Many developers originally from the EVM ecosystem, including myself, are gradually trying to use AO to build products. During development, many developers still stick to Ethereum's programming mindset and habits, directly treating processes as smart contracts. Of course, there's nothing wrong with this approach. Implementations like token blueprints and atomic assets can essentially be directly mapped to ERC-20 and ERC-721. It's fair to say that most process code on AO looks very much like smart contracts.
According to AO's whitepaper, AO is defined as an Actor Oriented Machine, meaning that Actors, or processes, are the fundamental units of this system. Compared to smart contracts, processes are more akin to computer processes, with cheap storage and the ability to execute in parallel. Starting a process is not expensive, and it can even be used and discarded on-the-fly. The low cost and parallelism make AO's programming paradigm (actor oriented programming) quite different from that of smart contracts. Here, I would like to expand on its application in gaming scenarios.
New Gameplay in AO Games
Imagine we're in a multiplayer online RPG similar to World of Warcraft, which we'll call AO World. Every character operated by a player is a process. Players can control this process to fight monsters, level up, trade equipment, and engage in combat. When a player logs off, World of Warcraft's approach is to save the character's current position and state, releasing the resources occupied by the character from the server's memory. Other players see the character become transparent with a system message indicating that a friend has gone offline. In AO World, when a player logs off, the process still exists and won't be released. Of course, we can add logic to the code to make the process refuse to handle any received messages, achieving a "pseudo-offline" state. However, a better approach is to give the process an "autopilot" mode, allowing the character to continue fighting monsters, leveling up, earning money, and even trading equipment while the player is AFK, essentially turning into an NPC. This "autopilot" code can be written by the player or even driven by AI to behave as complexly as a real player. With such a design, AO World will never suffer from ghost town phenomena caused by player attrition and will always be lively. Additionally, players can rent out their characters without worrying about exposing usernames and passwords, as is the case with World of Warcraft.
Regarding game equipment, each piece in AO World can also be an individual process, just like in the real physical world. For example, the iron sword held by Character A and the iron sword held by Character B might be identical when first forged (except for the forging time). However, over time, the processes of these iron swords record their transaction information and kill records, making them increasingly unique. Iron Sword A might have killed three chickens, while Iron Sword B might have slain a dragon, giving Sword B "cultural value." We could even make swords that are bloodstained from dragons more powerful. Recording the entire history of each piece of equipment has never been achieved in traditional games or blockchain games, but it comes naturally in AO's programming paradigm. In World of Warcraft, player communities often design challenges, such as a level 1 dark elf running from Darnassus (elf starting point) to Stormwind (human starting point), with the entire process being recorded to prevent cheating. In AO World, the same challenge can be done directly, as the entire history cannot be falsified, making the act of completion itself the validation. For entertainment purposes, it's still better to record the whole process.
How About AO's Performance?
At this point, game developers might ask: With so many players and equipment, each being an independent process, will AO World's state explode? Will an increase in concurrent players cause transaction congestion in AO World?
My answer is no; AO World will still run smoothly. First, regarding the state explosion problem: Unlike EVM's global state, each process's state is independent, meaning there is no global state, so a single physical machine doesn't need to store all AO's data. AO's computational resources can be dynamically allocated by CU, allowing for horizontal scalability. Developers can focus solely on game logic without worrying about cumbersome server maintenance issues.
Regarding transaction congestion, EVM is serial in computation, and no matter what layer 2 technology is used to speed it up, there will always be a processing speed cap. Iron Sword A hitting a chicken and Iron Sword B hitting a dragon must happen sequentially. However, AO is different: Iron Sword A, Chicken, Iron Sword B, and Dragon are four processes that do not share memory and do not need a world clock. The hit events of Iron Sword A and Iron Sword B can be computed in parallel. Therefore, AO structurally does not have transaction congestion issues.
Continuous Operation and Flexible Combination
In traditional games, once a game stops making money or its license expires, the operating company will shut down the servers. Sometimes, to make the shutdown dramatic, they'll create an apocalyptic event where an unbeatable boss kills all players. In AO, once game characters and equipment are developed, they exist forever (at least as long as AO exists) and are always online. Even if developers decide to stop maintenance, other developers can seamlessly take over. Developers can even allow players to create their own DLCs, characters, and weapons right from the start, collaboratively building the entire game.
On AO, all processes can communicate with each other. What does this imply? It means that all applications on AO, including all games, are inherently interconnected. Let's stretch our imagination: Player A buys an iron mine in a Monopoly game, takes the produced iron ore to AO World to forge an iron sword, and then uses the sword to kill a mushroom monster in the Mario world. Any bizarre combination can be achieved, much like how Ready Player One features Gundam and Ultraman fighting side by side. Traditional game developers often scour asset libraries and reskin them. Art resources often take up more than half of a game's development cost. In AO's gaming world, the richness of materials will grow over time, making it easier for subsequent developers to pick up and use ready-made materials, items, and eventually as simple as assembling Lego bricks, making game development accessible to everyone.
Conclusion
In summary, AO has unique advantages in gaming: characters and items never go offline or get destroyed, and historical records are fully preserved. All game resources can be fully circulated and highly reused, making development easier over time. AO's storage and computational resources can be elastically expanded, eliminating concerns about server configuration and management. Processes can handle tasks in parallel, avoiding congestion. These features make AO a haven for game developers. However, achieving this goal requires a continuously enriched ecosystem and the ongoing participation of game developers to build together.