[MUD-Dev] Object Architecture [Longish]

[Draymoor a Vin il'Rogina]

Ben Chambers wrote:

> 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'm going with a largely OOP approach to my mud. C++ with windows
c-style multithreading, c-style function pointers (I'm looking for a
better way, though), and Windows SDK Winsock 2.

One of my main goals in my implementation is to isolate the usage of
pointers as much as possible to within the basic classes that have
to work with them to avoid null pointer crashes. I'm not using java
because at the start of the project I didn't know java, I still
don't have a good enough knowledge of the language, I don't have a
suitable IDE for a large-scale project, and, most importantly, I'm
not willing to start over until I finish what I started. That said,
here're the objects.

  Basic Types:

   Fifo - File Input/Output

   fString - Formatted string

   UniversalObject - An object with an enumerated type
  
     Derivitives of UniversalObject:

      System - Main game driver

      Database - Virtually Linked Hash Table

      ListObject - Object that goes on the database
  
     Derivitives of Database:

      Socket - A socket capable of accepting connections

      Interp - Command Interpreter

      PlayerDB - Database to handle players, hashed by 18-character
      unique names

      ChannelDB - Database to handle logged in-game communication
      and notification channels.

      NSMLParser - Nirvana Standard Markup Language, rather than
      learning XML, I decided to make my own. I recognise this as a
      mistake ;)

      FuncServ - Interp and NSMLParser load their commands/tags from
      file, the file stores the name of the function to be looked up
      on the FuncServ, which holds a static list of all function
      pointers, accessable by name. Allows dynamic modification of
      commands. Is there a better way to do this?
  
     Derivitives of ListObject:

      DescriptData - Connection to a socket, with input/output

      PlayerData - All the data on a player, but not an in-game
      character

      Channel - Stores a dynamicly modifiable channel format, and
      allows for sending messages to all players with that channel
      set to on.

      NSMLTag - A tag stored in the NSMLParser

      CommandEntry - A command stored in the Interp

      Function - function name + pointer, used for lookup in
      FuncServ
  
I have not yet started the actual world code. I'm trying to figure
out how to handle the NSML currently. Any comments/input here would
be appreciated.  Especially criticism :)

As for arrangment, The main loop declares an instance of Socket and
System.  System loads the settings from a file, and socket opens the
port that system defines. Theoreticly, you could run 2 different
ports with totally seperate connections but on the same world/system
settings, vice versa, or just two independant muds on the same
program. I'm not planning on doing that, though ;)

System stores accessable instances of Interp, PlayerDB, ChannelDB,
and NSMLParser, all save the PlayerDB are loaded from file. The
PlayerDB is empty until people login to PCs or start the creation
process. All databases (and derivitives) store a pointer to the
System object, accessable by an alias returning function. All
ListObjects (and derivitives) store a pointer to their database,
accessable by an alias returning function. That way, any object can
link back to the System and access the different subsystems (like
channels). PlayerData also stores a pointer to the descriptor,
accessable just like all the others.

Otherwise, I moderate access between ListObjects by use of their IDs
(__int64) and the databases. This way, if I have a null object, I
don't crash, but rather get a bug-report on the bug channel. When
the world code comes in, I'll be further buffering access by putting
in an event list handler of some kind.

As I said, comments and criticism would be greatly appreciated. I
hope this helped ^_^


| Philip Loguinov
| Draymoor a Vin il'Rogina
| Head Coder/Admin: Nirvana Project
| http://drayworks.dhs.org



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev