The ideals of web3 seem to fit perfectly with the gaming industry and the gamification trend of recent years. For quite some time, we’ve been promised a new disruption in the shape of a unique experience- On-chain-gaming. With properties such as decentralisation which shift the power balance from the incumbents of the gaming industry much more towards the creative entities, composability that breaks the walls of the long-closed gardens, and true ownership for players.

But these powerful ideals remain aside as we have yet to see them in practice. MUD is the first brave attempt to create a complete framework for on-chain games, a spark that might ignite the next generation of games. This is not a pipe dream. In their short-lived period MUD team is responsible for OPcraft an actual 3D Minecraft-themed game fully on-chain.

Lessons from the traditional gaming industry

Much can be said about the obsession to innovate, build everything from the ground up, and create an entirely new creature. But regarding gaming, there are dozens of years of lessons in design patterns and the creation of a new engineering niche that should be taken seriously. Dismissing these is the equivalent of trying to create an AAA game with Atari tech.

When looking into the early years of game development, we can see an unmistakable resemblance to on-chain gaming — vast amounts of talents and highly inspirational projects but also a lack of coordination and clear frameworks.

In the early days of video games, before the inception of game engines, established convictions and design patterns. Different video games had little in common, up to a point, similar games could have a completely different code base. But with the introduction of game engines, everything changed.

It’s hard to exactly establish a clear distinction between game engines and the games themselves. Generally, game engines are frameworks with a set of rules and design patterns that can be slightly modified and extended to create different game implementations. In the ’90s, after years of fragmented game development, something changed, and “genre-based” gaming engines and some efforts to develop general-purpose engines took the lead. Games like Doom and Unreal had core components that could be reused for creating many different games. Games with similar genres started to share many of their core logic implantations. The cost and complexity of developing racing, fighting, and first-person-shooter games decreased in orders of magnitude. The impossible became possible, and generations of games and upgraded code have accumulated on top of each other. From a software perspective, this is one of the main reasons game development became a huge industry.

There are a few core problems associated with on-chain games:

1. Lack of frameworks: Every team is trying to build everything from scratch resulting in poor efficiency and a lack of systemic knowledge following the aggregated experience of builders tackling the same issues and optimizing towards the best solutions.

2. Lack of code reusability: Take many of the on-chain games being developed today. How many of them can be copied successfully to create slightly different games? How many of them have a clear distinction between different layers and components of the game that allows building a new generation with a similar code base? The promise of creating the most significant and interconnected open-source project for games seems far away.

3. Lack of data composability: It doesn’t end with code reusability. It’s also about the ability of on-chain games to leverage the shared blockchain state to build on top of each other using the data of game A in-game B. In practice, it takes much work and resources to incorporate the data and logic of one game into the other.

The solution of MUD:

Mud is the first brave attempt to create an engine and framework for on-chain games by providing the structure for Maintainability, upgradability, and moldability. The Entity Component System (ECS) pattern advocated by mud makes sense not just in the sense of general game development but even more so for on-chain game development.

ECS in smart contracts:

The most basic building blocks in MUD are components. They are deployed contracts that function like databases that store data about entities. For example, let’s take an entity (an address) like the player’s wallet. This entity represented by an address can have different properties, such as position value(x,y) in the position component, level 10 in the level component, and 50 in the coins component . Components consist only of a mapping and basic configuration. Systems are more complicated and implement the logic of changing the value in components. You can think about this as systems specifics the API for POST requests on the databases (components). They could do so only if granted writing access to specific components. Here it gets interesting. Systems can interact with different components to create detailed logic. You can have a movement system that specifies the valid movement player can make (e.g., two steps each time), and you can have a reward system that gives players coins each time they level up. All of them are registered at “World contact” such that every change in component data is followed by an emitted event. World contracts are permissionless. Anyone can add new systems and components. In theory, different worlds can interact with each other.

Bringing ECS to on-chain games results in a very elegant structure, such that OPcraft only consists of 10 components and about 15 systems. You can check this great blog post on MUD.dev

True composability

The ECS system doesn’t just make perfect sense in traditional game development but even more so in on-chain games by providing two important features

1. Upgradability of deployed game

2. The highest degree of composability

Imagine two paths. One is to preserve the base design. And the other is changing core game logic.

Think about a standard PVP strategy game in which players can build armies to battle each other. The base version was 2D, but now the team has decided they want to create a detailed 3D render of the game. All they need to do is to take all the position-related systems and create upgraded versions with (x,y,z) coordinates instead of(x,y). All the other systems and components (like attack system, HP, and army building) can remain the same. It even goes beyond the initial dev teams, communities can create different mods of the game by redeploying systems and components or even interact with the same components by granting writing access to new systems(if it’s a community-owned game, various governance models can be applied for these kinds of decisions)

The other approach will keep the same components and systems without giving new systems writing access. But with added components and systems to extend functionalities within the game, what might it look like? Consider a basic on-chain chess game. Moves and rules systems are already deployed. People can play the game as if they were playing real-life chess, but maybe your team decides that you need to create an additional layer, a social one that consists of a rating system for matchmaking or any other use case. All you need to do is add a rating component and a system with rating rules. This results not only in a very seamless shift to new game versions (improved UX) but also creates the technical means for different versions to co-exist side by side or on top of each other at the smart contract level. Players may stay on various game versions while interacting with the same core components’ data, which is very innovative, apart from composability applications. It creates a feature of opt-in immutability, creating another dimension of ownership that on-chain games would provide. True ownership of different game assets(like score, NFTs, achievements) that is secured by immutable logic that might be extended with additional upgrades but not changing in its core. It solves one of the main problems of web3 games, which is the ability of creators to nerf assets without consent.

Client side an overall perspective:

Notice MUD is a project in progress. The next part may not be up to date and contain some inaccuracies and rough distinctions, but the general architecture is not expected to be changed drastically.

So far, we have looked into MUD at the smart contract level. But there’s much more. MUD provides a full suite with client libraries and layers. There are a few unique features MUD is designed for.

1. Client composability

2. The client fully synced with blockchain state change (game data)

3. PhaserX as the rendering layer

Let’s dive 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 config) and the API for game interactions. When the network layer is created, it has a specification of all the different components and systems your client will be able to interact with, and you may choose to interact only with specific components/systems. For example, if you wish to create movement in your game and give it representation on the frontend, you’ll need to create a network layer that syncs with the position component’s deployed smart contract and also with the movement system. Now you can create a Move API that takes a position and some in-game object (entity) and sets its position or move it from one place to another. Any time players would use the Move API. They are going to submit a transaction to the blockchain. In the case of the movement system, they are going to execute a function within the movement system smart contract.

This structure allows multi-client-based games. Everyone would be able to create unique clients, and all of them are equally valid as long as they are synced with blockchain and follow the network layer base structure. We’ve seen very cool use cases for multi-client games, such as in the case of a dark forest, in which players compete against each other but use different clients and plugins. The client’s structure allows us to take network layer implantation and modify the API to get different client versions very quickly, achieving a high level of client moldability and composability.

You might ask how exactly the client components sync with chain components. This is one of the significant challenges builders face when dealing with the client side of on-chain games. MUD has a few solutions for it.

First, MUD put in place a snapshot feature that allows the client to sync with the world state (i.e., values of entities by components) without processing all the past events to reconstruct the state, which results in low latency and decreased complexity.

Also, the ID system of MUD, in which every system and component gets an id based on their name, and upon deployment, they get registered at the world contract, making it much more accessible to track changes, interact with the game, and fetch events easily.

Rendering layer - when and how events rendered

MUD comes with PhaserX, “A highly scalable engine building on top of phaser”, PhaserX is not mandatory. In OPcraft, there is a Noa voxel engine instead of PhaserX. In theory, you can use any engine you would like as long it follows the structure.

As stated earlier, every component and system is registered on the world contract, and when a change takes place, an event will be emitted(with identified data such as component ID and entity ID). Here the ECS stream service can provide the client with the option to choose which events to subscribe to.

The graphical representation of entities can be whatever you want. A fighting game could have anime characters, knights, or even your favorite crypto influencers. All of them are valid versions as long they represent and react to on-chain events.

Additional resources

Game Engine Architecture- Jason Gregory

In the next part we’re going to dive deep with a detailed tutorial. If you’re builder looking to build on MUD please dm @Natan_benish **
**

Article written by:

Don’t miss upcoming articles: