[MUD-Dev] TECH DGN: a few mud server design questions (long)

[J C Lawrence]

On Wed, 25 Jul 2001 13:20:26 -0500 (CDT) 
Robert Zubek <rob at cs.northwestern.edu> wrote:
> Caliban Tiresias Darklock writes:

> i agree. it seems everyone develops these solutions from scratch,
> which just screams out for knowledge sharing. :) there probably
> isn't any literature on this sort of engine design - but with some
> luck, as more people talk about their design approaches, perhaps
> newbies such as myself will be able to piece together a more
> coherent picture. :)

There's quite a bit of this sort of thing in the list archives.  At
least three significantly different base design approaches are
documented there.

  Note: The search engine at Kanga.Nu is currently roughly 60% of
  the way through re-indexing the list archives.  Blame it on a
  silly finger slip on my part.

> this is quite cool. how would you say does this impact
> extensibility of the mud? does this mean that adding a new type of
> action requires changing all three handlers?

I didn't take that sort of approach as it assumed and required a
central intelligence or at least configuration for all significant
object features.  I want to support and actively encourage free
end-user programming in the game world and so don't want the
relatively high barrier of having to explicitly allow access to new
methods:

  Well, I added a method to this object.  Whaddya mean I can't just
  call it?

While it breeds dirty code, I need to explicitly support ad hoc
programming.

>> This is the normal response. If I were implementing something
>> like this, I'd place these events into a time-sorted queue which
>> popped events off when they became due and passed them along. In
>> the meantime, I'd set a state on the appropriate objects that
>> caused other events to either fail or force the failure of the
>> pending event.

> ah, that sounds good. i was trying to figure out whether there's a
> clean way to hide the multithreading, so that temporally-extended
> events would be indistinguishable to the programmer from regular
> ones - but that doesn't look at all easy. and besides, the
> programmer needs *some* control over the entrance and exit points
> for the event.

There are at least two methods that have been extensively discussed
on this list, the C&C model I use, and Jon Lambert's model (which
doesn't suffer the penalty of having a cute name).  In the end
you're really talking about distributed transactional models and
methods for determining, predictively if possible, rollback
scenarios.  This is an old old field in the world of databases and
has been well researched.
  
      ( Not that I did any research on the area when I picked C&C, )
      ( but that's another matter, or at least should be           )
    O
  o
.

> hehe, yes, as i try to work out the design of the mud, i find
> myself repeatedly needing to simplify the functionality for the
> sake of cleaner implementation. damned tradeoffs. :)

Choice of base models can be all important.

--
J C Lawrence                                    )\._.,--....,'``.	    
---------(*)                                   /,   _.. \   _\  ;`._ ,.
claw at kanga.nu                                 `._.-(,_..'--(,_..'`-.;.'
http://www.kanga.nu/~claw/                     Oh Freddled Gruntbuggly
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev