In-depth Analysis of Full-Stack Game Engine MUD

The original text was posted on PANEWS.

Traditional Game Engines#

A game engine is a software framework used for developing and creating electronic games. It includes many core functionalities required for game development, such as rendering engines, audio processing, physics simulation, and animation systems, among others. By using a game engine, developers can focus on game design and creativity without having to build the entire technical infrastructure from scratch. Game engines provide developers with a fast and efficient tool to reduce development costs and time.

There are many well-known traditional game engines for Web2 games, such as Unity, Unreal Engine, and Godot, among others. These engines are not only suitable for professional developers but also for independent developers and beginners. Game engines are highly customizable and can be adjusted according to project requirements. They usually support cross-platform development, allowing developers to create games for various devices, such as personal computers, game consoles, and mobile devices, among others. Additionally, many engines also provide support for virtual reality (VR) and augmented reality (AR) to meet the evolving technological needs. Game engines also include a rich set of tools to help developers easily create game worlds, characters, and objects. These tools contribute to an efficient game development process, including visual scene editors, script editors, animation, and effects tools, among others.

Full-Stack Game Engines#

Game engines play a crucial role in game development. For full-stack games, developers also need a tool that can help them quickly deploy game logic. This not only shortens the development cycle but also provides a unified data standard for iterative development and interoperability in an open ecosystem.

In this field, a mature project is the MUD full-stack game engine based on Solidity, developed by Lattice Studio. It allows developers to quickly deploy game logic to smart contracts and achieve functions such as contract-client state synchronization, significantly improving development efficiency.

It is worth noting that, besides Solidity, Cairo in StarkNet is also a commonly used language for full-stack games. However, MUD is not compatible with Cairo. Therefore, the founders of two active projects in the StarkNet ecosystem, Realms and Briq, have jointly developed Dojo, a full-stack engine based on Cairo. Due to the similar core concept of Dojo and MUD, it has caused dissatisfaction from Ludens, the founder of MUD. However, after some controversy, Ludens eventually expressed willingness to assist in deploying MUD to StarkNet.

ECS Architecture#

The biggest challenge in developing a game engine is how to represent game objects, which can range from simple 2D images without control or interaction to complex 3D objects with control, sound, animation, and AI. Conceptually, game objects can be understood as entities with multiple functionalities in the game. Initially, object-oriented programming (OOP) was used, but now the more popular architecture is ECS (Entity Component System).

ECS improves the flexibility and maintainability of game development by separating logic, data, and entities. This architecture pattern helps reduce code complexity, minimize coupling, and improve performance and development efficiency. ECS consists of the following three main components:

Entity: An entity is a basic object in the game world, such as characters, props, or scene objects. An entity itself does not contain any data or logic; it is only a unique identifier used to associate components and systems.
Component: Components are used to store the properties and data of entities. Each component represents a specific feature or functionality, such as position, velocity, or health, among others. Components only contain data and do not include any logic. By combining different components, entities with various functionalities and characteristics can be easily created.
System: Systems are responsible for handling game logic and behavior. Systems perform operations based on the components owned by entities. For example, a movement system will look for entities with position and velocity components and update their positions based on their velocities. Systems are independent of entities and components, making game logic more modular and reusable.

ECS helps address some issues in game development with traditional object-oriented programming (OOP), such as deep inheritance hierarchies and difficulties in code reuse. ECS makes the construction of game objects more flexible, allowing complex behaviors to be easily created by combining different components. Additionally, ECS helps optimize performance, especially when dealing with a large number of game objects. Many modern game engines, such as Unity and Godot, have adopted ECS as their core architecture.

Full-stack games, Web2 games, and even common GameFi games (games with blockchain-based assets but the game itself is not on the blockchain) have significant differences. For example, Solidity is commonly used as the programming language, and the properties and states of game objects are stored in smart contracts. This makes traditional OOP unusable, and ECS architecture must be adopted.

Let's take a look at Solidity, which has unknowingly used a variant of this pattern. Taking the ERC-20 contract as an example: The ERC-20 contract stores the token balances of each address in a mapping (from address to uint256 balance). We can consider each ERC-20 contract as a table with two columns: "address" and "balance". This corresponds to a component with a single pattern value ("balance"). Each row in the table associates an entity ("address") with a component value ("balance"). An address can hold balances in many independent ERC-20 contracts, which corresponds to an entity associated with many independent component values. In the current ERC-20 reference implementation, the state and logic are coupled in the same contract. In ECS, we would have a generic "transfer system" to handle the logic of transferring tokens from one address to another by modifying the state stored in the token component.

Another example is a simple video game with available components such as "position" and "health". Entities with positions have an entry in the position component, and entities with health have an entry in the health component. The "movement system" can implement rules for moving entities from one position to another. The "combat system" can implement combat logic based on the positions of involved entities and modify their health.

MUD Game Engine#

MUD is an Ethereum application framework. Its core consists of a set of contract interfaces and conventions for using them. These core interfaces and libraries enable a range of tools, integrations, and libraries to work more smoothly, making the development of on-chain applications more concise.

MUD can achieve the following functionalities:

Currently:

State synchronization between contracts and clients without custom network code
Generic indexer without custom indexing code
Seamless contract upgrades (+ automatic contract upgrades during development)
Shared state between contracts
Optimistic updates
Automatically generated types for contracts and systems
Query language for interacting with contract states
Data browser for inspecting and modifying contract and local states
Bit packing utilities

Future:

Local simulation of transactions (including optimistic states)
Built-in support for account abstraction
Contract package manager

The MUD framework consists of eight library files.

SOLECS is the core Solidity library of MUD, which includes interfaces and reference implementations for on-chain components, systems, and more. Since all states are stored in components and all state updates are registered in the central World contract, MUD can provide out-of-the-box network logic to achieve synchronization between contract and client states.
RECS is a reactive ECS library implemented in TypeScript. It can be used independently of any on-chain components but can also be used together with SOLECS to mirror on-chain states in the same format on the client side.
Services include common indexers for synchronizing on-chain states using the aforementioned methods.
Network is a library for state synchronization between smart contracts and nodes.

Dojo, based on StarkNet, is similar in functionality to MUD and can be considered as a reimplementation of MUD using the Cairo language. Therefore, it will not be further explained. The MUD developer documentation provides a specific example to teach how to develop a full-stack game, Emojimon, in just one day. Interested readers can refer to the official tutorial: https://mud.dev/tutorials/emojimon/

Games Developed with MUD#

Sky Strife
Sky Strife is an on-chain game built using MUD. The game features fast-paced real-time strategy (RTS) battles, where players compete to escape the battlefield with the "Ember Crown."

Kamigotchi
Kamigotchi is a multiplayer online role-playing idle game with PvP mechanics. Players can harvest $KAMI from nodes scattered around the world using their Kamigotchi (referred to as "Kami"). $KAMI can be used to upgrade Kamis and purchase food. However, harvesting consumes the life of the Kami, and when the life is low, other players can hunt down the Kami with their own Kamis. Players need to keep their Kamis well-fed and carefully observe them to maximize output. Death is not permanent, as the core NFTs are unaffected, but it comes at a cost - a killed Kami cannot be used again in the game unless revived using certain consumables from the store, which requires $KAMI. Additionally, the experience will affect the mood of the Kami.

Muddy Forest
Muddy Forest is a fully on-chain, large-scale multiplayer online real-time strategy space conquest game, where every action, from transportation and resource sending to planet occupation, occurs on the blockchain.