The progress in the gaming industry is always evolving alongside advancements in technology. From changes in graphics and sound to shifts in game design and interaction methods, all contribute to the development of gaming. The first game developed by Atari, Pong, is widely considered as the first commercially successful electronic game, sparking a trend in electronic gaming. The 1970s were a period of rapid development for integrated circuits. In 1975, Motorola introduced the 6502 processor, laying the groundwork for the subsequent success of home consoles. The most famous home console pioneer, Atari 2600, was born out of this, making Pac-Man a household name.
Modern gaming is an integrated art and also a complex technology. Early games were relatively simple in code logic and interface interaction. Developers were more accustomed to working from 0 to 1, but as capabilities improved, gameplay became more diverse, and technology became more complicated. Starting development from scratch became increasingly inefficient. By the 1990s, the advent of CD-ROMs and 3D graphics acceleration cards brought games to new heights in content and visual performance, leading to a dramatic increase in the amount of code required to develop a game. Against this backdrop, the concept of game engines emerged. Game developers standardized some of the underlying technologies and integrated them into an efficient toolset to shorten development cycles, reduce complexity, and support multi-platform game releases. The emergence of game engines brought great convenience to developers. These modular, generalized, and standardized features allow developers to focus more on game content and gameplay design. Nowadays, a mature game engine may include systems for graphics, physics, and scenes.
In 1993, Id Software used the DOOM engine (Id Tech 1) to create the game “Doom”, achieving tremendous success with sales reaching 3.5 million copies in the first year. The success of “Doom” was largely attributed to its software architecture design. The game software architecture was divided into core software components, art assets, game world, and game rules, among others. This clear architectural division allows different developers to use the same engine and create entirely new games by producing new art, levels, characters, game worlds, and rules. The success of the DOOM engine sparked interest in MOD production 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 CryTech’s CryEngine, to Unity, which shines on the iOS platform. Apart from commercial engines, many manufacturers also built proprietary engines for internal use, such as Valve’s Source engine, Infinity Ward’s IW engine, and Ubisoft’s Anvil engine.
The two most well-known blockchain game engines, MUD and DOJO, both use ECS architecture. ECS stands for Entity-Component-System. It’s a common architectural pattern in Web2 game development for managing game objects (entities), their properties (components), and behaviors (systems). The benefits of this architecture include:
MUD V1 is a typical example of ECS architecture. In the framework of V1, Entities are also the basic units in the game, which can be various objects, props, or wallet addresses, identified by a unique ID. Components are the data part of entities used to describe different attributes of the entity, such as the location of objects, attributes of characters, etc. By attaching different components to entities, diverse and varied game objects can be created. Systems handle the logic of Components, implementing various game rules and behaviors. They exist on-chain in the form of smart contracts. Entities, components, systems all exist in a Worlds smart contract, each Worlds is equivalent to an independent game environment.
How does this architecture reflect scalability? Suppose we need to upgrade a feature in the game or the community wants to add new content. First, you need to give the new game function/logic (system) write access to relevant components. Then create an upgraded version; other content in the game remains unchanged. If not given write access, then you can consider creating new components and systems with new features. Players can choose different versions to play while interacting with the same core components’ data. From the perspective of Worlds, anyone can create components and systems, just like anyone can create new ERC-20 tokens and “attach” them to addresses.
Although blockchain technology has not yet fully landed in daily applications, its unique features such as authentication rights and transparency will inevitably bring important changes to the gaming field. Especially that people have already witnessed the huge opportunity brought by DeFi. What will happen if the game is fully on-chain? From DeFi, it is not difficult to infer the changes blockchain will bring to the game:
Blockchain games have been highly anticipated, especially after DeFi and NFT, these two blockchain application areas have successively exploded. However, there are still many obstacles to implementation:
These are just some of the foreseeable difficulties and are also the reason why almost all full-chain games currently focus on SLG— the game mechanism is simple, does not require high TPS, and the information incompleteness can be perfectly applied by existing technology. If we expect an MMORPG, it is undoubtedly quite challenging. Taking reference from the changes game engines have brought to Web2 games, if chain games also adopt ECS architecture, it can possibly solve:
The challenges of full-chain games are still numerous, and the game engine only solves a small part of the problem. However, challenges and opportunities coexist, and full-chain games as a complex application may become the stepping stone for the real implementation of blockchain technology.
Currently, full-chain game engines are still in a very early stage. As mentioned earlier, we have seen the embryonic form of complex applications, but they lack the tools for implementation. The fastest development progress is currently MUD V2 and Dojo. MUD V2, compared to V1, has improved the ECS architecture, but V2 is still under development. Dojo is currently the only verifiable game engine built by the Starknet community, benefiting from the Cairo language, it can natively implement fog of war. Dojo also adopts the ECS architecture and plans to develop exclusive L3 games on Starknet to further improve scalability.
Additionally, the infrastructure that chain games rely on is also evolving. L2 has been so developed that you can launch a chain with one click. Perhaps a blockbuster game can sustain its dissipative structure by earning the spread through self-built Rollup, thereby avoiding a death spiral. Utilizing ERC-4337 account abstraction technology, full-chain games can allow players to conduct game transactions and create characters within a single account, which helps simplify the user experience. Different game mechanisms can also be encapsulated into an upgradeable contract account, making it easy for developers to update or optimize game rules, content, etc.
The progress in the gaming industry is always evolving alongside advancements in technology. From changes in graphics and sound to shifts in game design and interaction methods, all contribute to the development of gaming. The first game developed by Atari, Pong, is widely considered as the first commercially successful electronic game, sparking a trend in electronic gaming. The 1970s were a period of rapid development for integrated circuits. In 1975, Motorola introduced the 6502 processor, laying the groundwork for the subsequent success of home consoles. The most famous home console pioneer, Atari 2600, was born out of this, making Pac-Man a household name.
Modern gaming is an integrated art and also a complex technology. Early games were relatively simple in code logic and interface interaction. Developers were more accustomed to working from 0 to 1, but as capabilities improved, gameplay became more diverse, and technology became more complicated. Starting development from scratch became increasingly inefficient. By the 1990s, the advent of CD-ROMs and 3D graphics acceleration cards brought games to new heights in content and visual performance, leading to a dramatic increase in the amount of code required to develop a game. Against this backdrop, the concept of game engines emerged. Game developers standardized some of the underlying technologies and integrated them into an efficient toolset to shorten development cycles, reduce complexity, and support multi-platform game releases. The emergence of game engines brought great convenience to developers. These modular, generalized, and standardized features allow developers to focus more on game content and gameplay design. Nowadays, a mature game engine may include systems for graphics, physics, and scenes.
In 1993, Id Software used the DOOM engine (Id Tech 1) to create the game “Doom”, achieving tremendous success with sales reaching 3.5 million copies in the first year. The success of “Doom” was largely attributed to its software architecture design. The game software architecture was divided into core software components, art assets, game world, and game rules, among others. This clear architectural division allows different developers to use the same engine and create entirely new games by producing new art, levels, characters, game worlds, and rules. The success of the DOOM engine sparked interest in MOD production 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 CryTech’s CryEngine, to Unity, which shines on the iOS platform. Apart from commercial engines, many manufacturers also built proprietary engines for internal use, such as Valve’s Source engine, Infinity Ward’s IW engine, and Ubisoft’s Anvil engine.
The two most well-known blockchain game engines, MUD and DOJO, both use ECS architecture. ECS stands for Entity-Component-System. It’s a common architectural pattern in Web2 game development for managing game objects (entities), their properties (components), and behaviors (systems). The benefits of this architecture include:
MUD V1 is a typical example of ECS architecture. In the framework of V1, Entities are also the basic units in the game, which can be various objects, props, or wallet addresses, identified by a unique ID. Components are the data part of entities used to describe different attributes of the entity, such as the location of objects, attributes of characters, etc. By attaching different components to entities, diverse and varied game objects can be created. Systems handle the logic of Components, implementing various game rules and behaviors. They exist on-chain in the form of smart contracts. Entities, components, systems all exist in a Worlds smart contract, each Worlds is equivalent to an independent game environment.
How does this architecture reflect scalability? Suppose we need to upgrade a feature in the game or the community wants to add new content. First, you need to give the new game function/logic (system) write access to relevant components. Then create an upgraded version; other content in the game remains unchanged. If not given write access, then you can consider creating new components and systems with new features. Players can choose different versions to play while interacting with the same core components’ data. From the perspective of Worlds, anyone can create components and systems, just like anyone can create new ERC-20 tokens and “attach” them to addresses.
Although blockchain technology has not yet fully landed in daily applications, its unique features such as authentication rights and transparency will inevitably bring important changes to the gaming field. Especially that people have already witnessed the huge opportunity brought by DeFi. What will happen if the game is fully on-chain? From DeFi, it is not difficult to infer the changes blockchain will bring to the game:
Blockchain games have been highly anticipated, especially after DeFi and NFT, these two blockchain application areas have successively exploded. However, there are still many obstacles to implementation:
These are just some of the foreseeable difficulties and are also the reason why almost all full-chain games currently focus on SLG— the game mechanism is simple, does not require high TPS, and the information incompleteness can be perfectly applied by existing technology. If we expect an MMORPG, it is undoubtedly quite challenging. Taking reference from the changes game engines have brought to Web2 games, if chain games also adopt ECS architecture, it can possibly solve:
The challenges of full-chain games are still numerous, and the game engine only solves a small part of the problem. However, challenges and opportunities coexist, and full-chain games as a complex application may become the stepping stone for the real implementation of blockchain technology.
Currently, full-chain game engines are still in a very early stage. As mentioned earlier, we have seen the embryonic form of complex applications, but they lack the tools for implementation. The fastest development progress is currently MUD V2 and Dojo. MUD V2, compared to V1, has improved the ECS architecture, but V2 is still under development. Dojo is currently the only verifiable game engine built by the Starknet community, benefiting from the Cairo language, it can natively implement fog of war. Dojo also adopts the ECS architecture and plans to develop exclusive L3 games on Starknet to further improve scalability.
Additionally, the infrastructure that chain games rely on is also evolving. L2 has been so developed that you can launch a chain with one click. Perhaps a blockbuster game can sustain its dissipative structure by earning the spread through self-built Rollup, thereby avoiding a death spiral. Utilizing ERC-4337 account abstraction technology, full-chain games can allow players to conduct game transactions and create characters within a single account, which helps simplify the user experience. Different game mechanisms can also be encapsulated into an upgradeable contract account, making it easy for developers to update or optimize game rules, content, etc.