[MUD-Dev] Combat Systems

[adam at treyarch.com]

On Wed, 19 Jul 2000, Ben wrote:
> From: <adam at treyarch.com>
> > I have seen implementations on other muds, although in many cases they
> > are only one level deep.  I'd be interested in hearing a listing of some
> > other muds that put character event queues to good use.  Then perhaps we
> > could discuss some actual implementations, places they work and places
> > they fail, rather than falling into the all-too-familiar "This will never
> > work!"/"Yes it will, dammit!" debate.
> 
> Can you provide more detailed information about your task model?

I known I've gone into detail about it many times in the past, but
unfortunately my archive searches haven't turned up any of the posts
in question.  So here it is again...

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

An example.  Out of band comments are in square brackets.

% l
A Room
exits: n e w s
% fish
You toss your line towards the water and begin to fish.
% hone sword
['hone' is equal priority to 'fish', so it gets added to the end of the queue]
%
[pause]
You reel in your line, a catfish on its hook.
You begin honing a sword.
[pause]
You drag your whetstone along the blade.
% w
[movement is higher priority than honing, so the task interrupts]
You head west.
[pause]
Another Room
exits: n e w s
%
[pause]
You drag your whetstone along the blade.
[pause]
You flip the blade over and begin honing the other side.
[pause]
You drag your whetstone along the blade.
[pause]
You finish your honing.
The blade is slightly sharper.
%

In practice, the "coolness" of the priority queue is mostly lost on players.
95% of the time they are doing one thing at a time.  Probably the main
advantage that they notice is that they are never stuck in artificial "lag"
that many muds use to delay player actions; they can always stop what they
are doing, or interrupt it with something of higher priority.

In fact, the tasks system has turned out to be not so much a gain to the
players, but a gain to me as a developer.  I can make actions stretch out
over time the way that they should without having to write anything special,
because it's all handled by the task system.  I just flesh out the "prepare"
and "resolve" functions for a given task, and don't worry about the red tape
of making it happen.

In fact, there is NO special code for handling the flow of combat.  Starting
combat is simply a matter of adding the combat task to each combatant, and
then the combat resolve function decided whether to launch an attack or
a defense (both of which are tasks).  Players can insert their own combat
tasks at any time (with commands like "attack", "resuce", "battlecry",
"retreat", "flee"...).

Another nice side-effect is that there's never a need to "spam" commands.  One
only needs to type "retreat" once, for example, and your character will
continue to try to leave combat until they succeed (or you type "stop
retreat").

There's more, but that's the jist of it.  All in all I'm quite happy with
it, and it pains me to see that many (most?) muds are still using a more
antiquitated system for character states and actions.  In fact, I'm
currently pondering a source release - it's not difficult to implement,
so perhaps showing how easy it is might inspire a few implementors.

Adam





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