{MUD} Re: roleplaying & combat

[Alex Oren]

On Mon, 26 Aug 1996 14:50:29 -0700, JCL wrote:

} > } [JCL:]
} > } 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[...]

} > [Alex:]
} > A direct requirement of the C&C model.
} > An event that didn't successfully complete does not exist.

} [JCL:]
} 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.

But what happens if Command1 contends with Command2?

} 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,

That is more or less what I meant.

} but there's no behavioural requirement for it.

OK.

} > } [JCL:]
} > } 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.

How would you know *beforehand* what objects will be involved in the execution
of the events?

} 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.

I disagree. Indirectly calling a method on objX will not necessarily cause event
C to fail C&C.

} > 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.

I think that the serialization requirement (when needed) should be based on
events, whether they result from commands or not.
Commands are just a simple case where we have predetermined the order of event
invocation.

Consider the case of two events, A and B.
It may be the case that the order of event completion will influence the results
of those events (we had lots of "dragon examples" to that effect).

I think that we need a mechanism that will ensure that the end result of all the
invoked events will be the same as if the evens were processed in strictly
serial fashion with a predetermined order.

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

Can this sequencing be generalized to include all events?

In the sake of "purity" I feel that the engine should not be concerned with the
origin of events (user commands or otherwise).


Have fun,
Alex.