{MUD} Re: roleplaying & combat

[Wout Mertens]

On Fri, 23 Aug 1996, Chris Lawrence wrote:

> On Aug 22, 11:23am, Chris Gray wrote:
> > [ChrisL:]
> 
> > :  1) by default commands must compleat in submission order.
> > :  2) a command must be able to be explicitly excepted from having to
> > :     compleat in submission order.
> > :  3) a command must be able to control the processing of prior commands
> >
> > Why have 3) at all? It seems to be the trigger of all of the complexity.
> > Real life doesn't let you undo or change something already done. I would
> > guess that most DM's in RPG's done allow it either.
> 
> To allow a player to enter a command ala:
> 
>   > do this then that then the other then kill fred

Ok, how about this:

The scheduler keeps a list of on-commit events. This is sorted by event
ID (a number that stays across rescheduling), and has a returnvalue field,
and a to-run event field.

When an event commits, it can give a return value, and the scheduler then
checks the list to see if the ID is there and then matches the return
value with the saved field. The matching one(s) gets put on the to
process list, and the others are killed.

When you add an event, you ask the object that is to run it if it should
only run after another event. if so, fill that event in in the list.

So for exaple, the player object could be asked if north should be run now
or later, and since the player object knows that east is the last command
that had something to do with movement, it says the ID of east. The
scheduler checks to see if east already compleated and if not, adds north
to the on-compleat list.

Whaddayathink?

Wout.