[MUD-Dev] Creating a MUD - Overview of design

[Daniel.Harman at barclayscapital.com]

From: Neil Edwards [mailto:neil at anyisle.org]

> Hi there, I have been writing a very simple MUD in java for ages
> now, getting so far then scrapping it all and re-writing it for
> sake of better ideas.

Well think carefully before starting from scratch, whilst it may be
necessary, you could end up de-railing th whole project.

> Firstly, object persistance. By this I mean that objects in the
> game (inc.  rooms etc) are always stored in some form or another
> for backup and actual use. In my MUD I just read everything from
> text files (XML formatted) and then keep everything in memory
> until it periodically saves everything again in case of a crash
> (Not yet implemented online creation but should be easy enough). I
> was hoping to move this system to a database system (been looking
> at MySQL (free) ) but I don't think I fully understand what goes
> into the database or how it is referenced. For example, if I have
> a table which holds all the items (swords etc.) that can be
> created in the game then do I also have another table that holds
> all of the actual items in use by the game and how do I reference
> these (by ID wouldn't work because two items of the same ID can be
> different (quality of sword, same sword less durable) so don't
> really know what to do there. At the momement I just have several
> Vectors in a room object that hold items, players, actors (NPCs)
> and other things. How would I change this to a database model? 
> Should I even bother?

I don't have a lot of time for flat file persistence models, I've
run into so many problem with them in my admitedly short
career. They tend to have this trait of nice performance for
one-five clients, and then complete inability to scale. Compound
that with inability to swiftly create bespoke queries and lack of
transactions (important) and I feel there is a very strong argument
to use a DB.

As to your particular problem, its easily solved. You would have one
table which would be the master item table, containing fields that
won't change over time and probably the starting values of those
that do. In addition, you would have an item instance table which
references items in the master item table, and has further fields
representing an items current state etc.


   Master Item                  Item Instance
   --------------------         ------------------------
  | primary key ItemID |___    | primary key InstanceID |
  |--------------------|   \__/|------------------------|
  | string Name        |      \| foreign key ItemID     |
  | number Weight      |       | number Wear            |
  | number Type        |       | number Quality         |
  | ...                |       | ...                    |
   --------------------         ------------------------
                           ^^ 1 to many relationship

> Secondly, networking. I have read that tcp is overly slow and that
> I should use udp (at least, I think that's what I read!) but
> surely with so little information being sent (it is only text
> based after all) then does that really matter? Also at the moment
> I have some simple ServerSocket which accepts requests from
> clients and sends each client off on it's own thread which waits
> on it. I have read that it is better to just have a few threads
> polling each client to see if they have written anything. Could
> anyone give me some MUD specific examples because I don't really
> see how the to put the one's on Sun's website into practice.

Well firstly, don't worry about UDP, its not really relevant to text
MUDs.  UDP has advantages for graphical/twitch games, but if you are
just punting ASCII around its largely irrelevant. As to the thread
per client model, that was a java limitation although it has been
addressed in 1.4 I believe. I'm not much of a java head though, so
search the mailing list for some info on this as it has been
mentioned several times in the last 2 weeks, or just check out the
1.4 docs.

Dan

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