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

[Shane Gough]

From: Valerio Santinelli

> many objects.  Of course you could still do a query and load the
> objects in memory from MySQL, but this way you lose all the "ons"
> of a RDBMS.

You could use write-through caching. A object loaded the first time
is cached in memory while still referenced - any query of the
objects properties occurs on the cached version. Changing a property
involves changing the in-memory version and then updating the record
with the updated record. This could be done immediately (which does
incur a performance overhead) or on a periodic basis using a
background thread.

In Java maintaining a cache is reasonably trivial if the objects are
cached as WeakReferences. The garbage collector will dump the
objects as necessary - attempts to reference a no-longer valid
cached object will result in an exception, the handler can then
reload the object from the underlying DB.

I'm using a similar system but in C++ on top of Berkeley DB instead
of Java on an RDBMS.

>> 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

Classes and instances. A particular type of sword (eg: Elven Short
Sword) is maintained as a class with a set of default values. When
one is created it makes a copy of the class with a new ID and a
reference to the parent class. This allows an instance of the sword
to have it's properties changed (become rusty, blunt etc) while
maintaining the original definition. No one can own a class
though. This is very much like OO languages such as SmallTalk (and I
Python I believe) where classes are objects too.

> You could have a table with all your basic items, and another one
> with extended attributes. So when you make a new sword you grab
> the basic sword and put its id in the table where you're going to
> put the custom attributes like quality, durability, etc. It's just
> one of the many solutions available with RDBMS.

This is how it would be implemented is a persistence layer - but
think of the 'basic items' table as class definitions and the
'extended attributes' table as object instances. This makes it a
*lot* easier to code with in an OO language.

>> 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.

You may want to look at using a thread pool. This involves a
collecion of worker threads that listen on a shared queue for work
units coming through. You would have to do some monitoring of your
system and the average workload to tune the number of threads
required. You could even code the thread pool to dynamically adjust
the number of available threads to get the performance you desire.

Regards,
Shane

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