{MUD} Re: roleplaying & combat

[Chris Lawrence]

On Aug 23,  8:15pm, Wout Mertens wrote:
> On Fri, 23 Aug 1996, Chris Lawrence wrote:

> > To allow a player to enter a command ala:
> >
> >   > do this then that then the other then kill fred
...(and have them interupt the above somewhere in the middle)....
> 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.

At the implementation level, this would do it, but it would seem to require the
scheduler etc to have prior knowledge of the character of the commands being
processed.

In you example (deleted) you mention movement commands.  The problem is that it
is not only those commands, or more specifically, those combinations of
commands which are sequence specific.

Consider, given the following map:


  +---+---+---+    Where:
  |   |   |   |      X is you.
  | d   D   T |      d is a small weak dragon.
  |   |   |   |      D is an unkillable, massively damaging sleeping dragon.
  +- -+---+---+      T is some great treasure you want.
  |   |
  | X |
  |   |
  +---+

  > n
  > kill dragon
  > e
  > e

It would be uncomfortable if the kill command were processed after the first
east.

> Whaddayathink?

I think Alex had the right idea is saying that be default all commands should
be forced to compleat in entry order.  His suggestion of also not starting
processing on one until the prior command compleats is tantalising, but I think
I'll extend that.  My idea is that a command resulting in an event which does
not call a method on the same object as the event it is sequentially dependant
on, may start processing prior to the event it depends on compleating first
compleating.

ie

  Given the following sequence of entered commands:

    > #1
    > #2
    > #3

  Where those commands result in events A, B and C respectively, and
    where event A calls a method on ObjectX, event B calls a method
    on ObjectX, and event C calls a method on ObjectY.
  A will start processing.
  B cannot start processing until A compleats.
  C may start processing before B compleats.

Another example of why I want to allow interruption of a pre-entered
series of commands:

  > n then e then e then s
  You go north.
  You go east.
    There is a an incredibly valuable object here!
  You go east.
  You go south.

Something like:

  > n then e then e then s
  You go north.
  You go east.
    There is a an incredibly valuable object here!
  > !!
  Queued commands killed.
  > get incredibly valuable object.
  Okay.

would be preferable.


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