[MUD-Dev] Re: Issues from the digests and Wout's list
Shawn Halpenny
malachai at iname.com
Thu Apr 24 10:29:54 CEST 1997
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:
>
> >> 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:
The player will be able to type "kill arm" and will essentially engage in
a very short battle (since the arm cannot normally retaliate by itself)
and destroy the arm. The battle will be incredibly short, since the arm
has no combat abilities of its own (making it a very dumb and very easy
opponent). You are not fighting against Bubba in this case, just
destroying the arm. Bubba can continue to hit the button and thwack you
while you're destroying the arm. I don't consider anything the player
does while destroying the arm as an attack on Bubba.
If we assume the arm is only present (i.e. can be directly interacted
with) in the room while it is thwacking someone, the player will not, of
course, be able to destroy the arm. The bottom line is that in none of
this does Bubba ever factor into the engine's calculations concerning the
thwacked-player until the player does something to Bubba. That Bubba is
indirectly causing the damage and probably _should_ be attacked is an
issue that is left to the player to resolve.
> > 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?" If that is the case, then
the tree falls and dams the river. If you're in the river you drown. The
fact that Bubba was the object responsible for your drowning doesn't
really matter. So I guess I have no special handling for indirect
effects, since I boil everything down into direct effects: bubba cuts
tree, tree dams river, river drowns player. The same with bubba pushes
button, button moves arm, arm hits player. 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.
> >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.)
This I definitely agree with. You can do anything at any time (barring
certain restrictions, such as moving while dead, things requiring vision
while blind, etc.).
> 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".
This as well.
>
> 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.
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.
> >> 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.
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
> 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.
> 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.
> > ...(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).
> 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).
This sort of thing is already handled by embedded codes cranked through my
output parser.
> >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.
Ya, I think that would be quite a difficult thing to do well, so I would be
inclined to do something like karate forms, allowing the user to select one
at any given point in the battle, and essentially the entire combat becomes
a movement from form to form.
> 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.
Exactly. This is the sort of thing I had in mind when I'd first started
looking at combat.
> >> >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.
I'm doing the same. The only thing you gain from combat is potential
increases in the abilities you use while in combat and any items you might
get as the victor. I've also got no levels, no xp, no classes, etc. either, so
this sort of "advancement" through combat is about my only option as well.
--
Shawn Halpenny
"Don't force it--get a bigger hammer."
- Unknown
More information about the mud-dev-archive
mailing list