The AO testnet has been running for half a year, attracting many developers from the original EVM ecosystem. During the development process, many developers still use Ethereum's programming thinking, but AO's process is more like a computer process, with the characteristics of cheap storage and parallel execution. The AO programming paradigm shows unique advantages in game development. For example, player characters and game equipment can persist as independent processes. Even if the player goes offline or the game is shut down, the characters and equipment still retain all historical records and continue to run. In addition, the independent process state and parallel computing of the AO system eliminate the problems of state explosion and transaction congestion. AO's elastic expansion of storage and computing resources allows game developers to not worry about server operation and maintenance issues. The AO ecosystem needs to be continuously enriched and more developers to join in order to realize its potential.
The AO testnet has been running for half a year, with more and more applications and a thriving ecosystem. Many developers (including me) who were originally in the EVM ecosystem are trying to use AO to make products. During the development process, many developers are still accustomed to Ethereum's programming thinking and habits, and directly use process as smart contract. Of course, this approach is not wrong. For example, the implementation of token blue print and atomic asset can basically correspond directly to ERC-20 and ERC-721. It can be said that most of the process codes on AO are very similar to smart contracts.
In the AO white paper, the definition of AO is Actor Oriented Machine, so Actor, that is, process, is the basic component unit of this system. Compared with smart contracts, process is more like computer process, with cheap storage and parallel execution. The cost of opening a process is not high, and it can even be used and discarded. Low cost and parallelism make the AO programming paradigm (actor oriented programming) and smart contracts quite different. Here, I would like to expand the association with the game scene and see the application of the AO programming paradigm in it.
New ways to play AO games
Imagine that we are in a multiplayer online RPG game similar to World of Warcraft. Let's call it the AO world. Each character operated by the player is a process. The player can operate this process to kill monsters, upgrade, buy and sell equipment, and compete in the game world. When the player goes offline, the way World of Warcraft does it is to save the current position and status of the character and release the resources occupied by the character from the server's memory. In the eyes of other players, what they see is that the character becomes transparent and the system prompts friends to go offline. But in the AO world, when the player goes offline, the process still exists and will not be released. Of course, we can add logic to the code to let the process refuse to process any received message to achieve "pseudo offline". But a better way is to let the process have an "autopilot" mode. The character can kill monsters, upgrade, make money, and even buy and sell equipment when the player is AFK, turning from a player into an NPC. This set of "autopilot" code can be written by the players themselves, and can even be driven by AI to make complex behaviors similar to real players. With this design, the AO world will not have the ghost town phenomenon caused by the loss of players, and the AO world will always be full of vitality. What's more fun is that players can rent out characters without worrying about exposing their usernames and passwords to each other like World of Warcraft.
Let's talk about game equipment. Each game equipment in the AO world can also be a separate process, just like the real physical world. The iron sword in the hands of character A and the iron sword in the hands of character B may be exactly the same when they are just cast (except for the casting time), but as time goes by, the process of the iron sword records the change of hands and the kill record, and becomes more and more different. Iron sword A killed 3 chickens, but iron sword B chopped down the dragon, and iron sword B has "humanistic value". Of course, we can also really let the iron sword stained with the blood of the dragon increase the attributes. Completely recording the history of each piece of equipment has never appeared in traditional games or blockchain games, but the AO programming paradigm can do it naturally. In World of Warcraft, there are often player communities designing their own challenges. For example, a level 1 dark elf runs from Darnassus (the birthplace of the elves) to Stormwind (the birthplace of the human race). The whole process must be recorded and live-streamed to ensure that there is no cheating. In the AO world, the same challenge can be done directly, because the entire history cannot be cheated, and it is verified by itself. Of course, for entertainment purposes, it is better to record the whole process.
How is AO performance?
Chain game developers may ask at this time. With so many players and equipment, all of which are independent processes, will the state of the AO world explode? Will the increase in online players at the same time cause congestion in AO world transactions?
My answer is no, the AO world will still run smoothly. Let's first look at the state explosion problem. Unlike the global state of EVM, the state of each process is independent and there is no global state, so there is no need for a physical machine to store all AO data. The computing resources of AO can be dynamically allocated by CU and can be horizontally elastically expanded. Developers only need to focus on the game logic and do not need to worry about tedious server operation and maintenance issues.
Regarding the transaction congestion problem, since EVM is a serial calculation, no matter what layer 2 technology is used to accelerate it, it always has a processing speed ceiling. Iron sword A hits the chicken and iron sword B hits the dragon. The two events must occur one after another. AO is different. Iron sword A, chicken, iron sword B, and dragon, these four processes do not share memory, and do not need a world clock. The event of iron sword A hitting and the event of iron sword B hitting can be calculated in parallel. Therefore, AO does not have the problem of transaction congestion in terms of architecture.
Never downtime + free combination
In traditional games, once the game is not profitable or the copyright expires, the game operator will stop the service. Sometimes, in order to make the suspension dramatic, a doomsday event is created, and an invincible boss kills all players. In AO, once the game characters and equipment are developed, they are permanent (at least as long as AO exists) and always online. Even if the developer decides not to continue maintenance, other developers can take over seamlessly. Developers can even allow players to build their own DLC, characters and weapons from the beginning of the game, and work together to build the entire game.
On AO, all processes can communicate with each other. What does this mean? It means that all applications on AO, including all games, are naturally connected. Let's use our imagination. Player A bought an iron mine from the Monopoly game, took the iron ore produced to the AO world to forge an iron sword, and finally ran to the Mario world to stab the mushroom monster with the iron sword. Any strange combination can be realized, just like the Gundam and Ultraman in the movie Ready Player One. What traditional game developers often do is to search for material libraries and change skins. Art resource expenses often account for more than half of the entire game. In the AO game world, the richness of materials will increase unidirectionally over time. There are more and more available written materials and items, and it will be easier for subsequent developers to get started, so that it will become as simple as building Lego blocks in the end, and everyone can start making games.
Summary
Let's summarize, AO has unique advantages in games. Characters and props will never go offline, never be destroyed, and all historical records will be retained. All game resources can be fully circulated and highly reused, and the more you develop, the easier it will be. AO's storage and computing resources can be elastically expanded, without worrying about server configuration and management. Processes are processed in parallel without congestion. These features make AO a paradise for game developers. However, to achieve this goal, the ecosystem needs to be continuously enriched, and game developers need to continue to join and build together.
JinseFinance
decrypt
Beincrypto
Bitcoinist