The future of full-chain gaming: “The promise of MUD ECS engine”

Web3's philosophy seems to fit perfectly with the gaming industry and the gamification trend of recent years. For quite some time, we have been promised new disruption in the form of a unique experience: on-chain gaming. Features like decentralization shift the balance of power away from the gaming industry’s incumbents and more toward creative entities, composability breaks down the walls of long-closed gardens, and true player ownership. But these powerful ideals remain on the back burner because we have yet to see them in practice. MUD is the first brave attempt to create a complete framework for on-chain gaming that could ignite the next generation of gaming.

Lessons from the traditional game industry

About innovation and starting from scratch There's a lot to be said for starting building everything and creating entirely new creatures, but as far as games are concerned, there are decades of lessons learned in design patterns and the creation of new engineering niches that deserve to be taken seriously, and ignoring them is the equivalent of trying to create using Atari technology AAA games.

When looking back at the early stages of game development, we can see clear similarities to on-chain games:Lots of talent and high levels of inspiration projects, but lacked coordination and a clear framework.

In the early days of video games, before game engines were born, beliefs and design patterns were established. Different video games have little in common,to the extent that similar games may have completely different code bases. But everything changedwith the introduction of game engines.

It is difficult to establish a clear distinction between the game engine and the game itself. Generally speaking, agame engine is a frameworkwith a set of rules and design patterns that can be slightly modified and extended to create different game implementations. By the '90s, after years of fragmented game development, things were changing, with"genre-based" game engines and some efforts to develop general-purpose engines becoming dominant. The core components of games such as "Doom" and "Unreal" can be reused to create many different games.Games of similar types are beginning to share many core logic implants. The cost and complexity of developing racing, fighting, and first-person shooter games has dropped by orders of magnitude. The impossible became possible, and code after generation of games and upgrades continued to accumulate. From a software perspective, this is one of the main reasons why game development has become a huge industry.

There are several core problems in on-chain games:

1. Lack of framework: Every team tries to build everything from scratch, leading to inefficiencies andlack of builders to tackle the same problems and optimize the best solution Summary of experience and system knowledge.

2. Lack of code reusability: Take the many on-chain games currently being developed as an example. How many of these can be successfully replicated and create a slightly different game? How many are clear distinctions between the different layers and components of a game, allowing newer generations of games to be built using similar code bases? The promise of creating the most important and interconnected open source project for gaming still seems far away.

3. Lack of data composability: It doesn’t end with code reusability, it >Also involves the ability of on-chain games to leverage shared blockchain stateto build on each other using data from Game A and Game B. In practice, it takes a lot of work and resources to integrate the data and logic of Game A, and one game becomes another.

MUD's solution:

MUD is the first brave attempt to serve as an on-chain game creation engine and framework by providing a structure that is maintainable, upgradable, and moldable. The Entity Component System (ECS) model advocated by MUD is meaningful for general game development and even more meaningful for on-chain game development.

ECS in smart contracts:

The best in MUD The basic building blocks are Components (Components), which exist in the form of smart contracts and function like a database that stores entity data. For example, we have an entity (Ethereum address) such as a player's wallet address. The entity represented by this address can have different properties, such as: position (x, y) in the location component, level 10 in the level component, and value 50 in the token component. Components only contain mapping and basic configuration .

Systems (Systems) are more complex and implement the logic of changing the values ​​of components (Components). You can think of it as a POST request API on a specified database (component) of Systems. Only by gaining write permissions to specific Components can they write data to that component. This is where things get interesting. Systems can interact with different components to create detailed logic. You could have a movement system that specifies the valid moves a player can make (eg: two steps per move), or you could have a reward system that gives players gold every time they level up.

All of this is registered with the world contact so that every change to the component's data emits an event. World Contracts is permissionless and anyone can add new systems and components. In theory, different world contracts can interact with each other.

Introducing ECS into on-chain games will produce a very elegant structure, making OPcraft composed of only 10 components and about 15 systems .

True composability

The ECS system not only makes perfect sense in traditional game development, but even more so in on-chain games because it provides Two important features are provided:

1. Upgradeability of deployed games< /strong>

2. Highest degree of composability

Imagine two paths: one is to keep the basic design, and the other is to change the core game logic.

Imagine a standard PVP strategy game where players build armies to fight each other. The base version was 2D, butnow the team decided to create a 3D rendering for the game. All they need to do is take all the location-related Systems and create an upgraded version using (x,y,z) coordinates instead of (x,y). All other systems and components (such as: attack system, health and army buildings) can remain unchanged. It even goes beyond the scope of the original development team. The community can create different mods of the game by redeploying systems and components, and even compete with the same components by granting write access to new Systems. to interact (in the case of a community-owned game, various governance models can be used to vote on such decisions).

Another approach keeps the same components and systems without giving the new system write access, but by adding components and systems to expand in-game functionality, what would it look like? Consider a basic on-chain chess game, where a system of moves and rules has been deployed. People can play the game just like real-life chess, but maybe your team decides to create an extra layer: a social layer with a rating system for matching or any other use case. All you need to do is add a rating component and a system with rating rules. This not only allows users to migrate to new game versions very seamlessly (better user experience), but also creates the technical means for different versions to coexist or overlap with each other at the smart contract level. Players can play on different game versions while interacting with data from the same core components, which is very innovative in addition to composability applications. It creates the ability to opt-in to immutability, creating another dimension of ownership that on-chain gaming offers. True ownership of different game assets (e.g. scores, NFTs, achievements) is protected by immutable logic that can be expanded with additional upgrades but does not change at its core. It solves one of the major issues with Web3 games, which is the ability for creators to cripple assets without consent.

Client overall perspective:

Please note that MUD is an ongoing project. The next part may not be up to date, and may have some inaccurate descriptions, but the overall architecture should not change dramatically.

So far, we have studied MUD at the smart contract level. But there's more, MUD provides a complete suite of client libraries and layers, and MUD is designed with some unique features.

1. Client composability

2. The client is fully synchronized with blockchain state changes (game data)

3. PhaserX as rendering layer

Let We dig into the technical details to make it more concrete.



Network layer:

The network layer is the base layer of the client. It contains basic configuration (World contract, game and network configuration) and API for game interaction. When you create a network layer, it has specifications for all the different components and systems that your clients can interact with, and you can choose to only interact with specific components/systems.

For example, if you wish to create movement in your game and represent it on the front-end, you will need to create a smart contract deployed with the position component, and the movement Network layer for system synchronization. Now you can create a Move API that acts on a location and some in-game object (entity) and sets its position or moves it from one place to another. Any time a player can use the Move API, they will submit a transaction to the blockchain. For the motion system, they will execute the functions in the motion system smart contract.

This structure allows multi-client based games. Everyone can create a unique client, and all clients are equally valid as long as they sync with the blockchain and follow the network layer infrastructure. We've seen really cool use cases for multi-client games, such as in Dark Forest where players compete against each other but use different clients and plugins. The structure of the client allows us to embed it at the network layer and modify the API to get different client versions very quickly, achieving a high level of client plasticity and composability.

You may ask how client components synchronize with chain components. This is one of the big challenges developers face when dealing with on-chain game clients, and MUD has some solutions.

First of all, MUD introduces the snapshot function, which allows the client to synchronize with the World state (that is, the component's entity value) without having to process all past events to reconstruct the state. , thereby reducing latency and reducing complexity.

In addition, MUD's ID system, in which each system (System) and component (Component) will get an id based on its name, and when deployed, they Will be registered in the World contract, making it easier to track changes and interact with the game.

Rendering layer: when and how events are rendered

MUD comes with PhaserX, "a highly scalable engine built on Phaser", PhaserX is not required. In OPcraft, the Noa voxel engine is used instead of PhaserX. In theory, you can use any engine as long as it follows the structure.

As mentioned before, each component and system is registered on the World contract, and when a change occurs, an event will be emitted (with the component ID and entity ID and other identification data). Here the ECS streaming service can provide the client with the option to choose which events to subscribe to.

The graphical representation of an entity can be whatever you want it to be. Fighting games can feature anime characters, knights, or even your favorite crypto KOL. They are all valid versions as long as they represent and react to on-chain events.

Original link: https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY