[MUD-Dev] Re: Leaving characters in play

[John Bertoglio]

From: J C Lawrence <claw at under.engr.sgi.com>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Friday, May 15, 1998 6:11 PM


>On Thu, 14 May 1998 11:21:17 -0700 (PDT)
>Adam Wiggins<adam at angel.com> wrote:
>
>> On Tue, 12 May 1998, John Bertoglio wrote:
>
>> A couple of things.  First, I think that the stuff above is pretty
>> different from VGA Planets.  It doesn't fix any problems (at least,
>> from where I'm sitting) incured by leaving people in game all the
>> time.  They can certainly set some standing orders for things their
>> character will do while they are away, but you don't need an
>> order-based combat system for this to work.  Secondly, getting the
>> above to actually work seamlessly in the mud environment might be
>> tricky.  Ie: while in combat, are *all* commands that you give
>> orders?  If not, doesn't that mean that players will quickly figure
>> out commands to hurt their opponents outside of the combat scheme?
>
>It is this point which ghas persuaded me to almost entirely move away
>from round based combat.  I refuse to place the entire game and all
>players on a pacing clock (humans shall not wait for machines), but
>not using a global clock while using usably long combat rounds opens
>the combat system for all sorts of interesting abuse due to the
>inconsistant time scales.

Minor point with confusion. Do you mean time scale as in real time (seconds
ticking on a clock) or another concept I am (obiously) unfamilier with.
Inconsistant time scales (real time vrs how long thing take to happen in a
game) are a reality in virtually every game I have ever seen on computers
with the possible exception of the most carefully crafted simulators
including those in commercial and military use. If you issue a command,
drink jug and the connection is quick, the screen quickly returns something
like "The jug is now empty". Now I know some of you out there could drain a
jug in a few miliseconds...but most of us can't. Most of us cannot work our
way up to the top of a 10,000 ft mountain in the time it takes to type
"CLIMB" or "UP" five times.


Less minor point and confusion. Perhaps I am missing something. My system
uses what I would call round based combat but is controled (usually) by
player command and inititive. Some quick questions. I guess most would
consider round-based combat to be similar to a boxing match where the
rounds are discrete chunks of time. I think more like a wargamer...a combat
round is a period in which a certain number of actions are executed by the
combatants and then resolved. Of course, the computer makes simultaneous
movement possible, something which has never been adequately modeled (in a
playable fashion) in board games. Our combat round consists of a certain
number of action points. Every action requested by the player consumes
action points. Actions can be interuppted, canceled due to combat results
and delayed. When the points are used up, the round is over. The amount of
AP in a round varies according to the capabilities of the combatants,
inititive, surprise, etc. Combat rounds are resolved quickly by the server.
Typing speed is not a major issue unless the combat profile chosen (a wimpy
variant on the JCL combat package) is not working out...and even then type
[>K 5] and you have changed to combat profile 5 (which you have carefully
designed for just this situation. ).

>Opening the combat to being entirely untimed conversely allows spam
>attacks and tends to guarantee that the fastest twitch will win.  Not
>good.  Further, as discussed earlier, I can't distinguish between
>combat and non-combat commands as even utterly innocuous commands will
>be used heavily in combat ("drop mana consumers"), and very
>combat-centric commands will be used peacibly (cf UggUgg's fight)..

This is the only way I can see to build a sensible parser. Besides...it is
fun to type KILL TORCH...and have torch be extinguished as opposed to
attacking it with a rock.

>I don't have a good design.  The best I can think of so far is:
>
>  -- No first blows are fatal.

Why? You hit a bunny with a halbred and you either miss or have a binary
bunny.

(OT aside: There is a (probably) apocraphal story about a dentist who had a
ranch outside of a major city in Arizona. This was during 60's when people
were still digging bomb shelters. Anyway, doing his patriotic duty, he
installs a 20mm antiaircraft gun on a motorized traverse in his back yard
(several thousand acres of desert). When asked by a reporter what he
installed the gun for he replied: "I use it to hunt jack rabbits. I don't
hit them very often...but boy when I do!")

Now when our system is finished, I guarantee that no player will score a
one hit kill on another player...but that is a different story.

>  -- First blows may be nearly fatal.

Of course.

>  -- Second blows can be fatal, but its very very unlikely, especially
>if the first blow was nearly fatal.

Sounds like you are considering manipulating fate (luck) in combat
fortunes. I see this a partial solution to PK...Operant conditioning..."I
got womped by a newbie with a dagger! Bummer. He took all my stuff."

>  -- Arrange these probabilities appropriately to force most combats
>to the 15 - 20 seconds point.

I disagree here. Let combat spin off on its own. I (barely) recall a movie
which had Sean Connery in single combat with a bad guy. Both were in full
armor fighting in the middle of a hot, grassy field. Neither could get the
better of the other. The fight took quite a while. At the end, both were so
exausted the could not stand. A similar fight could happen in our system
with carefully matched opponents. Fatigue happens even if damage doesn't.
Fighters could dance around each other for five minutes (RT) using
defensive attack profiles until one was taunted into launching a real
attack or they fell into a heap and were killed by a nasty bunny.

>  -- The game dynamically defines a "combat state" which is hidden
>from the player and is used only for event process control.

We define a combat state mostly to record the fight and trigger automatic
combat events for engaged pairs (every combat creates its own event) who
fail to execute a command.

>  -- Combat state is initiated upon a definitely combat-oriented
>command from any party (kill, fight, hit, damaging spell, etc).

Exactly. Looking at the archives, this seems to be a problem for people.
Lots of discussion of intent, accidents, etc. There is some fuzzy ground:
Is "THROW KNIFE TO BUBBA" equivilant to "THROW KNIFE AT BUBBA"? Looks like
we are going to drill down beyond the verb level and create the combat
event when the combat programs are called.

>  -- Combat state is declared for both target and source.

We just create an entry in a data table for each combat, attacker and
defender. We create as separate entry for each combat so if BUBBA fights
three hobbits, three events are spawned. If Hobbit 1 decides to flee, that
event is closed out. If #1 decides to join BUBBA and attack his former
buddies, cool. Their combat event is closed and new ones created.

>  -- Combat state's only effect is to enforce timings of actions.  It
>takes XXX time to swing a sword, YYY time to cast a spell etc.

Because I can't control time (stateless, you know), we use action points.
(BTW, an action can take so many points it takes three (or more) rounds to
fire.) This frees the players from the twitch factor. It also creates a
more leisurely (some would say slow) combat feel.

>  -- Combat state is torn down when one part dies or leaves the
>immediate vicinity.  (ie combat state does not apply to long distance
>battles, only proximate)

I don't think distance is a factor unless you mean really long distance. I
wouldn't consider the Unibomber involved in combat with his victims. Same
thing if someone thoughtfully mails my character a mana sink spell which
triggers when the letter is opened. If Boffo is shooting arrows at Bubba
from 100 yards away and Bubba is unaware of his position (Boffo is well
concealed, or Bubba is just clueless) a combat object is created. Bubba
cannot retaliate, but he can use his action points to flee, seek cover, set
off a smoke bomb or jump up and down and shout "unfair".

>I don't like it.  I really don't like it.  But its the best I've got
>right now.



>--
>J C Lawrence                               Internet: claw at null.net
>(Contractor)                               Internet: coder at ibm.net
>---------(*)                     Internet: claw at under.engr.sgi.com
>...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
>
>--


(I have a huge, somewhat incoherent post on a combat system started on my
workstation at work. I should be able to poach enough time to post it next
week sometime. It could even be coherent by then...It references a lot of
past posts and might even be interesting.)

John Bertoglio


>MUD-Dev: Advancing an unrealised future.




--
MUD-Dev: Advancing an unrealised future.