[MUD-Dev] Re: Issues from the digests and Wout's list

[clawrenc at cup.hp.com]

In <335F6E62.41C67EA6 at iname.com>, on 04/24/97 
   at 08:44 AM, Shawn Halpenny <malachai at iname.com> said:

>clawrenc at cup.hp.com wrote:

>> In <335E1FA1.41C67EA6 at iname.com>, on 04/23/97
>>    at 08:13 AM, Shawn Halpenny <malachai at iname.com> said:

>> >clawrenc at 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 at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...