[MUD-Dev] Combat Systems

[Phillip Lenhardt]

On Thu, Jul 27, 2000 at 03:22:40PM -0700, adam at treyarch.com wrote:
> On Wed, 19 Jul 2000, Ben wrote:
> > Can you provide more detailed information about your task model?
> 
> Each character has a task list.  The top node in the list is considered
> their current task: the one they are doing at this moment in time.
> In fact, their room description is generated based on this task: for example,
> you might see "Bubba is sitting here, honing a steel dagger" or "Boffo
> is standing here, eating an apple."
> 
> Tasks have a number of parameters, including priority (MENIAL, MOVEMENT,
> LIFE_OR_DEATH, and MUST, in accending order), target entity, accessory entity,
> time remaining to finish the task, and extra data which is specific to the
> type of task.
> 
> Almost all commands do nothing except to add a task to the character's current
> task queue.  The task add function inserts the task into the queue in front of
> any tasks of lower priority (but behind tasks of the same or greater priority)
> The most common scenario, of course, is that you have no tasks to begin with,
> and so the new task simply becomes the top node in the list.
> 
> If you already were doing something, and this task interrupts it, the other
> task is "suspended" and its time delay is saved, and you switch your
> attention to the new task.
> 
> Many tasks that take a long time (such as the famous digging the canal
> example) are actually broken up into many small tasks, each one which
> increments your "progress" on whatever it is you're doing.  This covers
> singing songs, repairing items, honing a blade, picking locks, eating,
> and so forth.  There are a few tasks which never end on their own, but
> instead wait for the player to interrupt them with something else.
> The primary example is the "hide" task.
> 
> Currently these long-term tasks don't easily allow for interruption.
> Originally it was set up such that it was easy to take a bite of your bread
> while honing your sword.  This turned out to be too unplayable, so it was
> changed a little bit.  You can still interrupt a lower priority task with a
> higher one - such as movement, or combat.
> 
> You can type "stop <task name>" at any time to stop a task of any priority
> lower than MUST, or you can type "stop" to simply stop everything you are
> doing.
> 
> The task handler has a lot of verification functionality, where it makes
> sure that your target and accessory entities are still accessable.
> For example, if you're picking a lock, and you walk away, it will cancel
> the lockpicking.  Ditto if someone breaks down the door from the other side...

The scheduler in Moebius works along these same lines, but we have one
global queue into which we insert events. Just like you, we simulate long
actions by having the Nth event in a long action schedule the N+1th event.

If I can convince Kevin (which mostly means I have to write the code :), we'll
be using a compare and commit strategy for each event as what you call
verification functionality.

We currently don't have a standard way to cancel a future event, but I can
see at least two ways of doing it. One would be to maintain a list of
the unique event ids we assign and delete from that list as needed. Another
would be for us to make sure that an invalid event always failed C&C by
poisoning its copies of objects. But the best way for us is probably to have
some sort function that gets called just before the event starts executing
that checks that the event has even a chance of passing C&C.

All the user-facing functionality you have is likely a ways off for us, but
it's nice to see that our basic assumptions can result in a working system.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev