<aside> 📢 This document aims to give a list of useful mental models when building Autonomous Worlds with MUD.

</aside>

Top-level mental models

Engineering

• If you have built multiplayer games before, you can think of the blockchain here (Ethereum) as the game server: it holds the state of the game and enforces the rule
• MUD is a toolkit that makes it easy to build gamer-server like applications on top of Ethereum. It comes with all the glue necessary to replicate the state of the game from the server to the client.
• When using MUD, you should model the state of your game in tables. We recommend to use the ECS data-modeling: each “thing” in your world is an entity — a number — and the substance of entities is defined by the components that have been attached to them.
  • As an example, a monster could be represented as an entity with a Position component attached to it, and a Hostile component attached to it.
  • With MUD2, data is stored in tables that do not enforce the ECS paradigm. It is however very easy to make them components by making sure they only have one key-column of type bytes32
• All “inputs” into your game (actions from players that modify the state) should be implemented as systems. Systems enforce the rules and modify the state of the game by writing to the tables you defined. The client will automatically sync the new values from the table.
• MUD is renderer agnostic: it simply synchronizes state. Currentzly MUD only works in the browser — and thus you must use renderers working in the browser. You can render your game as a text and button application using React (we have tooling for React) or Svelte. You can also render it as a list of sprites on the screen using Phaser or as a 3d applications using ThreeJS. We have templates for all these renderers, along with demo applications.

Design

• In Autonomous Worlds, each user action is a transaction. Although MUD 2 provides the most gas-efficient way of building on-chain games at present, the underlying tech still creates an environment in which any game with complex and/or frequent transactions will become very expensive (and slow) to play. There are a few considerations to keep in mind during design to keep costs as low as possible:
  • The most feasible Autonomous Worlds, at present, have a constrained number of user actions (i.e don’t build an FPS or racing game quite yet). This is why Sky Strife, our flagship on-chain game, is a turn-based RTS.
  • The most expensive actions are those that save data to the blockchain (and this is by multiple orders of magnitude). As a rule of thumb, reducing complexity and calculations required in user actions will create a much more feasible game.
  • However: do not think about cost for this hackathon! The worlds will be running on a Testnet (aka a free chain).
• Randomness is not a straight-forward process on-chain and should be used sparingly. The hacky way of doing this, at present, is to use user actions as a seed input for the randomness of events in the world. In other words, randomness can be ‘generated’ after a transaction is made (but cannot happen sporadically).
  • Blockchains are transparent and accessible by anyone; because of this, randomness is not even truly random. A sophisticated user will be able to ascertain events after the seed input is created.
• Anything on-chain is inherently financialized, and as such, will attract malicious actors past a certain scale. When designing Autonomous Worlds it is imperative that you do so with the knowledge that users may create bots (or armies of bots) to exploit it.
  • We recommend designing and building not to prevent the existence of bots in your Autonomous World, but to embrace them and plan around their inevitability.

The concept of time in Autonomous Worlds

• Because Autonomous Worlds are built on blockchains, you must think about time differently.
  • Time passes when blocks are added to the chain. A block encapsulates a series of transactions — they do not need to be financial! A transaction is simply a change in the state of the blockchain.
  • You can measure time passing either as changes in the block number (the amount of blocks that have elapsed), or in terms of “time” set by the node that added the block.
• There is currently no good architecture to add “ticks” to a blockchain: it’s not like a regular game server where you can make stuff happen every X unit of time
  • All actions must stem from a transaction. ie: from a player action.
• It is still possible to represent time passing, as long as it is possible to compute the status of the game state by plugging in time elapsed as a variable, or if the computation is bounded. Example:

  • Can be done Gold being generated linearly for each player.

    Save the last time a player used their gold to do something (build, buy, etc). Every time a player executes an action that requires gold, first refresh the amount of gold a player has based on their previous gold amount, their latest refresh, and the rate of refresh. On the client show the gold as it would be if the player were to make an action now

  • Can be done with tricks Moving monsters in a room automatically.

    When a player moves in a room, the transaction also moves all monsters in the room according to some pre-defined rooms. If you want to make it such that more players don’t make monsters behave faster (due to them making more moves), you can save the last time the monsters got moved and skip the monster move code-path if it happened recently enough. It is important that the code path of moving monster is bounded (eg: there can only be so many monsters in a room). Otherwise it is possible for the game to enter a deadlock where moving a player would lead to such a gas-heavy transaction to move all monsters that it would exceed the maximum block limit.

    Avoid this pattern if possible.

  • Can’t be done Minecraft-like system where the world is alive around you, even without actions

    There doesn’t exist good architecture for this yet.