Attributes

6 views
Skip to first unread message

Radomir 'The Sheep' Dopieralski

unread,
Oct 26, 2005, 7:33:15 AM10/26/05
to

I was always wondering why most computer rpg games use so
strange and not-meaningful names for the characters stats.

You usuallu have something like the usual set:
str, dex, int, etc.

And then, somewhere in the game logic, and probably in your
manual if you care enough to write one, you'll have something
like this:

sword combat = 50% str + 50% dex
mace combat = 90% str + 10% dex
polearm combat = 60% str + 30% dex + 10% con
find trap = 80% int + 20% dex
disarm trap = 80% dex + 20 int
evasion = 80% dex + 20% ac
etc.

Wat is the reason for all this? Woudn't it be much more convenient to
use the 'attributes' (following the Angband terminology) directly,
without the need for stats at all? You woudn't have to explain their
meaning, and you woudn't have to use complicated formulas in the game
logic code. What would you lose?

I can thing od two reasons for using such stats.

The first one is direct inheritance from a p&p rpg, where the stats have
to be vague, because the Game Master has to use them for variety of
situations.
Computer games ar edifferent. There's no way computer can use a stat in
a situation that wans't predefined.


The other reason might be related to character evolution. You might want
to allow the player to allocate experience points (or something similar)
directly to the stats, so it makes his character stronger, more
intelligent or anything.
But why should you store those choices, when they are used only once and
only on level up, and calculate all the attributes in all the places where
the stats are actually used? Why don't you present the player with choices
to make his character stronger, more intelligent, more dexterous, etc.,
and then modify and store the attributes -- as values that can be used
directly?


--
Radomir `The Sheep' Dopieralski @**@_
(==) 3 Yawn?
. . . ..v.vVvVVvVvv.v.. .

Max Bolingbroke

unread,
Oct 26, 2005, 8:24:59 AM10/26/05
to
Radomir 'The Sheep' Dopieralski wrote:
> But why should you store those choices, when they are used only once and
> only on level up, and calculate all the attributes in all the places where
> the stats are actually used? Why don't you present the player with choices
> to make his character stronger, more intelligent, more dexterous, etc.,
> and then modify and store the attributes -- as values that can be used
> directly?
>

Is it not about the difference between intrinsics and experience? For
instance, if I go weightlifting my muscles will get larger, so both my
mace combat and sword combat should get better. However, if I practice
my parries they will only be applicable to my sword combat. ADOM models
this with a combination of stats and weapon "marks", which seems to work
pretty nicely. I'm sure you know the mechanism, but for anyone who
dosen't, the marks increase through use of the particular weapon type
and the more general attributes are trained passively (in general, there
are other, special ways to do this), such as by carrying around heavy
loads, (thus improving strength).

However, I can certainly see the attraction of modelling attributes as
you have described. I'm currently puzzling over this issue myself in my
own permanently unfinished RL, so this thread should prove interesting..

Max

Radomir 'The Sheep' Dopieralski

unread,
Oct 26, 2005, 8:39:34 AM10/26/05
to
At Wed, 26 Oct 2005 13:24:59 +0100,
Max Bolingbroke wrote:

> Radomir 'The Sheep' Dopieralski wrote:
>> But why should you store those choices, when they are used only once and
>> only on level up, and calculate all the attributes in all the places where
>> the stats are actually used? Why don't you present the player with choices
>> to make his character stronger, more intelligent, more dexterous, etc.,
>> and then modify and store the attributes -- as values that can be used
>> directly?
>>
>
> Is it not about the difference between intrinsics and experience? For
> instance, if I go weightlifting my muscles will get larger, so both my
> mace combat and sword combat should get better. However, if I practice
> my parries they will only be applicable to my sword combat. ADOM models
> this with a combination of stats and weapon "marks", which seems to work
> pretty nicely. I'm sure you know the mechanism, but for anyone who
> dosen't, the marks increase through use of the particular weapon type
> and the more general attributes are trained passively (in general, there
> are other, special ways to do this), such as by carrying around heavy
> loads, (thus improving strength).

Still can't see a need for the str stat.

When you gain enough marks, your 'sword combat' attribute is increased.
When you gain physical strength, your 'sword combat' attribute is
increased along with all other attributes that are related to strength.

This way you keep all the information about gaining levels in one place
-- the level gain code.

--
Radomir `The Sheep' Dopieralski @**@_

(Uu) 3 Sigh!

Max Bolingbroke

unread,
Oct 26, 2005, 9:04:14 AM10/26/05
to

That would be nice. However, what about if you take temporary stat loss
such as weakness (strength loss) such a vampires bite? That would mean
you would have to decrement all the related attributes by a certain
amount and add them back on when the temporary effect ends. An
alternative solution would be masking the attributes with e.g.
RealSwordCombat and SwordCombat, with only SwordCombat taking the
temporary drop, but this is functionally equivalent.

This seems to lead to this sort of logic being spread over the code.
Compare that to a situation where change a base strength value and the
attributes themselves are recaculated when accessed: seems a little
neater to me.

Max

Radomir 'The Sheep' Dopieralski

unread,
Oct 26, 2005, 9:38:16 AM10/26/05
to
At Wed, 26 Oct 2005 14:04:14 +0100,
Max Bolingbroke wrote:

> Radomir 'The Sheep' Dopieralski wrote:
>> Still can't see a need for the str stat.
>>
>> When you gain enough marks, your 'sword combat' attribute is increased.
>> When you gain physical strength, your 'sword combat' attribute is
>> increased along with all other attributes that are related to strength.
>>
>> This way you keep all the information about gaining levels in one place
>> -- the level gain code.
>
> That would be nice. However, what about if you take temporary stat loss
> such as weakness (strength loss) such a vampires bite?

Obviously you can't have stat loss when you've got no stat, right?

> That would mean
> you would have to decrement all the related attributes by a certain
> amount and add them back on when the temporary effect ends. An
> alternative solution would be masking the attributes with e.g.
> RealSwordCombat and SwordCombat, with only SwordCombat taking the
> temporary drop, but this is functionally equivalent.

An equivalent of such a "stat loss effect" would be an easier to
understand and more straightforward "weaken effect". It would be probably
implemented using some kind of counters, for the duration and for
the amount of weakening, or maybe as a status change?

You can put the logic in two places (but you better make up your mind
ond choose one). First, you can put it all in the code for the effect.
That is, the effect is responsible for lowering the attributes when
it kicks in, and of rising them back again when it stops.
It's up to the effect to decide what attributes to affect and how much.
For example, "sticky substance" and "make clumsy" would both reduce dex,
but the former one would have no effect on disarming traps...

Second, you can make the effect a "core" one, and make all the game code
depend on it. You need this if you want effects other than just changing
your attributes, like "confusion" that affects your actions, not only
reduces your int, or "blindness" that prevents you from reading scrolls,
not only reduces your light radius.

> This seems to lead to this sort of logic being spread over the code.
> Compare that to a situation where change a base strength value and the
> attributes themselves are recaculated when accessed: seems a little
> neater to me.

Unless you use the str for calculating, say, the response modifier
for NPC looking for a strong warrior -- in which case you need a special
case to ignore the magical stat loss, but not the physical.

--
Radomir `The Sheep' Dopieralski @**@_

(==) 3 Yawn?

konijn_

unread,
Oct 26, 2005, 10:05:50 AM10/26/05
to
>Still can't see a need for the str stat.

>When you gain enough marks, your 'sword combat' attribute is increased.
>When you gain physical strength, your 'sword combat' attribute is
>increased along with all other attributes that are related to strength.

In my dream rogue system, sword combat indicates how good you are at
sword combat, strength indicates ( among other things ) how effective
you are at sword combat.

This means that a stone troll that is master in sword combat will
easily pulverize a human master in sword combat. It is a combination of
learned skill and intrinsics.

If you do not allow for stats, you end up with bizar situations. That
is what testing rules with some real life players tought me.

T.

Radomir 'The Sheep' Dopieralski

unread,
Oct 26, 2005, 11:13:17 AM10/26/05
to
At 26 Oct 2005 07:05:50 -0700,
konijn_ wrote:

>>Still can't see a need for the str stat.
>
>>When you gain enough marks, your 'sword combat' attribute is increased.
>>When you gain physical strength, your 'sword combat' attribute is
>>increased along with all other attributes that are related to strength.

> In my dream rogue system, sword combat indicates how good you are at
> sword combat, strength indicates ( among other things ) how effective
> you are at sword combat.

Ok, why not.
I mean: Why should you introduce stats and then derieve the attributes
from them (or just use the stats raw in the formula, which amount to the
same thing), when you're not using the stat for anything else.
Why won't we use a set of variables that fit better to the actual
mechanics we are using?

The "stat loss" example above not very good, as it's a case that
could actually justify introducing stats -- one variable to easily
modify all the derived values. But you must remember that at the same
time you're making the derieved values harder to modify and mantain.
How often will you use the derieved values? How often will there be
a stat loss? Which one of them you want implemented more clearly?

> This means that a stone troll that is master in sword combat will
> easily pulverize a human master in sword combat. It is a combination of
> learned skill and intrinsics.

Ok, so with the stats and abilities, you've got something like this:

Human (5 (str) + 10 (sword combat)) vs. Troll (10 (str) + 10 (sword combat))

and with abilities only, you've got it like this:

Human (15 (sword combat)) vs. Troll (20 (sword combat))

In the latter case, the ability already takes into accunt troll's greater
strength. And less numbers means simplier mechanics means easir balancing.

> If you do not allow for stats, you end up with bizar situations. That
> is what testing rules with some real life players tought me.

Can you provide some examples of such "bizare" situations? (I'm curious).
Besides, you get bizare situation with stats too. It's something you've
got to get used to ;).


--
Radomir `The Sheep' Dopieralski @**@_

(@a) 3 Be?

Jeff Lait

unread,
Oct 26, 2005, 12:57:40 PM10/26/05
to
Radomir 'The Sheep' Dopieralski wrote:
> I was always wondering why most computer rpg games use so
> strange and not-meaningful names for the characters stats.

People are under the mistaken belief that a "more complicated" system
is a "more fun" system. Stats make an excellent point to layer lots of
useless complications and formulas. By having enough tables of
meaningless numbers, it will become impossible to figure out what will
happen in an attack roll, so the author will conclude it must be
"balanced".

I'd point as a counter example You Only Live Once's combat system,
which is about as simple as you can get, but is still fun. In that
system, any attack will always hit and always do full damage. All the
crazy complexity people add on top of that is just random variable.

> Wat is the reason for all this? Woudn't it be much more convenient to
> use the 'attributes' (following the Angband terminology) directly,
> without the need for stats at all? You woudn't have to explain their
> meaning, and you woudn't have to use complicated formulas in the game
> logic code. What would you lose?

I recall going at length about this in the past. My argument was there
was no need for any statistic that doesn't have a unit of measurement
in a Roguelike.

Ah, here it is. "Why Stats Are Harmful"
http://groups.google.com/group/rec.games.roguelike.development/msg/33eaa49a18b00255?hl=en&
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)

David Damerell

unread,
Oct 26, 2005, 1:19:13 PM10/26/05
to
Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>The "stat loss" example above not very good, as it's a case that
>could actually justify introducing stats -- one variable to easily
>modify all the derived values. But you must remember that at the same
>time you're making the derieved values harder to modify and mantain.

Not in the least. In the traditional approach when you change the
character's strength you either recalculate all the derived values or
simply have functions that calculate them on the fly as needed. In your
approach when something changes the character's strength you also end up
doing something to all the derived values.

One serious problem with your approach is that it's hard to implement
sensible maxima and minima. If the only value you have for, say,
spellcasting is a derived value that encompasses intelligence and
spellcasting ability, how do you model the hero who might be quite
intelligent but simply doesn't possess the skill yet? With zero? Then what
does gaining the skill increase the value to - the same as for a stupid
hero because you don't have any inherent value for his intelligence, even
though his values for other brain-based skills are high?

If you don't know what proportion of a character's fighting skills are
strength/dexterity and which are skill, you have the interesting situation
where an attack that drains physical strength can reduce some skills to
nothing but there's still more capacity to drain another skill. This could
get actively ridiculous - imagine a character who, by training his
ability, has a monstrous skill value in two-handed sword. After being
drained of physical strength - well, it turns out he's too weak to use his
dagger, but he can still use the two-handed sword!
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is Tuesday, October.

wild.h...@gmail.com

unread,
Oct 26, 2005, 2:46:11 PM10/26/05
to

David Damerell wrote:
> Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
> >The "stat loss" example above not very good, as it's a case that
> >could actually justify introducing stats -- one variable to easily
> >modify all the derived values. But you must remember that at the same
> >time you're making the derieved values harder to modify and mantain.
>
> Not in the least. In the traditional approach when you change the
> character's strength you either recalculate all the derived values or
> simply have functions that calculate them on the fly as needed. In your
> approach when something changes the character's strength you also end up
> doing something to all the derived values.
>
> One serious problem with your approach is that it's hard to implement
> sensible maxima and minima. If the only value you have for, say,
> spellcasting is a derived value that encompasses intelligence and
> spellcasting ability, how do you model the hero who might be quite
> intelligent but simply doesn't possess the skill yet? With zero? Then what
> does gaining the skill increase the value to - the same as for a stupid
> hero because you don't have any inherent value for his intelligence, even
> though his values for other brain-based skills are high?

The ability to learn similar skills should be proportional, or
otherwise related to, the related skills. I think you bring up a valid
point - the system seems to lend credance towards having an
"intelligence" stat, but I also agree with the general statement that
all stats are not the same. I frequently care little for my Charisma
stat, and really, charisma should come cheaper than other stats.
Intelligence doesn't need to be on the same scale as strength, which
isn't terribly similar to dexterity. Ive never been a fan of the D&D
stat system.

> If you don't know what proportion of a character's fighting skills are
> strength/dexterity and which are skill, you have the interesting situation
> where an attack that drains physical strength can reduce some skills to
> nothing but there's still more capacity to drain another skill. This could
> get actively ridiculous - imagine a character who, by training his
> ability, has a monstrous skill value in two-handed sword. After being
> drained of physical strength - well, it turns out he's too weak to use his
> dagger, but he can still use the two-handed sword!

Not necessarily. The ability to wield a dagger has almost no dependence
on physical strength, while a large part of wielding a two-handed sword
is strength. It would consider the situation you described as a poorly
designed system, but merely not having a strength stat doesn't have to
make it that way.

Radomir 'The Sheep' Dopieralski

unread,
Oct 26, 2005, 2:48:20 PM10/26/05
to
At 26 Oct 2005 18:19:13 +0100 (BST),
David Damerell wrote:

> Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>>The "stat loss" example above not very good, as it's a case that
>>could actually justify introducing stats -- one variable to easily
>>modify all the derived values. But you must remember that at the same
>>time you're making the derieved values harder to modify and mantain.

> Not in the least. In the traditional approach when you change the
> character's strength you either recalculate all the derived values or
> simply have functions that calculate them on the fly as needed.

...scattered all around your sources.

> In your
> approach when something changes the character's strength you also end up
> doing something to all the derived values.

...if you want to model exactly the same beghavior as with stats.
Note that as long as you're using term "character's strength", you're
basically talking about his stat. It goes without saying that stats are
best modelled using, well, stats.

> One serious problem with your approach is that it's hard to implement
> sensible maxima and minima.

... of stats.

> If the only value you have for, say,
> spellcasting is a derived value that encompasses intelligence and
> spellcasting ability, how do you model the hero who might be quite
> intelligent but simply doesn't possess the skill yet? With zero?

If I need to know how intelligent the character is, I simply use
a variable (stat) for it. My point is that you don't always need
to know it.

> Then what
> does gaining the skill increase the value to - the same as for a stupid
> hero because you don't have any inherent value for his intelligence, even
> though his values for other brain-based skills are high?

I'd set the value on appropriate level for the character when it gains the
ability to cast spells. Sure, if the rules say it depends on intelligence,
then I'd need the intelligence recorded somehow.

> If you don't know what proportion of a character's fighting skills are
> strength/dexterity and which are skill, you have the interesting situation
> where an attack that drains physical strength

...which is a stat...


>can reduce some skills to
> nothing but there's still more capacity to drain another skill. This could
> get actively ridiculous - imagine a character who, by training his
> ability, has a monstrous skill value in two-handed sword. After being
> drained of physical strength - well, it turns out he's too weak to use his
> dagger, but he can still use the two-handed sword!

If you want to drain strength -- you must record strength as some
variable. Note that it still doesn't need to be a stat that everything
else depends on. But it's convenient to use normal stats in this case.

I fell like I'm talking about planes as alternate means of travel to a car
driver, and then he responds: "Right, but where's the honker? There's no
honker? Then what am I supposed to do in a traffic jam? Whistle?".

--
Radomir `The Sheep' Dopieralski @**@_

(Qq) 3 Sob?

Radomir 'The Sheep' Dopieralski

unread,
Oct 26, 2005, 2:58:31 PM10/26/05
to
At 26 Oct 2005 18:19:13 +0100 (BST),
David Damerell wrote:

Imagine similarily ridiculous situation:
The character is strong alright, but because of he meet a "master fencer"
monster, that used "finger chopping" attack on him, he cannot wield any
weapon -- thus his weapon-related skills are zeroed.

But he can still wield a dagger, because of his exception strength.
(he probably grabs it with his enormusly muscular hair on his hands)

You can make up any number of ridiculous situations with any system.

--
Radomir `The Sheep' Dopieralski @**@_

(`') 3 Grrr!

Radomir 'The Sheep' Dopieralski

unread,
Oct 26, 2005, 2:59:44 PM10/26/05
to
At 26 Oct 2005 09:57:40 -0700,
Jeff Lait wrote:

Right! I knew it's too good to be mine.
But at least there's some sort of discussion going on that maybe
will have some sort of interesting results. Sort of.

--
Radomir `The Sheep' Dopieralski @**@_

(nn) 3 Grin

Björn Bergström

unread,
Oct 27, 2005, 2:16:01 AM10/27/05
to
Jeff Lait wrote:
> Radomir 'The Sheep' Dopieralski wrote:
>> I was always wondering why most computer rpg games use so
>> strange and not-meaningful names for the characters stats.
>
> People are under the mistaken belief that a "more complicated" system
> is a "more fun" system. Stats make an excellent point to layer lots of
> useless complications and formulas. By having enough tables of
> meaningless numbers, it will become impossible to figure out what will
> happen in an attack roll, so the author will conclude it must be
> "balanced".
>
> I'd point as a counter example You Only Live Once's combat system,
> which is about as simple as you can get, but is still fun. In that
> system, any attack will always hit and always do full damage. All the
> crazy complexity people add on top of that is just random variable.

Dweller might not simplify things as much as You Only Live Once, but
still, the system is quite simple at least:

Each monster/player/item in the game has the stats Attack, Defence,
Magic and Speed. Each item that the player equips adds it's stats to the
players stats. If the player has Attack 11 and Defence 11 and equips a
Short Sword (att 3 and def 2) he gets an Attack value of 14 and a
Defence value of 13. Simple.

Combat is really easy: Generate a random number between 0 and the
attackers Attack value. This determines how good the attack was.
Generate a random number between 0 and the defenders Defence. This
determines how successful the defender was defending himself. If the
attackers value is higher than the defenders, it is a hit, otherwise a
miss. The amount of damage dealt is determined by the difference between
the two generated values.

This works really well and it is not overly complex.

>> Wat is the reason for all this? Woudn't it be much more convenient to
>> use the 'attributes' (following the Angband terminology) directly,
>> without the need for stats at all? You woudn't have to explain their
>> meaning, and you woudn't have to use complicated formulas in the game
>> logic code. What would you lose?
>
> I recall going at length about this in the past. My argument was there
> was no need for any statistic that doesn't have a unit of measurement
> in a Roguelike.
>
> Ah, here it is. "Why Stats Are Harmful"
> http://groups.google.com/group/rec.games.roguelike.development/msg/33eaa49a18b00255?hl=en&

Yes, this was a really good post! :-)

BR,
Björn

Brendan Guild

unread,
Oct 27, 2005, 2:32:28 AM10/27/05
to
Radomir 'The Sheep' Dopieralski wrote in
news:slrndlv78d....@atos.wmid.amu.edu.pl:

> I mean: Why should you introduce stats and then derieve the
> attributes from them (or just use the stats raw in the formula, which
> amount to the same thing), when you're not using the stat for
> anything else. Why won't we use a set of variables that fit better to
> the actual mechanics we are using?

It's probably because the stats fit well with a kind of simulation of
reality. We imagine the world of magic and monsters with images of
heros interacting with them, so we try to describe that in stats. Then,
as we are developing our games, when we inevitably find some great
effect that we can inflict upon the poor PC, we are less likely to
groan and discover that we have simplified the game to the extent that
it is impossible to implement this effect idea without a major rewrite.
The danger comes from the fact that we probably came up with the idea
based on the epic fantasy in our heads instead of the actual mechanics
we are using.

So plan to include a stat for strength, because even if your game
doesn't require it now, you could want it in the future. It seems that
stats and attributes are the things that are the most controversial and
quick to change in any roguelike.

> The "stat loss" example above not very good, as it's a case that
> could actually justify introducing stats -- one variable to easily
> modify all the derived values. But you must remember that at the same
> time you're making the derieved values harder to modify and mantain.
> How often will you use the derieved values? How often will there be
> a stat loss? Which one of them you want implemented more clearly?

Since stats, derived values, and attributes of all kinds are the most
volatile part of a game, one should be sure to make them maintainable
to a degree far beyond any other part of one's code. Specifically,
you've got attributes and then you've got the rest of your game and a
grand canyon of decoupling between them.

Of course, you'll need access to attributes to control game events,
like combat, but they should all be derived. There is no need to let
any other part of your game know where attributes come from, they
should just magically appear from behind the scenes. Plus, each part of
your game should use a different attribute and no two bits of code
should use the same attribute unless they are very strongly connected.
If your combat-ability-with-a-sword-against-a-green-dragon happens to
be the same as your combat-ability-with-a-sword-against-a-blue-dragon,
then let those attributes just magically have the same value. Don't
merge them into one because you don't think you'll ever need them to be
different.

For example, there are 4 major areas of attribute management that
should be kept strictly separate: The attributes that the player sees,
the attributes that are stored in memory, the attributes that are read
from data files, the attributes that are used by your game mechanisms.

There is no need for these groups of attributes to be connected. So if
in balancing the game we find that the 'strength' attribute that we are
storing in memory should be slightly different from the 'strength'
attribute that we are using for combat, then let's leave ourselves free
to make them different at any time and according to any formula. Plus,
let's leave ourselves free to totally redesign the attributes behind
the scenes without altering what the player sees.

Above all, we do not want to have to rewrite our data files just
because we are going with a new system of attributes. Let's keep firmly
in mind that a strength listing in a data file is not to be stored
directly in memory as if it were the actual strength that we will be
using. I can predict already that it won't be after a few redesigns.

The best way that I can see to achieve this is to forget about making
attributes into any kind of public members. Even accessors aren't
encapsulating enough. There is no point in creating an accessor for a
value that will only be used in one or two pieces of code outside of
the object. We should be free to have hundreds of attributes for every
creature all scattered across the code that interacts with creatures.
Naturally our game will be simple enough that the vast majority of
those attributes will have identical values, but let's expect that
someday that might change.

Instead, we need to represent each attribute as an object. We give an
attribute to a creature and it comes back with a value. Attribute
objects are not stored in creatures as a way to hold the values;
attribute objects are shared by the game and used like keys to access
values within creatures. Each object represents a category of value,
not a specific value.

This way, attributes do not need to be global the way a class is
global. If the attributes were represented as public members of the
creature class, every part of your code would see them and need to be
recompiled each time they changed. This way, only the parts of the code
with access to the attribute objects can see the attributes. Also,
attributes can have varying properties without creating a new class for
each different kind of attribute. All we need is to set the properties
on the object, such as observers, minimums, maximums, and they will
immediately be in force for everything with that attribute.

We are even free to give one attribute multiple names by simply
pointing to it from multiple places. Ability-with-sword and ability-
with-axe might be the same object now, but in the future, who knows? In
this way we can have the flexibility of limitless attributes but at no
extra cost.

We can make the UI code and the combat code seem as if they are working
with the same 'strength' attribute, but really they are working with
variables that have the same name but point to different objects. Or
perhaps they point to the same objects at first, but later in the
design we decide that they should be subtly different.

I'm going to give this a try on my roguelike and see how well it works.

ga...@dsdata.it

unread,
Oct 27, 2005, 6:13:08 AM10/27/05
to
There is a good reason for having "stats" that hasn't been mentioned
yet: orthogonality between intrinsic qualities and skills.
Different tasks can use the same skill with different stats, allowing
the rules to define a coherent model of what you are (stats), what you
know (skills) and what makes you good at each task (combinations of
appropriate stats and skills).
A very elegant task resolution system based on this principle is found
in R. Talsorian Games' Cyberpunk and Cybergeneration roleplaying games:
stats (intelligence, reflexes, luck, empathy, body, attractiveness)
increase or decrease rarely and permanently for specific reasons
(mutilation, high tech enhancements, etc.) and the many skills (e.g.
seduction, programming, shotgun, pilot helicopter, cyberdeck
engineering, swimming) increase with usage and by spending experience
awards.
All stats and skills have a normal range of 0 or 1 to 10 and all
success rolls are one stat + one skill + 1d10 vs a threshold or someone
else's roll (which can use entirely different stats and skills, it just
needs to be in the same range to work).
Tasks can use the most appropriate combination: for example weapon
skills are usually employed to fight in combination with reflexes, but
the GM can easily adlib that, for example, you can evaluate opponent
skills by looking for a while and rolling intelligence + the weapon
skill they are using, or that to shoot an awkward huge rifle you roll
the average of body and reflexes + rifle skill.
A computer game, not constrained by human memory, can list endless
defaults, special cases, derived attributes and skills, situational
modifiers, etc. and in such a framework balancing them would be very
easy: there is no power inflation (combat between strong opponents that
hit almost always becomes a matter of who shoots first or makes more
damage), task difficulty levels are fixed (5 is trivial, 15 is about
50% chance for an average character, 25 is very difficult), opposite
rolls are fair.
Of course, this system also promotes a deep separation of intrinsic and
learned qualities, and the numbers are exposed to the player as a
realistic model; there are no opaque rules interposing between the
character sheet and how effective the character is in the game.

Lorenzo Gatti

wild.h...@gmail.com

unread,
Oct 27, 2005, 9:21:07 AM10/27/05
to

ga...@dsdata.it wrote:
> There is a good reason for having "stats" that hasn't been mentioned
> yet: orthogonality between intrinsic qualities and skills.
> Different tasks can use the same skill with different stats, allowing
> the rules to define a coherent model of what you are (stats), what you
> know (skills) and what makes you good at each task (combinations of
> appropriate stats and skills).

Im not sure that this always makes sense. Some characteristics are
innate/instrinsic - such as intelligence. I believe it's fairly hard to
improve intelligence after a certain childhood developmental period,
but I think heavy exercise and weapons training DOES improve strength,
and getting your rear-end handed to you by a battallion of orc goons
will probably weaken you to the point that a rare but
typically-non-fatal snake venom will, in fact, kill you. The intrinsic
characteristics (described below) SHOULD, mostly, be mutable, and
hence, fit with the rest of the skills/stats.

> A very elegant task resolution system based on this principle is found
> in R. Talsorian Games' Cyberpunk and Cybergeneration roleplaying games:
> stats (intelligence, reflexes, luck, empathy, body, attractiveness)
> increase or decrease rarely and permanently for specific reasons
> (mutilation, high tech enhancements, etc.) and the many skills (e.g.
> seduction, programming, shotgun, pilot helicopter, cyberdeck
> engineering, swimming) increase with usage and by spending experience
> awards.
> All stats and skills have a normal range of 0 or 1 to 10 and all
> success rolls are one stat + one skill + 1d10 vs a threshold or someone
> else's roll (which can use entirely different stats and skills, it just
> needs to be in the same range to work).
> Tasks can use the most appropriate combination: for example weapon
> skills are usually employed to fight in combination with reflexes, but
> the GM can easily adlib that, for example, you can evaluate opponent
> skills by looking for a while and rolling intelligence + the weapon
> skill they are using, or that to shoot an awkward huge rifle you roll
> the average of body and reflexes + rifle skill.

This doesn't feel any different than most other P&P systems. The debate
centers around the nature of these intrinsic characteristics. The game
system is a model for (a not so real) world interaction, so the
intrinsic characteristics should take into account the aspects of the
world which are important. Charisma/attractiveness is a great example
because it's seldom important to dungeon crawling. An uncharismatic
character won't be able to haggle as well, and won't have success
leading companions, but its not nearly as important to general survival
for most roguelikes - in the heat of battle against a Greater Wyrm of
Anarchy, or some such beast, the character's ability to interact with
people is much less important than his ability to stick the pointy end
of the sword into the soft end of the baddy.

> A computer game, not constrained by human memory, can list endless
> defaults, special cases, derived attributes and skills, situational
> modifiers, etc. and in such a framework balancing them would be very
> easy: there is no power inflation (combat between strong opponents that
> hit almost always becomes a matter of who shoots first or makes more
> damage), task difficulty levels are fixed (5 is trivial, 15 is about
> 50% chance for an average character, 25 is very difficult), opposite
> rolls are fair.

I disagree. I think the more defaults, special cases, derivatives, and
situational modifiers that are present, the more difficult it would be
to balance said system. How do you decide how much experience a skill
is "worth" if there's an endless number of special cases? Is it more or
less valuable than the same quantity of experience in another skill?
Balancing a game's skills takes fine-tuning, and even relatively simple
systems can be fairly difficult to balance.

> Of course, this system also promotes a deep separation of intrinsic and
> learned qualities, and the numbers are exposed to the player as a
> realistic model; there are no opaque rules interposing between the
> character sheet and how effective the character is in the game.

What about all of the special cases, derivatives, and situational
modifiers? Even if you list them, their sheer quantity should present
an effectively opaque wall at understanding how good your character
will be in a particular task, based upon intrinsic qualities.

Radomir 'The Sheep' Dopieralski

unread,
Oct 27, 2005, 11:36:41 AM10/27/05
to
At Thu, 27 Oct 2005 08:16:01 +0200,
Björn Bergström wrote:

And what is it with bows? Why they are (0,0,0,0) by default?
And how long bow (0,0,0,0) is better than short bow (0,0,0,0)?

An what if I equip 255 arrows (+3,0,0+1) ?

--
Radomir `The Sheep' Dopieralski @**@_

($s) 3 Ching!

ga...@dsdata.it

unread,
Oct 27, 2005, 1:31:42 PM10/27/05
to
wild.h...@gmail.com wrote:
> ga...@dsdata.it wrote:
[...]

> > A computer game, not constrained by human memory, can list endless
> > defaults, special cases, derived attributes and skills, situational
> > modifiers, etc. and in such a framework balancing them would be very
> > easy: there is no power inflation (combat between strong opponents that
> > hit almost always becomes a matter of who shoots first or makes more
> > damage), task difficulty levels are fixed (5 is trivial, 15 is about
> > 50% chance for an average character, 25 is very difficult), opposite
> > rolls are fair.
>
> I disagree. I think the more defaults, special cases, derivatives, and
> situational modifiers that are present, the more difficult it would be
> to balance said system. How do you decide how much experience a skill
> is "worth" if there's an endless number of special cases? Is it more or
> less valuable than the same quantity of experience in another skill?
> Balancing a game's skills takes fine-tuning, and even relatively simple
> systems can be fairly difficult to balance.

You seem to agree that wrong success chances and unrealistic rules
would be easy to avoid; helping the player to choose advancements
wisely is another problem.
Trying to define the scope and purpose of every skill to make them
equally useful is not the only way to obtain a fair advancement system;
in my opinion it isn't very productive, since every player has a
different style and they will not value skills like the ideal player
you assume. Moreover, convoluted skill defintions can surprise the
player by themselves.
To a point, unbalanced skill usefulness isn't a true problem: players
invest on what they like and on what they need, regardless of
efficiency.
In a RPG there is a human GM who can shape player expectations, alter
and redefine skills and retroactively compensate or undo suboptimal
advancement choices; a RL game needs more conservative and adaptive
rules.

A game might avoid the traditional "you have x skill points to divide
among these y skills" advancement interface and decide according to
accumulated statistics and high level inputs:
- raise the skills that have been used with the lowest average success
chance (difficult odds can represent either excessive "bravery" or
frustrating failures)
- raise the skills that have been used most often (to promote
specialization)
- raise the skills that have been used least often (to promote
well-rounded characters)
- raise the skills for the weapons that would have been more useful
against recently fought monsters (to educate the player).
- raise the skills just enough to meet minimum requirements, e.g.
stealth over 4 at level 6 (to balance the character against challenges:
an hero of a certain level is guaranteed to have a chance)
- raise the skills according to a profile, e.g. a fighter-mage could
have 1/3 of his skill points in fighting (of which half in dodging and
half in weapons), 1/3 in spellcasting and 1/3 in general skills.

If quantitative skills are incremented outside the player's control,
pricing becomes less important: the player won't regret decisions he
hasn't made.
The choice of qualitative improvements (should I carry a rod of Healing
or a spare axe? Should I learn Fire Cloud or Raise Zombie?) remains
open, and players don't expect them to be balanced or even comparable.

> > Of course, this system also promotes a deep separation of intrinsic and
> > learned qualities, and the numbers are exposed to the player as a
> > realistic model; there are no opaque rules interposing between the
> > character sheet and how effective the character is in the game.
>
> What about all of the special cases, derivatives, and situational
> modifiers? Even if you list them, their sheer quantity should present
> an effectively opaque wall at understanding how good your character
> will be in a particular task, based upon intrinsic qualities.

I'm not advocating strange and surprising complications, nor forbidding
mountains of incoherent rules: players needs to understand the game to
play it (and we want them to appreciate the quality of our rules).
Complications should be applied in important places, where they are
most useful, and unimportant aspects should be simplified. In a good
game every rule is worth knowing and boring or irrelevant rules have
been eliminated; simulation quality and simplicity are two qualities
that can be combined if the game designer has a clear purpose.

For example, Cyberpunk 2020 emphasizes combat, and within combat it
emphasizes gunfights. Medicine or acting are single skills; pistol,
SMG, rifle, shotgun and heavy weapons are separate skills; close combat
is classified as "brawling" or "fencing".
There is a supplement about Far East describing many martial arts
skills and detailed procedures for martial arts duels (ranges,
movement, manoeuvres): obviously in such of campaign the players would
learn the extra rules at the expense of the finer points of shooting
people; the GM might coalesce several standard gun skills to make the
resulting broad skill as important as a martial art. Real basic
features, e.g. that combat is based on Reflexes and dying less easily
depends on Body, would remain constant.

In a RL game stats of any kind should be limited to a minimum: every
one should be an interesting and meaningful facet of the character.
Derived quantities (e.g. hit points computed as the average of
Constitution and Size) are supposed to be equally important and they
should be equally explicit on the character sheet.
Default skill values are not a complication (the character simply
starts from better than 0 skill) and they only need to be explicitly
listed when and if skill ratings are raised by the user.
Using unusual skills and stat combinations for unusual tasks is to be
expected; to avoid surprises the relevant attributes of a task can be
told to the user, to let him preview his chance of success and enjoy
the extreme cleverness and forethought of the game designer
("Lockpicking + Body? Ah, this Chest is a Rusty Chest. I guess my thief
will need a Ring of Strength or a Crowbar to open it safely").
Attempting new actions should never devolve into guessing the required
die rolls and difficulties.

Lorenzo Gatti

Glen Wheeler

unread,
Oct 29, 2005, 2:08:02 AM10/29/05
to

"Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> wrote in
message news:slrndlvken....@atos.wmid.amu.edu.pl...

What? That doesn't make any sense. You just said ``he cannot wield
any weapon'' and then mentioned how he would wield a dagger. That's not
consistent.

On the other hand, David's issue is rather important, and also not
uncommon. Another example: you have a spellcasting character who has a
massive `spellcasting' skill. Presumably, he is pretty intelligent.
But then, since the poor player didn't put any skill points into
`diplomacy' he runs into trouble trying to negotiate with some enemies.
But he can't speak properly, if at all, despite his massive
intelligence. Weird.

Another example. Master thief with huge thief skills has no ability
with other nimble-fingered related skills. Why?

Stats were invented to solve these problems.

--
Glen
L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+

Glen Wheeler

unread,
Oct 29, 2005, 2:13:11 AM10/29/05
to

"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:1130345860.6...@g44g2000cwa.googlegroups.com...

> Radomir 'The Sheep' Dopieralski wrote:
>> I was always wondering why most computer rpg games use so
>> strange and not-meaningful names for the characters stats.
>
> People are under the mistaken belief that a "more complicated" system
> is a "more fun" system.

Which is sometimes the case. See chess vs checkers (at least IMO).

> Stats make an excellent point to layer lots of
> useless complications and formulas.

In a poor implementation.

> By having enough tables of
> meaningless numbers, it will become impossible to figure out what will
> happen in an attack roll, so the author will conclude it must be
> "balanced".
>

First, they don't have to be meaningless. Use words instead of
numbers. For example, if you have ten levels of physical strength, then
use unambiguous words for the ten levels. If you don't need ten then
only use five. Or three.

For some reason people seem to think that to have stats implies to
have hideously complicated game mechanics.

> I'd point as a counter example You Only Live Once's combat system,
> which is about as simple as you can get, but is still fun. In that
> system, any attack will always hit and always do full damage. All the
> crazy complexity people add on top of that is just random variable.
>

YOLO was indeed very nice. But it still had, and used stats. For
example, damage dealt by each character.

>> Wat is the reason for all this? Woudn't it be much more convenient to
>> use the 'attributes' (following the Angband terminology) directly,
>> without the need for stats at all? You woudn't have to explain their
>> meaning, and you woudn't have to use complicated formulas in the game
>> logic code. What would you lose?
>
> I recall going at length about this in the past. My argument was
> there
> was no need for any statistic that doesn't have a unit of measurement
> in a Roguelike.
>
> Ah, here it is. "Why Stats Are Harmful"
> http://groups.google.com/group/rec.games.roguelike.development/msg/33eaa49a18b00255?hl=en&
>

Sometimes you can go too far in the wrong direction. Stats are very
useful, if used correctly, to model situations that force the player to
make an Interesting Decision.

Jeff Lait

unread,
Oct 29, 2005, 9:33:38 AM10/29/05
to

Glen Wheeler wrote:
> "Jeff Lait" <torespon...@hotmail.com> wrote in message
> news:1130345860.6...@g44g2000cwa.googlegroups.com...
> > Radomir 'The Sheep' Dopieralski wrote:
> >> I was always wondering why most computer rpg games use so
> >> strange and not-meaningful names for the characters stats.
> >
> > People are under the mistaken belief that a "more complicated" system
> > is a "more fun" system.
>
> Which is sometimes the case. See chess vs checkers (at least IMO).

I don't recall saying that a more complicated system could not be a
more fun system. I was pointing out that one does not necessarily
follow the other.

> > Stats make an excellent point to layer lots of
> > useless complications and formulas.
>
> In a poor implementation.

Which the majority of "Let's pull some primary stats out of the air and
then shoe horn them in my eventual game mechanics" usually are.

> > By having enough tables of
> > meaningless numbers, it will become impossible to figure out what will
> > happen in an attack roll, so the author will conclude it must be
> > "balanced".
> >
>
> First, they don't have to be meaningless. Use words instead of
> numbers. For example, if you have ten levels of physical strength, then
> use unambiguous words for the ten levels. If you don't need ten then
> only use five. Or three.
>
> For some reason people seem to think that to have stats implies to
> have hideously complicated game mechanics.
>
> > I'd point as a counter example You Only Live Once's combat system,
> > which is about as simple as you can get, but is still fun. In that
> > system, any attack will always hit and always do full damage. All the
> > crazy complexity people add on top of that is just random variable.
>
> YOLO was indeed very nice. But it still had, and used stats. For
> example, damage dealt by each character.

As I mentioned at great length last time this came up, my complaint is
with meaningless "primary" statistics that have no "units" with them.
The damage per character is a valid statistic. Just like a "Skill with
the sword" is a valid statistic. Or "Colour of hair". In Sheep's
terminology, these things are all "attributes" rather than "stats".

> >> Wat is the reason for all this? Woudn't it be much more convenient to
> >> use the 'attributes' (following the Angband terminology) directly,
> >> without the need for stats at all? You woudn't have to explain their
> >> meaning, and you woudn't have to use complicated formulas in the game
> >> logic code. What would you lose?
> >
> > I recall going at length about this in the past. My argument was
> > there
> > was no need for any statistic that doesn't have a unit of measurement
> > in a Roguelike.
> >
> > Ah, here it is. "Why Stats Are Harmful"
> > http://groups.google.com/group/rec.games.roguelike.development/msg/33eaa49a18b00255?hl=en&
> >
>
> Sometimes you can go too far in the wrong direction. Stats are very
> useful, if used correctly, to model situations that force the player to
> make an Interesting Decision.

Attributes are useful in that respect. Traditional primary stats
(which is what I am referring to here) are not. They are ineffective
at making interesting decisions because the player rarely can figure
out what the effect of modifying them would be.

Jeff Lait

unread,
Oct 29, 2005, 9:36:24 AM10/29/05
to
Glen Wheeler wrote:
> "Radomir 'The Sheep' Dopieralski" <thesheep@ sheep.prv.pl> wrote in
> message news:slrndlvken....@atos.wmid.amu.edu.pl...
> >
> > But he can still wield a dagger, because of his exception strength.
> > (he probably grabs it with his enormusly muscular hair on his hands)
> >
> > You can make up any number of ridiculous situations with any system.
> >
>
> What? That doesn't make any sense. You just said ``he cannot wield
> any weapon'' and then mentioned how he would wield a dagger. That's not
> consistent.
>
> On the other hand, David's issue is rather important, and also not
> uncommon. Another example: you have a spellcasting character who has a
> massive `spellcasting' skill. Presumably, he is pretty intelligent.
> But then, since the poor player didn't put any skill points into
> `diplomacy' he runs into trouble trying to negotiate with some enemies.
> But he can't speak properly, if at all, despite his massive
> intelligence. Weird.

I understand the point you are making. First, I'd say that such things
should be covered by synergistic skills. This is something computers
are quite good at tracking.

Secondly, the case of having a super-smart spellcaster with no
diplomatic skills doesn't seem the least bit far fetched. I can think
of many smart people who's diplomacy could use a fair number of skill
points.

Glen Wheeler

unread,
Oct 29, 2005, 8:18:59 PM10/29/05
to

"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:1130592984.2...@g44g2000cwa.googlegroups.com...

Yes, perhaps diplomacy was the wrong term. The idea was that with 0
points in `talking' or whatever he wouldn't even be able to start
talking with them (such as in fallout 1 or 2, with a character of
intelligence < 3 (IIRC)).

Synergistic skills you say? Like skills that affect eachother, so
that when you raise one you are actually also contributing towards
raising another?

Taking an example from Sangband (which also happens to be my favourite
*band): raising burglary contributes to stealth, disarming and
perception?

Wasn't the whole point of this to remove `complicated' mechanics? I
don't see how a tiered weighted relationship between skills is any less
complicated than some collection of stats which exchibit a weighted
relationship to several skills. At least the stats are conceptually
different, and easy to sort out in the players mind (if I raise
strength, then all this other stuff will happen; if I raise magical
power, do I get a free point in another skill? all other magical
skills? a subset?)

Glen Wheeler

unread,
Oct 29, 2005, 8:23:21 PM10/29/05
to

"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:1130592818.7...@f14g2000cwb.googlegroups.com...

> Glen Wheeler wrote:
>> "Jeff Lait" <torespon...@hotmail.com> wrote in message

As evidenced by my above post, I was defending the concept of stats,
not the traditional usage of them. I agree that traditional stats are
not very useful, but they were not the subject matter of my post, and if
I was to be pedantic I would say that this is the first time I've seen
Sheep or yourself mention traditional stats in this thread...but of
course, I could be blind.

If attributes are defined as well-implemented stats then I would much
rather just call them stats, and call the games that implement them
poorly as ineffective.

Björn Bergström

unread,
Oct 31, 2005, 3:53:04 AM10/31/05
to

Some items that you equip doesn't modify stats. Arrows are one thing
that doesn't affect them. Long Bows have a damage mod (not clearly
visible though). Ok, not a perfect system, I admit :-)

BR,
Björn

konijn_

unread,
Oct 31, 2005, 8:48:53 AM10/31/05
to
<SNIP>

> > In your
> > approach when something changes the character's strength you also end up
> > doing something to all the derived values.
> ...if you want to model exactly the same beghavior as with stats.
> Note that as long as you're using term "character's strength", you're
> basically talking about his stat. It goes without saying that stats are
> best modelled using, well, stats.
>
> > One serious problem with your approach is that it's hard to implement
> > sensible maxima and minima.
> ... of stats.
>

No, of skills.
Lets take the troll <> human thing.
Troll = 20 sword , Human = 15 sword
Why ? What is the maximum of sword skill ?
What is the minimum ? How much can the human train in swordskill ?
A human master should never ever have the same sword skill as a troll
master, how do you account for that ?

T.

<SNIP>

wild.h...@gmail.com

unread,
Oct 31, 2005, 9:51:16 AM10/31/05
to

konijn_ wrote:

> No, of skills.
> Lets take the troll <> human thing.
> Troll = 20 sword , Human = 15 sword
> Why ? What is the maximum of sword skill ?
> What is the minimum ? How much can the human train in swordskill ?
> A human master should never ever have the same sword skill as a troll
> master, how do you account for that ?

These are numbers that you can magically make up. The more details you
account for, the more magic numbers you'll need to base on outside
information. In this scenario, it would probably make sense for the
human to top off a few points before the troll, as masters. As for the
minima for the skills.. 0 for each, and the growth curve would take
into account the player race.

I've pretty much been arguing both sides of the debate, but I do like
stats - just not the conventional ones. Stats are easy to work with and
conceptualize.

konijn_

unread,
Oct 31, 2005, 10:02:20 AM10/31/05
to
>As for the
>minima for the skills.. 0 for each, and the growth curve would take
>into account the player race.

Noops, give a troll a sword and a human a sword, and tell them to
fight, each of them has never seen a sword. Who will win ? The troll of
course unless the human gets really lucky. Because strength is a part
of the sword skill, if the minimum for human is 0, the minimum for
troll cannot be 0.

T.

Jeff Lait

unread,
Oct 31, 2005, 10:23:44 AM10/31/05
to
Glen Wheeler wrote:
> As evidenced by my above post, I was defending the concept of stats,
> not the traditional usage of them. I agree that traditional stats are
> not very useful, but they were not the subject matter of my post, and if
> I was to be pedantic I would say that this is the first time I've seen
> Sheep or yourself mention traditional stats in this thread...but of
> course, I could be blind.

Sheep started this off with:
> You usuallu have something like the usual set:
> str, dex, int, etc.

I weighed into this arugment with:


> I recall going at length about this in the past. My argument was there
> was no need for any statistic that doesn't have a unit of
> measurement in a Roguelike.

I also provided a link to my "Why Stats are Harmful" post in which I
had gone on to some length about the difference between "primary",
useless, stats, and "secondary", useful, stats.

> If attributes are defined as well-implemented stats then I would much
> rather just call them stats, and call the games that implement them
> poorly as ineffective.

Sure, let's just define away the problem rather than try and figure out
what the problem is!

It is an undisputable fact that there exists "primary" stats in the
vast majority of roguelikes. Whether they are called Str, or Will, it
seems a common trope to bring out an array of fungible "stats".

Glen Wheeler

unread,
Oct 31, 2005, 11:06:25 AM10/31/05
to

"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:1130772224.4...@g14g2000cwa.googlegroups.com...

> Glen Wheeler wrote:
>> As evidenced by my above post, I was defending the concept of
>> stats,
>> not the traditional usage of them. I agree that traditional stats
>> are
>> not very useful, but they were not the subject matter of my post, and
>> if
>> I was to be pedantic I would say that this is the first time I've
>> seen
>> Sheep or yourself mention traditional stats in this thread...but of
>> course, I could be blind.
>
> Sheep started this off with:
>> You usuallu have something like the usual set:
>> str, dex, int, etc.
>
> I weighed into this arugment with:
>> I recall going at length about this in the past. My argument was
>> there
>> was no need for any statistic that doesn't have a unit of
>> measurement in a Roguelike.
>
> I also provided a link to my "Why Stats are Harmful" post in which I
> had gone on to some length about the difference between "primary",
> useless, stats, and "secondary", useful, stats.
>


Apologies, I am blind after all.


>> If attributes are defined as well-implemented stats then I would
>> much
>> rather just call them stats, and call the games that implement them
>> poorly as ineffective.
>
> Sure, let's just define away the problem rather than try and figure
> out
> what the problem is!
>

My problem is that there exists a very intuitive seperation from
inherent traits of a player character, and skills which are learnt by
that player character. I am arguing that these traits, which are
colloquially (sp?) called stats, are a Good Thing, for various (rather
obvious) reasons.

It all boils down to modeling. Model a little of the game world, not
much, but just enough. If your game only needs a health rating, then
only use that. Attack damage, then fine. But if you want to go with a
skills system such as Sheep was describing earlier, and in other
tangents, then a statless game is ambiguous and confusing.

> It is an undisputable fact that there exists "primary" stats in the
> vast majority of roguelikes. Whether they are called Str, or Will, it
> seems a common trope to bring out an array of fungible "stats".

Ah, but are we criticising current roguelikes, or trying to develop
better ones? So they have a few nonesense stats for the characters.
They are flawed; I don't think anyone is arguing for that.

But to not use stats with a non-trivial skill system? Crazy.

Jeff Lait

unread,
Oct 31, 2005, 12:55:10 PM10/31/05
to
Glen Wheeler wrote:
> "Jeff Lait" <torespon...@hotmail.com> wrote in message
> news:1130772224.4...@g14g2000cwa.googlegroups.com...
> > Glen Wheeler wrote:
> >> If attributes are defined as well-implemented stats then I would
> >> much
> >> rather just call them stats, and call the games that implement them
> >> poorly as ineffective.
> >
> > Sure, let's just define away the problem rather than try and figure
> > out what the problem is!
>
> My problem is that there exists a very intuitive seperation from
> inherent traits of a player character, and skills which are learnt by
> that player character. I am arguing that these traits, which are
> colloquially (sp?) called stats, are a Good Thing, for various (rather
> obvious) reasons.

My problem is that I don't believe there is a separation between
"learned" abilities and "built-in" abilities. Or, to be more precise,
any such separation has nothing to do with what is captured by "stats"
such as "Strength".

A better example of well done "built-in" abilities would be Class or
Race in roguelikes. Crawl shows this off nicely with things like
Mummies or Ghouls. By playing those characters, you have certain
inherent differences which are not a function of character development.

If we want a character who is a powerful warrior but can't cast spells
in our roguelike, we are likely better off making a Barbarian Class
rather than trying to manipulate Str and Int to create the same effect.

> > It is an undisputable fact that there exists "primary" stats in the
> > vast majority of roguelikes. Whether they are called Str, or Will, it
> > seems a common trope to bring out an array of fungible "stats".
>
> Ah, but are we criticising current roguelikes, or trying to develop
> better ones?

To develop better ones we had better be able to critique the old ones.
This also involves trying to find a common language to describe the
behaviuor of old roguelikes.

> So they have a few nonesense stats for the characters.
> They are flawed; I don't think anyone is arguing for that.

If no one was arguing for it, why do we keep seeing roguelikes
reverting to Str/Dex/Int as their first step?

Ray Dillinger

unread,
Oct 31, 2005, 3:10:52 PM10/31/05
to
Radomir 'The Sheep' Dopieralski wrote:

> I fell like I'm talking about planes as alternate means of travel to a car
> driver, and then he responds: "Right, but where's the honker? There's no
> honker? Then what am I supposed to do in a traffic jam? Whistle?".

I feel like you're describing planes as an alternate means of
travel to people who want to travel on the ground and see the
scenery up close and be able to stop and park and maneuver and
reverse and enjoy twisty roads and picnic lunches and scenic
overlooks and roadside attractions like the gopher farm or the
big ball of string, and picking up interesting (or cute)
hitchhikers and like truck stop restaurants and the feeling
of the wheels on the pavement.

I mean, and sorry for abusing your metaphor, with a plane, you
get in, you fly, and maybe you get to see some cool sights from
way up high that you wouldn't be able to see from the road, and
maybe you get there faster, but you lose most of your
opportunities to interact with the places you just flew over.

I contend that stats, properly implemented, provide a bunch of
interactions that belong in a fun game and that people like. It
is sensible to restrict the use of most weapons and armor, for
example, to those who can lift and carry their weight.

It is sensible that races stronger than humans will and should
routinely develop weapons that most humans cannot lift, or, if
able to lift, won't be able to use effectively. ("You're an
excellent swordsman, however, an ogre's sword weights 120 Kilos
and you're not that strong.") It is sensible that races smaller
and weaker than humans would develop small, light versions of
weapons that might be suitable for a human child or physical
weakling.

It is sensible and reasonable that the same weapon in the hands
of equally skilled opponents with different intrinsic abilities
of greater speed on the one hand and greater strength on the other
would be used differently and have different effects (more attacks
per round and a greater chance to parry/deflect vs. more damage per
attack and a greater chance to pierce armor).

It is sensible and consistent with legend that the attacks of some
creatures cause strength and speed to drain away leaving the victim
weak and vulnerable and possibly unable to use several of his/her
weapons and/or skills.

It is sensible that a person who is unusually strong would find
it easier to learn certain skills and that a different person
who is unusually fast would find it easier to learn others.

All of these things create Interesting Decisions and Challenges
and Opportunities to Roleplay for the players. All of these
things are most straightforwardly implemented using primary
stats.

Bear

Glen Wheeler

unread,
Oct 31, 2005, 9:46:38 PM10/31/05
to

"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:1130781310.1...@g14g2000cwa.googlegroups.com...

Abilities? Is lifting a heavy object an ability? Bashing a door?
What do you use internally to represent ``skill bashing a door''? Is it
the same as ``skill lifting backpack''? Argh. *bashes head on wall*
Having no stats and further no differentiation between skills and
stats leads to a certain number of very silly scenarios. I won't repeat
Bear's post, although will point out that I mentioned his conclusion in
my first reply to Jeff.

>> > It is an undisputable fact that there exists "primary" stats in the
>> > vast majority of roguelikes. Whether they are called Str, or Will,
>> > it
>> > seems a common trope to bring out an array of fungible "stats".
>>
>> Ah, but are we criticising current roguelikes, or trying to develop
>> better ones?
>
> To develop better ones we had better be able to critique the old ones.
> This also involves trying to find a common language to describe the
> behaviuor of old roguelikes.
>
>> So they have a few nonesense stats for the characters.
>> They are flawed; I don't think anyone is arguing for that.
>
> If no one was arguing for it, why do we keep seeing roguelikes
> reverting to Str/Dex/Int as their first step?

Most likely they aren't in this thread, or less likely they are are
not implemented as ``nonesense stats.''

R. Alan Monroe

unread,
Oct 31, 2005, 10:21:38 PM10/31/05
to
In article <1130781310.1...@g14g2000cwa.googlegroups.com>, "Jeff Lait" <torespon...@hotmail.com> wrote:
>My problem is that I don't believe there is a separation between
>"learned" abilities and "built-in" abilities.

Ah, so you came straight from the womb knowing how to program in C...
:^) :^) :^)


Alan

Radomir 'The Sheep' Dopieralski

unread,
Nov 1, 2005, 8:38:31 AM11/1/05
to
At Mon, 31 Oct 2005 20:10:52 GMT,
Ray Dillinger wrote:

> Radomir 'The Sheep' Dopieralski wrote:
>
>> I fell like I'm talking about planes as alternate means of travel to a car
>> driver, and then he responds: "Right, but where's the honker? There's no
>> honker? Then what am I supposed to do in a traffic jam? Whistle?".
>
> I feel like you're describing planes as an alternate means of
> travel to people who want to travel on the ground and see the
> scenery up close and be able to stop and park and maneuver and
> reverse and enjoy twisty roads and picnic lunches and scenic
> overlooks and roadside attractions like the gopher farm or the
> big ball of string, and picking up interesting (or cute)
> hitchhikers and like truck stop restaurants and the feeling
> of the wheels on the pavement.

<snip>

> All of these things create Interesting Decisions and Challenges
> and Opportunities to Roleplay for the players. All of these
> things are most straightforwardly implemented using primary
> stats.

I think I see now.

But still, I'm a little uncertain. I'll try to explain why. I began
this explanaition in the original post, but wasn't still sure what
I mean ;).

The stats, in their "traditional" form, often seen in computer role
playing games, like int, dex/agl, str/mgt, wis/pty, chr, con/tgh, etc.
seem to be derieved directly from pen and paper roleplaying games.
Furthermore, they come from a certain type of p&p games -- namely those
known as "Heroic Fantasy". They are pretty well designed for "general
roleplaying" in heroic fantasy worlds, for deciding the outcome of
actions in a wide variety of situations. To get a feel of it, here's
how you might describe a character looking at it's stats:

He's a strong, muscular fellow, with somewhat slow moves and reflexes,
and average health and posture. He's not extraordinarily bright and
smart, but is well educated and has strong morals. He's handsome.
He prefers to do things slowly, but is very dedicated to whatever he
starts and usually finishes it.

The rest is usually handled by the character's background, his skills and
various modifiers and bonuses.

Now, what I'd want to discuss, is whether such a general and universal
system is really good for roguelike games, which tend to be pretty limited
and restricted, both because of being only computer games (all the
situations have to be predefined), and because of (usually) simplified
setting (dungeon).

For exmaple, compare with solely ability-based description:

He looks, moves and generally behaves like all the adventure hunters
that came to explore the dungeon recently.

(This is the equivalent of the previous description, but assuming all the
"stats" are average).

He moves at slow speed, but he can easily spot all the traps and
secret passages. Disarming traps and picking locks are hard for him.

He's good at hand-to-hand combat, especially with heavy weapons.
He's a good marksman and he knows how to use even very heavy bows.
His good sight allows him to see farther than others, even in
darkness.

He is not very good with magic, usually fails to properly recite
spells. Prayers are easier for him, however.

He doesn't have any exceptional resistance to poisons and diseases,
and he heals at normal rate. He has good apetite and fast digestion.

He is a good packager and can carry around lots of items without
trouble, but seems to be helpless when it comes to selling them and
haggling.

He's good with animals and can easily tame pets.

Ok, the latter description is much more detailed, partly because it
includes information that's covered in "skills" in the former one. But
note how it is dungeon-specific. It doesn't tell you how your character
should behave when in royal court, for exmaple -- it's up to the player to
decide, it's not covered by the game mechanics.


The stats in p&p rpg are both for the player and for the game master --
and they are supposed to both fill in the gaps by being creative and
telling a story.

In the crpg, the game cannot be creative. So maybe it's good to have
game mechanics related abilities/attributes, that are easy to use, easy to
tune and easy to see what they are for, and maybe a description,
background, picture, or just a name -- for the player to roleplay.

This also somewhat solves the problem of player not playing in accordance
to his character stats -- when there are no stats recorded, it's up to the
player to make up his character, and to decide how it should be played.

--
Radomir `The Sheep' Dopieralski @**@_

(><) 3 Ouch!

David Damerell

unread,
Nov 2, 2005, 11:20:48 AM11/2/05
to
Quoting Jeff Lait <torespon...@hotmail.com>:
>I understand the point you are making. First, I'd say that such things
>should be covered by synergistic skills. This is something computers
>are quite good at tracking.

All skills that involve the use of physical strength being synergistic is
equivalent to having a physical strength stat.

>Secondly, the case of having a super-smart spellcaster with no
>diplomatic skills doesn't seem the least bit far fetched. I can think
>of many smart people who's diplomacy could use a fair number of skill
>points.

Indeed, but very few of those programmers simply can't speak the language
at all.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Leicesterday, October.

Radomir 'The Sheep' Dopieralski

unread,
Nov 2, 2005, 1:10:41 PM11/2/05
to
At 02 Nov 2005 16:20:48 +0000 (GMT),
David Damerell wrote:

> Quoting Jeff Lait <torespon...@hotmail.com>:
>>I understand the point you are making. First, I'd say that such things
>>should be covered by synergistic skills. This is something computers
>>are quite good at tracking.
>
> All skills that involve the use of physical strength being synergistic is
> equivalent to having a physical strength stat.

But why would you want that at all?
Is "carrying strength" tha same as "door bashing" strength, "fighting"
strength and "open tin" strength, not to mention "shoot bow" strength.

These are totally different things, and putting them under a common
"strength" stat is as appropriate, as having separate, unrelated
stats for it.

--
Radomir `The Sheep' Dopieralski @**@_

(TT) 3 Waaah!

konijn_

unread,
Nov 2, 2005, 1:40:35 PM11/2/05
to
Last post of mine on this subject,

effectiveness = skillmix% * statmix %.
or
effectiveness = how well can you use it% * how potentially good are
you% ?

T.

mix = any thing you might want to try might need a mix of skills &
stats.

PS : No need to reply unless you have the rules for a fun game game
without stats.

PPS : Okay, you might find such rules, but any game of sufficient
complexity needs stats. You're game just wont be sufficiently complex ;)

David Damerell

unread,
Nov 2, 2005, 2:05:14 PM11/2/05
to
Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>David Damerell wrote:
>>Quoting Jeff Lait <torespon...@hotmail.com>:
>>>I understand the point you are making. First, I'd say that such things
>>>should be covered by synergistic skills. This is something computers
>>>are quite good at tracking.
>>All skills that involve the use of physical strength being synergistic is
>>equivalent to having a physical strength stat.
>But why would you want that at all?
>Is "carrying strength" tha same as "door bashing" strength, "fighting"
>strength and "open tin" strength, not to mention "shoot bow" strength.
>These are totally different things, and putting them under a common
>"strength" stat is as appropriate, as having separate, unrelated
>stats for it.

Not in the least. Having them be completely independent's absurd, as if
fighting all day and building huge muscles doesn't let you bash down doors
any more easily.

Having them synergistic is OK but equivalent to an underlying strength
stat and skills in door bashing, fighting, etc. Use the synergistic-skill
approach if that makes the implementation easier but don't kid yourself
this is any different from having a stat.

[I doubt it does make it easier. Opening tins is a good example of why
not; you want a default strength value that can be used for unimportant
tasks without adding a new synergistic skill every time you add a new test
of physical ability to the game.]

Having a single strength stat is an obvious simplification which doesn't
produce any gross absurdities except those stemming directly from the fact
that is _is_ a simplification.

Radomir 'The Sheep' Dopieralski

unread,
Nov 2, 2005, 2:17:50 PM11/2/05
to
At 02 Nov 2005 19:05:14 +0000 (GMT),
David Damerell wrote:

> Quoting Radomir 'The Sheep' Dopieralski <sheep1 % sheep.prv.pl>:
>>David Damerell wrote:
>>>Quoting Jeff Lait <torespon...@hotmail.com>:
>>>>I understand the point you are making. First, I'd say that such things
>>>>should be covered by synergistic skills. This is something computers
>>>>are quite good at tracking.
>>>All skills that involve the use of physical strength being synergistic is
>>>equivalent to having a physical strength stat.
>>But why would you want that at all?
>>Is "carrying strength" tha same as "door bashing" strength, "fighting"
>>strength and "open tin" strength, not to mention "shoot bow" strength.
>>These are totally different things, and putting them under a common
>>"strength" stat is as appropriate, as having separate, unrelated
>>stats for it.
> Not in the least. Having them be completely independent's absurd, as if
> fighting all day and building huge muscles doesn't let you bash down doors
> any more easily.

My personal experiences are different, but wha am I to decide? ;)
Everything has been said, I guess. Now it's just a matter of
rereading and rethinking.

--
Radomir `The Sheep' Dopieralski @**@_

(><) 3 Ouch!

Jeff Lait

unread,
Nov 2, 2005, 4:07:14 PM11/2/05