[MUD-Dev] Re: Combat in the Abandoned Realms

[John Bertoglio]

This post has expanded way beyond my original plan. Sorry for the size.
Please note the refs in this doc are spread all over 1997. In most cases I
refer the reader back to the archives for the full context. The Abandoned
Realms is nearing the point where I will be able to make it available for
messing with. Any comments would

- - - - - VOCABULARY - - - - - - - - - - -
The words we use to describe our system are not fully congruent with
conventional mud terminology. The following are some terms which will help
to explain what follows:
Action Points: Pas are abstract units of time. APs  are comsumed when any
action in combat mode is attempted. Actions are scaled according to their
RL time costs. One AP is a very quick action like flicking a dart at an
opponent. Loading a crossbow might take 30 AP or more depending on
character skills and stats and other factors.
Area: A convenient way to refer to a logical grouping of cells. There is
not data representation for areas.
Cells: Cells are the equivalent of mud "rooms". They are built inside of
zones. Multiple gateways between meta locations and grouping of can exist
in a specific zone. The world does not uses real space coordinates allowing
conventional area design. Cells do have average size, average terrain,
cover and other characteristics which affect game play.
Combat Mode: CM is when time slows down and players begin to track their
actions against a time budget. Note that combat mode does not require that
any combat take place. Many game actions can turn CM on.
Gateway: Gateways are stored in a data table which controls the display of
exits to and from each cell and zone. We use conventional compass
directions (8) plus up and down. We also support IN and OUT to allow an
unlimited number of gateways to other locations. The gateway model allows
the player to view adjacent locations through the gateway description which
may be somewhat different than actual location description.
Location: Any spot in the world that can be entered or moved to. This inclu
des realms, regions, areas, zones and cells.
Meta: This refers to actions (movement, viewing, etc.) which reference the
meta surface of the world. These are the large locations which hold the
smaller "room" locations typical of muds.
Named Location: Cells and Zones can become "Named Locations". Named
locations are used as targets for teleport, public and private
transportation and other game features. Teleport also works by cell
coordinates and cell id but this is not available to users.
Object: We use persistent data table combined into databases to store all
objects including temporary ones. When we refer to an object, we are not
taking about OOP, just a table entry which probably has one or more integer
fields with up to 31 binary flag values for each field. While our language
supports it, we have not build the system using an object model. The work
object is also sometimes used as a synonym for item in the text.
Profile: These are essentially character flags that control or affect
player activity during a given event. Profiles can be edited at any time,
even while they are being executed. Multiple combat profiles can be stored
for each system user. These can be selected from menus or by appending a
number to a profile command.
Realms: Worlds. A mirror world can be created by copying the database and
changing the realm mapping. Current world is set on class M planets (moons,
actually) orbiting a gas giant which in turn orbits around a star
Region: Logical groupings of zones. Regions are used for events (like
weather) which are not global but affect a number of cells.
Size: Location size is calculated in meters. It is abstracted as the
average of the overall length and width of the location.
Zone: A meta area. The world is a sphere built on a 1200 by 800 grid. Each
world zone about 20 km high with a variable width from 27km at the equator
to almost nothing at the poles. For game purposes the "size" of a zone is
the average of its width and height. The centroid of each zone is used to
calculate distances. Visual mapping done assuming a 20 by
20 km zone trading visual distortion for ease of mapping.

- - - - - COMBAT SYSTEM - - - - - - - - - - -
Combat pacing. Combat in AR is designed to be a "significant event". In
list terms, it is very granular. It is therefore fully described in a
detailed output text display. Each combat round is between 5 and 15 seconds
of game time and describes a small number of scripted actions or commands.
This causes the pacing to be somewhat leisurely if left in computer
control. About every 30-45 seconds, all combats are polled. If the combat
object is still active (players are still engaged, no retreat or surrender
has taken place) and no manual combat command has been issued, the current
combat profile is triggered again.
Attack. You are under attack if are the subject of any "attack" command in
the system. A combat object is created. You can be under attack and not
know where the opponent is. An element of the combat profile defines your
action when you fail to locate your assailant. The only local function of
this object is to be polled to see if a manual control has been issued
since the last poll. If not the combat program triggers an auto response
based on the player's current combat profile. Otherwise it moves on to the
next combat object.
When you return the attack an additional combat object is created. An
object is created for each pair of fighting players in the world.
Aggression status is checked and marked.

Players have several options during combat. One is to issue direct commands
controlled by specific combat profiles. Another is to issue individual
commands to alter elements of a combat profile. The most common method will
be to simply change the profile being used.

Example [> KILL 5 will choose combat profile #5 associated with the kill
command (and its synonyms). The command [>SPAR 5] would execute the same
combat profile but not do any damage to the players (Fatigue would be
applied as normal. Sparring is almost as much work as actual fighting. Crit
ical failures can also cause damage) or weapons because of "pulled
punches".

The final method is adjusting the entire combat profile via an on screen
menu.

Time frames. Each combat round maps a discrete chunk of time.

All combat starts with awareness checks. This factors ambush, concealment,
combat perception and weapon readiness. Significant differences in
awareness can lead to a first strike situation where action points can be
expended without a reaction from the opponent. Combat range is also
affected by awareness/readiness.
Any unanswered combat actions are now performed. Damage, fatigue, etc. are
calculated and text responses are set to the message queue.

Then combat range preferences are checked. A contest of skills is made to
see if the current combat range is altered. This contest is skill/attribute
based + a random number. This allows a person of lower overall aptitude to
win the range test.

Initiative is then calculated. This is based on the characters base action
point total (modified by increases/decreased to governing stats) modified
by a random number. The base number of action points for the round is the
highest number. Combat starts by performing actions against the base
number. When the person with the highest initiative is finished, the combat
round is over. Actions are performed sequentially according to the combat
profile. Action point costs are scaled against the base number. Therefore,
action point costs will vary in a relative to the speed/dex of the
combatants. This is in keeping with the "slow motion" view of combat. Sam
Peckinpaw would be proud.

Attack. Attacks are direct attempts to use the wielded weapon or weapons
including shields.

Feints. Feints may or may not provide advantage. If successful, the
opponent will be more vulnerable to the next attack. A critical success in
a feint could cause the opponent to loose balance and fall.

Shield Blocks. This is an attempt to block an attack with the best
defensive device.  If you drop your shield you may try to use your forearm
in the heat of combat. Shields may disarm an opponent if the weapon imbeds.

Parry Attempts. These will a clash of weapons. Potential for weapon
breakage and disarm based on the types and sizes of the weapons involved.

[JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00194.html]
   Add a "fight" command which sets an internal state on the
  player character which concomitantly kicks in the combat
  packages.  The "fight" command is then analogous 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.
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 torso...")?  The ruling idea is that at each quantum a
participant would have the opportunity to causitively react and
attempt to manage the results.

[JB]  The goal of the combat display is to approach this level of detail.
The program looks at each action in its time frame and presents the
action/reaction to the players. This is similar to the detail created by
older text based baseball programs which that were internally just stat
engines, but provided an (optional) play-by-play, pitch-by-pitch
description of the
action. What we are trying to simulate is the cinematic (Myself and most of
the rest of the world have no other reference) type non-firearm combat.
This model tends to have one combatant attack with a flurry of blows, while
the other defends. Then the other fighter responds with a number of counter
blows. A "correct" (read: good guess) defensive move can result in disarm
or a knockdown, but normally just allows the combat to continue with no
damage being taken.

[JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00194.html]
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.

[JB] We handle this by allowing "extra" (that is, unallocated by the
current combat profile) actions to be assigned to elective moves.  A
defensive approach might call for one feint, a single offensive blow with
all other action points channeled into a mixture of shield blocks and
weapon parries. Essentially, the more you "hard code" your combat profile,
the better chance you have of a "critical" result, good or bad. Choosing a
profile that is less specific will "smooth out" the numbers somewhat.

Two Scenarios (Note action point values are not really thought through at
this point)
Bubba and Boffo have identical action points and random rolls so combat
will start counting down from 20. Bubba has a fast weapon, a dagger, Boffo
wields a club. Combat has been going for a round or two so initial
positioning is set. Neither has a shield or significant armor. Bubba wants
the combat to take place at range 1 (less than one meter but not range 0
which is hand to hand). Boffo wants combat to take place at range 2 (1-2
meters), staying outside of the range of Bubba's dagger. Current combat
range is 1

Scenario One: Conservative scripting, both players.

Both combatants script a single attack, a thrust for the dagger and an
overhead smash for the club. All remaining points allocated to defense.
Bubba the knife fighter uses his low encumbrance to attempt to Dodge
incoming blows while Boffo uses his weapon parry as an exclusive defense.
Since both have an action point buffer (because they have reserved action
points for defense), their combat profile has the choice of aborting an
attack to avoid an incoming attack. The combat aggressiveness setting
determines the chance the attack being aborted. At the highest level
(Berserk) there is 0% chance the attack will be aborted. The lowest level,
(Extremely Cautious), means that an attack will always be aborted to make a
defensive move. Boffo is feeling aggressive but Bubba is being careful.

Note: Text is abridged since four text streams are created, one from the
point of view of each of the combatants, one for onlookers and one for
logging/historical purposes.

[20]
> Bubba attempts to close with Boffo [ contest of skills is calculated]
[18]
> Bubba closes with Boffo (combat is now a very close range)
> Boffo swings his club at Bubba
> Bubba thrust his dagger at Boffo
[15]
> Bubba aborts his attack and dodges the blow. [uses a dodge action]
> Boffo misses Bubba with his club
[16]
> Bubba thrust his dagger at Boffo
[14]
> Boffo dodges the dagger thrust [uses a dodge action]
[12]  All planned actions are finished report a stalemate situation
> Boffo and Bubba circle each other with blood in their eyes
Imagine a situation where both players have nothing but defensive
moves....they circle, shout out taunts and combat either starts or one or
both go away.
Same sequence both players have turned their combat amps up to 11 (cf.
Spinal Tap, the movie)
[20]
> Bubba attempts to close with Boffo [ contest of skills is calculated]
[19] ....
[18]
> Bubba closes with Boffo (combat is now a very close range)
> Boffo swings his club at Bubba
> Bubba thrust his dagger at Boffo
[17] ...
[16]
> Bubba hits Boffo in the torso with his dagger and draws blood [ armor
penetrated, light damage done, no stun effect]
[15]
> Bubba thrust his dagger at Boffo
> Boffo ignores the pain and smacks Bubba soundly on the shoulder with his
club.  [medium concussion]
> Bubba momentarily stunned. Attack is aborted.
[14]
> Boffo swings his club at Bubba
[13]
> Bubba recovers and thrusts his dagger at Boffo's eye
[12] ...
[11]
> Boffo hits Bubba with his club. A glancing blow. [a few points of
fatigue]
> Bubba aim is off but he hits Bubba in the shoulder with his dagger. Boffo
is bleeding. [hit points are depleted]
[10]
> Boffo swings his club at Bubba
> Bubba thrusts his dagger at Boffo
[9] ...
[8]
> Bubba drives his dagger into Boffo's chest [major damage]
> Boffo is momentarily stunned. Attack is aborted.
> Bubba thrusts his dagger at Boffo
[7]... and so on.

If you had a light weapon like an epée, you might allocate all defensive
efforts to shield blocks, a heavy weapon user could allocate to weapon
parries to go for a disarm or a broken opponents weapon.

[JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00194.html]

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.

[JB] This is a great idea. The current system does not really support it
directly because the combat "scripting" is done via menus and short command
snippets. We could add and export utility, which lists the current settings
of a profile, but I am unsure of the benefit to players. I am thinking
about an "AGAIN" command, which repeats the previous action. Due to
statelessness, we would have to buffer the last command given in a
player-linked table. This would help when a really nasty string needs to be
typed for a complex command and then repeated. Any comments on this one?

[Adam Wiggins
http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00198.html]
On our mud, you can go immediately get into a fight, and your character
will make semi-intelligent decisions.  Now, you can do infinitely better
if you a) customize his fighting style and other options before combat
and b) interject command during the fight to take the ideal action.  But
if you just get into a fight without knowing what any of these commands
and options are, you won't be swearing at your player for acting like a
total dumbass.

Thus, the default is to stand up after you get knocked down, attack
whenever you see a reasonable opening, block when you see a blow that you
think is gonna be potentially dangerous to you.  As you go along you'll
probably decide to customize your character quite a bit - for instance,
setting your aggressiveness very low, which will keep you character
circling and then manually typing "swing" or "thrust" or whatever to
time your blows just as you like.  Or if you've got a magical sword made
of glass, you can toggle off parrying for the time being, even if you're
a master fencer and this is your main defense.  Or if you're a judo type,
you may not want to get up when you get knocked down - you'd rather try
to drag your opponent down with you, since that's where you're at an
advantage.

But the point is, your character as he or she enters the game will do
basically what you'd expect a normal, unskilled person to do in a given
situation (and this applies to many things other than combat).  From there
you can customize and tweak as you develop them.

[JB]  This is done in our system by the use of default combat profiles.
Even if you are not aware of their existence (because of a failure in my
interface design), you have one and it will work for you.

[Shawn Halpenny
http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00200.html]
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?

[JB] What happens is Joe can issue any command he wants and go about his
business. When combat is polled, the object will terminate (recording Joe
as the victor since he is alone in the combat location and the time of
combat) since one of the opponents is missing. If Bubba and Boffo were
fighting Joe and Bubba left, that object would terminate but the Joe-Boffo
would continue to poll. The state called "combat" only exists to keep NPC's
interested in the battle and prevent people from being attacked without a
plan of defense. Link dead issues also apply here but since on web you are
"always link-dead", they are an important primary design consideration.

[Shawn Halpenny:  ibid]
 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.

[JB] Absolutely. You have to restart the combat. If Bubba comes back into
the room with Joe with weapons sheathed and says "Please don't kill me.",
it would be kind of uncool for Joe's combat profile to finish off the
wounded Bubba (unless that is just what Joe told his combat profile to do).
Now...if Joe want to whack Bubba....he types kill Bubba, a new combat is
started, Bubba is probably dead (more likely, unconscious) before he auto
draws his dagger in defense.

[JC Lawrence:
http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00214.html]
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.

[JB] We do something similar. We create combat objects for each pairing of
fighters. This allows multiple opponents and different combat states for
each player and NPC. It also allows for checking aggressor status and other
elements. It also allows one-way combat. Example: Robinhood pops up from
cover and shoots Bubba with an arrow. Robin is in combat with Bubba, but
Bubba's combat reaction is only triggered if he is able to respond to the
attack. His defensive combat profile would then probably have him go prone
and/or look for cover. At some point, his perception skills will locate
Robin (which will create a combat object) and he can attempt to close and
fight or run like crazy.

[JC Lawrence: IBID]
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 continuing the fight in the new location.

[JB] My system provides a profile setting for combat pursuit. Like other
elements it can be changed on the fly. If the player issues >FLEE [dir] or
> ESCAPE [dir] command, the server assumes the retreat is contested (the
retreating player hopes to avoid pursuit) and a skills/stat test is made to
see if the pursuit was effective. A successful pursuit results in both
players in the new cell and the combat continues. A failed pursuit places
the retreating character in the new cell and the combat winner stays in the
original cell.

[JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00219.html]
Does your combat have some sort of automated attack/defense?  That is,
can a user launch a command like "Kill Boffo" and more or less sit
back and watch the slaughter?  If not, if Bubba does a "Kill Boffo"
and then does absolutely nothing further, will anything in fact
happen?  I suspect that there is a question of state in there under
the comverse.

[JB] I don't see how some kind of combat state can avoid being created.
Issue a KILL command and you will target the target (courtesy of The
Department of Redundancy Department) and trigger your first pre-set combat
profile.

[JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00219.html]
<Adam Wiggins comments some people just want to play>
Good point.  I have a system default combat package which rides along
on default bodies, but its, err, well, wimpy.  Its basic modus
operandi equates pretty well to, "run in circles, wave your arms
about, scream and shout, hit him with your inventory, run some more".
The point of a learning curve also raises the question (outside of
steepness and duration) of how much better a player at the top of the
learning curve should be than one at the bottom.

[JB] Your default profile is about right. One whack, and a lot of running
and ducking is a reasonable expectation from a newbie. Regarding the
learning curve: Skills and talents balance the careful choice of a combat
package. Careful (or just plain lucky) choice of a combat profile can cause
a beginner to deal massive damage to an arrogant expert. On the other hand,
a newbie will usually wither under the determined assault of a more
experienced player. Holes and bugs in the system will be discovered and
exploited as well.

[JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00232.html]
Having a binary engagement state (in-combat or out-of-combat) also
obviates (or at least reduces) lesser forms of engagement, such as
passing spats, displays of force, etc.  I like the idea that there can
be an I-am-fighting state as maintained by the character-internal
flag, but that for general manipulation, especially for less dedicated
affairs, the situation remains fluid.

[JB] This comment prompted me to add optional combat states/goals to the
combat profile. Non-decisive posturing can be very important in a conflict
simulation. While I support a binary combat state, I am totally against the
idea of a binary (kill or be killed) outcome. In America we have a habit of
liking "good" bad guys. A good way to be a cool bad guy is not to kill your
opponents. "Your money or your life" is a classic cliche seldom heard in
most online environments. Asking for surrender allows success for the
aggressor without total failure for the victim.

[Adam Wiggins http:
//www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00238.html]
<Regarding silly things which happen during standard mud combat>
My favorite is stopping for a quick snack and changing into your armor
during combat.  Of course, most give you some sort of 'lag' to make
it so that you can't do other things in the meantime, but it still
seems silly to me that this doesn't have any impact on your combat
prowess.  If I'm wriggling into my jeans, chances are my ability to defend
is rather low.

[JB] Try that during combat rounds in AR and you will be toast. Something I
forgot to mention about the combat: All commands are available but most are
forced through the combat round system as long as a combat flag is thrown.
You can still [LOOK WEATHER] but the [WEAR] command will charge you action
points for each item being removed and added. You will have some problems
if you start combat with your pants down around you ankles.

- - - - - Random Thoughts - - - - - - - - - - -
[JCL ibid.]> 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 dada yada,
> so keeping advancement via combat (or even any dregs of the
> "experience points" idiocy) would be counter-productive.

[Adam Wiggins] Honestly, is _anyone_ on this group still using classes,
levels, or
experience?  I'm to the point where I can't even bring myself to play
non skill-based muds, although classes don't bother me all that much.

[JB] No classes in the system, but a strong bias towards creating a mix of
characters whose design-time and playtime choices mold them to be similar
to characters forced into artificial classes.  Levels are replaced by
social achievement, non-linear, not related to specific accomplishments but
using a system carefully poached from JCL's RP system. Experience is
tracked but converted into Development points which allow personal growth.
Experience is granted for EVERYTHING. Even moving from place to place. A
key tuning issue will be how to balance these numbers. Experience provides
a metric for accomplishment.

[Jeff Kesselman
http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00679.html]
UOL has been making all these noises about their great ecological
simualtion-
PREDICTION:  Within 3 months a group of purposefully destructive players
will have blasted hell out of their "delicate ecology" just for the purile
thrill of destruction. I do NOT believe in uncontrolled simulation. In an
unconrtolled world with few real world consequences, the destructive
minority destroy the
experience for everyone.

[JB] Turned out Jeff was right. I thought the sim part was great, but did
not take into account the power of players to screw things up. I guess it
turns out that abstraction is not that bad an idea where necessary.

[Chris Grey
http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00248.html]
I'll repeat my first experience on an old LPMud: I knew it
was a combat MUD, so when a saw a "stick", I picked it up and tried to
wield it as a weapon. The system simply replied "Huh?" to all of my
attempts, leading me to wonder how to use a weapon. It never occurred
to me that the system would fail to understand a commonly used verb
just because there were no appropriate objects nearby. (It turned out
that the stick was a dead torch.) I suspect that most new users would
have exactly the same response.

[JB] In our system, you type WIELD STICK and you will now have a stick as a
weapon. It is not classed as a weapon, it will default to generic modifiers
for an object with its general parameters, height, weight, etc. This means
(due to limitations in our design) that a two foot stick of salami has the
same characteristics as a two foot stick of oak of the same weight. Players
would prefer a club (a weapon class object) with a tapered shaft and most
weight near the end. Being a weapon class it will be much more effective
than a general class or food item. (Food combat is an under-explored topic,
IMVHO) Of course certain field expedients, like breaking a bottle will
create a weapon class item out of (in this case, Liquid Container) type of
object.

- - - - - Chronons  - - - - - - - - - - -
[JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00298.html]
BIRTH:  Ideas of birth are entwined with character generation.  One day,
as I pondered MUDs, an idea formed, fully developed:  When a new character
is generated, it is assigned a certain number of "chronons" which roughly
represent the number of hours (or other suitable unit of time) the
character has until death by old age.  This number is hidden from the
player.
To generate statistics, the player spends these
chronons, as many or as few as he or she would like, on a desired  skill.
This represents the number of hours in life that the character has spent
learning this skill (for example, in generating my character, I decide
that swimming, assuming it is allowable in the MUD, is a good skill.  I
spend 1000 chronons on "swimming").  These chronons are subtracted from my
original amount.  In exchange, this skill confers certain benefits to my
character: additions in strength, overall health, the ability to cross
water, etc.
<Snipped further description of concept including death from old age>

[JB] This is an interesting idea. It might be (commercially) viable if
presented as a play option (particularly for advanced characters/players).
The gods grant you semi-immortality in return for accepting constraints
(which prevent you from competing with the self-same gods for supremacy in
the world). For these players chronons spent are not deducted from a life
line. They are used only to measure resource consumption verses time. So if
you hole up in your loft for a week and consume the book of runes, you
better have some frozen pizza and beer or you will emerge from your ordeal
weak (or dead). You might also suffer hallucinations (which could get very
cool...vision quests, etc.)  A player could elect to live a life and accept
the fact of aging in return for the ability to approach god like power near
the end of life. They would live their life according to the constraints in
JCL's post, but would have the ability to grow faster and higher. Like the
replicants in Blade Runner, they would live short lives but burn brightly
for the duration....could get interesting!

---------------Prepositions and parsing-----------------
 [JCL http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00326.html]
What with the recent discussion of parsers and methods of parsing
commands, and old entry from my to-do list popped up:
  Support for prepositions such as "under", "on top of", "behind" etc.
Anyone got any ideas for supporting/parsing a command like:
  hide under the desk
or
  put the rock under the rug behind the pillar

[JB] We support the notion of objects being "external containers" An
external container is a object on which items can be placed. It differs
from a standard container because its objects are fully accessible and
visible. A table is a simple example. A "fast access" container is one in
which items are contained but visible. Examples: a quiver of arrows, a
bandoleer of darts or bullets, etc.

It would be easy to add flags that further describe the container state and
options. A conceal flag would add toggle the hidden state with the hidden
object value based on the skill of the hider. We make the assumption that
if it is possible to hide items in/on/under another item, the success of
the hiding is skill based.

An item like a stone altar would have the "put on surface" flag turned on.
A desk might have a surface, under, behind, and in flags. The IN flag allow
a desk to be a standard container and eliminates the need for individual
drawer objects...of course the desk could have drawers which are containers
and have their own flags etc....

Some checking would have to be done on the size of the items being
concealed. I would probably make is so only items of essentially 0 bulk,
(letters, rings, maps, etc.) could be dealt with in this way. This would
avoid the ability to hide the elephant under the rock behind the pillar. A
item would gain these flags by default during creation based on their size.
Some abstractions is required as it would be possible to put that a scroll
placed under a small book would be in RL visible, but the server would
report seeing only a book on the desk.  Some dinkering around with values
will be required to implement this in a meaningful manners.

---------------Roleplaying-----------------
[Marian Griffith
http://www.kanga.nu/~petidomo/lists/mud-dev/1997Q2/msg00372.html]
The simple way to get rid of combat twinks is to have a real (gamewise)
cost attached to it. Make armour and weaponry expensive to get and
maintain. Don't give it away for free with each corpse, but make players
purchase it with a armourer and weaponsmith. Make money hard to get at,
and make not having it a hazardous lifestyle (e.g. characters can really
starve to death if they don't eat enough, or the right things). Don't
reincarnate characters when they get killed but make that dependent on
the actions of other players. If you don't have friends then your
characters
won't last long. That should make players who are looking to fight think
twice and give players who don't want to other things to do.

[JB] All good ideas above. The key to maximizing RP is to understand what
you are trying to accomplish. We are working to create an environment where
seeing a suit of full plate mail being worn is a rare and interesting
event. You want the rusty cutlass to be a valued weapon because it has
awesome destructive power compared the players bare hands. Create risk.
Create reasonable danger. People will respond by roleplaying because that
is how they will get out of a situation. Another point is differentiation
of player races, weapons, tools etc. If you have to think like a Hobbit to
get out of a situation, your mind will automatically roleplay the
situation. If you want to figure out how a small child did something, you
go down on your knees to see the world from their perspective.

Very few computer RPG games have ever put me into a RP frame of mind. I
never have felt like I was an elf or a dwarf. Mostly I felt like an adult
male living in the late 20th century who was running around in a computer
world solving problems and discovering things. Perhaps this is the reason I
finish so few of these games. After a while they get to much like work.
Now, world building/god games are another story. They can create emotion.
You begin to think things like "Stalin is a least predictable, he will
attack as soon as he is able, but Ghandi is tricky...I just don't trust
him." Now this is roleplaying. You can't help it. My wife come running
thinking my monitor fell on my head because I yelled at the Queen of
England who just broke her alliance while the bulk of my forces were
deployed on another front. Real emotions translate into real roleplaying.

It is a simple fact of life that if you reward something, you get more of
it. Reward healing, reward giving money to beggers, reward killing monsters
with poor equipment...you will get more of it. Use the server to mold
behavior by altering the world somewhat. A grocery store near my office
doesn't have any rules about how fast you can drive in its parking lot. The
speed bumps control speed just fine without signs or enforcement.