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

[Miroslav Silovic]

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

This is an answer to both of the above. Currently Cold uses $scheduler to
implement timed pause (i.e. to keep the task suspended for a number of
seconds). The normal way of implementing 'animation' is to schedule
next move of the monster to some time in the future, and to cancel the
scheduled task if anything else happens. Don't get me wrong, even though
it's currently implemented in the core and runs off heartbeat (basically
$scheduler object checks the task queue every few seconds and resumes
the tasks that need it), it properly belongs to the driver.

Both ways are slow, though - 1000 monsters running around are plenty, unless
you set them to a rather long period, say, a minute ($scheduler uses heap
and it doesn't have problems with a large number of active tasks, the
bottleneck is the actual movement). Cold simply isn't meant to simulate
the world in the same way it's done in DIKU (but there are other ways.
For instance, you can make the monsters /really/ smart. And you can get
them to wind down, so that they sleep unless something is happening
nearby).

Oh, and to respond something else, Cold is not threaded yet, except for
the cooperative multitasking supported by interpreter itself. The reason
for it is that we decided that it'd take us ages to finish the system if
we do it, so threading is scheduled for the next major version. Also,
thanks to cooperative thingie, Cold doesn't face any of the problems
usually associated with threads, and currently has no builtin systems
that deal with it.

	Miro

PS. Thanks for inviting me to the list. :) I see it could be fun.

Background notice: I'm working on Cold development, and I expect to be
instantly recognized by the people involved with it. I mostly play
MUSHes, and I tend to enphasize roleplaying over slashing, imagination
over code, and imagination-stimulating code (such as weather,
player-to-player informational systems, detailed geography, good
building support) over video-game code - unless it really is *smashing*
game code. :)