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

[Jon A. Lambert]

Hi Miro!  Glad to have you aboard.  :-)

Let me fetch some stuff from both posts first an then get on about
what I'm attempting to say.

[J Lambert said:]
> > An event-driven system would need: 
> > Cold                            Cold
> > Subsystem/ ----???? event ----> Subsystem/
> > Object                          Object 
>
> From: Miroslav Silovic <silovic at srce.hr>
> It's right there! :) -- Check $event_handler, which handles listening for
> events, sending events and autoupdates (for instance, you can specify that
> mob listens to events of a certain kind from another object, and that the
> accepted sender changes as the mob moves). The idea with this system
> is that event that is supposed to propagate to a large number of objects
> only hits those objects that care about it.
> 
>:  From: Miroslav Silovic <silovic at srce.hr>
>: 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.

OK, Let me agree that Cold is event driven.  Cold is a generic interactive server.
You are not restricted to programming a mud with it.  The events modeled
within the cold language, because of the application's nature, are "computer"
events.  Objects in the core like $connection, $scheduler, and $event_handler
require a "data processing" view to the application.  There is nothing
wrong with this, it allows great flexibility.

What I am attempting to accomplish is a programmable game server.  The scope
of my core language is limited to objects that are game oriented.  All of the
the objects you mention above have been consigned to the dispatcher as they
have little to do with the "game".  Also all events that take place within visibility
of the interactive mud language are game related and implemented by providing
both syntax constructs and multiple $root classes like $player, $thing, $location 
and game system abstract classes like $help, $table, etc.  Its the bare essentials
on which to build a number of FRPG rules systems on.

The hopeful reasoning behind this is that I don't require builders to be coders
in the traditional sense.  I can build an interactive environment where events and 
objects reside strictly within the problem domain.  Put a "visual" framework
around this interactive programming environment and I hope to have something
that will attract hard-core RPG game players and game masters.


JL