Original article link: https://twitter.com/hiCaptainZ/status/1656306576293244928
Original title: In-depth Analysis of Full-Chain Game Engine Architecture: ECS and ARC
Introduction of ARC#
JumpCrypto proposed a new full-chain game engine architecture called ARC (Action Registry Core) in January this year. Here, I will introduce what ARC architecture is and the differences and connections between ARC and ECS architecture.
There are generally only two types of game engine architectures, OOP (Object-Oriented Programming) and ECS (Entity Component System). As the number of objects in games increases, OOP becomes less scalable in the later stages. Subsequently, many game engines introduced the data-oriented ECS architecture. I have previously introduced the ECS architecture in my previous articles, so I will not go into detail here. Because traditional games are loop-based, while full-chain games are push-based, JumpCrypto borrowed from the ECS architecture and proposed the ARC architecture, which is more suitable for blockchain games.
The ARC (Action Registry Core) architecture is a data-driven approach used to organize on-chain information. In ARC, entities are component containers without data, components are data types without behavior that can be "attached" to entities, and actions are functionalities that can be performed on specific components. Unlike traditional ECS, ARC takes into account the push-based nature of blockchain architecture rather than the loop-based nature of traditional games. Actions are responsible for updating the on-chain game progress-related states, including reading entity PDA and deserializing components, as well as modifying serialized components to update entities. This architecture provides scalability, allowing for expansion as game assets increase and interdependencies increase, while avoiding technical debt that may come with object-oriented programming methods.
Comparison and Analysis of ARC and ECS#
So where are the similarities and differences between ARC and ECS?
They both tend to have a data-driven design pattern, which is more efficient and flexible compared to Object-Oriented Programming (OOP).
Similarities:
Entity: Both have the concept of entities. Entities are unique identifiers used to contain components. These entities themselves do not contain data but acquire data through attached components.
Component: In both ECS and ARC, components are pure data types without behavior. Components can be attached to entities to provide data for entities.
Differences:
System vs Action: ECS uses systems, while ARC uses actions. A system is a function that matches entities with certain sets of components. On the other hand, actions can be performed on specific components rather than the entire system. This is because traditional ECS is based on a loop architecture, suitable for traditional games, while ARC's action package takes into account the push-based nature of blockchain.
Off-chain vs On-chain: ECS is typically used for traditional games running locally or on servers, while ARC is designed for games and assets on the blockchain. Therefore, ARC deals with more challenging issues such as transaction costs, data storage limitations, and cross-chain operations.
Registry: ARC introduces the concept of a registry to track registered components and actions that can modify specific components. This is to achieve better governance features to adapt to the decentralization nature of blockchain, which traditional ECS does not have.
The above statements may be too abstract, so let's use an example to illustrate: Suppose we are making a combat game with two entities: player and monster. Each entity has some attributes, such as health points and attack power.
In ECS (Entity Component System):
Entity: Both player and monster are entities.
Component: Health points and attack power are components. These components can be attached to both player and monster entities.
System: We can have a "combat system" that performs combat based on the attack power and health points of the player and monster when their positions are the same. This system runs periodically, checking all entities that meet the conditions and updating their components (e.g., reducing health points).
In ARC (Action Registry Core):
Entity: Similarly, player and monster are entities.
Component: Health points and attack power are still components.
Action: Here, there are no systems, but actions instead. For example, we can have an "attack" action that is triggered when the player chooses to attack a monster, reducing the monster's health points. The execution of this action is event-based rather than periodic checking.
Registry: This is a unique concept in ARC. The registry records which actions can modify which components. For example, we can register in the registry that the "attack" action can modify the "health points" component. Only actions registered in the registry can change the corresponding components.
These are the main similarities and differences between ECS and ARC. In ECS, logic is actively processed by systems in each game loop, while in ARC, logic is executed through event-triggered actions. Additionally, ARC adds a layer of registry to provide better management and flexibility for the relationship between actions and components.
Game Loop and Push#
Traditional games are loop-based because their core mechanism is the game loop. The game loop is a repetitive process that typically includes handling user input, updating game state, and rendering the game world. This loop continues during the game runtime, usually running tens to hundreds of times per second to maintain the smoothness of the game world. In this architecture, game systems (such as physics engines, AI systems, etc.) check and process the game entities and components they are concerned with in each loop.
However, blockchain architecture is push-based. Blockchain is a distributed database that shares and stores information among nodes in the network. When a node generates a new transaction (such as a transfer, contract invocation, etc.), this transaction is pushed to the network, and other nodes in the network receive and verify it before adding it to the blockchain. This is a passive process where nodes do not actively search for new transactions but wait for new transactions to be sent by other nodes in the network. Therefore, blockchain architecture is referred to as push-based.
This fundamental difference leads to the design differences between ECS and ARC. In ECS, systems actively process their tasks in each game loop. In contrast, actions in ARC are passive and are only triggered and executed when relevant transactions occur on the blockchain. This design better suits the characteristics and requirements of blockchain.