MUD – Autonomous Worlds Architect Engine

Abstraction is the Key to Making Software Easy to Extend and Improve — Alan Kay

The Origin of Game Engines

From General to Abstract Evolution

Traditional Web2 game development has evolved from a monolithic code architecture to a game engine framework-based elastic development mode. Like all engine frameworks, the main problem to be solved is the conflict between abstraction and concreteness. For example, the game battle module, the process of players joining and leaving is almost the same for all game designs. We can abstract it into a series of interfaces, and then give it to game developers to implement specific instances, similar to the interface and implementation design in object-oriented programming.

The most popular game framework in the game industry is Unity. Unity was founded by three young people, David Helgason, Nicholas Francis, and Joachim Ante, in 2004. It was listed on the stock exchange in 2020 and currently has a market value of $16 billion. The launch of Unity originated from the high cost of game development at the time. The development cost was often tens of thousands of dollars. So these three young people started from the garage and shouted the slogan “Democratizing The Game Engine”. As of now, Unity has taken up 48% of the market share, serving more than 270 million game players worldwide, and more than 70% of games are developed based on Unity.

Currently, the development of GameFi involves the interaction of on-chain state, asset management, and off-chain game logic. After the team behind the MUD framework – Lattice, has developed and designed a number of full-chain games such as Dark Forest and OpCraft, they began to shift their focus from the detailed development of games to how to abstract out a full-chain/AW game framework, redefining the on-chain game state management interface and composition, and permission management (ECS abstract model). This led to the division of labor and collaboration between the game development team and the engine framework team, with the former focusing on the value logic of the game and the latter mainly driving the design and integration of abstract underlying capabilities. MUD is more like Unity in the field of AW (Autonomous Worlds) games.

The Evolution of the MUD Core Architecture

ECS Architecture – V1 Version

The ECS architecture (Entity/Component/System) was not originated by MUD. It has already been adopted in the Unity engine framework, which is mainly suitable for the design of large and complex games. In fact, the ECS design concept is not a new thing, it was proposed in the 1990s. However, it was widely recognized by the game industry from the game Overwatch. In 2017, the Overwatch team shared their best practices at GDC: “Overwatch Gameplay Architecture and Netcode”. In this technical sharing, the best practices of ECS were fully proposed, including modules: World, Entity, Component and System.

The MUD framework is based on the industry-popular ECS foundation, and it summarizes the design of AW games based on on-chain computing and state pattern. The main design idea is to separate state and computation, and the concept of state driven by player and system events.

Entity
- An entity is an ID that corresponds to a set of components, such as a player character in the game.
Component
- A component is used to store game state and does not have any behavior, such as player position and level.
System
- A system has behavior but no state, such as combat action behavior.

0xparc has detailed the details and cases of ECS in his technical article “MUD: An engine for Autonomous Worlds“.

Community Computers – V2 Improvements

V2 version has made more improvements in on-chain state management, contract permission inheritance and composition compared to V1. In particular, the concept of Community Computers has been proposed, which provides a more solid technical and design concept foundation for the AW game scene.

World – Community Computers

World independently contains Resources and Namespaces. The three core resources are Namespace, Table and System. The following is an example. Based on namespace, write/read permission control can be implemented.

root
|-- mudswap <- Namespace
    | Balance <- Table
    | Pool <- Table
    | Transfer <- System
|-- Tetris <- Namespace
    | Board <- Table
    | Move <- System
    | Drop <- System
    | Score <- Table
    | Win <- System

Game developers can deploy independently or inherit, which provides a larger imagination space. The following hypothetical scenarios are given:

I am building an independent proof of concept: start with a new World.
I am building a project for a new chain that does not yet have a World: start with a new World.
I am building features for an existing project, such as a market for on-chain games or an aggregator of two AMMs deployed in the same world: build on the World that contains the application you want to extend.
I want some features that can only be installed by the root user/DAO of the World, and the World does not contain them: start with a new World.
I want to add new features to the application I built before: build on the World where you originally deployed the application.

Based on the permission and space design of the world, MUD proposes a new concept: Community Computers.

Storage Store – Multi-Chain State Management

In V2 version, the concept of entity (Entity) is replaced by a new module called Store. The upper layer implements a SQLite-like interface, and the underlying chain-based contract implements the on-chain database (Onchain Database). This design directly shields the complexity of multi-chain state management and provides functions such as multi-chain state management and interoperability.

// definition of MyTable
tables: {
  MyTable: {
    schema: {
      foo: "uint256",
      bar: "bool",
      fooArray: "uint256[]", // Store supports dynamic arrays
      barArray: "uint256[2]" // Store also supports static arrays
    },
  },
}

MODE Client – Reduce the Complexity of State Queries

The MODE module greatly reduces the complexity of state queries for game clients, helping developers to shield the original full-node transaction detail decomposition. The main core functions are: efficient store indexing, depending on the special client Node https://mud.dev/mode [PostgresDB]

MUD Ecosystem Landing

Open Source Contributor Activity

By analyzing the statistical indicators of the GitHub code repository, we can see that the code update frequency has become more active since April this year, with a record of nearly 100 contributions per month. Currently, there are approximately 39 active open source contributors, and alvrs and holic are the two most contributing authors.

MUD Ecosystem Games Landing

The team behind MUD, Lattice, has also begun to actively support the incubation and innovation of AW games this year. In May of this year, Lattice supported an AW Hackathon at ETHGlobal, providing $50,000 in support. During the event, 435 developers registered and submitted 109 projects. In the end, 10 winners were selected.

🧱 OPCraft2
🤑 Coin Race
🧬 Autonomous Game of Life
🍩 Netherscape
🎲 MUDVRF
🗺️ Realm of Pepe
🎨 Isle of Colors
💎 Garnet
⚔️ PFP WAR
🚢 Trade Wars