Issues from the digests and Wout's list

clawrenc at cup.hp.com clawrenc at cup.hp.com
Sun Apr 20 11:57:06 CEST 1997


In <199704171445.OAA134695 at out1.ibm.net>, on 04/17/97 
   at 10:28 AM, "Shawn Halpenny" <rsh at dos.nortel.com> said:

I think we're operating with a mismatched set of definitions here. 
This area got thrashed over pretty heavily between Wout, ChrisG, AlexO
and I on the old list, so I guess I forgot to redefine the terms.

My definition of a combat script is a one-shot statement of the combat
actions to attempt in a specific combat round.  It is dynamically
generated, possibly edited by the user, and thrown away as soon as the
round is over.  It is purely a statement of action.  A trivial example
(in english) would be:

  Stab Bubba in the chest with the sword.

It is specific and peculiar to the combat round in question.  It has
no relevance to any other combat round.  It also has no intelligence. 
Any inteliigence embedded in a script via reactions (conditionals) is
purely reactive.  It has no computatioal power.  It is an unthinking,
autonomous, and stupid push-button affair.  An example with reactions
would be:

  Stab Bubba in the chest with the sword.
  If Bubba attacks my head then block with the shield and stab him 
    in the leg with the sword.

If Bubba does *ANYTHING* but attack you in the head, you will try to
stab him in the chest.  Only if he attacks your head will you block
with the sheild and try to stab his leg.

Like I said -- they are dumb, very deliberately dumb.

Scripts are generated by Combat Packages which are installed on the
character.  There may be more than one combat package installed on a
particular character.  It is up to the combat packages (which may also
be of various authorship) to mutually conspire to present one or more
suggest (one primary) combat scripts for a given combat round.  It is
the combat packages which attempt to have the inteligence by cleverly
authoring scripts.

I suspect that Shawn and Nathan are confusing and/or blurring the line
between combat scripts and combat packages.  Many of Shawn's comments
in particular seem to assume that a script is persistant, or can
determine behaviour across multiple rounds.  However, that's the job
of the Combat Packages.

Note: The reason that a combat package is called a package is because
it is a user-authored (Yes!  Users write the combat packages!)
discrete unit which can be installed, removed, bought, sold, traded,
re-writen, extended, etc as if it were a distinct object.  In many
ways it can well be thought of as a cybernetic bolt-on.

>> :Hurm.  A combat script needs to be able to express the following:
>> :
>> :--  Attacks, where blows are any of magic, physical, mental, or
>> :aggressive defenses.
>>
>> How about: an attack is any action which deliberately harms you, from your
>> POV. 

Because even the definition of harm is arguable and many times moot.

>> ...I can't see these scripts going inactive when not
>> "in combat", mainly because combat is an arbitrary description of a state
>> in which you and another entity are mutually attempting to cause each
>> other damage, in my system.

True, the combat packages are always there, and thus always available
for action.  I am however unable to arrive at a state model where the
system can accurately determine that "XXX is fighting," with the main
problem being that most "fighting" conditions are missed.

>The attack doesn't even have to be one such that it deliberately
>harms you. Intention isn't a factor, since the decision to retaliate
>will always rest with the victim (who can code his scripts
>appropriately:  that is, if he's the jumpy sort, almost everything
>will cause him to retaliate, whereas someone more calm would perhaps
>let an "attacker" get away with more).  

You appear to be assuming tht almost any action can be broken down
into a personal relevance where the action can be weighed as an attack
or ignorable.  I'm not happy with that.  It places
advantage/disadvantage/combat into a priority role in the game where
all events are actively weighed as to their personal effects.

>> :--  Defenses, where defenses are any of magic, physical, mental, or
>> :defensive attacks.
>>
>> Why must the script be able to recognize these as a seperate class of
>> actions? Or do you mean successful defenses against your own actions, ie.
>> failure of the target to display damage after you threw everything you had
>> at it?

Because the concentration of a defensive attack is in the _prevention_
of success of an opponent's attack whereas a normal attack is a
straight forward attempt to damage the opponent.

>> :-- Feints, where a feint can be an illusory attack or defense.
>>
>> Again, why does this stand alone? There are too many ambiguities
>> associated with breaking non harmful actions into categories..

Because a feint is used as a cover for a more deliberate attack or
defense.  Its entire purpose is to mask a real action.

>I understand Nathan's PoV on this one, I think because I'm leaning
>the same way:  I don't plan to make any distinction between offensive
>and defensive actions, short of saying that offensive means damage
>can be done and defensive means damage can be prevented.  Will the
>user coding his combat script care if his defensive action is an
>illusory attack or just a straight parry?  If there is a different
>advantage to using one over the other, then yes, but does the combat
>engine require a distinction between the type of defense?

He can feint an action with the intention of deluding his opponent
into reacting to the feint and thus opening himself for the real
attack.

>> :-- Sequences, where a sequence is any ordered set of attacks,
>> :defenses, and feints (including a sequence of one member).
>>
>> Do you mean like "charge, dodge, swing, parry, duck, block"? Hmmm.

>Can sequences simply be chained-together commands with the odd
>conditional? And then extrapolate to chained-together scripts?

A sequence is an ordered series of attack, defense, and feint moves. 
There is an implied conditional in that a feint can be defined as
successful or unsuccessful (ie did the opponent appear to think it was
a real blow), and dependant on that state continue with a defined
sequence continuation (ie one branch for success, another for failure
of the feint).  

Outside of that there are no conditionals in sequences -- that is left
up to reactions.  A reaction is a defined state or occurance, which if
true responds with a sequence.  There are no nested conditionals here. 


As scripts are thwo-away items that are unique to the combat round,
no, scripts can't be chained.  Of course a combat package *could* plan
out a sequence of scripts to be played over multiple rounds in an
attempt to achieve a certain state, but that is external to the
scripts.

>> :-- Reactions, where a reaction is a defined sequence to be used in
>> :response to a stated sequence or sequence characteristic from a
>> :defined or undefined opponent.
>>
>> OK, this I can see. But why does it require recognizing the actions as
>> "defensive", "feint"?

It doesn't.  A reaction is purely a, "If someone does XXX, then do
YYY."  The attack/defense parts are purely internal components of the
YY above.  A worded example might be:

  "If Bubba attacks my head then parry with the shield (defense)
followed by feinting a sword attack at his left shoulder.  If the
feint is successful, slash at his stomache.  If unsuccessful. thrust
shield at his face and stab him in the leg with the sword."

Here we have a siple reaction:  If Bubba attacks my head then...

Followed by a sequence: parry with the shield (defense) followed by
feinting a sword attack at his left shoulder.  If the feint is
successful, slash at his stomache.  If unsuccessful. thrust shield at
his face and stab him in the leg with the sword.

>If you build the conditional into the combat scripting, then I'm not
>sure you'd need reactions, since anything inside the conditional
>would be the reaction to an action that the conditional evaluated to
>true.

Reactions *are* conditionals.  However their state-awareness is
limited to other's actions or non-actions, and don't enclude other
environmental states.

I probably shouldn't comment here that each of the individual actions
(attack/defense/feint) are individually specified (ie each and every
blow) with force (how strong a defense/blow/feint) and commitment (how
much you hold is reserve to put into subsequent actions etc).

>I'm curious, Nathan, how long your "average" combat...er,
>session...lasts? 

I'm aiming for most combats resolving (one party dead) in 3 - 5 rounds
with the majority at the 3 end.  __ALL__ combats will resolve in less
than 10 rounds unless all parties are absolutely incredibly well
prepared and have massively huge resources.  

Is it fast-paced (assuming, say, a couple of
>matched-ability guys knocking about with swords)?  Does each
>combatant have control over each atomic attack (i.e. Ugg swings sword
>at Bubba.  Bubba sees this and then has a slice of time to choose his
>reaction to Ugg's swing.  Etc.), or is it more automated?  

That's one thing I don't allow:  Seeing the opponents action and
causitively reacting to it.  Instead I have each combatant dreaming up
what he *thinks* the others may do, and based on that, what he thinks
he maybe should do.  This is the combat script.  All the combat
scripts, each one a picture of what each combatant thinks may happen
in the round are then submitted to the combat object, the combat
object resolves them against each other (decides what actually
happens), and life goes on or ends from there.

>I'm not
>happy with the traditional combat model:  I want there to be more
>thought and involvement in it, rather than just swinging your sword,
>automatically blocking, and casting spells left and right.  I just
>haven't hit upon a comfortable solution yet.

Ditto.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...




More information about the mud-dev-archive mailing list