[MUD-Dev] Object Architecture

[Brian Lindahl]

>From : "Ben Chambers" <bjchamb at bellsouth.net>

> How do you implement your MUD?  Which objects do you use?  How do
> they interact?  If on Java, how do you divide your projects?  I'm
> wondering because I'm at the beginning phase of design of my own
> MUD, and was wondering how other systems have implemented these
> things.  Any other information about the arrangement of your
> objects within your MUD would be interesting as well.

I started designing my scatch C++ mud quite some time ago. My OOP
style is pretty detailed, in that I have large inheritance trees
usually. As such, I won't go into great detail, but here are some of
the more profound ideas I use:

  1) Actor/Brain Relationships
  2) Input Handlers
  3) Event Queue
  4) Database Filing System
  5)a Scripting Language

1) Actor/Brain Relationships

  The concept of the Actor and the Brain is quite similar to that of
  an object and a force. A Brain handles all AI and decides what to
  tell an Actor to do. An Actor relays sensual information to the
  Brain based upon it's attributes. Sometimes an Actor may act on
  it's own, without a Brain, this is a reaction. All players connect
  with a Brain, which is then later attatched to an Actor of some
  kind. This Actor may be a chat room Avatar, a discussion board
  Avatar, a character in the world, the limits are endless. As far
  as the world goes, I intend on describing each object/race as a
  class derived from Actor so I can interchange Brains with
  ease. Brains will also handle all of the AI and I intend on taking
  my AI model to the same extreme, designing an AI for each race,
  and quite possibly for different attitudes of a race. However, I
  may utilize my scripting language to flesh out AIs to a high level
  of detail, while using Brain derived AI classes to handle simple
  AI decisions.

2) Input Handlers

  Essentially, all Actors are input handlers. They have a method for
  handling input and parsing the input into a meaningfull
  reaction. This could be modeled with a seperate InputHandler which
  mediates between a UserBrain and an Actor, although I prefer to
  encapsulate the InputHandler in the Actor, since all the data the
  InputHandler will be modifying will be contained in the Actor, in
  most cases.

3) Event Queue

  This concept is pretty straight forward. Using a hash table as a
  Scheduler, you can schedule events in the future. The Scheduler
  also keeps track of the smallest time value that all of it's
  Events may have. Each game loop, if the smallest time value <=
  current time, a hash lookup is used to obtain a list. The list is
  then searched through, firing off all events who's execution time
  <= current time. Events are an abstract data type with a virtual
  function of execute. Each event type encapsulates the data it
  needs to execute the event, as well as defining 'execute' as to
  what it should do upon execution.

4) Database Filing System

  This concept is one that many have looked into. Many in the past
  have used an SQL database, or something similar to handle files. I
  am currently working on a FreeBSD/Linux/Windows compatable MudDB
  library which will be optimized for Object Oriented Mud Database
  systems. The language will be C++. My goal with this system was to
  create a database system which is optimized for MUDs so that one
  could either use it as a serialization structure for primary
  storage and secondary storage, or as a secondary storage
  substitute for mud objects, which are most commonly stored in
  primary storage. For those of you that do not know, primary
  storage refers to RAM and secondary storage most commonly, and in
  this case, refers to a hard drive or some other file system.

5) Scripting Language

  Like the Event Queue, this concept is also rather straight
  forward. I believe that any quality MUD out there should have some
  form of a scripting language. I have chosen to go the compiled
  route, as opposed to the interpretted route. I intend on having
  scripts compiled into a fast-execution bytecode format from a high
  level language that I have begun to design. I may also release
  this part of my code as a library, as I intend to do with MudDB.

These are some of the major decisions I've made while designing a
C++ MUD. If you're looking for more specific, I suppose I can flesh
out more detail. I'm going a non-conventional route for my
locational system, but I won't delve into that until I've begun to
actually design the code.

Hope this helped,

-Brian Lindahl, coder of TCP ('The Cathyle Project')
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev