{MUD} Re: roleplaying & combat

[Chris Lawrence]

On Aug 26,  5:53pm, Alex Oren wrote:
> Subject: Re: {MUD} Re: roleplaying & combat
> On Mon, 26 Aug 1996 09:02:28 -0700, JCL wrote:

> } I think Alex had the right idea is saying that by 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[...]
>
> A direct requirement of the C&C model.
> An event that didn't successfully complete does not exist.

Not true.  What you appear to be missing is the difference between an event
starting processing, and an event compleating.  Consider:

  > Command1
  > Command2

The requirement is that the above commands must compleat in order, ie Command1
must compleat before Command2 compleats.  What this does not mean is that
Command1 and Command2 cannot be processing at the same instant.  Consider:

  > Command1
  > Command2
  Command2 starts processing.  // Note: the order of what command started
  Command1 starts processing.  // first is immaterial.
  Command2 finishes processing, but blocks, waiting for Command1 to C&C.
  Command1 finishes processing.
  Command1 C&C's.
  Command2 C&C's.

Now I can simplify the processing model somewhat by requiring that a command
can only start processing when its immediate processor has compleated
processing, and there may be some efficiency gains to be garnered from this
rule due to fewer events failing C&C and having to be rescheduled, but there's
no behavioural requirement for it.

The example quoted below looks at a specific case of three commands entered in
sequence, and allowing their out-of-order processing, while continueing to
require their in-order compleation.

> }   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.
>
> Some questions:
>
> 1) Event C calls a method on objectY, which calls a method on objectZ, which
>    calls a method on objectX. How will you handle?

Event C may fail C&C, and so will be rescheduled.  No special handling
required.

> 2) You mention events that are the result of commands.
>    What about events that result from mob programs, user-written scrips,
>    etc.?

They follow all the same rules, except that (one would hope) such automated
events not originating from player characters would not need the ability to
kill all prior uncompleated events.

> 3) Consider the following sequence of commands:
>
>       [Bubba is naked, has 1 HP left]
>       #100> north
>       You enter the dragon's cave.
>       There's a sleeping dragon here.
>       There's the magical amulet of invulnerability here.
>       #101> get amulet
>       #102> kill dragon
>
>    Serialization is needed. How will you handle?

I believe I have already admitted the need for guaranteed serialisation of user
commands, which I am intending to approach thru sequence numbers.



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