Full-chain Game Preview: Starting from the Development History of Web2 Game Engines

Written by: Snapfingers DAO

01 Underlying Technology Drives Leapfrog Development in Gaming

The progress of the gaming industry has always evolved alongside technological advancements. From changes in graphics and sound effects to transformations in game design and interaction methods, all of these factors drive the development of games. The first game developed by Atari, Pong, is recognized as the first commercially successful video game, which became a sensation and sparked the video game craze. The 1970s was a period of rapid development for integrated circuits, and in 1975, Motorola launched the 6502 processor, laying the foundation for the subsequent glory of home consoles. The most famous home console pioneer, Atari 2600, was born from this, and Pac-Man became a household name.

Modern games are a combination of art and complex technology. Early games had relatively simple code logic and interface interactions, and developers were more accustomed to creating from scratch. However, as capabilities improved, gameplay became more diverse and technology more complex, making it slow and inefficient to develop from the ground up. By the 1990s, the emergence of CD-ROMs and 3D graphics acceleration cards brought game content and visual performance to new heights, leading to a dramatic increase in the amount of code required to develop a game, which in turn gave rise to the concept of game engines. Game developers standardized some underlying technologies and integrated them into an efficient toolkit to shorten development cycles, reduce complexity, and support game releases across different platforms and devices. The emergence of game engines has greatly facilitated developers. These modular, generalized, and standardized functions allow developers to focus more on game content and gameplay design. Today, a mature game engine may include various systems such as graphics, physics, and scenes.

In 1993, Id Software used the DOOM engine (Id Tech 1) to create the game DOOM, which achieved tremendous success, selling 3.5 million copies that year. The success of DOOM was largely due to its software architecture design. Its game software architecture was divided into core software components, art assets, game worlds, and game rules. This clear architectural division allowed different developers to use the same engine to create entirely new game works by producing new art, levels, characters, game worlds, and game rules. The successful division of the DOOM engine sparked interest in MOD creation within the community and became the first commercial game engine. In the following decade, game engines became highly sought after, from Epic Games' Unreal Engine to Cry Tech's CryEngine, and then to Unity, which shone on iOS. In addition to commercial engines, many companies also developed their proprietary engines, such as Valve's Source engine, Infinity Ward's IW engine, and Ubisoft's Anvil engine.

02 ECS Architecture of Web3 Game Engines

Currently, the two most well-known full-chain game engines, MUD and DOJO, both adopt the ECS architecture. ECS stands for Entity-Component-System, a commonly used architectural pattern in Web2 game development for managing game objects (entities), their attributes (components), and behaviors (systems). The benefits of this architectural pattern include:

• Performance Optimization: The ECS architecture allows game developers to better manage memory layout and data access patterns, thereby improving game performance. The close arrangement of entities and components helps reduce cache misses and improve data access efficiency.
• Scalability: Due to the decoupling of entities and components, adding new features only requires adding corresponding components and systems without changing existing code. This makes it easy to expand the game's functionality and content.
• Reusability: By dividing attributes into independent components, these components can be more easily reused to create different types of entities, thus reducing redundant code.

MUD V1 is a typical ECS architecture. In the V1 framework, Entities are the basic units in the game, which can be various objects, items, or wallet addresses, identified by a unique ID. Components are the data part of the entities, used to describe different attributes of the entities, such as the position of an object or the attributes of a character. By attaching different components to entities, a rich variety of game objects can be created. Systems handle the logic of Components, implementing various rules and behaviors of the game, existing on-chain in the form of smart contracts. Entities, components, and systems all exist within a Worlds contract, with each World representing an independent game environment.

How does this architecture reflect scalability? Suppose we need to upgrade a certain feature in the game or the community wants to add new content. First, we need to grant the new game feature/logic (system) write permissions for the relevant components, and then create an upgraded version, while the other content in the game remains unchanged. If write permissions are not granted, we can consider creating new components and systems that include the new features, allowing players to choose different versions to play while interacting with the same core component data. From the perspective of Worlds, anyone can create components and systems, just as anyone can create new ERC-20 tokens and "attach" them to an address.

03 The Significance of Web3 Game Engines for the Development of Chain Games

Although blockchain technology has not yet fully landed in daily applications, its unique features such as ownership and transparency are bound to bring significant changes to the gaming field. Especially as people have already witnessed the immense power brought by DeFi. What would happen if games were fully on-chain? From DeFi, we can easily deduce the changes that blockchain will bring to games:

• Open Economic System: Blockchain allows virtual assets in games to have real ownership and scarcity. This means players can verify the rarity and yield of items, avoiding centralized gaming companies' control and management of assets.
• Composability: Placing games in an open blockchain environment allows different games and projects to complement each other. Progress in one game can be reflected in others, even sharing assets, creating a more open and interconnected gaming ecosystem.
• User-Generated Content: Users can fully autonomously construct game content or assets and own those assets in an open-source environment. This promotes a user-generated game loop, increasing the playability and distribution of games. For example, users can load verified mod content into the game contract, enriching gameplay while potentially earning some revenue.

Blockchain games have always been highly anticipated, especially after the explosive growth of DeFi and NFTs in the blockchain application fields. However, there are still many obstacles to achieving this:

• First, there are limitations in technological infrastructure. EVM is slow, gas fees are high, and the Solidity language is almost incapable of handling complex game logic, severely limiting the complexity and interactivity of games.
• Economic model design is crucial; it is well known that the economic system of chain games is of utmost importance, and finding a balance between effective incentives and financialization is necessary.
• Freedom and governance: On-chain games have a high degree of freedom or openness. They should allow any player to create and deploy different game content, but this inevitably leads to a more complex game world and potentially unforeseen economic impacts, requiring effective governance mechanisms for coordination and management.

These are just some of the foreseeable difficulties, and they are also the reason why almost all full-chain games currently focus on SLG—simple game mechanics that do not require high TPS, and the incompleteness of the required information can be perfectly applied with existing technology. If we expect an MMORPG, it undoubtedly presents considerable challenges. Drawing on the changes that game engines brought to Web2 games, if chain games also adopt the ECS architecture, it could potentially solve:

• Data Organization and Management: On-chain games also have a large amount of game data to process, including character attributes, items, map information, etc. The ECS architecture can help organize data into reusable components and effectively manage data modifications and access.
• Flexibility and Scalability: By separating game entities (Entity) and components (Component), developers can easily create new game objects and features without affecting existing logic. This flexibility and scalability are particularly important in on-chain games, as complex game mechanics may require frequent upgrades and expansions.
• Smart Contracts and Data Updates: The ECS architecture can manage data updates in smart contracts more effectively. Each component can be updated independently without needing to update the entire entity. This can reduce the execution costs of smart contracts and improve interaction efficiency.
• Composability: One advantage of ECS is the composability of its components and systems, which aligns with the concept of composability in on-chain games. Perhaps players can create new content, leading to richer experiences.

04 Outlook on Web3 Full-Chain Games

There are still many challenges facing full-chain games, and game engines only address a small portion of the issues. However, challenges and opportunities coexist, and complex applications like full-chain games may become the stepping stone for the true implementation of blockchain technology.

Currently, full-chain game engines are still in a very early stage. As mentioned earlier, we see the embryonic form of complex applications but lack the tools to implement them. The development progress is relatively fast for MUD V2 and Dojo. MUD V2 has improved the ECS architecture compared to V1, but V2 is still under development. Dojo, built by the Starknet community, is currently the only verifiable game engine, benefiting from the Cairo language, which can natively implement fog of war. Dojo also adopts the ECS architecture and plans to develop a dedicated L3 for games on Starknet to further enhance scalability.

Additionally, the infrastructure that chain games rely on is also evolving. L2 has become robust enough to allow for one-click chain deployment, and perhaps a blockbuster game can maintain a dissipative structure by earning price differences through self-built Rollups, avoiding a death spiral. Utilizing ERC-4337 account abstraction technology, full-chain games can enable players to conduct game transactions, create characters, and more within a single account, helping to simplify the user experience. Different game mechanics can also be encapsulated as an upgradable contract account, allowing developers to easily update or optimize game rules, content, and more.