[MUD-Dev] C&C and Event Rescheduling

[clawrenc at cup.hp.com]

In <33F3D6A9.82A at dial.pipex.com>, on 08/14/97 
   at 01:09 PM, Richard Woolcock <KaVir at dial.pipex.com> said:

>clawrenc at cup.hp.com wrote:

>> A silly implementation to be sure, but it illustrates.  Another:
>> 
>>   > n,n,n,n,n,n,n,n,n,e,e,e,e,e,e
>>   You go north
>>   ...
>>   There an incredibly valuable diamond here.
>>   You go north.
>>   You go east.
>>   You go east.
>>   ...
>>   > Go back!  Go back!
>>   ...
>>   > l
>>   There is nothing here.

>Well suppose you have an update every half second or so, which
>performs the next command on the list, sort of like:

Some background here.

I'm working on an explicitly multi-threaded potentially event-driven
server where there is no concept of a tick, nor any polling loops. 
User commands generate events.  The pool of currently ready to execute
events execute simultaneously in a thread pool, competing to compleat. 


The actual process:

  User enters command.
  Command is translated to an event, which is merely a specified 
    method call on an object with known arguments.
  Command event sent to Dispatchor with a ZERO_DELAY flag.
  Dispatchor sends the command to the Executor.
  Executor puts event on the Event Queue (priority sorted).
  Events on the Event Queue are assigned in priority order to the 
    the first free thread in the Event Pool for execution.
  Command event gets executed and command is parsed.
  This generates a new event to do the actual command.
  New event is sent to the Dispatchor etc.

Its all, very very parallelised.
  
The current model is slightly more complex than the diagram above, in
that user command events are assigned sequence numbers.  The
Dispatchor's Event List is actually now split into three lists:  1)
Timed events, 2) Uncertainly timed events, 3) Sequenced player events. 
Now when an event sucessfully compleats (C&C's), its sequence ID is
sent back to the dispatchor as a new event with a special key value,
causing the next sequence ID event to be released.

Now of course players can enter commands which are to be executed in
parallel to their normal command/event stream.  The only change
required to ensure that these events are processed correctly is to no
assign them a sequecne number, and to then place them on the normal
(uncertainly) timed events queue, and let rip from there.  High
priority interrupts are then just handled as a variation on this --
non sequenced commands which start with high priority levels.  

The question of job control for parallelised event streams of course
still remains:

  > what am I doing?
  Digging the panama canal.
  Getting hungry.
  etc...
  > stop digging.
  You stop digging the panama canal.

>>n,n,e,n,n        | Your commands list now has 'n'->'n'->'e'->'n'->'n'

Each of which are individual entries in the Dispatchor's event list,
or the Event Queue.  

>You walk north.
>[half a second later].

I have severe allergic reactions to tick based systems. 
Characteristically I prefer the "as fast as the system will let you,"
model. The idea that I'll deliberately program a system so that a
human can wait on a computer seems treasonous.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...