The past week, I worked on a project built on MUD with a few others called “Trade Wars,” an open world trading game placed on the high seas, for the ETHGlobal Autonomous Worlds Hackathon. It was a really interesting experience building with MUD and I’ve gathered some thoughts.

A quick primer on WTF of MUD:

MUD is a framework developed by the Lattice team as an game development framework for onchain games. MUD was initially built in response to the challenges faced during development of Dark Forest and other early on chain games. MUD is a full stack framework - using the Optimism’s OP Stack and v2 offers tooling for easier front end creation. There’s a few games already built using MUD, from Sky Strife, OPCraft, and Moving Castles.

This Wired piece also provides a great overview.

Why MUD?

To understand why MUD is interesting and what explains their design decisions its important to ask – why develop MUD in the first place?

Upgradability:

We all know and love the EVM for all the tooling and existing compatibility that it has, but it is really primitive. This is fine with DeFi where the state updates (accounting etc) and the scope of interactions are fairly limited (a small set of immutable contracts).

Importantly, this lack of specificity at the base layer leads to a diversity of approaches to even fairly basic operations.

For instance, the ERC-20 standard is only a recommended standard for how fungible tokens should be created. However, things like honeypots and rebasing tokens all modify this behavior in nonstandard ways, and there’s no way to push forward any changes post finalization.

For ERC-20s where there’s a significant amount of infra built around it, this is a good thing. But for on chain games – it’s much more difficult. Game development is a dynamic process and immutable contracts don’t work very well with this style of development. The focus on frameworks as opposed to standards is in this same vein – if there are going to be changes, it’s better to think about upgradability than bending backwards for compatibility.

Tables

One of the key areas that MUD leans into is the use of table-based storage. Blockchains are frequently derided as expensive SQL databases, but unfortunately this isn’t the case!

Take a mapping for ownership of tokens by address. If a frontend wants to see everyone who holds a sword, there’s no way to do this by directly querying the contracts, given that mappings are only one way. There’s ways around it, but it’s easier to pull things from a database, which makes the process of building frontends much easier.

Instead of needing to query different pieces of state in different contracts, you only need to know the DB schema – just like querying a SQL database in a normal web2 application. This requires a different way of thinking about state in contracts – each contract no longer holds state, but instead writes to the World Contract’s state contract.

This requires some changes in how developers write contracts, but these

Composability

One of the key aspects of autonomous worlds is the composability aspect. These inherently open systems allow and encourage others to hook into these primitives.

There are two ways that MUD encourages composability:

• Client side, via Plug-Ins which modify the player experience via the UI

• Contracts side, via new entities registered with the World contract (Entity Control System)

Both aspects are extremely primitive for now, but a great example of the promise that composability holds.

For plugins, there were plugins like chat, or shared resources which enabled novel means of coordination.

For new entities, this how we’d be able to see things like object interoperability in these worlds – the classic example being the ability to bring a rare sword from one game to another. Admittedly there’s more work to do here – the game needs to explicitly recognize the schema of the table containing the sword for instance.

Despite the reliance on Solidity and its syntax, all of these changes make MUD a really novel way of looking at games – in the same way that React compiling down to Javascript, it opened up the door to the creation of more interactive frontends.

Exciting areas for new onchain games

• zk/ml x AW

New technologies like zk and zkml will first find their footing within onchain games.

The lower stakes nature of games, and the expanded design space of these games allows for exploration into these newer computing primitives. Autonomous in-game agents built using zkml, or zk fog of war as seen in Dark Forest are all aspects that dramatically increase the exploration space for on-chain games.

• DeFi x AW

The deeper integration of DeFi and AW is extremely exciting. We explored this in our game for the hackathon, where the trading system that players used was actually a Balancer v1 style multiasset AMM which allowed arbitrage opportunities for players who could pilot their ships to complete arbitrages between AMMs.

This is still really nascent (there isn’t even ERC-20 compatibility or native ERC-20s) but the ability to create AMMs, interact with other DeFi primitives allows for an exciting new areas.

If I were to put my chips for how AW is able to grow significantly, it’s tapping into existing tokenomic playbooks and expanding on the scope of financial interaction beyond the simple token inflation – token sink model that both bootstrapped P2E games but also caused them to fizzle out due to unsustainability.

• Full stack dapps x AW

The tight integration of frontend and backend make it particularly interesting for practical usage for a full stack dapps, also called hyperapps by Jai Bhavnani. It’s still early stages, but user control of the full stack experience along with the frontend composability via plugins is a really interesting way to think about how we can really see full stack dapps become a thing.

Conclusion:

It’s clear that there is a lot of work to get done on MUD. Just working on it in the past couple days, there were bugs, issues with documentation, and general clunkiness.

But if there’s anything that’s clear it’s that the vibrant community and speed that MUD allows these games to be developed out holds out the promise of truly exciting onchain games.

Special shout out to my teammates Cometshock, Bitzoic as well as the Lattice team for putting together the hackathon and making it a really cool experience.

The past week, I worked on a project built on MUD with a few others called “Trade Wars,” an open world trading game placed on the high seas, for the ETHGlobal Autonomous Worlds Hackathon. It was a really interesting experience building with MUD and I’ve gathered some thoughts.

A quick primer on WTF of MUD:

MUD is a framework developed by the Lattice team as an game development framework for onchain games. MUD was initially built in response to the challenges faced during development of Dark Forest and other early on chain games. MUD is a full stack framework - using the Optimism’s OP Stack and v2 offers tooling for easier front end creation. There’s a few games already built using MUD, from Sky Strife, OPCraft, and Moving Castles.

This Wired piece also provides a great overview.

Why MUD?

To understand why MUD is interesting and what explains their design decisions its important to ask – why develop MUD in the first place?

Upgradability:

We all know and love the EVM for all the tooling and existing compatibility that it has, but it is really primitive. This is fine with DeFi where the state updates (accounting etc) and the scope of interactions are fairly limited (a small set of immutable contracts).

Importantly, this lack of specificity at the base layer leads to a diversity of approaches to even fairly basic operations.

For instance, the ERC-20 standard is only a recommended standard for how fungible tokens should be created. However, things like honeypots and rebasing tokens all modify this behavior in nonstandard ways, and there’s no way to push forward any changes post finalization.

For ERC-20s where there’s a significant amount of infra built around it, this is a good thing. But for on chain games – it’s much more difficult. Game development is a dynamic process and immutable contracts don’t work very well with this style of development. The focus on frameworks as opposed to standards is in this same vein – if there are going to be changes, it’s better to think about upgradability than bending backwards for compatibility.

Tables

One of the key areas that MUD leans into is the use of table-based storage. Blockchains are frequently derided as expensive SQL databases, but unfortunately this isn’t the case!

Take a mapping for ownership of tokens by address. If a frontend wants to see everyone who holds a sword, there’s no way to do this by directly querying the contracts, given that mappings are only one way. There’s ways around it, but it’s easier to pull things from a database, which makes the process of building frontends much easier.

Instead of needing to query different pieces of state in different contracts, you only need to know the DB schema – just like querying a SQL database in a normal web2 application. This requires a different way of thinking about state in contracts – each contract no longer holds state, but instead writes to the World Contract’s state contract.

This requires some changes in how developers write contracts, but these

Composability

One of the key aspects of autonomous worlds is the composability aspect. These inherently open systems allow and encourage others to hook into these primitives.

There are two ways that MUD encourages composability:

• Client side, via Plug-Ins which modify the player experience via the UI

• Contracts side, via new entities registered with the World contract (Entity Control System)

Both aspects are extremely primitive for now, but a great example of the promise that composability holds.

For plugins, there were plugins like chat, or shared resources which enabled novel means of coordination.

For new entities, this how we’d be able to see things like object interoperability in these worlds – the classic example being the ability to bring a rare sword from one game to another. Admittedly there’s more work to do here – the game needs to explicitly recognize the schema of the table containing the sword for instance.

Despite the reliance on Solidity and its syntax, all of these changes make MUD a really novel way of looking at games – in the same way that React compiling down to Javascript, it opened up the door to the creation of more interactive frontends.

Exciting areas for new onchain games

• zk/ml x AW

New technologies like zk and zkml will first find their footing within onchain games.

The lower stakes nature of games, and the expanded design space of these games allows for exploration into these newer computing primitives. Autonomous in-game agents built using zkml, or zk fog of war as seen in Dark Forest are all aspects that dramatically increase the exploration space for on-chain games.

• DeFi x AW

The deeper integration of DeFi and AW is extremely exciting. We explored this in our game for the hackathon, where the trading system that players used was actually a Balancer v1 style multiasset AMM which allowed arbitrage opportunities for players who could pilot their ships to complete arbitrages between AMMs.

This is still really nascent (there isn’t even ERC-20 compatibility or native ERC-20s) but the ability to create AMMs, interact with other DeFi primitives allows for an exciting new areas.

If I were to put my chips for how AW is able to grow significantly, it’s tapping into existing tokenomic playbooks and expanding on the scope of financial interaction beyond the simple token inflation – token sink model that both bootstrapped P2E games but also caused them to fizzle out due to unsustainability.

• Full stack dapps x AW

The tight integration of frontend and backend make it particularly interesting for practical usage for a full stack dapps, also called hyperapps by Jai Bhavnani. It’s still early stages, but user control of the full stack experience along with the frontend composability via plugins is a really interesting way to think about how we can really see full stack dapps become a thing.

Conclusion:

It’s clear that there is a lot of work to get done on MUD. Just working on it in the past couple days, there were bugs, issues with documentation, and general clunkiness.

But if there’s anything that’s clear it’s that the vibrant community and speed that MUD allows these games to be developed out holds out the promise of truly exciting onchain games.

Special shout out to my teammates Cometshock, Bitzoic as well as the Lattice team for putting together the hackathon and making it a really cool experience.