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

[Orion Henry]

At 10:42 PM 5/18/98 +1200, Oliver wrote:
>On Mon, 18 May 1998, Orion Henry wrote:
>
>> >I have a feeling I've seen discussion of this before on the list, but 
>> >anyway..
>> 
>> Yes, this was brought system was brougt up over a year ago.  Its been so
>> long since we have talked combat systems and we have so many new
>> subscribers I didnt feel bad about recycling it.  Also all the luck stuff
>> at the end was new and I was curious as to what people thought.
>
>I actually meant the "how do you work out which actions are appropriate"
>idea - I'm sure I saw a thread to do with climbing trees vs. finding
>healers at one point. WebGlimpse on the archives is spitting internal
>server errors at me currently, and the other search engine is timing out, 
>so I can't find it :(

That tree climbing thing was an offshoot of the first time we presented
this system.


>> >  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!
>> 
>> hahaha... yes, that COULD happen under the system as I understand it.  I
>> had a few things to compensate:  1) the "stop" command clears the queue of
>> all volintary actions.  Thus if you see something bad heading your way you
>> can immidatly stop your action queue.
>
>Hm, well, my point was that it might kick in before you have a chance to
>react, which is why you want the system to be intelligent about which
>actions it selects. more on this below.
>
>> 2) different actions have different
>> fragility levels.  If you get bonked on the head you will most likely
>> forget about your apple.  If you casually kill bubba without breaking a
>> sweat you'd go right back to eating it.  Some things (like counting) get
>> broken very easily. ;)
>
>Right, this sounds like what I was suggesting later. Anything significant
>should interrupt less important actions, so combat of any length would
>probably result in the open chest action being cancelled.
>
>Do you use a simple priority system to work out what to cancel? ie. "being
>bonked on the head cancels all actions at priority 'menial'"? Or
>something more complex like "if I'm bonked on the head more than twice in
>10 seconds, cancel all actions at 'menial' that will take more than 5s 
>to execute"? Or something different again?

I was planning on adding a fragility level to each possible action.  Things
like pain, loud noises or being distracted could cause them to fall out of
the queue.  Now I have to admit you have a lot of good points on what to do
when an action is surpressed and then resurfaces.  My stubbornness on this
is rooted in the fact that most of the things I am implimenting in the mud
are there to achieve my "cinematic realism" quota.  Basically I choose a
cool action movie and try to figure out what I need to add to the code so
that all the things that happen in the movie could easily happen in the
dayly context of the mud.  "The Princess Bride" was a big contributor, with
the flashing sword play vs. the standard Diku 400 hp with platemail and a
big axe.  The rice ball scene at the begining of "Ninja Scroll" is what I'm
aiming at with the priority queue. (If you have seen it you know what I am
talking about, and if you havent go see it).  The hero is munching on a
ball of rice and is jumped by 3 thugs.  He tosses the ball straight up,
dispatches all three, does a cool cinematic pose where we slides the sword
back into his shieth, and then catches the ball of rice and keeps eating. 

I figure that with this system 90% of the time the menial actions will be
dropped in combat... but when the character dosnt break a sweat in the
fight I am assumign the player isnt either, and just to puncutate the
bad-ass-ness of the situation let them keep doing whatever it was without
considering the fight an interuption.

>I can see the advantages of having a more complex system, so that someone
>can't sit there and repeatedly scream "WE'RE UNDER ATTACK" in your face,
>thus preventing you from ever eating your apple. Conversely, a lot of this
>system seems to be oriented around improving player control - at least
>partially to counteract the speed-demon-typist syndrome, I suspect: it's
>so that the character has some basic intelligence of its own, rather than
>being a mindless puppet. 

Absolutly.  It does many things for me.  The character is more intelegent.
Actions are paced correctly.  The flow of combat is realistic with people
on the offensive and defensive, w/ parrys, dodges and counterattacks all
makign sense.  Light vs. Heavy weapons work correctly.  Spamming commands
is useless.  Actions and execution of actions seem more realistic and dont
allow for as many reality loopholes for players.  It lets me avoid an ugly
"Combat" state that is somehow seporate from the rest of the world. I have
to admit I have become quite fond of the system.

>You want a -predictable- system, as requiring a
>player to constantly guess what their character will do if they enter a
>command doesn't seem too enjoyable to me.

I have been hopeing that if I do things correctly the character will only
forget about the old actions if the player does too, avoiding confusion.
If you were right in the middle of stacking plates and washign dishes when
an ogred tried to kill you, needless to say you have  to stop and stack
stock of the situation to figure out where you where when things calmed
down... "Now where was I..."  If the fight was quick and clean and
painless, quite likely the character will just keep washing dishes as if
nothing had happened, just as the player would want. ( I think )  This
looks like a great opertunity for customization on the players part...


>Not sure on this - the ear was probably a bad example. You want to assume
>that if the player suddenly enters a stream of high-priority actions, or
>if a pile of reflex actions kick in, then something -important- is
>happening, and the player doesn't want to be worried about whether he'll
>be opening the chest next.

Right... the trick is figureing out what is important.  I'm working under
the assumption that if the actions are of high priority in the first palce
then they are important.  Byond that I assume that if the characer breaks a
sweat, its reasonable that he'll forget the menial tasks he was doing.  And
lastly if the "player" views something as really important then he will
issue a stop command to drop everythign and then get to work.

>There's an element of "people don't -do- that!" in here too. Having
>players eat apples while fighting off dragons and opening chests in the
>breaks in combat seems vaguely obsessive-compulsive to me. "Ooh, he's
>pausing to cast a fireball, I can open another chest! <creak> <boom>"

Heheheh... I have an information priority action called "on guard" that
blocks you from doing anything menail.  It lets you react faster to
attacks, lets you notice things like knives in the back better.  And since
its not life-or-death priority you can use the time to check out your
oponent, notice how wounded they are, how tired ect... being "on guard" is
a standard reaction to other people being on guard or people casting spells
ect... thus everyone tends to be on guard even for a bit after combat
stops... thus the above is not likely to happen.
 

>Perhaps suspend actions when there's something important going on, and
>remind the player about them in some way when the fuss dies down.
>
>   > open chest
>   A dragon flies in and tries to eat you. Ouch.
>   [.. combat ..]
>   The dragon collapses to the ground, dead.
>   You could probably continue opening the chest now.
>   > continue
>   You open the chest.

This is a really good idea, but my "Ninja Scroll" sensibilities will
proboly prevent me from useing it.  Alas...

Now... heres something I have been working on in the back of my head, and
if any of you old school hackers have any ideas on how I should code this
please let me know.  I havnt found a data structure that I feel is simple
and straight forward enough.

I wanted to make the priority queue more complex, wider.  Where actions tie
up bodyparts as well as priorites.  Thus, when sword fighting with someone,
your hands and eyes are doing things at life-or-death but your mouth is not
so you can still talk to someone in the midts of the fray, without slowing
your attacks down.  At the same time you would have to stagger your coments
while eating an apple as each in turn would need access of the mouth.  Each
action would require some limbs to be free.  This would also automate limb
loss.  If you are missing both your legs a walk command will never get off
as it cant get the limbs needed, but a crawl command would work as it only
needs arms, and for the quadraplegis, wriggle would only require a torso ;)
 This would also make it easy to automate things like grabbing an opponent
or having your hands tied or being in an arm lock.  You could define one
arm as a prime hand and one as an off hand.  Actions like blocking a blow
could be done with an off hand but most attacks would require a primehand.
Thus you can block with your shield, and while that arm is tied up on the
queue, you could attack with your other hand.  If you simply defined
someone as ambidextrous as having two primehands they could have two
simultanoius queues of hand actions being processed at once.  This would
allow you to easily add things like 4 armed races or winged races where the
"fly" action requires 2 wings.  Things get sticky and I start to get
confused when I consider attacking with a two handed sword that needs any
two hands.  If i impliment parallel queues, one hand delay could get stuck
behind if one queue was cloged and one was not, while in practice I'd want
both hands to get stuck until both queues are open... Also I wanted to
leave things open for things like limbs that are both hands and feet...
like a chimp...

	Any ideas?

	Orion



--
MUD-Dev: Advancing an unrealised future.