[MUD-Dev] Re: Combat Was Re: Leaving characters in play

[Adam Wiggins]

On Mon, 18 May 1998, Oliver Jowett wrote:
> On Mon, 18 May 1998, Orion Henry wrote:
> > -- Actions all have a priority that the queue is sorted by.  The priority
> > levels we had decided on were (from lowest to highest) menial, information
> > gathing, life-or-death, reactionary, and involentary.
> 
> I have a feeling I've seen discussion of this before on the list, but 
> anyway..

Yes, I wrote many a message on this topic.  Mainly when we had just
finished implementing it (about a year and a half ago now, I think) and
were very busy patting ourselves on the back. :)  Seriously, it's a very
cool system that has stood the test of time very well.  We've yet to come
across any actions which we couldn't do elegantly in this system.  And the
source file for *all* the handler code is something like 250 lines, so
it's not like it's difficult to implement.

> How long do actions last in the queue? How are they affected by changes in
> the environment?

This is probably the least fleshed out part so far.  Actions get kicked
out based on simple length of the queue.  At a certain point low priority
actions start getting dropped off the far end if they've been "put off"
for too long.  As Orion has illustrated with his examples (I'll try not to
repeat him too much), that means that if you are momentarily interrupted,
you return to what you were doing, but if you do something important for a
long time your 'forget' about the piddling stuff you were doing before.

Thus:

% hide
You hide in the shadows.
% [...]
Bubba arrives from the south.
Bubba looks around furtively.
Bubba sets down a bag of treasure.
Bubba picks up a shovel.
Bubba begins digging a hole.
% palm bag
You furtively nab the bag.
You return to hiding.
% [...]
Bubba finishes digging the hole.
Bubba frowns.
Bubba says, 'hum, must have left it in the other room'
Bubba leaves north.

But:

% hide
You hide in the shadows.
% [..]
A dragon appears from the north.
The dragon massacres you with his bite.
% 
[long fight]
The dragon is dead!
%

Note no 'you return to hiding' at the end.

>   > get sword
>   > open chest
>   You pick up the sword.
>   Bubba charges in and swings his sword at you!
>   > parry
>   You parry Bubba's wild blow.
> 
> [.. combat ..]
> 
>   Bubba casts the dreaded "make all chests electrified" spell.
>   > skewer bubba
>   You skewer Bubba with your sword. He collapses to the ground.
>   You open the chest. ZAP! You are dead!
>   > say damn!

Although I realize this isn't a very good answer, we actually get around
this by not doing things like the above. :)  Seriously, we've designed
character actions as things that take time and perparation, in hopes to
reduce the action-game feel to the gameplay.  Our magic system doesn't
have any spells, instead it involves a pretty complicated process of
channeling elemental forces from some source, focusing them in your body,
and then streaming them into a target.  There are *no* commands that
happen instantly when you type them.  Thus you always have warning.  I
might add that magic (which is *very* hard to come by, and does not have
any 'spells' persay) takes a long time to execute, and gives several
pretty nasty-looking messages warning you what's going on.  If you're
still around when the spell is released, you get what you deserve.

Which brings up an important point: the system doesn't work unless *all*
actions which physically affect the world are implemented as tasks.
Otherwise you get the affects I mentioned in that thread about Jon's
turn-based combat where you can abuse the asyncronous freebie commands in
order to get advantages.  (Note: status commands like "config" or "score"
are flagged as being system-level commands and do happen the moment you
type them.  But those are the only ones.)

> Perhaps parse commands when received, to the point where you know what it
> refers to (ie. resolve context at the point the command is entered, not
> when the action un-queues). Then, if there is a visible state change in

Yes, that's what happens.  In some cases, if the action is a long one, it
gives a "you begin.." message, which ends up chaining a series of tasks.

One of the first major uses I made of the task system was to implent
lockpicking in a slightly more interesting way than "You pick the lock."
Since I'm at work I can't pull up a direct log at the moment, and I'm too
lazy to try to remember all the messages, but I'll try to give the gist of
it:

% pick lock with lockpicks
You begin attempting to pick the lock on the door with your lockpicks.
You slip one lockpick into the lower part of the keyhole.
You slip the second lockpick into the upper part of the keyhole.
% say okay just give me a sec
You say, 'Okay, just give me a sec'
You continue lockpicking.
You probe gently with the lower pick, searching for the tooth-guard.
[...]
You press gently inwards with the top pick.
A soft click cues the completion of your work.
% smile

> what a queued action refers to, and the action has been queued for >N
> seconds, cancel it / require confirmation from the player. 

Nods...actually, this is all rather tranparent to the player, so we've
tried to limit the amount of manipulation they do to the queue.  In fact,
they shouldn't even really be aware that they have a queue at all.
There is the 'stop' command, but tasks generally transpire so quickly (it
is rare that a task should have an execution time of more than two
seconds) that it's not really all that useful.

We *do* do simple validation of object targets, of course, but that's just
simple stuff like:

You raise your weapon to swing at Bubba.
Bubba flees north.
Your weapon cuts through empty air.

or:

% open door
You are suddenly teleported away.
You stop attempting to open the door, confused.
%

or, more likely:

% tickle bubba
A huge fireball arrives from the north and incinerates Bubba, leaving a
small pile of black goo on the ground.
You decide not to tickle Bubba, after all.
%

> Or the system could drop lower-priority actions if something "important"
> happens? eg. >X higher-priority actions queued since the low-priority
> action was.

Right.  Little things tend to get 'lost' in times of stress.  If it's
something that you really care about you can always use the '!' override
to increase the priority of a small action.

> This could be desirable and/or irritating for other reasons:
> 
>   Ouch! You have an itchy ear! You scratch it.
>   > open chest
>   Ooh, that ear really is sore. You scratch it some more.
>   > look in mirror
>   Scratch, scratch.
>   Yup, looks like you've got a nasty rash on your ear.
>   Scratch, scratch.
>   You forget about opening the chest for now. That ear sure is itchy!
>   > grumble


Hehe, sure.

Adam



--
MUD-Dev: Advancing an unrealised future.