March 1997
- Linear Quadtrees Carter T Shock
- Linear Quadtrees gzhang1234@yahoo.com
- q-tree stuff Chris Gray
- q-tree stuff Carter T Shock
- q-tree stuff coder@ibm.net
- Issues from the digests and Wout's list Alex Oren
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
In <199704171445.OAA134695@out1.ibm.net>, on 04/17/97
at 10:28 AM, "Shawn Halpenny" <rsh@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@null.net
(Contractor) Internet: coder@ibm.net
---------------(*) Internet: clawrenc@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith... - Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list S001GMU@nova.wright.edu
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Travis Casey
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Orion Henry
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Jeff Kesselman
- ListMail dupes coder@ibm.net
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues Chris Gray
- Threads, IO handling, and Event Queues coder@ibm.net
- Threads, IO handling, and Event Queues Carter T Shock
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues claw@null.net
- Threads, IO handling, and Event Queues coder@ibm.net
- mud grammar (was Just a bit of musing) Carter T Shock
- mud grammar (was Just a bit of musing) Nathan Yospe
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar Carter T Shock
- mud grammar Nathan Yospe
- mud grammar Alex Oren
- mud grammar Nathan Yospe
- mud grammar Adam Wiggins
- mud grammar Chris Gray
- Just a bit of musing (VRML) Dmitri Kondratiev
- Just a bit of musing (VRML) claw@null.net
- Room coding Nathan Yospe
- Room coding Furball
- command parsing Chris Gray
- command parsing Adam Wiggins
- command parsing claw@null.net
- Room coding S001GMU@nova.wright.edu
- Room coding Chris Gray
- Resets and repops Furball
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Travis Casey
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Shawn Halpenny
- Resets and repops Jeff Kesselman
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops Furball
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops coder@ibm.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops clawrenc@cup.hp.com
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops lhulbert@czn.com
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar claw@null.net
- List software claw@null.net
- List software Nathan Yospe
- List software Chris Gray
- List software claw@null.net
- List software claw@null.net
- I got your message..! MAYA DASWANI
- 3D graphics claw@null.net
- Sorry for the dups (again) coder@ibm.net
- mud grammar Jon A. Lambert
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar coder@ibm.net
- mud grammar Nathan Yospe
- mud grammar Chris Gray
- mud grammar claw@null.net
- EVOLUTION response claw@null.net
- EVOLUTION response Jon A. Lambert
- EVOLUTION response claw@null.net
- Garbage Collector Artur 'Revinor' Biesiadowski
- A perspective out of time - the mudreport document Nathan Yospe
- A perspective out of time - the mudreport document claw@null.net
- Old missing posts from old list coder@ibm.net
- Execution Chris Gray
- Mixture Furball
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Adam Wiggins
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) <= hah! Chris Gray
- VT100 codes ... Khanone@aol.com
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- Dupes coder@ibm.net
- Efficiency Chris Gray
- Event Handling Nathan Yospe
- Event handling Shawn Halpenny
- Event handling Vadim Tkachenko
- Event handling Maddy
- A brief introduction.. ok, you got me: an introduction Greg Munt
- A brief introduction.. ok, you got me: an introduction Adam Wiggins
- A brief introduction.. ok, you got me: an introduction coder@ibm.net
- Greetings. :) Michael Hohensee
- Greetings. :) claw@null.net
- Greetings. :) Nathan Yospe
- Greetings. :) Michael Hohensee
- Greetings. :) coder@ibm.net
- Greetings. :) Nathan Yospe
- Greetings. :) Chris Gray
- Greetings. :) coder@ibm.net
- Greetings. :) Chris Gray
- Greetings. :) Nathan Yospe
- Greetings. :) Jeff Kesselman
- Greetings. :) Chris Gray
- Greetings. :) Greg Munt
- Greetings. :) Jon A. Lambert
- Greetings. :) Nathan Yospe
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Furball
- Greetings. :) Chris Gray
- Greetings. :) clawrenc@xsvr1.cup.hp.com
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Jeff Kesselman