MUD

Intro

How to write a MUD.

Parts

• Data store: Persistence for the world state
• Game rules: The rules for the game.
• Interface: How people interact with the game.

Notice how the parts map directly to MVC.

Data Store (Model)

I'd like to have a data store that is extremely flexible. That means, I can define new data types on the fly, and have them all sit behind appropriate indexes. I'd like to have a reasonable caching strategy so that I am not disk bound but I can still have a pretty reliable backup.

The closest thing we have to this today is something like PostgreSQL. Stick that behind SQLAlchemy, and you get *dang* close.

Game Rules (Controller)

At the heart of the game rules is going to be a system where people can interact with the game itself. That is, tell their character to move or pick something up. But another important part is the messaging to the people about what is happening.

Then there are actions not caused by player characters. These would be governed by some sort of clock.

It's clear that most of the rules are defined as, "When X happens, do Y."

I'll discuss more of what the actual rules are later, and how you can add or change the rules, but the fundamentals are pretty obvious.

• Entities exist.
• Those entities have attributes, attributes that relate them to other entities or define quantities or values.
• Entities may observe events happening around them. These events may include ticks of the clock, things that are seen, felt, heard, or such.
• Entities may interact with the things around them by modifying the game state, usually their own state.
• Actions have a start, a duration, and an end. During each of these phases, the game state changes based on the type of action, as well as the entity state.

At the heart of the above is an Event Queue. Like the processes in an OS, the Event Queue is a list of everything that is happening, or will happen, ordered by when they will happen.

Events in the event queue need not be handled synchronously. A good MUD would be processing events in parallel.

The Actor Model

The Actor Model is a different way to look at the problem altogether. In the Actor Model, each object receives messages and changes their state in response to them. It may also send out messages of its own.

The Actor Model can be implemented pretty easily with greenlets.

Interface (View)

How players interact with the game world is through the interface.

At the most basic level, a TTY connection may be sufficient. At the more advanced level, perhaps the character has a special client that can interpret the game state. Or perhaps they will make web requests to the game server to see what has happened since the last update or declare actions.

Each of these views has a different requirement from the others. They share some elements, but other elements are completely different.

Threading

In a MUD, lots of things should be going on at the same time all the time. This is really great environment to work with threads, especially microthreads or greenlets.

It may make sense to describe an action as a cascading series of instantaneous events. It may make more sense to simply define a greenlet that interrupts itself when an action has completed its instantaneous event and needs to wait for the next one.

A Universe you Program

A MUD is really not much different than an OS. However, the intentions are different. Rather than manage computer resources, MUDs focus on how entities interact with each other. In particular, it allows people to communicate one with another, either through chatting or through creating entire worlds and algorithms to explore.