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