mpMUD: Overall Architecture

There are three distinct 'entities' which together make up the MUD:
  * Core (aka driver/engine/server)
  * Modules (somewhat like a LP mudlib)
  * World (definitions of objects, etc.)
  
The core contains basic functionality such as:
  * Object management
  * Connection handling
  * Event scheduling

The modules implement generic aspects of the world, such as:
  * Player commands (get, drop, look, quit)
  * Object containment (person in chair in room in house in world)
  * Object states (standing/sitting, damage level(s), locked chests, etc.)

The world consists of definitions and instances of objects; it defines the attributes of things, like how much a chair weighs. It also defines behaviors of unique objects, like that magic sword.

------------------------------------------------------------------------
Events

mpMUD is event-based. A sorted queue of events is kept; on each main loop iteration, the topmost event's "runs-in" time is checked, and the server blocks waiting for IO or until that time is up, at which point it runs the event.

Events are stored across reboots along with the world (see below).

------------------------------------------------------------------------
World

The world is fully persistent - all state is saved to disk; a reboot has no effect on the world. Some consequences of this:
  * Resets/repops are even more obviously Wrong
  * There will need to be a way of cleaning up junk
  * Player bodies are simply saved with the rest of the world, eliminating the need for a separate mechanism for saving players.

Currently, the world is divided into rooms. I have written down a plan for a coordinate-based world, but have not yet implemented it.

------------------------------------------------------------------------
Players

Players are kept distinct from their bodies. Inside the world, it is impossible to tell whether a body is a PC or a NPC. Eventually, I plan to have NPC AI which is implemented through a separate process connecting to the MUD just like players do.

When a connection is made to the MUD, a connection object is created. This object initially contains the connection's current "state", the socket, and possibly information about the player's terminal, if it can be found.

The "state" of the connection determines what prompt is sent, and how incoming text is processed. 

Once a player has logged in, their preferences and body's ID number are loaded from their player file. When they enter the game world, their connection is "linked" to the body, which allows the output from the body to be sent to the connection, and commands from the connection to be sent to the body. A possible extension is to allow multiple bodies per connection (swarms or multiplaying or admins controlling NPCs) or multiple connections with one body (schizophrenia or multi-headed monsters?).

(On a side note, I think that a persistent world goes well with permanent player death. With separate PC save files, you can just reread the player file and would have to explicitly take action to delete it. With PCs saved in the world, you have to take action to get the PC back to a pre-death state.)

------------------------------------------------------------------------
Objects

Among the things I've decided not to do is have a system like LP's, where the majority of objects' behavior is defined by custom code. Instead, most/all objects have NO code; instead, they have "fields" (or "attributes" if you prefer) which define the object.

Objects' fields can be inherited from other objects using the 'prototype' system. Generally, one prototype object is created, and actual in-world instances of the object merely inherit from the prototype.

When an object's fields are modified, they are copied from the prototype into the object, then modified. It is probably not a good idea for an object's prototype to be 'in the world' and therefore modifiable by players; however, doing so might allow for some 'magical' effects.

------------------------------------------------------------------------
