Issues from the digests and Wout's list

[Nathan Yospe]

On Thu, 10 Apr 1997 clawrenc at cup.hp.com wrote:

:In <199703040508.FAA81286 at out2.ibm.net>, on 03/03/97 
:   at 12:13 PM, alexo at europa.com (Alex Oren) said:
:
:>I know that C&C, Spoofs, Watchers, Affects/affects, etc. have been
:>beaten to death in the previous (Wout's) incarnation of this list,
:>but some of the later participants might benefit from a concise
:>summary.
:
:Is this still true?

(shrug) I wouldn't mind another in-depth of affects... or alternatives
thereof. At this point in time, I don't have anything actually
coresponding to an affect, and have not been able to think of anything
that _would_ so correspond. Most things of that sort seem to be temp
changes of stats, something I handle with a real change and an event to
undo the change instead. 

:>One of the things that were not discussed at length is the issue of
:>parsing and handling user input.  Could you comment on that too?
:
:<shake head>  
:
:The only outstanding one I can remember here is suggesting command
:compleation ala:
:
:  > get bag
:  Do you want the:
:    1 -- Mouldy sack
:    2 -- Paper bag
:    3 -- Leather satchel
:    0 -- Cancel command
:  >> 3
:  You take the leather satchel,

:I currently do this, with caveats for nested compleations, multiple
:character support (multi-playing) and priority interrupts.

I think there was a pretty heavy discussion on the rgm.* groups of command
completion.... mainly because I started it. I don't even remember when
that was, or what the name was... In any case, a few other schemes have
been proposed. I use a warning/override method that applies to both unwise
and ambiguous commands, by which my interpreter takes what it thinks is
the most likely choice, and asks you if you really want to get the mouldy
sack. If you repeat the command, it goes ahead with it, or if you hit a
'Y' or '&' or '!'. An unwise action can override the warning by being
prefixed with '&' or postfixed with 'anyway' or, after recieving the
warning, simply by typing '&'. A command can be repeated by typing '!', or
repeated at a later date by typing "!<first letter or two of the
command>", as in a unix eviron. I'm still working on some parts of the
wild card substitution system, mainly because I have a number of wild card
keys that perform differently.

:>Some of the discussions that (IMHO) were left unfinished were:
:
:>1) The combat system.
:>* Limb based combat.
:
:Someone else will have to resurrect this one/  I'm not a big fan.

Limb based combat as a seperate topic bites rocks. It just complicates an
already ingrown combat system. Now limb based existance, with everything
being limb based, is a different story. More to the point, a limb is just
an object attatched to the body that happens to respond to mental control.
If an agressor wants to target that limb in particular for an aggro
action, that's fine. I have elliminated the combat round, with all of its
baggage, and instead use a sort of 'combat is just another type of action'
approach, where having someone attack you is a bias factor in your command
parser, but nothing more, and your reflexive reactions are defensive only,
as they are at all times. Offensive moves must be activated implicitly or
by a script. (IE: if attacked, draw gun, shoot attacker until one of
you is dead.)

:>* Staged combat (scripts).
:>} > By default chop at Bubba's legs with the shield.  But, if Bubba swings
:>}   at my head, buck and stab at him with the sword.  If Bubba attacks my
:>}   legs, jump clear while smashing his head with the shield.  If Bubba
:>}   attacks my middle or arms, block with the shield and stab his legs with
:>}   the sword.
:
:I'd like to ressurect this one.  There's a lot of value in there to go
:yet.  My current model for the combat scripts is woefully crude, and
:not very human readable.  My recent moves to de-emphasise physical
:combat in place of stressing magical and/or mental battles is also not
:helping.  I need something a lot more freeform.
:
: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. If it was unintentional, but the attacker is of a sort unfamiliar
enough to you that you didn't realize his electric buzz was a joke and not
an attempt to fry you, then to you, that was an attack. No matter what the
attacker intended it as. 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.

:--  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?

:-- 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..

:-- 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.

:-- 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"?

:-- Scripts, where a script is a statement of the various sequences and
:reactions to attempt during a combat round.

*nod*

:The design is for every combatant to submit a script (as above) to the
:controlling Combat Object for the fight for each round (I use round
:based combats).  At the end of the round, the combat object resolves
:the scripts against each other (eg feedback loops between reactions),
:and sets the sequences attempted by each combatant.  These resolutions
:are then sent back to the combatants, they do them, the relevant
:damages are levied (this is all automatic), and the next round starts. 

Ack! Round based combat. That explains a lot. *gag* Sorry, but this went
out the door for me a long time ago. It tends to spoil the momentum of a
good story sequence, whereas reactive and monoactive events do not. In
other words, it doesn't flush with the rest of the game.

:The oproblem here is to define a simple user-friendly scripting
:language which is capable of expressing the sequences and reactions
:constituting a script.

That is extremely difficult. I'm still trying to create one of these
myself. (My reflex system)

:This also raises the doubt in my mind that my basic approach to combat
:is flawed.  Most MUDs treat a fight as some sort of special state. 
:Various commands are no longer available, new ones are added, motion
:is commonly curtailed, etc.  To an extent the combatants are removed
:from the normal run of the game.  

Ah. There you go. Go with these doubts, they will lead you to a better way
of doing things(tm).

:This creates verisimilitude problems.  Bubba sits high on a cliff with
:a sniper's rifle and shoots at some chap a couple miles away on the
:plains.  Are they *really* in a fight?  What if the guy on the plains
:climbs into a tank and fires a howitzer back?  How about the sniper is
:instead a spell caster and the plains hugger is a knight in a tin can? 
:How about the lurker in ambush who throws a knife?  The guy in the
:middle of the street who throws a knife?  They guy who stabs you in
:the back?  The pitched battle?  The melee?  The two tanks sitting on
:opposing hills trading shells?

Under my system, these is all as much a fight as two idiots in armor
trading blows with swords. The only difference is that the guys in armor
with swords are toast when that longbowman finally gets a bead on them.
The critical thing to remember is that a) I use a levelless system, and b)
experience is not given for winning a combat sequence, it is confered to
each appropriate skill and/or attribute on an action by action basis,
making the action of shooting a guy from a mile off with a longbow pretty
good experience, where the action of hacking at a guy with a sword and
getting in a lucky shot might not be so great, experience wise, as barely
surviving, and not killing the other guy, but getting a damn good workout.

:There's a concept of level of engagement here that I'm not sure how to
:deal with.  It get messier when you realise that many actions are not
:fighting actions in themselves, but may effectively act as attacks or
:defenses when in a battle.

The point I raised earlier: there is a bias based on the "aggresion
coefficient", that makes a combatish interpretation of a command more
likely for me, but aside from that, things flow much more smoothly without
combat rounds. Don't get insulted by this, please, but rounds make me
think Diku/LP. They are so typical of those systems...

:Consider the hyopothetical battle I posted earlier:
:--<cut>--
:
:Your giving the charmed TC to UggUgg __acted__ as an attack in the
:context of a fight because the TC attempted to eat UggUgg's inventory. 
:However, normally giving someone a TC, even a charmed TC would not be
:an attack.  Similarly, UggUgg giving you his magical inventory in an
:effort to exhaust your mana stores and cause all your magical objects
:to destruct in the context of this fight was an attack.  However
:giving someone a macgical item or items during a fight is often NOT an
:attack.  This same sort of dichotomy holds true for the TC spores.

Not really. Whatever your intent, the results are the same, yes/no? The
only complaint I can see is that this means the script has to have a
friend/foe value for the other guy, to know if him slapping you on the
back so hard it made an impression of your face in the wall of that house
that had been a few meters away was an aggressive act (and, due to the
fact that he can do that to you and that you forgot your ultra-anhiliator
cannon in your other leather jerkin, is obviously going to win in a fight,
would trigger your "run away screaming ohshitohshitohshit I'm gonna die
I'm gonna die I'm gonnaDIE!!!"[1] reaction) or an attempt at a friendly
gesture by a guy who's a little too big to be making such gestures.
(actually, neither comes into play, as you were rendered unconscious by
your impact with the wall, but that's another story.) I dunno how to
determine a clean friend/foe factor... right now, if the other guys are
wearing the same uniform as you, or if you have a friend/ally tag on your
memory tag for them, they are friend, otherwise, foe.

[1] also known as the Rincewind reflex, for any Pratchett fans out there.

:These are not fighting actions any more -- but in the context of a
:magical battle where indirect control and manipulation of the the mana
:supply is the major weapon, they suddenly turn into fighting actions.
:
:Think you have a rule?

Yeah. I think its not that bad, actually. At this point in time, both of
these guys have each other pegged as major foes. Anything the other guy
does, short of raising a white flag or running away screaming, is going to
be interpreted as hostile. Even sneezing.

:What if Boffo the clown wanders into the fray, DOESN'T join the fight,
:but does proceed to do all the same things as above (giving magical
:objects etc).  He could be trying to help you by giving you a super
:magical weapon, or help UggUgg by accellerating your magical
:inventory's decay...
:
:Friend or foe?  Context driven I'm afraid.

Do you remember Boffo as a friend? Hmm... yep. scream at boffo "You stupid
clown! Don't do that! I'm in a fight right now, can't you see? I'll talk
to you after I pulp this idiot!"

:I'm beginning to think that fights should be handled like any other
:player interaction.  Let each player enter individual commands for
:each blow which are then handled as if they were exactly the same as
:every other command.  Allow automation of this process via scripts
:etc, but forget the whole deal of combat objects, rounds, etc.  Let
:the guy pick his nose one command, shoot his neighbor the next, and
:water his garden the third.

Yup. Now your talking sense. *grin*

:Problem:  Fast typists and fast clients have a massive advantage. 
:Solution: All commands need to be paced.  Problem:  This makes for a
:laggardly game.  Next thing you know you'll be insisting that
:characters rest and sleep, feed and shit, and wear holes in their
:longjohns.  Whaddya want?  Toothbrushes and cavities?  Athletes foot? 
:Jock itch?  Flatulence?   I can see it now:

I do insist that there be a little of that... I have rest and sleep, and
passing out from blood loss, and recovery time for a serious injury,
though all of these can be remedied by cybernetics and nanotech,
purchasable at a later time in the game. But seriously.. the solution is
make combat fast, not slow. Really, really fast. The guy who gets in the
first initiative wins, half the time, if he sets it up right. Client isn't
part of it, nor is the connection, if there is hardly time to think once
the blows have started to fly. The other factor here is that fights are
usually several on several, not one on one, thanks to the fact that having
a buddy minding your back can often mean the difference between a killing
blow from behind and a victory. Actions are paced by how fast a character
can manage them, not how fast the player can type (though faster typists
can afford greater control, see my old posts on command parsing and
control/specificity) and there are rarely enough of them once things get
hairy for the faster guy factor to come into play anyway. As I've
described before, the majority of battle strategy for a front line
combatent comes into play before the fight, and half of it goes out the
window when the bombs start going off behind you.

:  Bubba of the awful farts...
:
:<<Still thinking>>
:
:>2) Namespaces.
:>* Allowing players to name one another.
:>* Introduction systems.
:>* The "familiar face" element and remembering/forgetting names. *
:>Naming objects and exits.
:
:I proposed this initially.  I still rather like my solution where
:there are no global names, there is no WHO command etc.  Players can
:assign whatever names they wish to whatever they see, be they rocks,
:mobiles, other players, or whatever, and those name assignments are
:private to that player.
:
:I'll flesh this area out later if anyone is interested.

I'm working on a name/id in my memory tag that should give some of this
flex.

:>3) Skills and skill trees.
:
:Nathan: I like your recent comment on flat trees without
:pre-requisites (eg anyone can *try* to fly, it just won't work if you
:don't have wings/rocket assist etc)  Care to expand?

Sure. I have verbs stored as keys to something called an action container.
Action containers contain a series of actions, their dependancies, and a
priority weighting of each, relative to those dependancies. (This is part
of my natural language parsing model, BTW) Now, if there is no actually
feasable action associated with a given verb, the verb returns a possible
abortive to the commandinterpreter, the highest likelyhood abortive, such
as attempting to fly without wings... the interpreter will take it under
advisement, but will try other verbs first. (IE, if the player typed f up,
it might then try to f*ck up... dunno if this is ever going to be a real
verb, but the interpretation, in the context of the "up", might lead to a
query of whether the player really wants the character to fail at what he
is currently doing, which, say, happens to be defusing a bomb.) Most
probably, though, the player would type out the full command, 'fly to
mountain', say, or simply 'fly moun'. The result here would be a lack of
any other choice, and the player would attempt to fly to the mountain. If
I recall correctly, fly generates an action of flapping one's arms in liu
of any realistic means of flight. Though, I think an engineer with the
right background might actually start the action of attempting to
construct a hangglider with the right materials handy. Anyone could type
"build hangglider", but the weight on that action is too low for it to be
an automatic action for anyone who hasn't learned how. This verb tree is
attached to the model for a Character (read, static member list in class
Character) and has access to data specific to the Character referencing
it. Other trees may append themselves as well, and will be traversed
_first_ by the command interpreter. These include trees on items (IE: the
item you hold may override the 'charge' command, as it happens to be an
electric source of some sort.) trees in rooms (similar to a MOO command
system) and trees on appendicies (special commands that are _not_
universal to all characters, but permanently append to a specific player
- admins get several packages of these, depending on admin class and
rank.) Most verbs, however, are part of the static player tree. A skill is
simply an arbritrary designation for a verb that you are particularly
adept at invoking. If you are a tre'laeci, flying is almost certainly a
natural skill, as tre'laeca are an avian species with large wings and
tremendous pectoral muscles attached to those wings. This does not make a
human incapable of trying to fly... and with a rocket pack or antigrav
device, or a hangglider, a human can learn to fly quite well, in time. I
have one species that can fly by nature, but might never think to invoke
it as a skill, as the species is a swarm. Flying is the default form of
motion for them, and they cannot move in any other way, really.

:>4) Rumors.
:>* Decaying rumors.
:>* "Alerting authorities".
:
:We definitely need to get back into this.

Not my bag.

:>5) Containers and grouping.
:>* Handling different yet similar objects.
:>* Groups of people/mobs.
:>* "Piles of junk".
:>* Referring to specific items/individuals in a group.
:
:Still no real idea how to handle.

I've been working on my own versions of J C's bulking containers and other
sorts of container and grouping objects. They seem to be shaping up quite
well, using several rules for grouping and a series of rules for
distribution of common reference input. In other words, the container for
a mob decides how to handle you shooting the mob. If you use a directed
weapon, it just sends you a specific target in the mob as a ref to be
shot. It seems pretty straightforward at this point.

:>6) Global mob AI.
:
:Ouch.  Like it.  Don't have an elegant solution yet.

Neither do I.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu