Combat system Design

[Nathan F. Yospe]

The Black Man <sd...@st-andrews.ac.uk> wrote:

:Well, seeing as this news group doesn't getr much traffic, I thought I'd
:ask if anyone reading it had done much theoretical work on combat system
:design?

Part of the reason it gets little traffic is that it is officially dead.
Right now, rec.games.mud.admin is the most suitable place for these sort
of posts, though it certainly lacks. See the new groups proposals.

:I'll abstract this as much as possible, because it's a rather different
:Mud... (well, it will be)...

:I'm writing/admining a Mud, where we have made significat changes to the
:bog standard hit point system, and thus need to follow it through with
:changes to the combat system.

Hmmm. What you do will, of course, be highly reflective of the degree of
change from standard hitpoints. Were you to use damage to bady parts, or
locations of damage, you would need to have combat reflect that.

:We have two types of damage: hard and soft. Soft (pretty much standard
:HP) regenerates with time, Hard requires special attention to regenerate.

Hmmm. A good start.

:In addition, we have stats, weapons, weapon skills, and armour...

:Anyone got any comments, or is the standard

:if(random( skill + stat1 + stat2 + weapon class + weapon skill ) >=
: random( armour class + dodgeing skill + stat)
:/* hit */

:a decent system?

Guess so, if you are going to run with that sort of system, though those
randoms are going to play havok with predicatability. Maybe make the ran
seed an addition to the above set?

Just some additional thoughts. After a great deal of thought and playing
around with my system, I settled on a roundless, pulseless, combat model
with all aspects of combat being normal skills, and a degree of reflexed
reaction, combat or no, for actions done in a character's viscinity. The
best part of this is that NPCs get the same treatment, without having to
invoke their AIs. I also ended up with a variant damage curve, running a
nearly logarithmic fall for impactive damage, (thus, the bum knee) yet a
nearly linear rate for things like shock recovery. Ultimately, anything,
no matter how minor, is going to transmit what amounts to a token damage
impulse, so the slap in the face leaves your face stinging, and the rock
you kicked might stub your toe. The result? You can kill their character
without being there to get retaliated against, by setting up a trap. The
concept of combat rounds becomes obsolete when ranged weapons work, thus
making reaction management the critical concept. How do I calculate hits
and misses? Simple enough. (Target Size)/(Target Distance)(Target Speed)
gives the difficulty of that particular target (well, simplified, but in
that vein) and skill and several local factors involving focus give your
character's ability to hit a target of mean difficulty. No random needed
for a calculation that is dependent on that many environmental factors.
--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!

[john]

Nathan F. Yospe and The Black Man wrote
[a few snips throughout]
: :ask if anyone reading it had done much

: :theoretical work on combat system design?

: :I'm writing/admining a Mud, where we have made significat

: :changes to the bog standard hit point system, and thus need
: :to follow it through with changes to the combat system.

while i retain the standard hp for bodily health points, i also add
ep, for combat endurance/effort points. your EP are lost first in
most cases, as a measure of how long you can go before taking
damage. this restores itself linearly over time. once you start
taking HP damage, though, your effectiveness drops proportionally.
HP restore themselves next-to-not-at-all, and must be dealt with
by magic or hospitals, etc.

: :We have two types of damage: hard and soft. Soft (pretty much

: :standard HP) regenerates with time, Hard requires special attention
: :to regenerate.

=)

: Just some additional thoughts. After a great deal of thought and

: playing around with my system, I settled on a roundless, pulseless,
: combat model with all aspects of combat being normal skills, and a
: degree of reflexed reaction, combat or no, for actions done in a

like Nathan, i also wanted to get away from the standard your-turn-my-
turn heartbeat-driven put-me-to-sleep combat. however, to implement
my "effectiveness drops proportionally" notion, i did not want to spend
a nice complex ton of calls to calculate the hit/damage formulas every
'round'. so, the next strike for a living is called out based on his own
determination on how fast he can move. in a fight where one guy gets
in huge hits early, realistically the opponent won't get a nice equal
number of return hits. i leave the damage alone, as i figure even a guy
with his leg cut off can inflict the same damage with his bow&arrow.
for example, a high-level warrior might start with a 'round' every 2.4
seconds, while a newbie farmer would get a 'hit' attempt every 4.3 secs,
and the seriously wounded archer would get his next shot in 5.4 secs.
he'd better make it count :}

: best part of this is that NPCs get the same treatment,

yeps.

: concept of combat rounds becomes obsolete when ranged weapons

: work, thus making reaction management the critical concept.

that's what _really_ forced me to leave round-based combat. i couldn't
think of a way to have an archer and a warrior standing in front of each
other trading blows realistically. now the archer will probably get in 2
shots if he's good, before he'll have to drop his bow in favor of a sword,
or else run to set up another volley. if there's someone in front of him,
the bow becomes a bash weapon, not a ranged one.

i'd like to hear other combat system ideas...
-John

[Chris Lawrence (Contra)]

Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:

: ... How do I calculate hits

: and misses? Simple enough. (Target Size)/(Target Distance)(Target Speed)
: gives the difficulty of that particular target (well, simplified, but in
: that vein) and skill and several local factors involving focus give your
: character's ability to hit a target of mean difficulty. No random needed
: for a calculation that is dependent on that many environmental factors.

Not all weapon behaviours are deterministic.

Many weapon behavious are dependant on external influences.

Given a short barrel length the resultant trajectory of a bullet after a
dozen yards or less pretty well equates to, "in the general direction of".
Given dead still air and a Sharps .50, a good marksman can repeatably pick
ticks off buffalo ears poking over the horizon (minor exageration). Give
even a slight breeze or intervening thermal...

So, in your system Bubba can pull out his Saturday Night special with the
cut down 1" barrel and plug the stationary mugger in the left eye at 10
yards every single time? After all, if he can do it once, he can do it
every time.

--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...

[Nathan F. Yospe]

claw...@cup.hp.com (Chris Lawrence (Contra)) wrote:

:Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:

:: ... How do I calculate hits

<snip>
:: character's ability to hit a target of mean difficulty. No random needed

:: for a calculation that is dependent on that many environmental factors.

:Not all weapon behaviours are deterministic.

:Many weapon behavious are dependant on external influences.

Umm, that was sort of my point. I model a set of fluid environmental
factors, which elliminates the need for a random() call for the hit.
I've never liked the types of curves you get with random(), and even
more complex bell curves don't quite cut it. I kind of like having a
visable environmental factor spoiling your aim...

:Given a short barrel length the resultant trajectory of a bullet after a

:dozen yards or less pretty well equates to, "in the general direction of".
:Given dead still air and a Sharps .50, a good marksman can repeatably pick
:ticks off buffalo ears poking over the horizon (minor exageration). Give
:even a slight breeze or intervening thermal...

And in a vacuum, the breezes and thermals are mute. With a random(),
there is no way to handle the difference therin. More important, any
laser will lose power quickly in atmosphere, but has unlimited range
in vacuum.

:So, in your system Bubba can pull out his Saturday Night special with the

:cut down 1" barrel and plug the stationary mugger in the left eye at 10
:yards every single time? After all, if he can do it once, he can do it
:every time.

Naw. The shifted breeze will mess him up, or the reduced response of
his right arm, or the fact that his balance is still off from recoil
on the last shot.

[Andy Davidoff]

i'm implementing the world design something like each of those points.
terrain will be generated by querying the area. it is true that you lose
the "feel" of a room description when it's generated for you, but i think
that the versatility is worth it. you can issue a command like "walk to
fountain", and you'll walk to the fountain. (this can be done fairly easily
in circle, btw) you _could_ walk north, but chances are you would never
perform this kind of "freestyle locomotion" unless you were exploring.
objects do not have x,y,z coordinates, rather the world follows a standard
sub-allocation technique where an area with a need for more detail can
spawn a more detailed version of itself if necessary. the more detailed
version would contain sub-containers to handle locations of objects in the
area. it'd be nice if you could assign a mesh of distances between
locations, but it really isn't practical.

combat will be something similar to what we designed at sfmud a few years
ago; if yer not busy, you get busy. i'll be adding all the typical stuff
you would expect to find in a OO mud; limbs, range, yadda yadda yadda...

...still looking fer more java coders & designers...
de...@pobox.com
nauga networks
vision mud

[Andy Davidoff]

Nathan F. Yospe wrote in article ...
:Umm, that was sort of my point. I model a set of fluid environmental

:factors, which elliminates the need for a random() call for the hit.

this sums it up perfectly. the added benefit is that you can tell your
players that nothing is random. this means they have noone to blame, and
they will be prompted to research the game/environment more closely.

is the real world random? (ok, dont answer that with some bullshit about
sub-atomic particles) i'm talking about the level of the gun, the wind, and
the buffalo - code what you know. if your system is well designed, the wind
doesn't move randomly, the gun doesn't move randomly, and the buffalo
doesn't (yep, you guessed it) move randomly. was that so hard?

the player who spends the time to develope a shooter's stance and read the
winds before taking aim should be rewarded with success.

[Chris Lawrence (Contra)]

Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:

: claw...@cup.hp.com (Chris Lawrence (Contra)) wrote:

: :Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:

: :Not all weapon behaviours are deterministic.

: :Many weapon behavious are dependant on external influences.

: Umm, that was sort of my point. I model a set of fluid environmental

: factors, which elliminates the need for a random() call for the hit.

: I've never liked the types of curves you get with random(), and even

: more complex bell curves don't quite cut it. I kind of like having a
: visable environmental factor spoiling your aim...

That just changes the representation without changing the model. Now
the forumulae doesn't have a random seed/weight for "environmental
influences" but has a variety of such random values to calculate specific
environmental influences and from thence their effect on the attempted
action. A little more complex, more detailed text descriptions (wind etc),
but the same thing under the covers.

: :Given a short barrel length the resultant trajectory of a bullet after a

: :dozen yards or less pretty well equates to, "in the general direction of".
: :Given dead still air and a Sharps .50, a good marksman can repeatably pick
: :ticks off buffalo ears poking over the horizon (minor exageration). Give
: :even a slight breeze or intervening thermal...

: And in a vacuum, the breezes and thermals are mute.

There are very few pure vauums out there. Space? Try long distance laser
fights in one of the denser nebulae, or low orbit about an atmospshered
planet, etc etc yada yada. Heck, I'll bet you'll get some pretty neat
gaseous effects just haning out above one of IO's more active volcanoes.

: With a random(),

: there is no way to handle the difference therin. More important, any
: laser will lose power quickly in atmosphere, but has unlimited range
: in vacuum.

Any just where are you going to find a perfectly focussed laser whose beam
has no spread? Sure, its damn near perfectly collimated, but ran the puppy
for a few hundrend/thousand/million klicks and you'll just get that all over
slightly warm feeling.

NB Not applicable of course if everything is close range, tho chaff, metal
gasses, and colour absorbtion still work great (try cutting a green cloth
with a green laser).

[Ben Greear]

In article <336E58B1...@mc.net>, Narien <dben...@mc.net> wrote:
>Erik Lavander wrote:
>> 4. A world model where no absolute locations exist. Coordinates are
>> given for every object. A description engine produces room
>> descriptions from the information gathered from the world model, with
>>distances to objects, players and monsters.
>
>like to hear more about it. The possible bad sides I see here are:
>
>1) Difficulty in determining walls -- Actual room making difficult.
>2) Loss of "feel" with this type of descripting, though it does make
>things a LOT easier for the builder.
>3) Overall construction difficulties.

Two and three seem to contradict, I'd argue FOR 3 and against 2 here..
>
>Good sides I have observed:
>1) makes some things easy for builder.
>2) Makes combat VERY cool, and much more realistic (not to mention a
>little easier to work out).
Especially if you include ranged combat (which I suppose would have to
be default in a coordinate type of system.

>3) Makes the world as a whole cool.
>4) Has options for hearing range, and sight range, leaving room for
>different races with better vision/hearing, and spells that can improve
>these senses :).
>5) Lots of other neat stuff.
>
>I would like to hear other thoughts on this design of how to do areas,
>especially remedies to the flaws in it. Thanks.
>Narien

One possible solution would be to tag descriptions with a 'detail' level.
If you can detect above/equal the level, then you get the desc. The
bad parts to this would be that descriptions might look choppy if the
zone builder wasn't very careful. Also, the concept of a 'room' would be
meaningless. This may very well turn out to be a bonus, but, it could
throw off users used to a room based layout. Because we must eventually
construct the enter world within our own minds in order to play with any
fun/success, a non room based system might not catch on too quick.

I'm kicking around a space-based MUD idea, and coordinates are a natural
draw. These and other problems still linger however...

Ben

--
Ben Greear | "He said he let the bottle do the thinking,
gre...@pollux.cs.uga.edu | but you can't shake the Devil's hand and
www.cs.uga.edu/~greear | say you're only kidding. --TMBG

[D. B. Brown]

Andy Davidoff wrote:
> is the real world random? (ok, dont answer that with some bullshit about
> sub-atomic particles) i'm talking about the level of the gun, the wind, and
> the buffalo - code what you know. if your system is well designed, the wind
> doesn't move randomly, the gun doesn't move randomly, and the buffalo
> doesn't (yep, you guessed it) move randomly. was that so hard?

Well, take for example, a basketball player making a free throw.
The player is in a specified place, always the same distance from
the hoop. The hoop is always the same distance from the floor.
The player always has no interferance, yet even professionals (getting
payed millions to shoot the ball) miss as many as one in three.

Is that random? I don't think so, but in what way are you going to
model 'shoot basketball' in any way beyond using a random() call?

> the player who spends the time to develope a shooter's stance and read the
> winds before taking aim should be rewarded with success.

Should be rewarded with a better chance of success, IMO.

There is a small percentage of nerve impulses that don't get fired or
interpreted properly. This can effect the success of a high
dexterity action. How is that going to be modeled?

IMO, life/mud combat/etc isn't totally random, but there are so many
variables that affect the outcome that randomness is a reasonable,
natural modeling scheme.

--
+=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-+=--=--=--=--=--=--=--=-+
|Do you ever get the feeling that the story's|D.B. Brown |
|too damned real and in the present tense? |da...@bme1.image.uky.edu|
| -Ian Anderson | "..." |
+=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-+=--=--=--=--=--=--=--=-+

[Narien]

> >1) Difficulty in determining walls -- Actual room making difficult.
>
> >2) Loss of "feel" with this type of descripting, though it does
> make
> >things a LOT easier for the builder.
> >3) Overall construction difficulties.
>
> Two and three seem to contradict, I'd argue FOR 3 and against 2
> here..

I was meaning that description writing would be easier, but other
things, such as object layout (hence construction, not writing) would be
difficult.

> One possible solution would be to tag descriptions with a 'detail'
> level.
> If you can detect above/equal the level, then you get the desc. The
>
> bad parts to this would be that descriptions might look choppy if
> the
> zone builder wasn't very careful. Also, the concept of a 'room'
> would be
> meaningless. This may very well turn out to be a bonus, but, it
> could
> throw off users used to a room based layout. Because we must
> eventually
> construct the enter world within our own minds in order to play with
> any
> fun/success, a non room based system might not catch on too quick.

Aye, players may be discouraged by the shift from the norm.

Narien

[AeternuS]

It is the goal of most programmers to get their game as real as
possible... but, there is a point where it's too real. If the game was
as real as life, why would we play it?

[aeternus]

[Brolli]

Heh. Good point. We play MUDs to leave some segment of realism behind.
Personally I think 'realism' could be added if you didn't let players log
off, thus letting them 'live' on the MUD. A line has to be drawn
somewhere. You have to balance 'playability' with 'realism'.

Also, a balance needs to be struck between overly simplified models and
overly complex code. Earlier in this thread someone claimed to have
eliminated the random() call from combat by weighing in environmental
conditions. I'd _really_ like to see a model that accounts for _all_
possible infuences on a combat strike (assuming that the system is based
on RL physics), so that there is nothing left to chance. IMHO using
environmental factors should alter the probabilities (maybe even to the
point of a 99.99% sucess rate in 'perfect' conditions), but there should
always be some chance of failure.

Here's an extreme example: An Orc is tied up on a table and completely
defenceless. The lighting is such that I have an excellent view of my
victim, I am an expert in orc-killing, and I have mastered the use of my
weapon. Even though I am currently in excellent health, there is a tiny
chance that a small dust particle lodges in my nasal passageway as I'm
about to strike, causing me to sneeze and miss the hapless orc.

Now do I need to track every dust particle to see if they happen to fly up
my nose? Of course not. I call random() to see if any out-of-the-ordinary
things happen.

Unfortunately nearly every combat system I've read realies way too much on
random() to predict those actions which are much better dictated by
models. (DISCLAIMER: there are exceptions)

[Scott Anderson]

In article <5kos17$59o$1...@cronkite.cc.uga.edu>,

Ben Greear <gre...@pollux.cs.uga.edu> wrote:
>>Good sides I have observed:
>>1) makes some things easy for builder.
>>2) Makes combat VERY cool, and much more realistic (not to mention a
>>little easier to work out).
>Especially if you include ranged combat (which I suppose would have to
>be default in a coordinate type of system.
>>3) Makes the world as a whole cool.
>>4) Has options for hearing range, and sight range, leaving room for
>>different races with better vision/hearing, and spells that can improve
>>these senses :).
>>5) Lots of other neat stuff.
>>
>>I would like to hear other thoughts on this design of how to do areas,
>>especially remedies to the flaws in it. Thanks.
>>Narien

Some ideas I've been kicking around:

For speed, use a single int for the coords. With a 32-bit int, you can use
10 bits for each coord for 1024 positions for x, y, and z. That leaves 2
bits that could be used for rotational positioning, perhaps.

Coords would be relational to the room. i.e. when I walk in the door I
get a new set of coords.

Each room has a coord which positions it inside its encompassing area.

Rooms can be arbirarily large (the room would define the granularity or
the coords of objects within it), but with a corresponding increase in the
minimum granularity within the room. Therefore, a field would be one large
room with each coord having a granularity of 5 feet perhaps, as opposed to
one inch within an interior room.

Exits are defined by specifying which 'wall' (and I use the term loosely:
a 'wall' is really the room boundary). Outside exits could have a bit set
which signifies that it covers the entire boundary. Exits would default to
'center of the wall'. This makes building easy for rooms which fit the
default criteria (defined walls, 'door-like' exits in the center of each
wall), but flexible enough to encompass outdoor areas and oddly shaped
rooms. You would be able to define an exit as being positioned to one
side, or wider than the default, etc.

Determining distance should be fairly easy using bit operations on the
integer coordinate.

My feeling is that a system like this would make some compromises, but it
would gain 1) ease of building areas and 2) some speed. It would lose some
flexibility, perhaps, and the granularity increases with the size of the
room, but typically you don't need a fine granularity with a larger room.

Regards,
-scott

[Ben Greear]

In article <5kspcj$c...@conch.msen.com>, Scott Anderson <ba...@msen.com> wrote:
>In article <5kos17$59o$1...@cronkite.cc.uga.edu>,

>
>Some ideas I've been kicking around:
>
>For speed, use a single int for the coords. With a 32-bit int, you can use
>10 bits for each coord for 1024 positions for x, y, and z. That leaves 2
>bits that could be used for rotational positioning, perhaps.

This might save space, but not speed. You would have to OR masks to get the
values out, and by the time you make this a MACRO or function, your code is
going to get messy too. RAM is pretty cheap, I'll probably use floats, if
not doubles.

>
>Coords would be relational to the room. i.e. when I walk in the door I
>get a new set of coords.
>

I think that if you are going to go with the coord system, you might as well
just scrap the entire room concept completely. You could erect generic
(ie only a ptr to an oft used data struct) walls within your coord system
that would make better sense realistically. This system would allow a
field or forrest, which is hard to think of as rooms anyway, to be
modeled more efficiently.

>Exits are defined by specifying which 'wall' (and I use the term loosely:
>a 'wall' is really the room boundary). Outside exits could have a bit set
>which signifies that it covers the entire boundary. Exits would default to
>'center of the wall'. This makes building easy for rooms which fit the
>default criteria (defined walls, 'door-like' exits in the center of each
>wall), but flexible enough to encompass outdoor areas and oddly shaped
>rooms. You would be able to define an exit as being positioned to one
>side, or wider than the default, etc.

With a true coord system, you wouldn't need exits. You just type in a
direction you would like to go, and based on your dex, MOV, leg-lenght or
whatever else, you move x amount of distance in that given direction.
You would need some kind of automation on collision avoidance I would
think, especially in the 'Z' direction, if you chose to implement the world
3-d.

>Determining distance should be fairly easy using bit operations on the
>integer coordinate.

Yeah, but slow and messy. You can always use 8-bit chars as small
integers if you are worried about space.

>
>My feeling is that a system like this would make some compromises, but it
>would gain 1) ease of building areas and 2) some speed. It would lose some
>flexibility, perhaps, and the granularity increases with the size of the
>room, but typically you don't need a fine granularity with a larger room.

I think coords would work great in a space based MUD, where there is much
more empty space than objects. However, it would be harder to model
descriptions, in say a forest. Are you to specify each tree? That would
be stupid and redundant. So how are you to generate a description? One
method might be to have special, META type objects, which are only
descriptions with coordinates. You see the one closest to you. Some
code trickery might be needed to make determining the 'closest' easy..but I'm
sure it could be done...

As for other descriptions, like items or mobs in the rooms, I like the
idea of <tagged> descriptions, with visibility/detection ranges.

>-scott

[Nathan F. Yospe]

Brolli <wbor...@mail.bcpl.lib.md.us> wrote:

:Also, a balance needs to be struck between overly simplified models and

:overly complex code. Earlier in this thread someone claimed to have
:eliminated the random() call from combat by weighing in environmental
:conditions.

More precisely, I have local conditions modeled into everything.
Yes, it results in complex code... but that is not as bad as you
might think... most of the overhead in most muds comes from byte
interpretation (in LPs and TinyMUD) or bad search/update methods
(in Dikus). I will admit that modeling an environment is a large
burden on the CPU, relative to a few random() calls, but the CPU
can handle it, in most cases. As for overwhelming the players by
telling them every detail of the calculation... I don't. Players
get what is relevant. They may be notified whenever they sneeze,
but the only time they will get a notice of the sounds of things
in the nearby swamp is when they are able to pay attention.

:I'd _really_ like to see a model that accounts for _all_

:possible infuences on a combat strike (assuming that the system is based
:on RL physics), so that there is nothing left to chance. IMHO using
:environmental factors should alter the probabilities (maybe even to the
:point of a 99.99% sucess rate in 'perfect' conditions), but there should
:always be some chance of failure.

If the chance of failure is one time in ten thousand, doesn't it
really not matter? The conditions are sure to change before that
sort of odds catches up with you. (And no, I cannot imagine such
a set of environmental conditions and skills that the player has
a 100% success rate for anything.)

:Here's an extreme example: An Orc is tied up on a table and completely

:defenceless. The lighting is such that I have an excellent view of my
:victim, I am an expert in orc-killing, and I have mastered the use of my
:weapon. Even though I am currently in excellent health, there is a tiny
:chance that a small dust particle lodges in my nasal passageway as I'm
:about to strike, causing me to sneeze and miss the hapless orc.

Hmmm. OK...

:Now do I need to track every dust particle to see if they happen to fly up

:my nose? Of course not. I call random() to see if any out-of-the-ordinary
:things happen.

Wouldn't it be better to just see if he ever sneezes while those
dust particles are in the room with him, and schedule his sneeze
event at some point in the future? That way, he gets warned, and
chances are against that sort of wierd thing happening only when
he is about to do something critical. I don't like having things
happen only when there is a critical moment... I've always hated
that when playing paper & pencil, and never included it in games
I ran, and I'm not about to use a random to put it into Physmud.

:Unfortunately nearly every combat system I've read realies way too much on

:random() to predict those actions which are much better dictated by
:models. (DISCLAIMER: there are exceptions)

*grin*

[Nathan F. Yospe]

gre...@mordred.cs.uga.edu (Ben Greear) wrote:
:In article <5kspcj$c...@conch.msen.com>, Scott Anderson <ba...@msen.com> wrote:

:>For speed, use a single int for the coords. With a 32-bit int, you can use

:>10 bits for each coord for 1024 positions for x, y, and z. That leaves 2
:>bits that could be used for rotational positioning, perhaps.

:This might save space, but not speed. You would have to OR masks to get the
:values out, and by the time you make this a MACRO or function, your code is
:going to get messy too. RAM is pretty cheap, I'll probably use floats, if
:not doubles.

Depends on the scale, but I have found that either floats or longs do
the trick best. Floats are a bit slower, however, and you hardly ever
notice the granularity of a long. I actually what I call regions, and
while I allow rooms, I discourage them for anything but actual rooms.
A region is defined in terms of its dimensions, in cm (1 cm granular)
or m (1 m granularity - reserved for space combat) and objects can be
accessed by spacial location, as well as by direct listing. I tend to
think that a spacial system encourages exploration, if only because a
landmark requires you to pay attention, as opposed to knowing to type
north ten times, south five, etc.

:>Coords would be relational to the room. i.e. when I walk in the door I

:>get a new set of coords.

:I think that if you are going to go with the coord system, you might as well
:just scrap the entire room concept completely. You could erect generic
:(ie only a ptr to an oft used data struct) walls within your coord system
:that would make better sense realistically. This system would allow a
:field or forrest, which is hard to think of as rooms anyway, to be
:modeled more efficiently.

Using regions is critical to both my event and my threading system. I
find that, where appropriate, walls are useful... you have to have an
outer limit somewhere... but even rooms can be (and had better be, if
the builder hasn't got a real good reason) walled with something that
can be destroyed. The principal difference between a room and a zone,
or region, or field, is how they are described. You tend to see where
you are as static, without concern for direction, when enclosed. Were
I to ask you to describe your setting, and you were in a room, if you
follow the norms, you would describe the entire room. Standing in the
middle of an open space, you would describe what was in front of you,
then what lay to either side. This is what I do, and why I keep rooms
as part of the game.

:>Exits are defined by specifying which 'wall' (and I use the term loosely:

:>a 'wall' is really the room boundary). Outside exits could have a bit set
:>which signifies that it covers the entire boundary. Exits would default to
:>'center of the wall'. This makes building easy for rooms which fit the
:>default criteria (defined walls, 'door-like' exits in the center of each
:>wall), but flexible enough to encompass outdoor areas and oddly shaped
:>rooms. You would be able to define an exit as being positioned to one
:>side, or wider than the default, etc.

:With a true coord system, you wouldn't need exits. You just type in a

:direction you would like to go, and based on your dex, MOV, leg-lenght or
:whatever else, you move x amount of distance in that given direction.
:You would need some kind of automation on collision avoidance I would
:think, especially in the 'Z' direction, if you chose to implement the world
:3-d.

I find myself siding with Scott on this one. When you have coordinate
frames for each room, it is useful to have a device to hand an object
from one to the next, whatever the experience of the player. The exit
between my plain and my forest in the snippet I posted earlier wasn't
visable, but it was there. As for the collision avoidance (in the 'Z'
direction - cute. Never thought of describing gradiental deterence as
collision avoidance) that is an extremely good idea. I never put much
though into that... I do have the slope concept, but as each room has
its own coordinate system, your relative position is mainly a product
of the exit's translation algorithm. (My exits also play an important
role in my event system, and in resolving any thread concurency issue
before it happens.)

:>Determining distance should be fairly easy using bit operations on the
:>integer coordinate.

:Yeah, but slow and messy. You can always use 8-bit chars as small
:integers if you are worried about space.

Agreed here.

:>My feeling is that a system like this would make some compromises, but it

:>would gain 1) ease of building areas and 2) some speed. It would lose some
:>flexibility, perhaps, and the granularity increases with the size of the
:>room, but typically you don't need a fine granularity with a larger room.

:I think coords would work great in a space based MUD, where there is much
:more empty space than objects. However, it would be harder to model
:descriptions, in say a forest. Are you to specify each tree? That would
:be stupid and redundant. So how are you to generate a description? One
:method might be to have special, META type objects, which are only
:descriptions with coordinates. You see the one closest to you. Some
:code trickery might be needed to make determining the 'closest' easy..but I'm
:sure it could be done...

I have meta objects, as you put it, but I kind of want to scrap them.
As for describing each tree... describe a generic tree, create points
where the description can be randomly modified, and define a density,
then fill the tree filled region at that density with tree objects. I
would, of course, prefer an alternative, as this creates way too many
trees in a forest... right now, I'm testing the idea of creating some
trees around the player, but having the rest of the forest be sort of
a virtual forest, with trees coming into existance only when a player
approaches. There is one problem... if a player notches a tree, it is
going to have to become permanent. If a player remembers that the big
oak with the thick moss and wild roots was next to the notch, and the
new batch brings up a thin maple instead...

:As for other descriptions, like items or mobs in the rooms, I like the

:idea of <tagged> descriptions, with visibility/detection ranges.

As do I. See my scenarios in the tagging thread that followed the mud
protocol thing. I tag for every sense and sensitivity.

[Todd Lair]

AeternuS wrote:

>It is the goal of most programmers to get their game as real as
>possible... but, there is a point where it's too real. If the game was
>as real as life, why would we play it?

A second chance?

Todd

[Matt Chatterley]

<g>

I think the point to be taken here is that the degree of realism which you
put into a game is relative to the sort of game it is.

If it's a fantasy-fiction LPmud based around questing for experience and
power (in one way or another), you'll probably want an 'interpreted' view
of reality, where you can have magic, and other sorts of artistic license.

If it's a WoD game set in modern day Chicago, you'll want a pretty
realistic set of things, until you get into the 'WoD' elements, such as
Vampires.

If it's a simulation of New York IRL, you'll want it damned realistic. :)

At least, thats my take on things. But theres another issue, at least as
important (imho) as realism - internal consistancy.

If X works at A, it should also work at B, and if Z applies at A, it
should also apply at B, assuming B and A are the same (or very similar)
conditions. What ever sort of game it is, having it consistant with itself
(ie, real to it's own interpretation of reality) all through adds greatly
to the atmosphere created when you play it.

Regards,
-Matt Chatterley
http://user.itl.net/~neddy/index.html
"Fishing is complete and utter madness." -Spike Milligan

[Scott Anderson]

In article <5kt2se$fh0$1...@cronkite.cc.uga.edu>,

Ben Greear <gre...@mordred.cs.uga.edu> wrote:
>This might save space, but not speed. You would have to OR masks to get the
>values out, and by the time you make this a MACRO or function, your code is
>going to get messy too. RAM is pretty cheap, I'll probably use floats, if
>not doubles.

Floats would definitely slow it down. If you stay in integer arithmetic
you'll be much faster. I was thinking from an LPC perspective. My initial
gut feeling was that querying each coodinate from the object would take
three function calls, whereas putting them in a single int would drop that
to one. If you put the info in chars you have the same problem. If you put
the chars in a string then you have the overhead of extracting each
individual char from the string which would be slower than bit operations.
Same problem with storing the info in an array or mapping under LPC. You
have more options for optimization under a Diku-type server. I haven't put
much thought into this at all (basically maybe 1 minute :) so I could be
tragically wrong. :)

>I think that if you are going to go with the coord system, you might as well
>just scrap the entire room concept completely. You could erect generic
>(ie only a ptr to an oft used data struct) walls within your coord system
>that would make better sense realistically. This system would allow a
>field or forrest, which is hard to think of as rooms anyway, to be
>modeled more efficiently.

The point of using rooms is to pare down the number of comparisons you
have to make for calculating what you can and can't see. As I said, it's a
compromise. A room is not the usual definition of a mud room. Rather, it's
the smallest contiguous space that can be traversed without passing a
boundary that limits sight or movement. You can automatically limit your
set of objects for comparison. Otherwise, you'd have to start comparing
the player to every object in the mud. If you have an easy way of defining
hard and fast sight limits, then your set becomes much smaller.

>With a true coord system, you wouldn't need exits. You just type in a
>direction you would like to go, and based on your dex, MOV, leg-lenght or
>whatever else, you move x amount of distance in that given direction.
>You would need some kind of automation on collision avoidance I would
>think, especially in the 'Z' direction, if you chose to implement the world
>3-d.

No, for collision detection you most definitely need to define your exits.
Otherwise you'll have people walking through walls and the like.

>I think coords would work great in a space based MUD, where there is much
>more empty space than objects. However, it would be harder to model
>descriptions, in say a forest. Are you to specify each tree? That would
>be stupid and redundant. So how are you to generate a description? One
>method might be to have special, META type objects, which are only
>descriptions with coordinates. You see the one closest to you. Some
>code trickery might be needed to make determining the 'closest' easy..but I'm
>sure it could be done...

To the east you see several trees. North of you lies a cave entrance, etc.

You would need to specify location of each real or virtual object.

Regards,
-scott

[Nathan F. Yospe]

ba...@msen.com (Scott Anderson) wrote:
:Ben Greear <gre...@mordred.cs.uga.edu> wrote:

:The point of using rooms is to pare down the number of comparisons you

:have to make for calculating what you can and can't see. As I said, it's a
:compromise. A room is not the usual definition of a mud room. Rather, it's
:the smallest contiguous space that can be traversed without passing a
:boundary that limits sight or movement. You can automatically limit your
:set of objects for comparison. Otherwise, you'd have to start comparing
:the player to every object in the mud. If you have an easy way of defining
:hard and fast sight limits, then your set becomes much smaller.

Of course, sometimes sight limits do not corespond to motion limits.
The question is, which defines a room? I define rooms by the general
layout of the land: a field may be a room, the neighboring forest, a
glade within that forest (yes, this can be done - dimensions default
to the size of the glade from the outside, but can be set to a point
if desired. Likewise, mass of the glade is coherent with that of the
forest, unless specified), the house the room sits in, and so forth.
Why do I define fields (rooms) this way? This is the easiest way for
the builders, which was my primary concern.

:>With a true coord system, you wouldn't need exits. You just type in a

:>direction you would like to go, and based on your dex, MOV, leg-lenght or
:>whatever else, you move x amount of distance in that given direction.
:>You would need some kind of automation on collision avoidance I would
:>think, especially in the 'Z' direction, if you chose to implement the world
:>3-d.

:No, for collision detection you most definitely need to define your exits.
:Otherwise you'll have people walking through walls and the like.

Hmmm. Never though of it that way... I tend to use less rigorous set
vectors than would require that... slightly fuzzy logic when defined
as a path, which gives the impression that your character is more of
a person you are controlling than an automaton... steer for the door
when told to go forward, etc...

:>I think coords would work great in a space based MUD, where there is much

:>more empty space than objects. However, it would be harder to model
:>descriptions, in say a forest. Are you to specify each tree? That would
:>be stupid and redundant. So how are you to generate a description? One
:>method might be to have special, META type objects, which are only
:>descriptions with coordinates. You see the one closest to you. Some
:>code trickery might be needed to make determining the 'closest' easy..but I'm
:>sure it could be done...

:To the east you see several trees. North of you lies a cave entrance, etc.

:You would need to specify location of each real or virtual object.

I've posted this one before, but its the best test run I've had so far.
Locations are specified, but intersections are fuzzy.

{

> look
The flat green plain stretches away into a distant ridge of hills to
your right. Sixty meters to your left, a crop of trees springs up, thick
and forbidingly twisted. The strange, flat grass crunches under your
feet, releasing a pungent scent. Ahead, thirty meters off, a twisting
blue stream makes its slow, twisting way out of the small dark forest.
Sparse clouds drift by overhead.
Something streaks by overhead with a roar. A cluster bomb explodes ten
meters off ahead to your right! A piece of turf flies by, but misses
you.
> run
You start running toward the stream.
> run forest
You turn toward the forest, running as fast as you can. A roaring sound
reaches your ears. The forest is thirty meters away. Something roars by
overhead, leaving the impression of a silver streak in your eyes. A
whistling sound reaches your ears. An impulse makes you dodge left, and
a reddish object streaks by your right ear. The missile starts to climb,
but impacts into the forest. You keep running. The forest is ten meters
away. You dodge as branch as you reach the edge of the forest. You stop,
winded, to catch your breath. You are just within the edge of a small,
gnarled forest. Ahead and to each side, crooked black branches tangle
together, making it impossible to pass without considerable effort.
Mushrooms grow out of the mulch and rot at your feet, and there is a
damp smell to the air. The sun filters through the treetops, almost
entirely gone by the time it reaches you.
> look plain
You turn around and stare out through the edge of the forest. The plain
stretches out into the distance. Far ahead, the flat green plain
stretches away into a distant ridge of hills. Thirty meters ahead and to
the left, a twisting blue stream makes its slow, twisting way out of the
small dark forest. Far off to the right, a fence surrounds a complex of
buildings.

[Andy Davidoff]

D. B. Brown wrote in article <33706C...@bme1.image.uky.edu>...
:Well, take for example, a basketball player making a free throw.
:The player is in a specified place, always the same distance from
:the hoop. The hoop is always the same distance from the floor.

:The player always has no interferance, yet even professionals (getting
:payed millions to shoot the ball) miss as many as one in three.
:Is that random? I don't think so, but in what way are you going to
:model 'shoot basketball' in any way beyond using a random() call?

:> the player who spends the time to develope a shooter's stance and read
the
:> winds before taking aim should be rewarded with success.

an easy way out would be to make a comparison between the
player's skill and a random number. i think the point i (and others
)
are trying to make is that there should be enough events occuring
in the environment to provide an effectively random outcome of an
such an attempt. that's not to say that the things which are influencing
the player's game are random. they aren't. but taken together, they
form a background which could turn the tide of the lakers' game in
anyone's favour. this is just with the free-throw scenario, of course.
other skills may be more or less affected by difference elements of
the background environment.

:Should be rewarded with a better chance of success, IMO.

:There is a small percentage of nerve impulses that don't get fired or
:interpreted properly. This can effect the success of a high
:dexterity action. How is that going to be modeled?

it's not. i don't want to model anything unless i have a reason. why
bother modeling something that is going to be random anyway?

:IMO, life/mud combat/etc isn't totally random, but there are so many

:variables that affect the outcome that randomness is a reasonable,
:natural modeling scheme.

why not model the variables that affect the outcome? too lazy?

de...@pobox.com
nauga networks
sf & vision muds

[Brandon J. Rickman]

Andy Davidoff wrote:
>D. B. Brown wrote in article <33706C...@bme1.image.uky.edu>...

> :Should be rewarded with a better chance of success, IMO.
> :There is a small percentage of nerve impulses that don't get fired or
> :interpreted properly. This can effect the success of a high
> :dexterity action. How is that going to be modeled?
>
> it's not. i don't want to model anything unless i have a reason. why
> bother modeling something that is going to be random anyway?
>
> :IMO, life/mud combat/etc isn't totally random, but there are so many
> :variables that affect the outcome that randomness is a reasonable,
> :natural modeling scheme.
>
> why not model the variables that affect the outcome? too lazy?

Don't confuse probability with randomness. You dismiss the idea of
modeling
nerve impulses as merely producing random results, yet any legitimate
model of the nervous system would probably _appear_ random because the
visible effect is so far removed from the original catalyst. But the
mere
appearance of randomness doesn't preclude the possibility of some hidden
logic
in a system.

At the same time, I personally like to use random numbers (which may
only be a
part of what makes up randomness) to represent systems that are too
complicated/too fine
to model [in real time], but I spend a lot of time tweaking the
distribution of
those random numbers (Gaussian versus uniform distributions) so that
there are some interesting probabilistic outcomes.

Applying random numbers to rigid modeling causes problems because many
mud
designers are really trying to produce an indeterminate result for a
well
defined action. While the most immediately satisfying way to achieve
this
indeterminacy [in the world of the paper RPG] is by rolling a die, it is
actually
quite easy to create less random/more probabilistic results simply by
building
up a more complex system of random numbers.

But...

Nathan F. Yospe wrote:

> Brolli <wbor...@mail.bcpl.lib.md.us> wrote:
> :Here's an extreme example: An Orc is tied up on a table and completely
> :defenceless. The lighting is such that I have an excellent view of my
> :victim, I am an expert in orc-killing, and I have mastered the use of my
> :weapon. Even though I am currently in excellent health, there is a tiny
> :chance that a small dust particle lodges in my nasal passageway as I'm
> :about to strike, causing me to sneeze and miss the hapless orc.
>

> Wouldn't it be better to just see if he ever sneezes while those
> dust particles are in the room with him, and schedule his sneeze
> event at some point in the future? That way, he gets warned, and
> chances are against that sort of wierd thing happening only when
> he is about to do something critical. I don't like having things
> happen only when there is a critical moment... I've always hated
> that when playing paper & pencil, and never included it in games
> I ran, and I'm not about to use a random to put it into Physmud.

If, as in this hypothetical example, a completely vulnerable orc is
about to be
unceremoniously disposed of by a very unvaliant hero, then *I would make
the hero
sneeze and miss every damn time.* I would rather the hero be struck
down by a
fatal cold, or let the orc perform an impossible escape, or have the orc
survive the
mortal wound so he could seek revenge..., _anything_ but allow the
player to kill
the orc as if it was nothing more than tying one's shoes.

The very very small chance that the hero would sneeze at a critical
time, the
miniscule chance that the orc would survive, &c, can be modeled by as
many random
numbers as you like. But maybe we need to look at ways of manipulating
these numbers
within a context of why someone would bother to play such an ugly
"hero". If I'm
expecting to kill the orc every time, merely because I have a lot of
experience
killing small forest creatures, do I really deserve the experience
points or even the
gratification of cold blooded murder?

- Brandon Rickman

[D. B. Brown]

Andy Davidoff wrote:
> an easy way out would be to make a comparison between the
> player's skill and a random number. i think the point i (and others
> )

Yeah, that's what my mud does. Has myriad modifiers, but it all
comes down to a random() call compared to a skill.

> are trying to make is that there should be enough events occuring
> in the environment to provide an effectively random outcome of an
> such an attempt. that's not to say that the things which are influencing
> the player's game are random. they aren't. but taken together, they
> form a background which could turn the tide of the lakers' game in
> anyone's favour. this is just with the free-throw scenario, of course.
> other skills may be more or less affected by difference elements of
> the background environment.

Actually, that's the same point I was trying to make. Either you
misread, or I miswrote, or a combination of the two...

That's what I was saying - any normal event has enough variables
affecting the outcome that make the action effectively random.

As an old computer joke goes, "We just built this computer to
exactly predict tomorrow's weather - problem is, it takes two
days to run the calculations" We could model just about anything,
but after a certain point it becomes impossible to tell the
difference between an action based on fifty-nine different
variables and total randomness.

> it's not. i don't want to model anything unless i have a reason. why
> bother modeling something that is going to be random anyway?

Same here. random() models Murphy's Law as much as anything else.

> :IMO, life/mud combat/etc isn't totally random, but there are so many
> :variables that affect the outcome that randomness is a reasonable,
> :natural modeling scheme.
>
> why not model the variables that affect the outcome? too lazy?

No, I'm modeling a large number of variables... for example:

- Size difference between fighters
- Skill difference
- Attack speed vs. dodge speed
- Attack skill vs. shield skill
- Attack speed vs. shield re-ready (from previous attack) speed
- Strength difference
- Weapon's natural attack ability vs. weapon's natural parry ability
- Health of fighters
- Armor of fighters
- Perception of fighters

Just to name a few off the top of my head. Even after all of this,
I then add a pretty big random() call to the end of it to make up
for all the hundreds of variables that I can't or don't model.

Also, on a related sidenote, it's more interesting to play a game
with some element of chance, IMO.

[Brolli]

On Thu, 8 May 1997, Nathan F. Yospe wrote:

> Brolli <wbor...@mail.bcpl.lib.md.us> wrote:
>
> :Also, a balance needs to be struck between overly simplified models and
> :overly complex code. Earlier in this thread someone claimed to have
> :eliminated the random() call from combat by weighing in environmental
> :conditions.
>
> More precisely, I have local conditions modeled into everything.
> Yes, it results in complex code... but that is not as bad as you
> might think... most of the overhead in most muds comes from byte
> interpretation (in LPs and TinyMUD) or bad search/update methods
> (in Dikus).

I agree with you here. I am currently revamping Circle(3.0bpl11), and one
of my major goals is to completely remove the heartbeat() function (guilty
for about 95% of the bad update methods...which mainly rely on polling
every single object every few seconds to see if they need updating) and
replace it with a viable event system in which each object is responsible
for updating itself. By 'complex code' I was referring to the coder's
time/ability constraints in writing the code. As sole coder at my site,
its hard enough to keep some semblence of of life, without going overboard
on environmentals. Although if a lib is to complete, some do need to be
addressed.

> :I'd _really_ like to see a model that accounts for _all_
> :possible infuences on a combat strike (assuming that the system is based
> :on RL physics), so that there is nothing left to chance. IMHO using
> :environmental factors should alter the probabilities (maybe even to the
> :point of a 99.99% sucess rate in 'perfect' conditions), but there should
> :always be some chance of failure.
>
> If the chance of failure is one time in ten thousand, doesn't it
> really not matter? The conditions are sure to change before that
> sort of odds catches up with you.

Again I apologize for not being very clear. I must have been feverish
when I wrote that post. My point was that if not all EC's
(#define EC Environmental Condition) are tracked by models, there is still
some randomness left in the system. The level of randomness would vary
(of course) inversely with the completeness of your system. From your
previous posts, it seems that you intend on a nearly complete EC system,
but this IMHO isn't feasible to assume for most MUDs.

[my really bad example snipped]

> Wouldn't it be better to just see if he ever sneezes while those
> dust particles are in the room with him, and schedule his sneeze
> event at some point in the future? That way, he gets warned, and

Hehe imagine a first-time player getting the msg:
-->You feel a sneeze coming on.
I'd say most players used to generic EC systems would think an IMP is
broadcasting that, and the illusion of a living DM running the EC's
is a 'good thing' (tm). (sarcasm/) Does this imply that a player would
have an 'allergy' stat? (/end sarcasm)

> chances are against that sort of wierd thing happening only when
> he is about to do something critical. I don't like having things
> happen only when there is a critical moment... I've always hated
> that when playing paper & pencil, and never included it in games
> I ran, and I'm not about to use a random to put it into Physmud.

Again, agreed. The purpose of my post was not to say that EC's shouldn't
be a factor in determining combat strikes. There are many cases in a
viable EC system where the probabilities can be narrowed down to the point
where the random() call is moot, but unless your EC's are _very_ complete,
there will be unaccounted factors which may seem insignificant by
themselves but will add up to a tailor made random() call.

The issue IMHO is completeness. If you are willing to buckle down and do
EC's thouroughly, random() calls will be few and far between. Personally
I guess it boils down to personal preference at some point. I feel that
while some factors contribute 'enough' to be worth coding, there are many
thousands of minor factors that influence hit probabilities. These
adjustments when totaled warrent a random() call, but not (at least to me)
the volumes of code that would be needed to account for them, especially
if these factors are outside of player control and wouldn't add that much
to playability.

You'd have something like:
if (random(1,200) + get_EC() > 100) perform_hit();
as opposed to:
if (get_EC() > 0) perform_hit();

Now if (get_EC() > 100) or (get_EC < -100) in the first case, the random()
call is moot, but otherwise, you'll have to rely on 'luck' to determing if
the shot hits. In the second method, if your EC system is hidden from
players, then as far as they are concerned the get_EC() is random() +
get_EC(). Players are smart, and if your EC system is consistent, they
will start to figure it out, and that opens a whole new set of problems.

[Chris Lawrence (Contra)]

Brandon J. Rickman (as...@ucla.edu) wrote:

: Nathan F. Yospe wrote:
: > Brolli <wbor...@mail.bcpl.lib.md.us> wrote:

: > :Here's an extreme example: An Orc is tied up on a table and completely

: > :defenceless. The lighting is such that I have an excellent view of my
: > :victim, I am an expert in orc-killing, and I have mastered the use of my
: > :weapon. Even though I am currently in excellent health, there is a tiny
: > :chance that a small dust particle lodges in my nasal passageway as I'm
: > :about to strike, causing me to sneeze and miss the hapless orc.

: >
: > Wouldn't it be better to just see if he ever sneezes while those

: > dust particles are in the room with him, and schedule his sneeze
: > event at some point in the future? That way, he gets warned, and

: > chances are against that sort of wierd thing happening only when

: > he is about to do something critical. I don't like having things
: > happen only when there is a critical moment... I've always hated
: > that when playing paper & pencil, and never included it in games
: > I ran, and I'm not about to use a random to put it into Physmud.

: If, as in this hypothetical example, a completely vulnerable orc is

: about to be unceremoniously disposed of by a very unvaliant hero,
: then *I would make the hero sneeze and miss every damn time.* I would
: rather the hero be struck down by a fatal cold, or let the orc perform
: an impossible escape, or have the orc survive the mortal wound so he
: could seek revenge..., _anything_ but allow the player to kill
: the orc as if it was nothing more than tying one's shoes.

Perhaps the player is RP'ing a really nasty piece of work? Perhaps the
player *needs* to slay the orc thus to collect his blood to feed his
starving and near-death vampire children? Perhaps the player wishes to
kill the orc in this manner for massacring his village and defiling his
family?

: The very very small chance that the hero would sneeze at a critical

: time, the miniscule chance that the orc would survive, &c, can be
: modeled by as many random numbers as you like. But maybe we need to
: look at ways of manipulating these numbers within a context of why
: someone would bother to play such an ugly "hero". If I'm expecting
: to kill the orc every time, merely because I have a lot of experience
: killing small forest creatures, do I really deserve the experience
: points or even the gratification of cold blooded murder?

<<You are really willing to play on a MUD which still has experience
points? What ever for?>>

Perhaps ths orc is a sacrifice to the Gods which will prevent a 20
year drought from killing their entire population? Or will stave off
a marauding dragon? There are a *lot* of possible scenarios for just
this sort of position.

[Brandon J. Rickman]

In article <5l83jg$667$1...@hpax.cup.hp.com>, claw...@cup.hp.com (Chris

Lawrence (Contra)) wrote:
> Brandon J. Rickman (as...@ucla.edu) wrote:
> : could seek revenge..., _anything_ but allow the player to kill
> : the orc as if it was nothing more than tying one's shoes.
>
> Perhaps the player is RP'ing a really nasty piece of work? Perhaps the
> player *needs* to slay the orc thus to collect his blood to feed his
> starving and near-death vampire children? Perhaps the player wishes to
> kill the orc in this manner for massacring his village and defiling his
> family?

So now you are trying to give some kind of _reason_ for killing the orc.
:) That's different. Okay, so I need to feed my starving vampire
children. Wouldn't it be curious if I didn't quite kill the hapless orc,
and he became a vampire too? He might be really pissed at me and come
hunt me down. The point is, if it is really _just that easy_ to kill an
orc and feed the family, why is it in the game?

I'm really just blowing up an absurd example. Lots of people build mud
areas of dungeons with miserable skeletons chained to the walls that
attack you but can't chase you. The noble Paladin feels obligated to
dispatch these lost souls. The _clever_ Paladin knows that those
skeletons used to be alive and that someone must have locked them up to
die. So the clever Paladin would find the evil king, kick his ass, and
the skeletons would be vindicated.

"Oh man, this nasty wizard keeps sending these zombies after me and they
are really tough. What am I supposed to do?"

Go after the wizard.

> : someone would bother to play such an ugly "hero". If I'm expecting
> : to kill the orc every time, merely because I have a lot of experience
> : killing small forest creatures, do I really deserve the experience
> : points or even the gratification of cold blooded murder?
>
> <<You are really willing to play on a MUD which still has experience
> points? What ever for?>>

Only when I'm really, really bored.

> Perhaps ths orc is a sacrifice to the Gods which will prevent a 20
> year drought from killing their entire population? Or will stave off
> a marauding dragon? There are a *lot* of possible scenarios for just
> this sort of position.

Well if it were _that easy_ to sacrifice an orc to the Gods...

--start--
- Prison cell -
There is an orc chained to a table here.
The orc is screaming.

> read scroll

% Shoehorn's Magick Ritual for Defeating Drought
% - Fill a crystal vial will blood from a live orc.
% - Bandage the orc's wound with dried moss and leaves soaked in wine
% - When the orc heals, bury the vial in a field of wildflowers.
% - Kill the orc before the next full moon.

The orc is screaming.

> wound orc

You attack the orc...
You smash the orc with your warhammer.
The orc has lost conciousness.
The orc is bleeding.

> fill vial with blood from orc

You get a small sample of orc's blood.

The orc is bleeding.
The orc has died. You gain 27 experience points.
--fin--

Oh well. Perhaps the warhammer wasn't such a good idea.

Anyway, the point is to make a mud experience that both 1) simulates an
interesting environment and 2) creates connections between seemingly
random (but actually probabilistic) events. Skill based systems are
actually part of 2).

- BR

[Steven R. Johnson]

In alt.mud.programming Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
<SNIP>
: <<You are really willing to play on a MUD which still has experience
: points? What ever for?>>
<SNIP>

And what is wrong with this? Most MUDS do use experience points.

-Steve

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ste...@mistic.net http://www.mistic.net/stevej
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Jon A. Lambert]

Ben Greear <gre...@pollux.cs.uga.edu> wrote in article <5lb3rm$6t4$1...@cronkite.cc.uga.edu>...
> In article <Pine.LNX.3.91.97051...@uni-corn.demon.co.uk>,
> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:

> >On 13 May 1997, Steven R. Johnson wrote:
> >
> >> And what is wrong with this? Most MUDS do use experience points.
> >

> >Its unrealistic and totally abstract. Moreover, the fact that 'most muds'
> >(of the lower case variety, sir) use it, does not make its use good, or
> >right, or justifiable.
>
> I would never argue that it would make it good, I would argue because it
> is simple to understand (and less importantly to code :))...
>
> >
> >Experience points are outdated. About as outdated as a lot of the stock
> >code flying around, IMHO.
>
> How do you measure advancement? I suppose you could do it by skill/spells
> only??? It is very abstract..but I have a hard time finding an alternative
> that works as well as a good ole long int!
> >
>
The use of the term "experience points" is in very bad taste in these
newsgroups, Ben. It is a politically incorrect term which is a relic of the
stock age of muds.
Perhaps members of the enlightened "mud community" can provide
you with alternatives that aren't as offensive. ;-)

JL

[Nathan F. Yospe]

gre...@pollux.cs.uga.edu (Ben Greear) wrote:

:In article <Pine.LNX.3.91.97051...@uni-corn.demon.co.uk>,

:Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
:>On 13 May 1997, Steven R. Johnson wrote:

:>> And what is wrong with this? Most MUDS do use experience points.

:>Its unrealistic and totally abstract. Moreover, the fact that 'most muds'
:>(of the lower case variety, sir) use it, does not make its use good, or
:>right, or justifiable.

:I would never argue that it would make it good, I would argue because it
:is simple to understand (and less importantly to code :))...

There are many other simple to code concepts - skill based improvement,
attribute improvement, and other by use systems are in many ways
simpler than xp.

:>Experience points are outdated. About as outdated as a lot of the stock
:>code flying around, IMHO.

:How do you measure advancement? I suppose you could do it by skill/spells
:only??? It is very abstract..but I have a hard time finding an alternative
:that works as well as a good ole long int!

How about _not_ measuring specific advancement? Improve skills, spells...
but center sucess around actual accomplishments within the context of
the game. Greg, Chris, myself, and a large number of other people out
there are writing muds with new codebases, around new concepts, and not
a one of us that I know of has traditional xps and levels.

[Ben Greear]

In article <yospe-14059...@usrns44.dialup.hawaii.edu>,

Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
>gre...@pollux.cs.uga.edu (Ben Greear) wrote:
>
>:In article <Pine.LNX.3.91.97051...@uni-corn.demon.co.uk>,
>:Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
>
>:I would never argue that it would make it good, I would argue because it
>:is simple to understand (and less importantly to code :))...
>

>:How do you measure advancement? I suppose you could do it by skill/spells
>:only??? It is very abstract..but I have a hard time finding an alternative
>:that works as well as a good ole long int!
>
>How about _not_ measuring specific advancement? Improve skills, spells...
>but center sucess around actual accomplishments within the context of
>the game. Greg, Chris, myself, and a large number of other people out
>there are writing muds with new codebases, around new concepts, and not
>a one of us that I know of has traditional xps and levels.

Ok, so how do you decide when a skill is advanced? I thought a long time
about this... Here is my best idea so far: for a certain amount of time,
if a spell was used, increase your adeptness at it, if it wasn't decrease it
by some value. This models reality pretty well, except that if you did this,
you would have ppl spam the mud with frivolous spell casting and skill using,
probably with a client. Another problem with this IMHO, is that you have a
hard time deciding when it's time to learn a new spell or skill. I model
my spell/skill system on a heirarchical system, where you must advance
so far in the prerequisite spells/skills before you can learn the next...

This system would work ok for spells/skills..but what about HP, MOV, and
MANA? I imagine you have different names for these, as these are also out
of vogue, but how do you decide when to increment/decrement them?

>--
>Nathan F. Yospe | There is nothing wrong with being a sociopath. Its

Ben

[Jon A. Lambert]

Phoenix <r.davies@*remove_this*virgin.net> wrote in article <5ldsc4$r...@news3-gui.server.cableol.net>...
>
> Far be it from me to show the temerity to cast a humble idea before the great gods of muddom, but... :)
>
> In the roleplaying game 'Call of Cthulhu', you roll against your skill level at the end of each
> adventure to see if you progressed - eg if you had skill 'Stealth' at a percentage competency of 90,
> you would have to roll IN EXCESS of 90 on percentile dice to advance. Thus it is much easier to advance
> low skills.
>
> You could apply this to muds at the end of quests, or play sessions (with a clock minimum of say an
> hour to prevent ppl logging in and out to gain extra 'rolls'), or just based on the game clock, every
> hour of played time, or something. Interval to vary accoridng to the needs/setup of the game.
>
> In any case, it's just one alternative.

This sounds suspiciously close to the ROM 2.4 implementation which is a
stock codebase. That would invalidate your otherwise worthy alternative
from consideration.

Thank you for playing though! ;-)

JL

[Ben Greear]

In article <5ldsc4$r...@news3-gui.server.cableol.net>,
Phoenix <r.davies@*remove_this*virgin.net> wrote:

>Ben Greear wrote:
>
>> Ok, so how do you decide when a skill is advanced? I thought a long time
>> about this... Here is my best idea so far: for a certain amount of time,
>> if a spell was used, increase your adeptness at it, if it wasn't decrease it
>> by some value. This models reality pretty well, except that if you did this,
>> you would have ppl spam the mud with frivolous spell casting and skill using,
>> probably with a client. Another problem with this IMHO, is that you have a
>> hard time deciding when it's time to learn a new spell or skill. I model
>> my spell/skill system on a heirarchical system, where you must advance
>> so far in the prerequisite spells/skills before you can learn the next...
>
>

>In the roleplaying game 'Call of Cthulhu', you roll against your skill level at the end of each
>adventure to see if you progressed - eg if you had skill 'Stealth' at a percentage competency of 90,
>you would have to roll IN EXCESS of 90 on percentile dice to advance. Thus it is much easier to advance
>low skills.
>

>You could apply this to muds at the end of quests, or play sessions (with
>a clock minimum of say an hour to prevent ppl logging in and out to gain
>extra 'rolls'), or just based on the game clock, every hour of played
>time, or something. Interval to vary accoridng to the needs/setup of the
>game.

Thats an idea, but unless you have everything as a quest, then whats to
stop ppl from just sitting around for x amount of time, then getting their
stats rolled?

Having enough unique quests is all but impossible, unless you cheezify
them by finding some way to automatically generate them...

If you could find a way around these hurdles, then this might be a decent
idea, but I don't see any easy way around them...

>
>In any case, it's just one alternative.
>

>Phoenix

Basically, for advancement in general, I think you should only be able to
advance for a certain amount of risk. If a world were so dangerous that just
living an hour, no matter how you did it, was an accomplishment..then this
system might work ok... However, I'm not sure this is a good idea, as
newbies would be sure to be turned off :)

I like XP as a measure, because the most (and sometimes only) threat on a MUD
is in battle. You should thus reward ppl who tested and overcame this
threat, and punish those who failed (for why else could it be a threat?).
XP allows all this....

I have another idea I'm going to post in a seperate thread...

[Broly]

> >>Ben Greear <gre...@mordred.cs.uga.edu> wrote:
> >>This might save space, but not speed. You would have to OR masks to get the
> >>values out, and by the time you make this a MACRO or function, your code is
> >>going to get messy too. RAM is pretty cheap, I'll probably use floats, if
> >>not doubles.

> > ba...@msen.com (Scott Anderson) writes:
> >Floats would definitely slow it down. If you stay in integer arithmetic
> >you'll be much faster.

> ^^^^
> On 12 May 1997 mor...@niuhep.physics.niu.edu wrote:
> That depends on your cpu.
> Robert
Actually, fixed point arithmitic gives you the best of both worlds. It
gives you better precision than ints, the RAM use of long ints, and the
speed (nearly) of integers. For the benefit of those who aren't familiar
with fixed points, what you do is create an 'imaginary' decimal place in a
long int, then perform arithmetic in bitwise operations. You don't get
quite the precision of floats, but they cut cpu usage (even with a math
coprocessor) dramatically in math-intensive algorithms.

[Broly]

On Tue, 13 May 1997, Brandon J. Rickman wrote:

> In article <5l83jg$667$1...@hpax.cup.hp.com>, claw...@cup.hp.com (Chris
> Lawrence (Contra)) wrote:
> > Brandon J. Rickman (as...@ucla.edu) wrote:
> > : could seek revenge..., _anything_ but allow the player to kill
> > : the orc as if it was nothing more than tying one's shoes.
> >

> I'm really just blowing up an absurd example. Lots of people build mud
> areas of dungeons with miserable skeletons chained to the walls that
> attack you but can't chase you.

Okay...as the author of the much-flamed orc-chained-to-table example I
would like to point out a few things:
1.) Yes it was a bad example. It was meant to be. The whole point was
that even in the most absurd situation there is still _something_ left
to chance. (no I would not add this, but I have seen it done...I think
there's an orc stuck in spider webs in Arachnos somewhere--proving again
that stock zones should be fixxed/burned)
2.) As far as experience points go, they are useful, but IMHO should be
hidden, along with much of the MUD internals, from the players. If you're
writing a skill-based MUD, why not just assign exp points to each skill?
The whole idea behind playing on the computer vs paper-N-pencil is that
you don't need to see dice rolls, exp points, and other mechanics. An
analogy would be your car. As a driver (mud-player) you don't need to
know that the gasoline mixxes with air before igniting, you just need to
know that you have to add gas (go adventure), and hope that your
carborator isn't shot (ack a bug?!?...). As IMP, we play the role of
mechanic (fix bugs, add nifty features once game is up), salesman ('come
play my MUD!!'), manufacturer (writing code bases/libs/worlds), and even
highway patrolmen (ick, I am _not_ looking forward to policing a MUD, but
even MUDs with limited rules will have rule-breakers).

[Greg Munt]

On 15 May 1997, Ben Greear wrote:

> I like XP as a measure, because the most (and sometimes only) threat on a MUD
> is in battle. You should thus reward ppl who tested and overcame this
> threat, and punish those who failed (for why else could it be a threat?).
> XP allows all this....

Combat should not be the only threat! Thats as abstract and unrealistic
as using experience points!

Also, I think you'll find that the usual reaction to death is 'oops, I
died, what a bummer'. Losing a few XP is hardly a great punishment for
death - you dont exactly *fear* dying, do you?

------------------------------------------------------------------------------
T H E F R O N T I E R S P R O J E C T
http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
Never settle with words what you can accomplish with a flame-thrower.

[K.L.Lo-94]

Ben Greear (gre...@pollux.cs.uga.edu) scribbled:
: I like XP as a measure, because the most (and sometimes only) threat on a

: MUD
: is in battle. You should thus reward ppl who tested and overcame this
: threat, and punish those who failed (for why else could it be a threat?).
: XP allows all this....

Surely to kill someone is a measure of achievement. How about the equipment
gained? On most muds, the stuff obtained from the body can be sold for
cash. Or, (gag) there's cash on the rabbit you just killed.

I remember in the first editions of Tunnels and Trolls (rilly old paper rpg)
gave out exp for *finding* treasure! That's like winning the lottery and
learning something from it.

My reward for people who overcome or avoid threats (no honour lost in running
away) is living. Maybe a bit of skill advancement if I was feeling
generous.

PS: Did I mention the high mortality rate? :)

--
Ling Lo
"Not a SHOPPING EXPEDITION!" - Halo Jones

[Ben Greear]

In article <5le7ui$c...@sun-cc204.lboro.ac.uk>,

K.L.Lo-94 <K.L....@student.lboro.ac.uk> wrote:
>Ben Greear (gre...@pollux.cs.uga.edu) scribbled:
>: I like XP as a measure, because the most (and sometimes only) threat on a
>: MUD
>: is in battle. You should thus reward ppl who tested and overcame this
>: threat, and punish those who failed (for why else could it be a threat?).
>: XP allows all this....
>
>Surely to kill someone is a measure of achievement. How about the equipment

I agree completely. That is why I chose to give them experience points
for it, because that is the best way I've found to measure one person's
achievement against another's.

>gained? On most muds, the stuff obtained from the body can be sold for
>cash. Or, (gag) there's cash on the rabbit you just killed.

Yep, but, as far as I can tell, the only reason one needs money is to buy
stuff that better allows one to kill (and thus get XP.)

>My reward for people who overcome or avoid threats (no honour lost in running
>away) is living. Maybe a bit of skill advancement if I was feeling
>generous.

This is fine, but how is the server to compare player x to player y? Should
we rank them by how many times they've died? Then newbies will be strongest
of all..

>PS: Did I mention the high mortality rate? :)

I got no problem with that :)

>Ling Lo

[Ben Greear]

In article <Pine.LNX.3.91.97051...@uni-corn.demon.co.uk>,
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:

>On 15 May 1997, Ben Greear wrote:
>

>> I like XP as a measure, because the most (and sometimes only) threat on a MUD
>> is in battle. You should thus reward ppl who tested and overcame this
>> threat, and punish those who failed (for why else could it be a threat?).
>> XP allows all this....
>

>Combat should not be the only threat! Thats as abstract and unrealistic
>as using experience points!

Exactly, see my other thread on MUD threats...
However, just because that is true in no way detracts from using XP.

>
>Also, I think you'll find that the usual reaction to death is 'oops, I
>died, what a bummer'. Losing a few XP is hardly a great punishment for
>death - you dont exactly *fear* dying, do you?

If you don't have XP, then you can't even take that away from them... Taking
permanent stats away might be an answer..but I'm not sure players would
really like it. You would have to provide much more of an incentive for
risky battle... What would you have me give for this incentive?

[Ben Greear]

In article <Pine.SOL.3.95.970515...@mail.bcpl.lib.md.us>,

Broly <br...@mail.bcpl.lib.md.us> wrote:
>
>2.) As far as experience points go, they are useful, but IMHO should be
>hidden, along with much of the MUD internals, from the players. If you're
>writing a skill-based MUD, why not just assign exp points to each skill?
>The whole idea behind playing on the computer vs paper-N-pencil is that
>you don't need to see dice rolls, exp points, and other mechanics. An
>analogy would be your car. As a driver (mud-player) you don't need to
>know that the gasoline mixxes with air before igniting, you just need to
>know that you have to add gas (go adventure), and hope that your
>carborator isn't shot (ack a bug?!?...). As IMP, we play the role of
>mechanic (fix bugs, add nifty features once game is up), salesman ('come
>play my MUD!!'), manufacturer (writing code bases/libs/worlds), and even
>highway patrolmen (ick, I am _not_ looking forward to policing a MUD, but
>even MUDs with limited rules will have rule-breakers).

Ohhh, but isn't it nice to be able to check how much gas you actually have??
Experience points for each spell is an idea, but then spells become just an
analogy for levels IMHO. Also, it would be easy enough to leave XP in
the game, just as they are in most muds, and just edit the display
functions so that a player can't check their XP with score. I don't
think this is particularly useful.. All the underlying assumptions of
the MUD are still there, but the player just can't see them.

[Andreas Bogk]

>>>>> "Broly" == Broly <br...@mail.bcpl.lib.md.us> writes:

Broly> Actually, fixed point arithmitic gives you the best of both
Broly> worlds. It gives you better precision than ints, the RAM
Broly> use of long ints, and the speed (nearly) of integers. For

Note that on most modern processors (read: anything except Intel)
floating-point is nearly as fast as integer arithmetics, meaning that
fixed point could even be slower than floating-point.

Andreas

--
Das Recht auf Kryptographie ist ein Menschenrecht. -- kr...@koehntopp.de

[Jon A. Lambert]

Greg Munt <gr...@uni-corn.demon.co.uk> wrote in article <Pine.LNX.3.91.97051...@uni-corn.demon.co.uk>...

> On 15 May 1997, Ben Greear wrote:
>
> > I like XP as a measure, because the most (and sometimes only) threat on a MUD
> > is in battle. You should thus reward ppl who tested and overcame this
> > threat, and punish those who failed (for why else could it be a threat?).
> > XP allows all this....
>
> Combat should not be the only threat! Thats as abstract and unrealistic
> as using experience points!
>

Show me any system for character advancement and I'll show you're really
using XPs.

A bold claim. :-)
Here's hoping I won't *gag* on it.

JL

[Nathan F. Yospe]

gre...@pollux.cs.uga.edu (Ben Greear) wrote:

:Ok, so how do you decide when a skill is advanced? I thought a long time
:about this... Here is my best idea so far: for a certain amount of time,
:if a spell was used, increase your adeptness at it, if it wasn't decrease it
:by some value. This models reality pretty well, except that if you did this,
:you would have ppl spam the mud with frivolous spell casting and skill using,
:probably with a client. Another problem with this IMHO, is that you have a
:hard time deciding when it's time to learn a new spell or skill. I model
:my spell/skill system on a heirarchical system, where you must advance
:so far in the prerequisite spells/skills before you can learn the next...

One thing that helps is making related skills significant... juggling
helps to keep a pickpocket in shape, to some degree... another thing
is having the learning of a new skill implicit, rather than explicit.
Anyone can attempt to do anything they have seen, but sometimes there
is an impossible threshold that must be passed over, and can only be
surmounted with help from a teacher. Not having a clue about the way
a vaulter moves makes any attempt to vault without training pure folly.
As for frivolous use... not really. You exercize a certain amount in
a day. You practice when you want to get better, but not beyond the
point of physical exhaustion. You will naturally maintain skill in
the things you use on a daily basis, of course, and skills you have
mastered in the past are relearned more easilly. Now, as for the set
of technical conditions I used to generate this... its a bastardized
descendent of neural net algorithms. I have three levels, and two
templates, and I use weighted responses to a set of skills and a set
of skill involved attributes. Increasing or decreasing linked skills
or attributes causes sympathetic responses in the dependancies. I
actually do the manipulation on a set of long ints, one per skill/
attribute, with the actual skills and attributes being static and
global, and with local dependancies for linkage. (IE, no wings, no
flight with the winged flight skill.) Actual evaluation of a skill
is upon calling, and has a modification check at that time. The
attributes are modified immediately when a skill with sympathetic
keying is modified. Does this mean a large table? Yes... the table
for attributes contains 135 entries, at the moment, and even a few
rekeyed attributes (strength is keyed at each point in the body
that is relevant, for example, as is dexterity and sensitivity.)
This means that a character can end up being quite a large construct.
This is why I am now working on effective swapping techniques.

:This system would work ok for spells/skills..but what about HP, MOV, and

:MANA? I imagine you have different names for these, as these are also out

:of vogue, but how do you decide when to increment/decrement them?

Never liked the idea of discreet values here. I track the condition
of every physical object, be it part of a character or part of an
object of indeterminate function. If badly enough damaged, in any
way... for example, charred meat does not function well as an arm...
though it might well serve as food... that part of a character is
effectively destroyed, though it might remain atatched. Shock can
kill, as can blood loss, or damage to a critical body part. Fatigue
is possible, though cybernetics can alleviate some of it. I don't
have magic, so mana is a useless concept, but even in the magical
universe I have been playing with, it is an environmental object,
as opposed to a component of the character. The point is, we are
not just renaming things, as you seem to think. We are changing the
fundamental assumptions, because we feel they were flawed from the
start, and are no longer even justifiable in terms of resources.

--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its

[Katrina McClelan]

In <5lfh81$hs5$1...@cronkite.cc.uga.edu> gre...@sandstone.cs.uga.edu (Ben Greear) writes:

>If you don't have XP, then you can't even take that away from them...

Sure ya can. Just wrap into the negatives. Diku muds bottom out at 0,
but that doesn't mean you have to keep that, or in Ben or I's case write
ours that way. I have negative exp in mine already.

>Taking
>permanent stats away might be an answer..but I'm not sure players would
>really like it.

This would be rather harsh, unless there was some way to get the stat
back.

>You would have to provide much more of an incentive for
>risky battle... What would you have me give for this incentive?

Well, one thing on this, incentive is a relative term. In a mud that is
unbalanced, as most dikus are, you can slaughter 99% of the mobs without
risk. In a mud where combat is generally risky, and where players are not
the caps of power this is not as much of a problem. Combart on my mud has
heavy influence of mob special abilities. Some mobs such as a beholder or
a dragon have more power than a player will ever see. Fortunately they
tend to be solitary and don't generally group so you can outnumber one.
Conversely mobs such as orcs and ogres are weak individually, but groups
of them (yes, my mobs group, and fight as groups), including perhaps an
ogre magi and ogre shaman can be quite dangerous. In such a system there
are not alot of unrisky ways to get reward, so the reward period is
incentive enough.

-Katrina

[D. B. Brown]

Ben Greear wrote:
> Ok, so how do you decide when a skill is advanced? I thought a long time
> about this... Here is my best idea so far: for a certain amount of time,
> if a spell was used, increase your adeptness at it, if it wasn't decrease it
> by some value. This models reality pretty well, except that if you did this,
> you would have ppl spam the mud with frivolous spell casting and skill using,
> probably with a client. Another problem with this IMHO, is that you have a
> hard time deciding when it's time to learn a new spell or skill. I model
> my spell/skill system on a heirarchical system, where you must advance
> so far in the prerequisite spells/skills before you can learn the next...

My current theory on this (and the skill system for the lib I'm writing)
involves a skill atrophy system which works somewhat similarly to
what you're describing; main difference is that while your idea is
based off of time, mine uses skill experience accumulated.

I.e, the advancement/atrophy does not happen until the player gains
'X' total skill experience points (SXP). At that point, skills are
modified in relation to what percentage of the last batch of SXP each
skill made up. This would work the same regardless of whether the
player spent 15 minutes or 15 hours gaining the SXP -- the gain/loss
is based on what portion of total skills used, not over time. While
this does take a hit in realism, I don't like the idea of making players
hop around constantly to keep things up, but that's my own mudlib
theory.

> This system would work ok for spells/skills..but what about HP, MOV, and
> MANA? I imagine you have different names for these, as these are also out
> of vogue, but how do you decide when to increment/decrement them?

Hit Points/Structure (still need a new name for 'Structure'), Endurance
and
Spirit :).

So far, I'm using the ancient concept of 'level' to handle that. Yes,
it's trite, but it works.

[D. B. Brown]

Ben Greear wrote:
> If you don't have XP, then you can't even take that away from them... Taking

> permanent stats away might be an answer..but I'm not sure players would

> really like it. You would have to provide much more of an incentive for

> risky battle... What would you have me give for this incentive?

Not that I'm the person you're replying to, but anyway...

Right now I'm looking at death causing loss of 20-50% of total
experience points gained, depending on what the player was killed
by and in what favor he/she is with his/her church (I'm making
players become associated with a church to secure the ability to
be raised from the dead).

Anyway, I want death to be a frightening prospect, without
permanently harming the character -- i.e., if the character dies,
there should always be some way to regain what was lost.

On the other hand, I'm currently using a 100 point stat system (max
human stat is generally 100, etc), and the loss of a few random
stat points may well be part of the deal.

[D. B. Brown]

Jon A. Lambert wrote:
> Show me any system for character advancement and I'll show you're really
> using XPs.
>
> A bold claim. :-)

> Here's hoping I won't *gag* on it.

Someone on the list suggested using the Chaosium system for skill
advancement - if after playing a skill is used, that skill has a
chance of going up. That doesn't use XPs, but it is IMO a large
step below XPs for serious character advancement.

[Greg Munt]

On 15 May 1997, Ben Greear wrote:

> >Also, I think you'll find that the usual reaction to death is 'oops, I
> >died, what a bummer'. Losing a few XP is hardly a great punishment for
> >death - you dont exactly *fear* dying, do you?
>

> If you don't have XP, then you can't even take that away from them... Taking
> permanent stats away might be an answer..but I'm not sure players would
> really like it.

I guess you have to choose between realism and appealing to mass demand.
I know which one appeals to me more. It's not the latter.

> You would have to provide much more of an incentive for
> risky battle... What would you have me give for this incentive?

Erm, why do you need an incentive for battle?

[Broly]

On 15 May 1997, Ben Greear wrote:

> In article <Pine.SOL.3.95.970515...@mail.bcpl.lib.md.us>,
> Broly <br...@mail.bcpl.lib.md.us> wrote:
> >
> >2.) As far as experience points go, they are useful, but IMHO should be
> >hidden, along with much of the MUD internals, from the players. If you're
> >writing a skill-based MUD, why not just assign exp points to each skill?
> >The whole idea behind playing on the computer vs paper-N-pencil is that
> >you don't need to see dice rolls, exp points, and other mechanics. An
> >analogy would be your car. As a driver (mud-player) you don't need to
> >know that the gasoline mixxes with air before igniting, you just need to
> >know that you have to add gas (go adventure), and hope that your
> >carborator isn't shot (ack a bug?!?...). As IMP, we play the role of
> >mechanic (fix bugs, add nifty features once game is up), salesman ('come
> >play my MUD!!'), manufacturer (writing code bases/libs/worlds), and even
> >highway patrolmen (ick, I am _not_ looking forward to policing a MUD, but
> >even MUDs with limited rules will have rule-breakers).
>
>
> Ohhh, but isn't it nice to be able to check how much gas you actually have??

Actually, XP would be the odometer[sp?] in this analogy. It would measure
just how far the player has come. As a driver, I drive (go adventure)
when there is something to do (rid the village of pirate raiders, etc).
Yes its nice to compare cars with friends (I've put 22k miles on my car
last year...how about you?), but this is where the analogy breaks down. A
car gets old and needs replaced after so many miles, but as a player gains
XP, the change is a gradual increase in strength. I am thinking of hiding
_most_ statistical information from players, except things they can keep
track of themselves (I'll have a breakdown of mobs killed, quests fiished
etc for a 'score' command, rather than you are level 10 have 123542 XP)
Players will realize that they grow in strength ('wow, my backstab
_REALLY_ f***ed up that troll') and NPC's will treat more powerful players
differently ('heh, you see that cityguard get out of my way back there?')
One of the major flaws of DIKU code bases (to me, this as a flaw, some
people like this) is that they tend to be number-crunchers. Players
shouldn't sit around discussing their hitrolls while Midgaard's mayor is
being slaughtered in Market Square. But I'll rant more about the lack of
roleplay MUDs in a different post.

> Experience points for each spell is an idea, but then spells become just an
> analogy for levels IMHO. Also, it would be easy enough to leave XP in

As it is intended to be. I _like_ XP and levels, if they are handled
correctly. A level 32 fireball _should_ be more powerful than a level 12
one, but don't bore your players by telling them that they increased a
level in their fireball skill, they'll find out by seeing the charred
remains of their foes in the next battle. I do, however, end up with the
problems of explaining just how to explain that mobs 'know' a players
power level (guildmasters only except people between certain levels as
pupils) and how to have players rate themselves within the 'community' of
other players. I guess I could just let each player establish himself via
roleplay, but (and I guess this is the DIKU in me) I think there needs to
be some concrete player scale. Dunno still gotta do some thinking in this
department.

> the game, just as they are in most muds, and just edit the display
> functions so that a player can't check their XP with score. I don't

Exactly. You're being sarcastic, but I'll agree with you anyways.

> think this is particularly useful.. All the underlying assumptions of
> the MUD are still there, but the player just can't see them.

Actually, one assumption I haven't made: Players want to know every
little detail about their players. I use as a rule of thumb the idea that
players shouldn't know anything about themselves that they can't find out
about a monster by ID'ing it. I also keep some statistical information
for them (win/loss/flee records, time online, etc) that they could keep
for themsleves, but don't bother.

> Ben
>
Derrick

[K.L.Lo-94]

Broly (br...@mail.bcpl.lib.md.us) scribbled:
: On 15 May 1997, Ben Greear wrote:

: > the game, just as they are in most muds, and just edit the display

: > functions so that a player can't check their XP with score. I don't

: Exactly. You're being sarcastic, but I'll agree with you anyways.

Yep, if you want to be as so crude, that's what it boils down to. Instead
of telling my players: STR 10. DEX 12. etc, my server displays a biography.

Your parents live in the Ronald Reagan sector of Shanterra, you lived there
all your life...
etc..
At 18 you enrolled in at the Yiu Medical School and came out with honours.
After that you joined the Shanterra Orbital Emergency Unit for 2 years
before being recruited to by the Tiy Regimental Medics.
more info, etc.

But that's all coz the player has to go through some lifepath choosing system
at char creation. Skills and things can be gleaned by reading the biography
carefully. The character above obviously has medical skills, esp those related
to battlefield medics. Oh, erm, yes, you can visit your parents, friends and
contacts. If the mud goes long enuff, those parents could be actual players
(although the players concerned should be informed really...).

Obviously, the server will keep statistics and things like that in its own
way. What I don't want is a comparison of statistics, everyone I know
says how boring statistics is as a subject, why go on a mud and brag then?
I don't think I have much in terms of skill advancement either, it's a bit
dull, my universe. :)

At the moment, death is permanent, although I think I oughta change this...
That's my fault for playing a certain mud with permanent death. It's all
in aid of keeping a plotline, you see.

Btw, when I refer to my server, it's still vapourware.
--
| Ling "Bitchbitchbitchbitchbitch."
_O_O_ Freshwater fish since 1976 - Freefall & Bliss

[Greg Munt]

On Thu, 15 May 1997, D. B. Brown wrote:

> Right now I'm looking at death causing loss of 20-50% of total
> experience points gained, depending on what the player was killed
> by and in what favor he/she is with his/her church (I'm making
> players become associated with a church to secure the ability to
> be raised from the dead).

This doesnt really make it so players are striving desperately to avoid
death (as realism would dictate). Perhaps instead of a percentage loss, a
loss of n XP, and if this gives them a negative score, they have to make
a new character?

This system would reflect the uncanny ability of heroes to always be able
to get out of impossible situations, while the low-life scum (ie you and
me;) die a meaningless death in a corner.

[Greg Munt]

On Thu, 15 May 1997, D. B. Brown wrote:

> Someone on the list suggested using the Chaosium system for skill
> advancement - if after playing a skill is used, that skill has a
> chance of going up. That doesn't use XPs, but it is IMO a large
> step below XPs for serious character advancement.

Er.. wasn't the that the point of the suggestion?

[Craig S. Dohmen]

Jon A. Lambert <jlsy...@ix.netcom.com> wrote in article
<01bc615f$1659c2e0$c23b...@jlsysinc.ix.netcom.com>...

> Show me any system for character advancement and I'll show you're really
> using XPs.

All right, I'll give it a go. :)

On Discworld, we have what we call the 'taskmaster'. Players performing
an action that uses the taskmaster system have a chance to gaining a level
(or levels - it depends on the coder) of the relevant skill. There are
various parameters of the task that can be twiddled to adjust the minimum
required skill, the steepness of the learning curve, and the difficulty of
the task. Combat was the first thing put on the system, and coders are
encouraged to use the system whenever they add a command that uses a skill.

Most commands either a) take time to execute, b) cost 'guild points', or
c) use up your spell components, so people abusing the system by using
scripts isn't much of a hassle.

The goal is to reduce the importance of xp so that it is actually possible
to be, for example, a thief without having to go slaughter NPCs. Of
course,
it's difficult to put some of the skills on the system. How do you 'use'
other.stamina, for instance?

So far, it's been one of our most popular features with the players, though
a couple of them threw a fit at the beginning. :)

--Craig

[D. B. Brown]

Greg Munt wrote:
> > Someone on the list suggested using the Chaosium system for skill
> > advancement - if after playing a skill is used, that skill has a
> > chance of going up. That doesn't use XPs, but it is IMO a large
> > step below XPs for serious character advancement.
>
> Er.. wasn't the that the point of the suggestion?

Quite. I was pointing that out.

[Martin Keegan]

Jon A. Lambert wrote:

> > Combat should not be the only threat! Thats as abstract and unrealistic
> > as using experience points!
> >

> Show me any system for character advancement and I'll show you're really
> using XPs.

Shurely "and I will show you the man" - Nem

Mk

--
http://cyburbia.net.au/~martin/
http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi

[Ben Greear]

In article <5lg24f$k...@cegt201.bradley.edu>,

Katrina McClelan <kit...@kinger.com> wrote:
>In <5lfh81$hs5$1...@cronkite.cc.uga.edu> gre...@sandstone.cs.uga.edu (Ben Greear) writes:
>

>>If you don't have XP, then you can't even take that away from them...
>

>Sure ya can. Just wrap into the negatives. Diku muds bottom out at 0,

No, no no!! I mean if you don't have the concept of XP...

[snip perm stat-- as a penalty for death]

>>You would have to provide much more of an incentive for
>>risky battle... What would you have me give for this incentive?
>

>Well, one thing on this, incentive is a relative term. In a mud that is
>unbalanced, as most dikus are, you can slaughter 99% of the mobs without
>risk. In a mud where combat is generally risky, and where players are not
>the caps of power this is not as much of a problem. Combart on my mud has
>heavy influence of mob special abilities. Some mobs such as a beholder or

[snip]

>ogre magi and ogre shaman can be quite dangerous. In such a system there
>are not alot of unrisky ways to get reward, so the reward period is
>incentive enough.

I agree here, and I'm supposing you reward them with XP and or Gold?
That is also how I propose to do it, I was agueing against ppl that didn't
like the idea that a player had (visible) experience points. Or at least
questioning what they would have us reward the player with instead..

>
>-Katrina

[Ben Greear]

In article <Pine.LNX.3.91.97051...@uni-corn.demon.co.uk>,
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:

>On 15 May 1997, Ben Greear wrote:
>

>> >Also, I think you'll find that the usual reaction to death is 'oops, I
>> >died, what a bummer'. Losing a few XP is hardly a great punishment for
>> >death - you dont exactly *fear* dying, do you?
>>
>> If you don't have XP, then you can't even take that away from them... Taking
>> permanent stats away might be an answer..but I'm not sure players would
>> really like it.
>
>I guess you have to choose between realism and appealing to mass demand.
>I know which one appeals to me more. It's not the latter.

Thats your choice, but I hope to write a game (yes a game) that as many
people as possible will enjoy, for a long time. I include myself in
these people... It is more enjoyable (for me at least) to play a mud
with many people, thats where the 'm' comes from, and its also why playing
a text adventure game on your pc (alone) usually just plain sucks.

>
>> You would have to provide much more of an incentive for
>> risky battle... What would you have me give for this incentive?
>

>Erm, why do you need an incentive for battle?

Ok, so suppose there is no incentive for battle. This would be ok if you
have some other reason to play the mud. What is it? What are the goals
and risks (I believe you must have these to have an interesting game.)
Also, how do you progress (in RL I work out 2-3 times a week, straining my
body to the point of exhaustion..this increments my STR, my CHA (perhaps)
and my CON.) Fine, I have advanced..I know it..it is self evident..and I
have also put forth effort. Thus I have paid for my advances.

How do you propose one pays for an advance in your realistic MUD? Most
MUD's make you pay for advancement in RISK of death or some other bad
thing.

>
>------------------------------------------------------------------------------
> T H E F R O N T I E R S P R O J E C T

Ben

[Ben Greear]

In article <01bc61fc$cf29b080$b42faccf@craig>,

Craig S. Dohmen <doh...@erols.com> wrote:
>Jon A. Lambert <jlsy...@ix.netcom.com> wrote in article
><01bc615f$1659c2e0$c23b...@jlsysinc.ix.netcom.com>...

>On Discworld, we have what we call the 'taskmaster'. Players performing

>an action that uses the taskmaster system have a chance to gaining a level
>(or levels - it depends on the coder) of the relevant skill. There are
>various parameters of the task that can be twiddled to adjust the minimum
>required skill, the steepness of the learning curve, and the difficulty of
>the task. Combat was the first thing put on the system, and coders are
>encouraged to use the system whenever they add a command that uses a skill.
>
>Most commands either a) take time to execute, b) cost 'guild points', or
>c) use up your spell components, so people abusing the system by using
>scripts isn't much of a hassle.

I like the idea of greater penalties for spell usage..but I don't see how
this affects advancement per se. Perhaps you could give an example of a
task and or how to solve it via this system?

>
>--Craig

[Ben Greear]

In article <yospe-15059...@usrns29.dialup.hawaii.edu>,
Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:

>gre...@pollux.cs.uga.edu (Ben Greear) wrote:
>
>mastered in the past are relearned more easilly. Now, as for the set
>of technical conditions I used to generate this... its a bastardized
>descendent of neural net algorithms. I have three levels, and two

Heheh, I bet the 'idea people' love this one!

[details snipped]

Sounds like a pretty complex system, and probably works pretty well
from the user's standpoint. If I had it all to do over again, I might
even think of doing it in a similar manner.. However, to be honest, I'm
not entirely clear on how you update skills. Do you basically update
them (or at least have a chance of update) every time a spell is used?
Do you also modify spells/skills related to it??

Sounds neat, good luck

>This is why I am now working on effective swapping techniques.

Hmmm, I always assumed that the OS can probably do the best job here, and
definately it is easiest...however, if you put a lot of time and nasty
code in you can probably out do the OS because you have better knowledge
of when an object will/will not be needed...

>Never liked the idea of discreet values here. I track the condition
>of every physical object, be it part of a character or part of an
>object of indeterminate function. If badly enough damaged, in any
>way... for example, charred meat does not function well as an arm...
>though it might well serve as food... that part of a character is
>effectively destroyed, though it might remain atatched. Shock can
>kill, as can blood loss, or damage to a critical body part. Fatigue
>is possible, though cybernetics can alleviate some of it.

[snip]

>as opposed to a component of the character. The point is, we are
>not just renaming things, as you seem to think. We are changing the
>fundamental assumptions, because we feel they were flawed from the
>start, and are no longer even justifiable in terms of resources.

I'll admit you do seem to be doing that...I'll be interested to hear how
it all turns out... It is definately more complicated than standard MUD
ways of doing things, the trick will be to see if the users can notice
(and, hopefully, care).

>--
>Nathan F. Yospe | There is nothing wrong with being a sociopath. Its

--

[Chris Lawrence (Contra)]

Steven R. Johnson (ste...@mistic.net) wrote:
: In alt.mud.programming Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:

: : <<You are really willing to play on a MUD which still has experience
: : points? What ever for?>>

: And what is wrong with this?

Its an overly simpliostic model that encourages overly simplistic play
trivialises some very interesting problems in character development.

: Most MUDS do use experience points.

This is a good thing?

--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...

[Chris Lawrence (Contra)]

Ben Greear (gre...@sandstone.cs.uga.edu) wrote:

: This is fine, but how is the server to compare player x to player y?

Why would you want to compare them? There's no real need other than mental
bubblegum to make players feel better.

[mor...@niuhep.physics.niu.edu]

gre...@sandstone.cs.uga.edu (Ben Greear) writes:

>Yep, but, as far as I can tell, the only reason one needs money is to buy
>stuff that better allows one to kill (and thus get XP.)

Do you only have fighters on your MUD? No thieves? No rangers?

>>My reward for people who overcome or avoid threats (no honour lost in running
>>away) is living. Maybe a bit of skill advancement if I was feeling
>>generous.

>This is fine, but how is the server to compare player x to player y? Should
>we rank them by how many times they've died? Then newbies will be strongest
>of all..

summation of all their skill levels.

my (mostly non-existant) mud advances skills based on use of the skill.

Success advances the skill most quickly,
a few failures can be educational
too many failures is counterproductive
doing easy tasks doesn't teach you very much at all.

Killing only helps you kill (which indeed can be useful if there are people
trying to kill you)

Back to rankings, I have a guild system, players go up in rank
according to a weighted summation of their guild and non-guild skills.
Asside from pride in rank players gain a few hitpoints and lives by going
up in rank.

Robert

specify the e-mail address below, my reply-to: has anti-spam added to it
Mor...@physics.niu.edu
Real Men change diapers

[Ben Greear]

In article <Pine.SOL.3.95.970516...@mail.bcpl.lib.md.us>,

Broly <br...@mail.bcpl.lib.md.us> wrote:
>On 15 May 1997, Ben Greear wrote:
>

>> Ohhh, but isn't it nice to be able to check how much gas you actually have??
>
>Actually, XP would be the odometer[sp?] in this analogy. It would measure
>just how far the player has come. As a driver, I drive (go adventure)

Perhaps you are right, but my point still stands. It is nice to know your
stats. YOu can see mileage, MPH, gas and maybe tach easily, with a
little effort (score -long) you can check the Horse Power, oil level,
brake fuel, tires etc.... I like being able to quatitize these values.

>XP, the change is a gradual increase in strength. I am thinking of hiding
>_most_ statistical information from players, except things they can keep
>track of themselves (I'll have a breakdown of mobs killed, quests fiished
>etc for a 'score' command, rather than you are level 10 have 123542 XP)
>Players will realize that they grow in strength ('wow, my backstab
>_REALLY_ f***ed up that troll') and NPC's will treat more powerful players
>differently ('heh, you see that cityguard get out of my way back there?')

Still, you are using numbers to determine how hard the player hit. IRL
we can get numeric values for most of our attributes. Other things, like
experience, we still have an intuition for. This intuition is impossible
in a text setting (hell, any out of body setting). There needs to be
some way to relay this information to the player, and numbers seem to be
the best way to me. You COULD translate the numbers to words, as in your
troll example, but that is all you are doing, the concept remains the same.

>Players
>shouldn't sit around discussing their hitrolls while Midgaard's mayor is
>being slaughtered in Market Square. But I'll rant more about the lack of
>roleplay MUDs in a different post.

I'll have to agree there, and I hope to add enough code that ppl will
want to protect such leaders, if not out of role-playing, but because
they will gain in some personal way (or at least won't lose :)).
>

>level in their fireball skill, they'll find out by seeing the charred
>remains of their foes in the next battle. I do, however, end up with the

If you make your descriptions fine-grained enough you could do this...but
I'm way to lazy to write 10 different descriptions for every desc in a
fire-ball spell.. At the same time, flog me if I ever code:
You hit the harmless kitten for 12986 HP of damage!!

>problems of explaining just how to explain that mobs 'know' a players
>power level (guildmasters only except people between certain levels as
>pupils) and how to have players rate themselves within the 'community' of
>other players.

Its true that 'level's are abstract, but after all, we hope to inhabbit a
world of numbers and letters...abstraction is necessary.

>Actually, one assumption I haven't made: Players want to know every
>little detail about their players. I use as a rule of thumb the idea that
>players shouldn't know anything about themselves that they can't find out
>about a monster by ID'ing it. I also keep some statistical information

This doesn't model one's self awareness very well though... I always
know much more about my own body than that of even my most intimate
companion...

>for them (win/loss/flee records, time online, etc) that they could keep
>for themsleves, but don't bother.

Yep, computers make damn good counters :)

>Derrick

[Jon A. Lambert]

D. B. Brown <da...@bme1.image.uky.edu> wrote in article <337B94...@bme1.image.uky.edu>...

> Jon A. Lambert wrote:
> > Show me any system for character advancement and I'll show you're really
> > using XPs.
> >

> > A bold claim. :-)
> > Here's hoping I won't *gag* on it.

>
> Someone on the list suggested using the Chaosium system for skill
> advancement - if after playing a skill is used, that skill has a
> chance of going up. That doesn't use XPs, but it is IMO a large
> step below XPs for serious character advancement.
>

Here we go! *splurgh* 8). Excuse me.
A reasonable alternative. I see some heavy duty problems with this
also. Repeated exercise of the same skill over and over would allow for
skill advancement? This must be what those mages and clerics are doing
behind closed doors on ROMs.
Throw in related skills being pulled along in advancement, some situational
modifers (to prevent above), some skill atrophying and a "neural net" and
we might be close to what Nathan is implementing ( which might be the best
alternative I've seen BTW, although still a bit beyond my comprehension ).

I really was hoping Greg had an alternative to offer after giving a sound
trouncing of Ben's ideas. I guess not. *grin*

JL

[Jon A. Lambert]

Craig S. Dohmen <doh...@erols.com> wrote in article <01bc61fc$cf29b080$b42faccf@craig>...

> Jon A. Lambert <jlsy...@ix.netcom.com> wrote in article
> <01bc615f$1659c2e0$c23b...@jlsysinc.ix.netcom.com>...

> > Show me any system for character advancement and I'll show you're really
> > using XPs.
>

> All right, I'll give it a go. :)
>

> On Discworld, we have what we call the 'taskmaster'. Players performing
> an action that uses the taskmaster system have a chance to gaining a level
> (or levels - it depends on the coder) of the relevant skill. There are
> various parameters of the task that can be twiddled to adjust the minimum
> required skill, the steepness of the learning curve, and the difficulty of
> the task. Combat was the first thing put on the system, and coders are
> encouraged to use the system whenever they add a command that uses a skill.
>

OK, This is good! You've recognized a problem with giving out "general"
XPs and are assigning them based on the relative difficulty of the
task at hand. Also, you are recognizing other tasks contributing to character
advancement.

> Most commands either a) take time to execute, b) cost 'guild points', or
> c) use up your spell components, so people abusing the system by using
> scripts isn't much of a hassle.

I like a) and c) a lot. I don't fully comprehend b). Sounds suspiciously
like another abstraction for players to base the goals on. ;-)

> The goal is to reduce the importance of xp so that it is actually possible
> to be, for example, a thief without having to go slaughter NPCs. Of
> course, it's difficult to put some of the skills on the system. How do you 'use'
> other.stamina, for instance?
>
> So far, it's been one of our most popular features with the players, though
> a couple of them threw a fit at the beginning. :)

From your post, I would venture to guess that you think XPs have some
value as an abstraction measuring advancement, although you
are making their use more granular in order to provide a more "realistic"
character development.

JL

[Craig S. Dohmen]

Ben Greear <gre...@sandstone.cs.uga.edu> wrote in article
<5lhvii$gj$1...@cronkite.cc.uga.edu>...

> I like the idea of greater penalties for spell usage..but I don't see how
> this affects advancement per se. Perhaps you could give an example of a
> task and or how to solve it via this system?

Hang on, I'm confused. My point with with the spell components and so
forth
was that it tends to keep people from abusing the system by setting up a
script to repeat the command over and over.

--Craig

[Craig S. Dohmen]

Jon A. Lambert <jlsy...@ix.netcom.com> wrote in article

<01bc6265$29d86e00$ec3b...@jlsysinc.ix.netcom.com>...

> I like a) and c) a lot. I don't fully comprehend b). Sounds
suspiciously
> like another abstraction for players to base the goals on. ;-)

Yeah, guild points are, in my opinion, arbitrary and fiddly. Having said
that, I haven't been able to come up with a good way to get rid of them.

> From your post, I would venture to guess that you think XPs have some
> value as an abstraction measuring advancement, although you
> are making their use more granular in order to provide a more "realistic"
> character development.

No. :) XPs don't apply to the taskmaster system at all. We still give
soime xp for killing things and for quests, but mainly because there aren't
enough ways to advance all the skills using the system. There probably
never
will be either, since it's difficult to think of a rational way to put some
of
the skills onto the system.

--Craig

[Jon A. Lambert]

Martin Keegan <mar...@cam.sri.com> wrote in article <337C75...@cam.sri.com>...

> Jon A. Lambert wrote:
>
> > > Combat should not be the only threat! Thats as abstract and unrealistic
> > > as using experience points!
> > >

> > Show me any system for character advancement and I'll show you're really
> > using XPs.
>

> Shurely "and I will show you the man" - Nem
>

Come on Martin. Where did you hide your XPs? *grin*

JL

Sommatime ya gotta beat da heads agin the wall and grab all da loos
coin dat fall out.

[Jon A. Lambert]

Ben Greear <gre...@sandstone.cs.uga.edu> wrote in article <5lfh0r$hie$1...@cronkite.cc.uga.edu>...
> In article <5le7ui$c...@sun-cc204.lboro.ac.uk>,
> K.L.Lo-94 <K.L....@student.lboro.ac.uk> wrote:
> >Ben Greear (gre...@pollux.cs.uga.edu) scribbled:
> >: I like XP as a measure, because the most (and sometimes only) threat on a
> >: MUD
> >: is in battle. You should thus reward ppl who tested and overcame this
> >: threat, and punish those who failed (for why else could it be a threat?).
> >: XP allows all this....
> >
> >Surely to kill someone is a measure of achievement. How about the equipment
>
> I agree completely. That is why I chose to give them experience points
> for it, because that is the best way I've found to measure one person's
> achievement against another's.
>
You give XPs for killing. I do that too. Players advance through killing.
Are you and your players happy with that? I don't think you'd be
posting here if you were.

Other reasons for giving XPs (or advancement of a more PC kind).

1) Successful execution of skills other than 'kill mob'?
2) Spell casting
3) Roleplaying awards
4) Quest solving
5) Other really cool skills, like climbing, swimming, riding, acting, disguise,
pick locks, finding/disarming traps, craft skills (cooper, smithy, cobbler, etc.)
assasination, ambush, pick pockets, research (boring eh?).
6) Appointments (guild, religious, political, military)
7) Building, running or maintaining shops, guilds, stronghols, inss, households,
farms, sewer systems, etc.

> >gained? On most muds, the stuff obtained from the body can be sold for
> >cash. Or, (gag) there's cash on the rabbit you just killed.

>
> Yep, but, as far as I can tell, the only reason one needs money is to buy
> stuff that better allows one to kill (and thus get XP.)
>

Well give players something they can own, maintain and be proud of:
1) shops, castles, lands
2) henchmen, hirelings, pets, slaves and harems
3) transport - ships, horses, carts, chariots
4) livestock

And they of course have more to spend:
1) rent, household maintenance
2) property taxes, tolls, weregeld, guild fees, tithes
3) really nice clothes, permanent tattoos
4) spell components
5) herbs, drugs, chocolate candies.
6) commissions to artists to make statues and paintings in their honor
7) custom made items, (have initials engraved on the trusty bastard
sword)

> This is fine, but how is the server to compare player x to player y? Should
> we rank them by how many times they've died? Then newbies will be strongest
> of all..
>

Rank them? Let them rank themselves by their accomplishments, wealth,
holdings, retainers, number of scars or interesting tattoos.

> >PS: Did I mention the high mortality rate? :)
>
> I got no problem with that :)
>
Oh yeh and wills, great tombs, inheritence, inheritance tax, weregeld.

JL

[Brandon J. Rickman]

Ben Greear wrote:
>
> In article <Pine.SOL.3.95.970516...@mail.bcpl.lib.md.us>,
> Broly <br...@mail.bcpl.lib.md.us> wrote:
> >On 15 May 1997, Ben Greear wrote:
> Still, you are using numbers to determine how hard the player hit. IRL
> we can get numeric values for most of our attributes. Other things, like
> experience, we still have an intuition for. This intuition is impossible
> in a text setting (hell, any out of body setting). There needs to be
> some way to relay this information to the player, and numbers seem to be
> the best way to me. You COULD translate the numbers to words, as in your
> troll example, but that is all you are doing, the concept remains the same.

How tall are you? Are you X' Y" tall because that is what your license
says?
You may find yourself in a crowd at the mall saying to yourself, "Hey,
I'm
about average/very short/kind of tall compared to everyone here." The
fact that
you can quantify your height and compare it with statistical averages
isn't very
useful when you are put into a non-statistical [i.e. a mall in Chinatown
or the
Outer Banks, NC] context, because the local context is usually more
important
than the global. And aren't muds all about context anyway?

So _while you can measure your strength_ on a variety of apparati, your
strength
relative to the people around you isn't always going to equal to your
absolute
strength. (This is why the idea of "max racial attributes" is
important; the strongest
Pixie might be able to bench press 50 pounds, but in a crowd of Dwarves
the Pixie is
quite a wimp. So while this Pixie is statistically very strong for its
race, in a
relative comparison with other races that quantity is meaningless.) So
the idea of
being able to compare your stats with _all the other players_ is A BUNCH
OF
MEANINGLESS CRAP.

> >level in their fireball skill, they'll find out by seeing the charred
> >remains of their foes in the next battle. I do, however, end up with the
>
> If you make your descriptions fine-grained enough you could do this...but
> I'm way to lazy to write 10 different descriptions for every desc in a
> fire-ball spell..

If you don't have the energy to make your mud interesting by providing
accurate and
informative descriptions to a fire-ball spell then I would say you are
not only lazy,
you are a bad designer.

> At the same time, flog me if I ever code:
> You hit the harmless kitten for 12986 HP of damage!!

I'm not really flaming you, but I think it is very important that we
come up with
a way to create meaningful descriptions that compensate for lazy
builders.

The "damage continuum" approach doesn't seem to be very satisfying:

You tickle the bread mold with your butter knife.
You jostle the bread mold with your butter knife.
You irritate the bread mold with your butter knife.
... sting ...
... poke ...
... slice ...
... smash ...
You obliterate the bread mold with your butter knife.

Verbs tend to be overloaded with meaning. (You POKE the bread mold?
Tickle?)
And an experienced player can almost always decipher that "sting" means
"5-8 HP".

Let's play with this model:
You [damage adverb] [damage verb] <target> [qualifier] with <weapon>.

Where:
clumsily is 1/4x damage
carefully is 1x damage
accurately is 4x damage

stab is 2x damage
cut is 1x damage
wound is 1/2x damage

very hard is 2x damage
hard is 1x damage
lightly is 1/2x damage

So now we have
You clumsily stab the dragonfly very hard with the halbard.
You carefully cut the dragonfly hard with the halbard.
You accurately wound the dragonfly lightly with the halbard.

Which all represent the same amount of damage. The best/worst attacks
would be:

You clumsily wound the dragonfly lightly with the halbard. (1/16x
damage, or 1 hp)
You accurately stab the dragonfly very hard with the halbard. (16x
damage, or 16 hp)

This system merely pretends to take into account the player's strength,
dexterity, and
weapon skill.

I don't recommend fighting dragonflies with halbards.

> >problems of explaining just how to explain that mobs 'know' a players
> >power level (guildmasters only except people between certain levels as
> >pupils) and how to have players rate themselves within the 'community' of
> >other players.
>
> Its true that 'level's are abstract, but after all, we hope to inhabbit a
> world of numbers and letters...abstraction is necessary.

Levels and XP are abstract, but many people seems to have forgotten that
the XP system
was designed to represent some sum of a character's skills. Now that we
are actually
interested in keeping track of the individual skills we should only use
XP and levels as
an abstraction of the skills of the character. So player A may be a
higher level than
player B, but B might be much stronger than A. It is rare to find this
kind of thing on an
XP based mud because skills tend to be limited by the character level,
which IMNSHO is a really
fucked up way to design a game.

Some comments not related to the above followup post:

The tiresome "what if someone wrote a script to cast fireballs all day
long" argument:

People write these mindless scripts because the normal way of increasing
skills (i.e. combat)
is just as mindless. By not allowing players to practice skills
mindlessly, you are refusing
to allow players to _master the skills they think are important_. If a
master
fireballer is going to unbalance your game then your game sucks. Adding
spell components
only fixes the problem as it relates to spells,
someone practicing archery on a bale of hay is never going
to "run out of components". But master archers and master fireballers
both tend to be very
bad at avoiding getting hit by Ogres wielding very large and brutal
fists. Can you
write a script that practices dodging?

A question:

Should combat ever last longer than 10 rounds?

I have a feeling that this text is formatted poorly.

- Brandon

[Nathan F. Yospe]

gre...@pollux.cs.uga.edu (Ben Greear) wrote:

:In article <yospe-15059...@usrns29.dialup.hawaii.edu>,

:Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
:>gre...@pollux.cs.uga.edu (Ben Greear) wrote:
:>
:>mastered in the past are relearned more easilly. Now, as for the set
:>of technical conditions I used to generate this... its a bastardized
:>descendent of neural net algorithms. I have three levels, and two

:Heheh, I bet the 'idea people' love this one!

*laugh*

:[details snipped]

:
:Sounds like a pretty complex system, and probably works pretty well
:from the user's standpoint. If I had it all to do over again, I might
:even think of doing it in a similar manner.. However, to be honest, I'm
:not entirely clear on how you update skills. Do you basically update
:them (or at least have a chance of update) every time a spell is used?
:Do you also modify spells/skills related to it??

You hit it close to the nose. What you have is:

Skill 1 (Climb) <---------> Attribute 1 (Strength)
^---\/----^
/\----v
Skill 2 (Weave) <--/------> Attribute 2 (Coordination)
/-
v
Skill 3 (Run) <---------> Attribute 3 (Endurance)

(Very simplified, and the links _could_ be one way)
Trying to climb checks to see if strength and/or coordination
have changed, then checks for improvement. If there is change
since last check, climb skill is updated before the improvement
and usage check. After the check, strength and coordination are
updated. The next check to them will update whatever did the
checking, unless its a check to climb, which is now dated.

:Sounds neat, good luck

Thanks.

:>This is why I am now working on effective swapping techniques.

:
:Hmmm, I always assumed that the OS can probably do the best job here, and
:definately it is easiest...however, if you put a lot of time and nasty
:code in you can probably out do the OS because you have better knowledge
:of when an object will/will not be needed...

I thought much the same, but have been corrected since. There are
several problems with OS swapping, most having to do with chunks
of memory small enough to swap ending up 95% old (ready to swap)
but not swapping because the 5% is something frequently used.

:[snip]

:>as opposed to a component of the character. The point is, we are
:>not just renaming things, as you seem to think. We are changing the
:>fundamental assumptions, because we feel they were flawed from the
:>start, and are no longer even justifiable in terms of resources.

:I'll admit you do seem to be doing that...I'll be interested to hear how
:it all turns out... It is definately more complicated than standard MUD
:ways of doing things, the trick will be to see if the users can notice
:(and, hopefully, care).

True. If you have seen my test run printouts, though, you will see
why I feel that it is worth it. Yeah, too rough for the diku crowd,
but very, very nice presentation. I'm after a new sort of audience.

--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its

yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!

[Mackay / Katherine Amanda (COM)]

Jon A. Lambert <jlsy...@ix.netcom.com> wrote:
>Show me any system for character advancement and I'll show you're really
>using XPs.

ZenMOO: You gain by not typing anything (except when you need to :)

--OH.

[Nathan F. Yospe]

mat...@king.cts.com (Mathue Moyer) wrote:

:Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
::[comment about thinking that the OS can probably handle swapping better than
:: the mud]
: [note that pages are not sized such that swapping is effective for
mud objects]
:While I haven't actually had a chance to test the idea yet, I believe you
:can provide tremendous assistance to the OS by allocating memory more
:intelligently. For instance, if you put in the effort to make sure that
:all memory associated with a particular area lies within a particular set
:of (memory) pages, and that there are no portions of other areas present in
:those pages, the OS will effectively swap the area out if it hasn't been
:visited in a while.

This sort of memory management scheme comes closer to what I intend than
actually doing the readin/writeout. I'm still working on the management
criteria. I'm probably going to resort to allocating chunks of memory,
overloading new to grab from those chunks, and delete to track the size
of leftovers, and periodically doing a shuffle to drop all the old stuff
into chunks intended for swap, consolidating the new stuff and the free
memory.

:While I could see such a strategy vastly improving the OS's ability to
:effectively swap out portions of the game, I can only speculate as to
:how desirable that is. I don't suppose it's all that important if you
:have plenty of RAM on your machine and few other processes running.

Which is not the case for a large number of muds out there.

[Mathue Moyer]

Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
[comment about thinking that the OS can probably handle swapping better than
the mud]

> I thought much the same, but have been corrected since. There are
> several problems with OS swapping, most having to do with chunks
> of memory small enough to swap ending up 95% old (ready to swap)
> but not swapping because the 5% is something frequently used.

While I haven't actually had a chance to test the idea yet, I believe you

can provide tremendous assistance to the OS by allocating memory more
intelligently. For instance, if you put in the effort to make sure that
all memory associated with a particular area lies within a particular set
of (memory) pages, and that there are no portions of other areas present in
those pages, the OS will effectively swap the area out if it hasn't been
visited in a while.

While I could see such a strategy vastly improving the OS's ability to

effectively swap out portions of the game, I can only speculate as to
how desirable that is. I don't suppose it's all that important if you
have plenty of RAM on your machine and few other processes running.

mathue

--
Mathue Moyer | Anyone who says they have only
Email: mat...@cts.com | one life to live must not know
URL: http://www.users.cts.com/king/m/mathue | how to read a book.

[Martin Keegan]

Greg Munt wrote:

> This doesnt really make it so players are striving desperately to avoid
> death (as realism would dictate). Perhaps instead of a percentage loss, a
> loss of n XP, and if this gives them a negative score, they have to make
> a new character?

Uh oh - I think I'm a bit ignorant here - is it that on Dikus
you can get killed as much as you want and not have to start
a new character?

Mk

-- "It's the Game, Stupid"
http://cyburbia.net.au/~martin/cgi-bin/mud_tree.cgi
#!/usr/local/bin/perl
@z=("I","os\'","dipu","so,emaGoeh");@s=reverse split'','0132';
@l[shift@s]=scalar reverse$z[scalar@s-1]while(@s);
map{print $_."\040"}split"o",join't',@l; print "\n";

[Ben Greear]

In article <yospe-17059...@usrns26.dialup.hawaii.edu>,

Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
>:>This is why I am now working on effective swapping techniques.
>:
>:Hmmm, I always assumed that the OS can probably do the best job here, and
>:definately it is easiest...however, if you put a lot of time and nasty
>:code in you can probably out do the OS because you have better knowledge
>:of when an object will/will not be needed...
>

>I thought much the same, but have been corrected since. There are
>several problems with OS swapping, most having to do with chunks
>of memory small enough to swap ending up 95% old (ready to swap)
>but not swapping because the 5% is something frequently used.

So you are going to try to consolidate pages??? If you are going to swap
it, I assume you will delete the 'old' data and write it to disk
(hopefully in the opposite order!). However, this might just give you
lots of holes that malloc has a hard time filling... Also, any IO you do
is going to be much less efficient than the systems Swapping procedures.
First of all you have to cross the system layer, and secondly, the OS uses
a specially formatted section of the HD, which you will not have.

Not saying it can't be done, but beware the pitfalls.

>Nathan F. Yospe | There is nothing wrong with being a sociopath. Its

[mor...@niuhep.physics.niu.edu]

claw...@cup.hp.com (Chris Lawrence (Contra)) writes:
>Ben Greear (gre...@sandstone.cs.uga.edu) wrote:

>: This is fine, but how is the server to compare player x to player y?

>Why would you want to compare them? There's no real need other than mental
>bubblegum to make players feel better.

Yes, and what is wrong with that?

It is only a game.

Many players want a relatively easy system for seeing whose is bigger.
Unless it seriously compromises the mud I say give it to them.

Though, reading Ben's comment again I do have to ask why "the server"
needs to compare them?

[George Reese]

This is a multi-part message in MIME format.
--------------E52EB2BB856CA4E14EB2B957
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Ben Greear wrote:
> =

> In article <Pine.LNX.3.91.97051...@uni-corn.demon.co.u=
k>,

> Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
> >On 15 May 1997, Ben Greear wrote:
> >

> >> I like XP as a measure, because the most (and sometimes only) threat=
on a MUD
> >> is in battle. You should thus reward ppl who tested and overcame th=
is
> >> threat, and punish those who failed (for why else could it be a thre=
at?).
> >> XP allows all this....
> >
> >Combat should not be the only threat! Thats as abstract and unrealisti=
c
> >as using experience points!
> =

> Exactly, see my other thread on MUD threats...
> However, just because that is true in no way detracts from using XP.
> =

> >
> >Also, I think you'll find that the usual reaction to death is 'oops, I=

> >died, what a bummer'. Losing a few XP is hardly a great punishment for=

> >death - you dont exactly *fear* dying, do you?

> =

> If you don't have XP, then you can't even take that away from them... =
Taking
> permanent stats away might be an answer..but I'm not sure players would=

> really like it. You would have to provide much more of an incentive fo=
r

> risky battle... What would you have me give for this incentive?

First off, this whole thread seems to base itself on the belief that
experience points (as such) are the way everything is done. The
Nightmare mudlib is one stock base that does not use exp. That having
been said, however, Jon is right in that any system can be reduced to
exp.

More to the point, however, is that the comment "If you don't have XP,
then you can't even take that away from them" is a very narrowly thought
out statement and ultimately self-defeating. Much like saying, "if
everything were red, then nothing would be blue".

On Nightmare LPMud, for example, people do not lose ANYTHING for dying.
They go to an underworld and live as an undead. The act of resurrection
costs them in SKILLS.

Now, you can argue rightfully that skill points are a variation on the
exp theme. Nevertheless, the point still stands that given a different
system, you can find different ways to make death meaningful.

-- =

George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
i've kissed mermaids, rode the el ni=F1o
walked the sand with the crustaceans
can find my way to mariana
--------------E52EB2BB856CA4E14EB2B957
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for George Reese
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: George Reese
n: Reese;George
org: http://www.imaginary.com/~borg
email;internet: bo...@imaginary.com
tel;work: (612) 509-3223
tel;fax: (612) 888-8829
tel;home: (612) 991-4446
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
end: vcard

--------------E52EB2BB856CA4E14EB2B957--

[Chris Lawrence (Contra)]

Jon A. Lambert (jlsy...@ix.netcom.com) wrote:

: Show me any system for character advancement and I'll show you're really
: using XPs.

: A bold claim. :-)

: Here's hoping I won't *gag* on it.

Of course it is supportable. If you have advancement then of necessity
you have some form of metric for counting that advancement. Once you
have that, you have an item which could be tagged as a form (mutation?)
of Experience Points. Even if you go the old skill-web/skill-tree route
and track it all seperately with hugely complex interdependancies and
restrictions, all you have really done is to fract standard XP's into a
larger number of XP-type metrics with specialised behaviours. Nothing
has really changed -- you've just cut them up into little pieces.

To a certain extent the argument is either for globbing everything
together in one unversal it-does-everything XP point system (cf
one-size-fits-all garments), or attempt to sub-divide those XPs into
smaller quanta and do your figuring on that smaller grain. Either way
the *system* is the same. The change is in the user actions necessary
to manipulate the system

[Chris Lawrence (Contra)]

Katrina McClelan (kit...@kinger.com) wrote:
: In <5lfh81$hs5$1...@cronkite.cc.uga.edu> gre...@sandstone.cs.uga.edu (Ben Greear) writes:

: >If you don't have XP, then you can't even take that away from them...

: Sure ya can. Just wrap into the negatives. Diku muds bottom out at 0,
: but that doesn't mean you have to keep that, or in Ben or I's case write
: ours that way. I have negative exp in mine already.

This doesn't work if your system does not even have the concept of XPs.
The question of what the value is no longer arises -- there's nothing there
to *have_ a value.

[Chris Lawrence (Contra)]

D. B. Brown (da...@bme1.image.uky.edu) wrote:

: Anyway, I want death to be a frightening prospect, without
: permanently harming the character -- i.e., if the character dies,
: there should always be some way to regain what was lost.

Why? Why not have death be permanent, and just delete the character?

[Chris Lawrence (Contra)]

mor...@niuhep.physics.niu.edu wrote:
: gre...@sandstone.cs.uga.edu (Ben Greear) writes:

: >Yep, but, as far as I can tell, the only reason one needs money is to buy

: >stuff that better allows one to kill (and thus get XP.)

: Do you only have fighters on your MUD? No thieves? No rangers?

I have no classes, and so don't distinguish fighters from theives from
rangers from druids, from healers, from bumps on a log. Anybody can
attempt to learn or practice (as in do, not train) any action or skill.

[Martin Keegan]

Chris Lawrence (Contra) wrote:

> : Most MUDS do use experience points.
>
> This is a good thing?

Hmm,, the idea that "lots of muds have this => it is popular =>
it must be inherently good" is flawed, isn't it?

[Martin Keegan]

Greg Munt wrote:
>
> On 15 May 1997, Ben Greear wrote:
>

> > I like XP as a measure, because the most (and sometimes only) threat on a MUD
> > is in battle. You should thus reward ppl who tested and overcame this
> > threat, and punish those who failed (for why else could it be a threat?).
> > XP allows all this....
>

> Combat should not be the only threat! Thats as abstract and unrealistic
> as using experience points!

Do muds have to be realistic? I'd have thought the very nature
of them prevented this. Do you mean "internally consistent"?

> Also, I think you'll find that the usual reaction to death is 'oops, I

> died, what a bummer'. Losing a few XP is hardly a great punishment for

> death - you dont exactly *fear* dying, do you?

In muds where there is risk (and there are muds which function without
it, like Tinys), it's easy to adjust the level of this risk. Dikus
are geared to "continuous gratification"; any risk has to be pretty
small, or players will be turned away. I've heard that on some Dikus,
if you get killed, you just lose XP, and never enough to make you
drop levels. I mean, really!

[Brandon J. Rickman]

Ben Greear <gre...@pollux.cs.uga.edu> wrote in article
<5lqs9i$s87$1...@cronkite.cc.uga.edu>...
> In article <337E3D...@ucla.edu>,
> Brandon J. Rickman <ashes...@ucla.edu> wrote:

> >Ben Greear wrote:
> >relative comparison with other races that quantity is meaningless.) So
> >the idea of
> >being able to compare your stats with _all the other players_ is A BUNCH
> >OF MEANINGLESS CRAP.
>

> Yess, you typed it in all caps, but I can't find your argument. If you
> are a dwarf, and your STR is 18, and I'm a pixie with a STR of 4, why
> can't I compare them? Do you believe that a pixie should be able to
> defeat a dwarf in hand-to-hand battle?? I don't, I think pixies aughta
> stay up in the trees, out of the way of big mean dwarves, which, if they
> could catch them, could sure rip them in two!

Your own 18 STR dwarf vs. a 4 STR pixie example is my argument. The point
which you so clearly make is _there is no point in making this comparison_.
Let me paraphrase this as "Dwarves are always stronger than pixies." This
relates to Shoehorn's Rule of Race: "If you want to be a fighter, don't
pick a wimpy race."

If a really strong pixie has a strength of 4, and a really wimpy pixie has
a strength of 2 then, um, average pixies have a strength of 3. So pixie
Alpha and pixie Beta are both very strong (4 STR). But maybe Alpha is just
a little stronger? Hm, maybe Alpha should get a 5.

Along comes pixie Gamma. She is stronger than Beta, but not as strong as
Alpha. Tell you what, let Alpha have 6 STR and Gamma can have a 5.

One day, Alpha decides to leave his gumdrop tree and go exploring. He
encounters Motch the Very Wimpy Dwarf (STR 6). A battle ensues. Alpha and
Motch are of equal strength (I assume this is clear from the above, please
feel free to reread this at your leisure until you understand it fully),
but since Dwarves are always stronger than Pixies, Motch will win.

Something is funny here. Either the Dwarf/Pixie case is a rather unusual
exception to the rules, or the premise of _directly_ comparing stats is a
bad idea.

> >If you don't have the energy to make your mud interesting by providing
> >accurate and
> >informative descriptions to a fire-ball spell then I would say you are
> >not only lazy, you are a bad designer.
>

> Well, I am not just coding spells, I have written the whole (yes whole)
> thing. I think that writing interesting mob AI code, and other, more
> interesting spells is a much better use of my time.

You are clearly a master coder. Perhaps you really aren't interested in
actually designing your world, otherwise you might try to come up with some
creative solutions for all those "lame mechanical descriptions" you so
fear.

> I'll predict that you'll never mechanically create any description close
> to as good as I can write. Sure mine is static, but it flows, and sounds
> nice. Also, there is a difference between lazy builders, and builders
> who produce only a small amount of work, if it's quality.

"Static" descriptions will be the death of you and your kind.

> >The "damage continuum" approach doesn't seem to be very satisfying:
>

> I thought you wanted me to add a continuim to my fire-ball spell..

>
> >And an experienced player can almost always decipher that "sting" means
> >"5-8 HP".
>

> If you don't want the player to know how hard they hit, why tell them at
> all? Just do the messages based on a random number or the hour of the
day!

I think ZenMOO was mentioned in an earlier branch of this thread.

> >So now we have
> >You clumsily stab the dragonfly very hard with the halbard.
> >You carefully cut the dragonfly hard with the halbard.
> >You accurately wound the dragonfly lightly with the halbard.
>

> Begins to all look like spam after a while :(

Ah, the dreaded spam comparison. I'll have to ask the jury to decide on
this one.

> >This system merely pretends to take into account the player's strength,
> >dexterity, and weapon skill.
>

> And you like this?? Once again, why not just randomize all the messages?

Let me reverse engineer it for you: I take a swing and hit the Lag Monster
for 8 points of damage. I need to pick a set of descriptors that
multiplies out to 1/2. (A multiplier of 1 indicates 16 points of damage.)

This assumes that you have _already_ checked weapon skills, rolled the
attack, etc. If you wanted you could somehow encode all of that numerical
information into the damage message. I am suggesting a cheap alternative.

> >Levels and XP are abstract, but many people seems to have forgotten that
> >the XP system
> >was designed to represent some sum of a character's skills. Now that we
> >are actually
> >interested in keeping track of the individual skills we should only use
> >XP and levels as
> >an abstraction of the skills of the character. So player A may be a
> >higher level than
> >player B, but B might be much stronger than A. It is rare to find this
> >kind of thing on an
>

> If XP and levels are an abstraction of skills, and skills are power, why
> should someone with less XP and levels be stronger?

Why should everyone with equal XP and levels have the same stats/skills?

> > Can you
> >write a script that practices dodging?
>

> Of course, as easy as mindless battle and mindless fire-balling.
> BTW, are you supporting mindless scripts as a method of increasing
power??

Yes. I don't see why mindless scripts are a problem. Just pretend the
players are clever mobs. Is power the point?

- Brandon

[D. B. Brown]

Not that I'm especially either person in the conversation, but...

Ben Greear wrote:
> >If you don't have the energy to make your mud interesting by providing
> >accurate and
> >informative descriptions to a fire-ball spell then I would say you are
> >not only lazy, you are a bad designer.

On a sidenote, I remember making a guild many moons ago that was
wowed at at them time because each power had 3-5 different messages
when it went off. Multiple damage messages are a very, very, nice
thing, however many muds either don't have them or just mechanize them.

Personally, I think a single well-written fireball message is beter
than the Diku spell damage message...

i.e.:

Your fireball maims the goblin.
Your fireball === OBLITERATES === the goblin.

vs.

You focus your will, bathing the goblin in luminous flames.

I'd prefer the second even if there is only one version. Even better
is multiple well-written (not mechanized) messages.

> Since you obviously are not as lazy as I, and are a better designer, I
> have a question. First of all, have you written spells like this. If so,
> how many lines of code? I could come up with the descriptions
> mechanically, but that begins to look predictably lame after the first
> couple of spells. So you check the damage and then go through a big ole
> switch statement? Any fool could do this, but it takes a great deal of
> time, and is quite tedious IMHO.

I think this is a function of the spell, not the mudlib (or mud/driver,
whatever paradigm you choose). Well-designed spells/guilds/classes/
powers/whatever should have some variance in message, but that should
be up to the wizard actually making the spell/guild/class/power.

> > but I think it is very important that we come up with
> >a way to create meaningful descriptions that compensate for lazy builders.

I don't think there is a _good_ way. There are ways, but none that
I'd call good.

IMO, the solution is not let the work of lazy builders hit the mud.
That's what a good QC (quality check) system is for.

> I'll predict that you'll never mechanically create any description close
> to as good as I can write. Sure mine is static, but it flows, and sounds
> nice. Also, there is a difference between lazy builders, and builders
> who produce only a small amount of work, if it's quality.

Very true. Very true.

> >And an experienced player can almost always decipher that "sting" means
> >"5-8 HP".
>

> If you don't want the player to know how hard they hit, why tell them at
> all? Just do the messages based on a random number or the hour of the day!

For my system, there will be enough different levels and attacks
coming and going fast enough, and enough targets on a monster (I'm
doing full limb-based combat) that if anyone can keep really close
track of what's going on they shouldn't be playing the mud - they'd
do much better counting blackjack in Vegas.

> >You [damage adverb] [damage verb] <target> [qualifier] with <weapon>.
>

> So how do you generate the adverbs, as it seems you calculate damage FROM
> the adverbs.

>
> >So now we have
> >You clumsily stab the dragonfly very hard with the halbard.
> >You carefully cut the dragonfly hard with the halbard.
> >You accurately wound the dragonfly lightly with the halbard.
>

> Begins to all look like spam after a while :(

That's a problem. Right now I'm faced with the really nasty
problem that my combat granularity is small enough to significantly
restrict what I can make combat messages say. I don't know how
it will end up yet...

> >This system merely pretends to take into account the player's strength,
> >dexterity, and weapon skill.
>

> And you like this?? Once again, why not just randomize all the messages?

Yech. Lack of information is one thing, but IMO, misinformation
should only be given if the player scores really bad on a lore-
related skill. Since I'm not explicitly listing 'damroll' or a
similar stat, I want the players to enter combat and see some
_real_ information that they're doing better if their strength
gets boosted. I want the information to be fairly accurate, and
granular enough to show moderate differences in combat ability.

> >Levels and XP are abstract, but many people seems to have forgotten that
> >the XP system
> >was designed to represent some sum of a character's skills. Now that we
> >are actually
> >interested in keeping track of the individual skills we should only use
> >XP and levels as
> >an abstraction of the skills of the character. So player A may be a
> >higher level than
> >player B, but B might be much stronger than A. It is rare to find this
> >kind of thing on an
>

> If XP and levels are an abstraction of skills, and skills are power, why
> should someone with less XP and levels be stronger?

My current plan (plan, level/skill advancement is a week or two away
on my lib so far) is to have skills determine most of power and
level have more meaning to 'respect' and the maxima of hp/sp/endurance.

(As far as respect because in addition to alignment I'm having
a 'reputation' attribute, which is stored in relation to each
area - a high level would give one a bonus to reputation, walking
in and killing the king of a castle would give you a really
shoddy reputation.)

Also, it would be possible for someone to sit around and do nothing
but gain skill points and have really high skills and still be a 1st
level character -- may even be able to step on a few higher levels
because of the high skill.

I would make XP/level based solely on skill advancement, but
currently one can advance skills by sitting with a trainer, and
one has to do something (at least mildly) dangerous to get XP.
But that goes into a whole other mud-design thread...

> >XP based mud because skills tend to be limited by the character level,
> >which IMNSHO is a really fucked up way to design a game.
>

> I'm waiting to see your alternative....

Me too.

> >A question:
> >
> >Should combat ever last longer than 10 rounds?
>

> Why not? If both are good at defense, I would say that they would clash
> swords a great many times.

For my system, combat lasting longer than 10 rounds is a bit of
a necessary evil. For a few reasons:

1) I don't want combat to be too short for balance and interest.
2) Since I'm doing a limb-based system, I don't want the players'
death rate increased too much because the orc got a single lucky
hit to the head. Two moderately lucky hits to the head a kill,
yes, but since I'm making death a generally very nasty
proposition, I don't want low-mid level creatures (in comparison
to the player fighting it) to be able to kill players
instantly.

--
+=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-+=--=--=--=--=--=--=--=-+
|Do you ever get the feeling that the story's|D.B. Brown |
|too damned real and in the present tense? |da...@bme1.image.uky.edu|
| -Ian Anderson | "..." |
+=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-+=--=--=--=--=--=--=--=-+

[D. B. Brown]

Chris Lawrence (Contra) wrote:
> : Anyway, I want death to be a frightening prospect, without
> : permanently harming the character -- i.e., if the character dies,
> : there should always be some way to regain what was lost.
>
> Why? Why not have death be permanent, and just delete the character?

Because most players don't like that.

Because death is going to be relatively easy to come by.

Because I want to have some form of playerkilling - and permanent
death tends to snuff that out.

[Chris Lawrence (Contra)]

mor...@niuhep.physics.niu.edu wrote:

: claw...@cup.hp.com (Chris Lawrence (Contra)) writes:
: >Ben Greear (gre...@sandstone.cs.uga.edu) wrote:

: >: This is fine, but how is the server to compare player x to player y?

: >Why would you want to compare them? There's no real need other than mental
: >bubblegum to make players feel better.

: Yes, and what is wrong with that?

Nothing, if you want to be a vendor of mental bubblegum. I don't.

: It is only a game.

: Many players want a relatively easy system for seeing whose is bigger.
: Unless it seriously compromises the mud I say give it to them.

Which is why I do report some numerical stats, but those stats are not on
any absolute scale, but are instead on a per-character private scale which
is composed of that character's experience in the field. Thus the strength
stat is reported (effectively) as a weighted value calculated from the
player's own strength, the perceived strength of others he has seen (ie
they did something requiring significant strength), and a fading memory for
extremes (very low or very high). It gives the chump a number to feel
happy about and which he can use to semi-measure his own progress. but it
is meaningless for comparison with others. Bubba's strenght of 50 (as
reported to Bubba) has little relation to Boffo's similar strength of 55
(as reported to Boffo).

It also makes for amusing side-effects:

> score
...
Strength: 98
...
> l
Boffo does something requiring incredible strength.
> score
...
Strength: 43

That extreme then fades with time, allowing his strength stat to gradually
return towards 98 as the memory "fades".

[Ben Greear]

In article <337E3D...@ucla.edu>,
Brandon J. Rickman <ashes...@ucla.edu> wrote:

>Ben Greear wrote:
>>
>> In article <Pine.SOL.3.95.970516...@mail.bcpl.lib.md.us>,
>> Broly <br...@mail.bcpl.lib.md.us> wrote:
>> >On 15 May 1997, Ben Greear wrote:

>> Still, you are using numbers to determine how hard the player hit. IRL
>> we can get numeric values for most of our attributes. Other things, like
>> experience, we still have an intuition for. This intuition is impossible
>> in a text setting (hell, any out of body setting). There needs to be
>> some way to relay this information to the player, and numbers seem to be
>> the best way to me. You COULD translate the numbers to words, as in your
>> troll example, but that is all you are doing, the concept remains the same.
>
>How tall are you? Are you X' Y" tall because that is what your license
>says?

[snip about can't compare x to y w/out context, or something]

>than the global. And aren't muds all about context anyway?

>relative comparison with other races that quantity is meaningless.) So

>the idea of
>being able to compare your stats with _all the other players_ is A BUNCH
>OF MEANINGLESS CRAP.

Yess, you typed it in all caps, but I can't find your argument. If you

are a dwarf, and your STR is 18, and I'm a pixie with a STR of 4, why
can't I compare them? Do you believe that a pixie should be able to
defeat a dwarf in hand-to-hand battle?? I don't, I think pixies aughta
stay up in the trees, out of the way of big mean dwarves, which, if they
could catch them, could sure rip them in two!

>If you don't have the energy to make your mud interesting by providing

>accurate and
>informative descriptions to a fire-ball spell then I would say you are
>not only lazy, you are a bad designer.

Well, I am not just coding spells, I have written the whole (yes whole)

thing. I think that writing interesting mob AI code, and other, more
interesting spells is a much better use of my time.

Since you obviously are not as lazy as I, and are a better designer, I

have a question. First of all, have you written spells like this. If so,
how many lines of code? I could come up with the descriptions
mechanically, but that begins to look predictably lame after the first
couple of spells. So you check the damage and then go through a big ole
switch statement? Any fool could do this, but it takes a great deal of
time, and is quite tedious IMHO.

>I'm not really flaming you,

Glad to hear it :P

> but I think it is very important that we come up with
>a way to create meaningful descriptions that compensate for lazy builders.

I'll predict that you'll never mechanically create any description close

to as good as I can write. Sure mine is static, but it flows, and sounds
nice. Also, there is a difference between lazy builders, and builders
who produce only a small amount of work, if it's quality.

>

>The "damage continuum" approach doesn't seem to be very satisfying:

I thought you wanted me to add a continuim to my fire-ball spell..

>Verbs tend to be overloaded with meaning. (You POKE the bread mold?

Cheezy ones for sure..

>And an experienced player can almost always decipher that "sting" means
>"5-8 HP".

If you don't want the player to know how hard they hit, why tell them at

all? Just do the messages based on a random number or the hour of the day!

>You [damage adverb] [damage verb] <target> [qualifier] with <weapon>.

So how do you generate the adverbs, as it seems you calculate damage FROM
the adverbs.

>So now we have

>You clumsily stab the dragonfly very hard with the halbard.
>You carefully cut the dragonfly hard with the halbard.
>You accurately wound the dragonfly lightly with the halbard.

Begins to all look like spam after a while :(

>This system merely pretends to take into account the player's strength,
>dexterity, and weapon skill.

And you like this?? Once again, why not just randomize all the messages?

>> Its true that 'level's are abstract, but after all, we hope to inhabbit a

>> world of numbers and letters...abstraction is necessary.
>
>Levels and XP are abstract, but many people seems to have forgotten that
>the XP system
>was designed to represent some sum of a character's skills. Now that we
>are actually
>interested in keeping track of the individual skills we should only use
>XP and levels as
>an abstraction of the skills of the character. So player A may be a
>higher level than
>player B, but B might be much stronger than A. It is rare to find this
>kind of thing on an

If XP and levels are an abstraction of skills, and skills are power, why

should someone with less XP and levels be stronger?

>XP based mud because skills tend to be limited by the character level,

>which IMNSHO is a really fucked up way to design a game.

I'm waiting to see your alternative....

>People write these mindless scripts because the normal way of increasing

>skills (i.e. combat)
>is just as mindless. By not allowing players to practice skills
>mindlessly, you are refusing
>to allow players to _master the skills they think are important_. If a
>master
>fireballer is going to unbalance your game then your game sucks. Adding
>spell components only fixes the problem as it relates to spells,
>someone practicing archery on a bale of hay is never going
>to "run out of components". But master archers and master fireballers
>both tend to be very
>bad at avoiding getting hit by Ogres wielding very large and brutal
>fists.

There is no inherent reason for this to be so.

> Can you
>write a script that practices dodging?

Of course, as easy as mindless battle and mindless fire-balling.

BTW, are you supporting mindless scripts as a method of increasing power??

>

>A question:
>
>Should combat ever last longer than 10 rounds?

Why not? If both are good at defense, I would say that they would clash

swords a great many times.

>
>

>I have a feeling that this text is formatted poorly.

You are correct.

>
>- Brandon

Ben

[Martin Keegan]

Chris Lawrence (Contra) wrote:

> Why? Why not have death be permanent, and just delete the character?

In player-gratification-muds this isn't possible. :)

[Orion Henry]

In article <01bc6263$03b66260$ec3b...@jlsysinc.ix.netcom.com> "Jon A. Lambert" <jlsy...@ix.netcom.com> writes:
>> > Show me any system for character advancement and I'll show you're really
>> > using XPs.

Show me a system with XP and I'll show you cheesy,
over-simplified, excuse for a character advancement system. :)

Orion

[Martin Keegan]

Martin Keegan wrote:

> I told one of them "OK, I'm going to take this to it's logical

God, its contagious!

[Martin Keegan]

Martin Keegan wrote:

> If everyone had this attitude, then no mud would have any challenge
> in at all, because it would be too difficult. If they want something

by "too difficult", I mean "too difficult to impose if you did
only what the players wanted". Some players once asked me to move
some spells from (can't remember the exact numbers) level 8 to
level 7, and others up from level 6 to level 7 and so on.
I contended that when they were level 8 they'd insist on moving
level 7 spells to level 8 and level 9 spells to level 8 as well -
ie, moving higher level powers down to their level, and restricting
everything below, and moreover changing their opinion of which
level powrs should be moved towards depending on which level they
actually were.

I told one of them "OK, I'm going to take this to it's logical

conclusion, and make you an archwizard. Is that what you want?"

"Wow! Yes!"

"There's a catch - EVERY PLAYER also gets to be an arch, even
newbies. Do you still want this"

He didn't. I thought this was really interesting :)

[Anthony C.]

In article <01bc6503$7651a260$3e15...@ashes.ppp.oxy.edu>,

Brandon J. Rickman <ashes...@ucla.edu> wrote:

>Ben Greear <gre...@pollux.cs.uga.edu> wrote in article
:If a really strong pixie has a strength of 4, and a really wimpy pixie has

:a strength of 2 then, um, average pixies have a strength of 3. So pixie
:Alpha and pixie Beta are both very strong (4 STR). But maybe Alpha is just
:a little stronger? Hm, maybe Alpha should get a 5.

The solution to this is to increase the granularity. Make stats
out of 1000 or out of 100, if you want you can set racial mins and
maxes.
:
:Along comes pixie Gamma. She is stronger than Beta, but not as strong as

:Alpha. Tell you what, let Alpha have 6 STR and Gamma can have a 5.
:
:One day, Alpha decides to leave his gumdrop tree and go exploring. He
>encounters Motch the Very Wimpy Dwarf (STR 6). A battle ensues. Alpha and
:Motch are of equal strength (I assume this is clear from the above, please
:feel free to reread this at your leisure until you understand it fully),
:but since Dwarves are always stronger than Pixies, Motch will win.

The paradox is that you have said Dwarves are always stronger than
pixies, but then in your numerical system dont enforce this. It is not
impossible, and in fact quite easy to do it.

:Something is funny here. Either the Dwarf/Pixie case is a rather unusual

:exception to the rules, or the premise of _directly_ comparing stats is a
:bad idea.

Or your rules are not consistent.

>> >If you don't have the energy to make your mud interesting by providing

--
Anthony Chen
Interactive Games Network
http://ign.cy-net.net

[Alberto BARSELLA]

In article <5lq718$o9j$3...@hpax.cup.hp.com> claw...@cup.hp.com (Chris Lawrence (Contra)) writes:
>
> Why? Why not have death be permanent, and just delete the character?

You've never been killed by lag, eh? :)
Or by a router going down.....

The situation is simple: I play to have fun. If every time I (or the
connection) screw up I have to restart with a char with no skills, no
abilities, no anything, then I'll not play bacause it will be boring,
not fun.

Alberto
--
Alberto BARSELLA
PGP fingerprint = 13 3F 22 D2 0B 0A D3 25 F1 89 FE B5 82 AD 75 2A

[Alberto BARSELLA]

In article <338180...@cam.sri.com> Martin Keegan <mar...@cam.sri.com> writes:

> In player-gratification-muds this isn't possible. :)

Do you mean that games should not give gratification?
If I want stress I already have a RL life for that, I don't need a mud
server :)

[Ben Greear]

In article <3382CA...@cam.sri.com>,
Martin Keegan <mar...@cam.sri.com> wrote:
>I beg to differ (*). However, I'll grant that a good middle road would
>be for the players to have a limited number of lives (say 10). After
>the tenth death, the character gets deleted.

I've an idea I've been kicking around... I hve a 'skin' command which
skins a player. Everytime you are skinned, you lose one CON stat. If
you can get your skin back and wear it, then you get your CON back.

Now, the fun part is that if you die, and your natural CON (ie minus all
spells and or EQ) is 0 or less, then you are permanently dead.

I think this could lead to some interesting conflicts I think!

> >Mk

[Martin Keegan]

D. B. Brown wrote:

> > Why? Why not have death be permanent, and just delete the character?
>

> Because most players don't like that.

If everyone had this attitude, then no mud would have any challenge

in at all, because it would be too difficult. If they want something

other than challenge (and I'm by no means criticising this) they
should be playing muds like TinyMUDs where there is no death, and
where the objective is building.

> Because I want to have some form of playerkilling - and permanent
> death tends to snuff that out.

I beg to differ (*). However, I'll grant that a good middle road would

be for the players to have a limited number of lives (say 10). After
the tenth death, the character gets deleted.

Mk

(*) This is Keeganish for "bollocks!"

[Chris Lawrence (Contra)]

D. B. Brown (da...@bme1.image.uky.edu) wrote:

: Chris Lawrence (Contra) wrote:

: > Why? Why not have death be permanent, and just delete the character?

: Because most players don't like that.

A sad shame.

: Because death is going to be relatively easy to come by.

As it was on SX MUD, MUD1 and MUD2.

: Because I want to have some form of playerkilling - and permanent

: death tends to snuff that out.

And the permanent death feature of PK was counted one of the better
features of SX MUD and MUD2.

[Martin Keegan]

George Reese wrote:
>
> I just have to keep iterating this, not because I think Nightmare is
> unique, but because people seem so bent on saying things do not exist
> which do in fact exist.

Tell me about it. Someone tried to tell me that Tiny was the first
mud with "building" a few weeks ago.

> Nightmare has permanent death. I know other muds do.

I'll admit I thought that any mud where death was a possibility would
have permanent death, and was quite surprised to find out otherwise.
Is it getting politically impossible to implement anything in a mud
which makes it more difficult for the players?

Mk

[Martin Keegan]

Miroslav Silovic wrote:

> > > In player-gratification-muds this isn't possible. :)
> >
> > Do you mean that games should not give gratification?
> > If I want stress I already have a RL life for that, I don't need a mud
> > server :)
>

> He refered to the sort of gratification that typically appeals to
> twelve-year-olds. Along with Van-Damme movies, for that matter.

By "player-gratification-muds", I meant muds where doing anything
which would upset the players (like making them lose levels for being
killed) is no longer possible. Obviously I didn't mean what Ishark
was implying.