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

[Joe Andrieu]

> -----Original Message-----
> From: Robert Zubek

[snip]

> 2. how to handle long-lasting events

>   somewhat related to the above is the technical side of how to
>   handle events. what i *think* is the standard approach is that
>   there's one global event queue from which events get popped off
>   and dispatched to the appropriate handler (global or local).

>   in this architecture, how does one elegantly handle temporally
>   extended events - for example, a spell that takes several
>   minutes to cast? the handler obviously can't block while waiting
>   for the event to finish.

>   one could imagine a number of solutions inspired by operating
>   systems research - perhaps implementing a fake
>   continuation-passing style (as a kind of non-preemptive
>   multitasking: a temporally-extended action would be expected to
>   initialize itself, do a fraction of the necessary processing,
>   then put a new fake event on the queue saying "continue the
>   spell event", and exit). or, if threads were cheap on that
>   system, one might consider actually spawning a new thread for
>   each call to the handler, and let those that take a while just
>   run quietly in the background until they finish.

>   temporally extended events is just one thing that's likely to
>   cause event processing problems - i'd be curious to hear what
>   are some other problems? what are the practical implementations
>   of event handling?  how well do they work?

Hey Rob.

Good questions. Let me address just the one question above.

My First Question: How do you measure the passage of time?  Is the
system running "realtime" or is there an internally generated time
mechanism? In the former, you now are in the realm of realtime
systems and operating with high-priority interrupts and all sorts of
ugly stuff that can get complicated. (It was because of incorrect
priority cascades that the Mars Sojourner robot crashed until they
could correct it.) Unless you are programming for deployment on real
robots, you probably don't need this.

First Assumption: Time is measured by internal representations of
units of time, aka "Ticks".

Second assumption: there are some data elements in your model,
"Objects", which have some means of semi-permanent instantiation
(persistent unless destroyed).

Third assumption: some subset of your objects are recipients of the
"tick" event the objects are "Living Objects". (The simplest case is
to have all living objects get all the ticks all the time. There are
also more complicated ways to manage it, but I digress.)

A long term event then is one that occurs over several ticks.  So,
instantiate an object which is active for the appropriate number of
ticks and engages in the activity.  Regarding your spell example, I
have seen systems which spawn a shadow object which attaches itself
to the user and performs its action over a long period of time. For
example, a poison object which slowly drains the character of 1 hp
every tick for 50 ticks and then deletes itself.

As long as objects are persistent and there is a periodic time
event, it is fairly straightforward to instantiate an object to
handle longer term events.

Alternatively, you can code various states into existing objects for
the same effect, e.g., if your character object is so coded, it
could have isSick = TRUE; and sickDamage = 1; sickTimeOut = 50; and
generate the same effect as the poison object.  Whether you want to
put everything into a base code or have objects instantiated on the
fly is a more complicated design issue which has no wrong answers,
just lamer ones.

I'm sure there are other ways to handle the passage of time and
events, but this is one that I've seen and used and been happy with.

-j

--
Joe Andrieu
jandrieu at caltech.edu
+1 (626) 395-8045

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