[MUD-Dev] Re: Multi-threaded mudding (was a flamefest)

Jeff Kesselman jeffk at tenetwork.com
Fri May 2 20:33:21 New Zealand Standard Time 1997

At 08:08 PM 5/2/97 PST8PDT, you wrote:
>On 02/05/97 at 05:58 PM, Jeff Kesselman <jeffk at tenetwork.com> said: >At
>04:38 PM 5/2/97 PST8PDT, coder at null.net wrote:
>>>While technically accurate, its really a questionable point.  ColdX's
>>>definition of envets are tightly limited to connection and I/O state
>>>changes.  It actually has no real concept of an internally generated
>>>event, or even an event model as regards internal state changes for
>>>the DB.  It's only events center on what happens on its network ports.
>>I think to make your poitn vaild you need to explain what the differnece
>>between an "internal event" and a message pass is, in your model. I see
>>no practical difference.  In my model and in the term event driven as I
>>understand it to be commonly used, the only difference is that the call
>>coems from the OS... which is to say it happens inresponse to IO (or the
>>clock, which is also a form of IO really.)
>A running MUD has the unusual property of being self-animating.  Ignoring
>the questions of swapping out inactive areas etc, even if no users ever
>log in, the mobiles will continue to wander their paths, night and day
>will progess thru the MUD world, weather will change, seasons will pass. 
>The game world will animate itself.
>I model these animations as events.  A mobile moves his next step by
>having a closing event log a new event to step him forward some time in
>the future.  

Pardon me, but it soudns like syntactic sugar on top of a timer event.

I just don't see it as beign paradigmaticly really all that different from
animating off of a generic call back timer.  I have sucha  thing in my Cold
core runnign off the heartbeat,as  I suspect virtually every Cold core does.

Thanks for giving me the reference, though.


More information about the MUD-Dev mailing list