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
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
In <335F6E62.41C67EA6@iname.com>, on 04/24/97
at 08:44 AM, Shawn Halpenny <malachai@iname.com> said:
>clawrenc@cup.hp.com wrote:
>> In <335E1FA1.41C67EA6@iname.com>, on 04/23/97
>> at 08:13 AM, Shawn Halpenny <malachai@iname.com> said:
>> >clawrenc@cup.hp.com wrote:
>> >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?
>That Bubba is indirectly causing the damage and probably
>_should_ be attacked is an issue that is left to the player to
>resolve.
Capiche. That's my tack as well.
>> > l
>> You are in a forest.
>> Bubba cuts down a tree.
>> The tree falls over and dams the river.
>> You drown.
>This is perfectly reasonable and I say that it's not an issue of
>indirect effect, since the only place Bubba factors into the sequence
>is "Does Bubba have what it takes to cut down the tree?"
...
>Bubba is only the instigator of the action, and unless
>he's at the end of the cause-effect chain, he is not a factor in the
>final action.
Agreed. I actually see this as a primitive variation on the
button/arm/thwack scenario, and so leave it up to the player to make
the connection.
>> The combat state should be toggled off once the combat object
>> destructs, or upon user command. Suggestions welcome for the
>> "peace" (?) command.
>Okay...if Bubba and Joe are fighting, (that is, a combat object is
>present), and then Bubba leaves the room. Does the combat object
>destruct?, implying that one of the two will have to type "fight"
>again once one tracks the other to the next room? It makes sense to
>me, since I don't think there are fixed, engine-aware criteria for
>determining if, once the two are back in the same room, the combat
>between them should resume.
Combat objects persist until there are no more combatants either due
to death or peace commands. The big reason for this is that I am
working hard to totally lose the concept of rooms. As such I actively
want to support two players fighting who are also seperated by the
entire width of the land, a couple rooms apart, or right beside each
other.
The syntax for the "fight" command is "fight <characterID>". The
first player to issue the fight command has the combat object created.
The combat object then maintains an "interested parties" list of
CharacterID's of who is fighting. As each player then issues his own
fight command, if the characterID matches an ID currently listed in
the interested parties list, then that player is merely added to the
combat objects list. If it is a new characterID, then a new combat
object is created.
Regarding the motion thing: If Bubba is fighting Boffo in hand to
hand combat, and Boffo leaves the room, and Bubba is actively
attacking (as versus trying to survive long enough to escape), I would
expect the Combat Package to script moving Bubba after Boffo thus
actively continueing the fight in the new location.
>As much as I like the idea of using the components of a single blow,
>I think it would make battle slower than I'd like it. I'm still up
>in the air over the precise granularity I want.
...
>> 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
...
>I'd like to avoid this as well, and your whole idea of packages and
>scripts is attractive in that respect, but it takes more thought on
>the user's part to make it work well. That's not bad, but it seems
>more...chess-like to me than hack-n'-slash, and I like the feel of
>hack-n'-slash, just with more mandatory participation than currently
>exists. I suppose though, that once a player has accumulated his
>suite of packages, things will be more hack-n'-slash, since he will
>have had the time to refine things so they'll apply to the more
>general combat case. Hmm, now I think I'm farther from having a
>combat model than I was at the start of this reply :P
Exactly! That's a pretty common reaction on this list. We're a bunch
of devil's advocates the pick apart any middling idea into rags. Only
the good ones survive (I hope). I've been down that road a heap of
times with Wout, AlexO, ChrisG and that lot pointing out the holes in
my thinking. Nathan's recently been complaining that he may be
looking at a redesign as well due to comments on this list (#5 I
think?). Its par for the course.
>> 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.
>Yeah, I'd seen it this way initially as well, and now I think I'm
>being drawn back to considering it again.
Yup, and there came my definition of a sequence. It was at that point
that the thought struck: "If he's in the middle of a long sword
sequence and NOT expecting the other chap to have dropped his mace and
now be pointing a Colt .45 at him, wouldn't he stop and do something
else? He'd probably get halfway thru the first roundhouse and
split..." And from there cme the idea of scripting the whole deal.
FWIW the combat objects resolves the various submitted scripts against
each other by iterating across them, again and again to allow
reactions to others reactions which were in turn reactions to you etc.
A small tweak here is that combatants with higher combat skill levels
get their scripts iterated more than lesser skilled combatants. Thus
a very low skilled player would get his script only evaluated the once
whereas a very highly skilled fighter may get evaluated four or five
time before the final resolution is reached.
>> 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.
>Yeah, I like the element of mystery too. I was thinking I could
>achieve that with finer granularity (if you have minute control over
>what your next action will be, it becomes much more an issue of what
>one's fighting style is, as opposed to straight ability vs. ability),
>but what I've pondered so far still seems too Diku-like.
The problem I see with the finer grain also is that you become
inextricably bound to the IO stream. Your combatants _have_ to keep
up with the pace of the fight, and have to insert their commands at
precisely the correct moments. Given lag, this can be a problem.
>> > ...(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.
>I guess my only qualm with the considerable thought and effort
>required is that _someone_ has to write those initial packages or no
>one will ever get anywhere. I'd like people new to the game to just
>"be able" to do combat without have to pick and choose amongst a few
>packages first (I suppose there could be a default set), but it seems
>to me you're at a disadvantage if you've never written one before.
>An alternative would be to disallow players writing their own combat
>packages and having only one source supplying them. This would put
>everyone on an equal footing from the start, but would quell any
>innovations from players (something I'd rather not do).
A key point in my game is free user programming. While there are
always security questions of "real" vs "newly user programmed"
objects, more or less I allow any user to program any type of object
or feature at any time. The security features then just ensure that
he can't program up a 50,000hp wet noodle to defeat the red dragon
(well, actually he can program such a weapon, its just that
unvalidated user-programmed objects can't affect validated objects
(like the red dragon) in that way).
At some point I'll spend some time and try and get a fairly decent
base set of system default packages written. From there on it will
jut be a matter of either keeping those moderately well maintained
against the user-written packages, or beg/borrow/stealing the
user-packages into the system-default ones.
--
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 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