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
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
In <335E1FA1.41C67EA6@iname.com>, on 04/23/97
at 08:13 AM, Shawn Halpenny <malachai@iname.com> said:
>clawrenc@cup.hp.com wrote:
>> 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.
>That's true--my approach is to process actions regarding a character
>from the point of view of that character.
How do you intend to handle indirect effects?
> l
You are standing in a strange factory. There is a button on
the wall.
Bubba is here.
Bubba pushes the button.
A mechanical arm reaches out from the wall and thwaps you
on the head. That hurt!
> Huh?
Bubba pushes the button.
A mechanical arm reaches out from the wall and thwaps you
on the head. That hurt!
> kill arm
What arm?
Bubba pushes the button.
A mechanical arm reaches out from the wall and thwaps you
on the head. That hurt!
...
Bubba pushes the button.
A mechanical arm reaches out from the wall and thwaps you
on the head.
You are dead.
Bubba is not attacking you. The indirect results of Bubba's actions
damage you however. Another example:
> l
You are in a forest.
Bubba cuts down a tree.
The tree falls over and dams the river.
You drown.
>There is a very large
>element of advantage/disadvantage in combat where one's combat
>abilities are concerned. It depends less on the order of actions in
>combat (probably more automated than what you're looking for, less
>automated than Diku's), and more on what those actions directly do to
>your opponent and his actions do directly to you. From what I'm
>learning, I think that there is less forethought for two characters
>to engage in combat in my model than yours. I'm not entirely happy
>with my combat system, yet...I think I still want less automation,
>but am not sure if I want there to be involvement to the level of a
>user scripting possible combat sequences.
I'm still waffling here on my combat approach. Current thought:
Entirely lose the concept of a "combat state" visa vis special
casing the game environment.
Keep the concept of a "combat state" for the player character
directly to allow easier combat function access. This is a
careful distinction -- internal combat state does not affect the
possibilities and manipulation of the character by the external
game, or in any way alter the functional capabilities of the
character (ie there are no motion restictions, no "You can't do
that! Your're fighting!" restrictions etc. All that has
happened is that his combat packages are now activated.)
Allow all combat functions to be accessable at any time, and
in any manner, Translation: Make them normal commands so
that "get cup" is effetively identical in processing to "stab
bubba with knife".
Add a "fight" command which sets an internal state on the
player character which concomittantly kicks in the combat
packages. The "fight" command is then analagous to the
decision to aggressively combat as vs sparring or other less
dedicated forms.
Note: It is the fight command that would create the combat
object and all the rule sets from there.
The combat state should be toggled off once the combat object
destructs, or upon user command. Suggestions welcome for the
"peace" (?) command.
>> 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.
>Another difference. I like the idea of having more time to react to
>what the other character did to you (so obviously my combat has to be
>slower)...there is much less forethought in my system...
Its a choice in granularity. I argued with myself about this one a
lot.
Should the basic granularity of a fight be the components of a form
(where a form is a sequence of blows etc), or entire forms, or some
larger grouping, or even the components of a single blow ("He raises
his sword above his head. He begins to swing the sword down and
sweeping to the side. Swooping up under your shield the sword heads
for your tors0...")? The ruling idea is that at each quantum a
participant would have the opportunity to causitively react and
attempt to manage the results.
DIKU/LP etc pretty well take the stance that the entire combat is a
quantum and you're just along for the ride to see the messages. I
did't want that. I also wanted the system to handle the old problem
of: You can carry four full suits of plate mail, strangle three orcs,
cast four fireballs, roundhouse kick two ogres and an elf, and tap
dance "Sweet Mary" all at the same time while hacking that poor hobbit
to bits with your two-handed sword. To a certain extent my server
design made my decision for me (only compleated events/transactions
actually exist) in encouraging going for entire forms as the basic
granularity.
The thing I also liked about going for the entire form is that it
presents an aspect of mystery. You don't know what he's going to do,
he doesn't know what you are going to do, but you each set up an
expectation that you hope best forwards your cause. It tends to breed
selectively for the best predictors. The problem is that this
requires a defense-strong combat scenario. Of necessity it must be
easier to selectively defend that it is to selectively attack --
otherwise the loop positive feedbacks into a slaughter fest as almost
any attack blow will be successful as it finds no matching defense.
> ...(though I would
>think that with your scripts and packages, combat becomes
>fascinatingly intricate from a coder's/player's PoV).
I am hoping that considerable thought and effort will be invested in
writing capable combat packages for resale to other players. I also
expect to see this spawn a complex sub-economy of its own where player
and mobile bodies are purposely stolen/traded/etc to obtain new combat
packages or install broken/weaker packages.
Tho little of this is done, I also hope to essentially have a
spam-meter so that some players can turn off all the combat
negotiation and just see the results (ie just let their packages work
for them, ignore and don't even see the rest).
>Is it correct
>to assume that you may have all the requisite skills and resources to
>win the battle (i.e. a loose definition of the most powerful
>combatant), you could still lose horribly if you choose the wrong
>package?
Yes-ish.
I hadn't actually thought of a playe having multiple installed
packages and then selecting from them as discrete units for a given
combat, tho actually, it could be done that way very easily. My
working concept was that the installed combat packages would mutually
conspire to arrive at a single suggested script. Of course exactly
how thta conspiration was to be done, and how the gestaltic decision
reached between the combat packages was another unconfronted matter.
Hurm.
I guess its going to have to be a case of the user picking.
Another concept here is the possibility of having distinct named forms
ala karate katas. The user could then replace any sequence or even
the entire script with a named form and its target.
Hurm.
I *really* like this idea. I reeks of the (shameful) popularity of
the special combo attacks for things like Mortal Kombat, It also
allows for easy breaking of the "I know what combat package he's
using, so I know what he's going to do next," mould.
>> >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.
>That said, I _do_ want more thought and involvement, but I think I'm
> aiming for less thought than you're aiming for. Related to that is
>the fact that I want to remove the emphasis from combat as the prime
>character advancement method (perhaps exactly what a more intricate
>combat system will do). Dunno yet :)
Absolutely. I don't reward anything for combat except for possible
skill improvement for the various actions used and seen in the combat.
Then again my system is level-less, class-less etc etc etc yada yada,
so keeping advancement via combat (or even any dregs of the
"experience points" idiocy) would be counter-productive.
--
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 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