How Many Attributes is Too Many for an RPG?


#1

And by attributes, I mean stats like Strength and Intelligence. This is a question of design philosophy; I know the de facto answer is “it depends on the game.”

My question is, however, how many different core attributes can a character have before a player becomes annoyed or confused? How many is too few? And how general should an attribute be?


#2

The best thing to do is playing other RPG’s and analyzing what you don’t like/like about the attribute system.
Or you could just throw out a prototype and wait for feedback to your attribute system.

I don’t think there is “the answer” to that kind of design problem. It’s a lot of playing around and your own taste.


#3

I would personally say between 3 and 9. 3 or 4 is good for light RPGs, ones that are supposed to be quick and easy to pick up and learn, 5-7 for your average difficulty rpgs, and 8-9 for more complex, more simulationist mechanics. More than that and it really starts getting so finely detailed in the difference between one stat and another that it can get confusing.


#4

DnD tells me six is a decent balance, so plus or minus stats from that is probably good.


#5

A heavy factor is also the importance of those states as well. The more clearly defined purpose a stat has the more willingly a player will agree to understanding it, so it the answer could be as many as you wanted if you were confident you could easily convey what they did.

Example: Players instantly understand what a “Strength” stat does and how to use it, while something less straight forward like “Pluckiness” is not as immediately understandable and might be ignored if the player can’t figure it out regardless of it’s importance, so if a Dev wanted to use a “Pluckiness” stat they would need to be able to express it’s utility to the player effectively in game.


#6

I think the first question is Is every attribute explained properly, In game or Out?
If yes, the question then goes to Does each attribute Interact with another attribute?
If no, then a small amount of attributes is fine.
If yes, then a larger amount of attributes makes sense, but doesn’t have to be large.


#7

It depends on how useful the attributes are. If the potency of magic spells is tied to Intelligence but magic is measurably less useful than other tactics, then Intelligence is a useless attribute.

As for a player’s threshold for becoming annoyed or confused, that’s very subjective. Perhaps the best way to test it is to see how new players react upon seeing a stats/attributes screen. If it looks like the item shop in League of Legends or the move list in a Soul Caliber game, then players will be intimidated or resentful of having to learn so much right off the bat. Conversely, if the list is too short, players won’t get to enjoy tough, meaningful decisions as to what they want to put points into. They’ll have everything figured out within a matter of minutes, if not seconds.


#8

I played a game where there were 8. this was an RPG from 2001, as well, and it worked. quite well in fact! it also had a pretty large amount of spells, crafting and skills, so it fared well to varied builds. and that was just the 8 basic attributes.


#9

I hate to put numbers on things since in my opinion it depends heavily on the concept and what you need for your game. Myself, I always implement what I feel I need but I make sure that what I do implement is the absolute minimum what I need.

In short I believe it is not as much about the number of attributes, but instead making sure every attribute you add is absolutely needed.


#10

true, if you want to add an attribute it better do something.


#11

This is heavily dependent on your game’s mechanics. In an RPG that strives to be highly realistic, you could have dozens of attributes attached to a character. I’ve played a fantastic professional wrestling simulator that had pages and pages of stats for a single character, maybe in the hundreds if you looked at all the role/class information tracked in other database tables. I’ve also played games with as few as 3 (HP, MP and attack). The stats that you track are more about what you’re trying to do with the game mechanics than the player.

Remember, you don’t have to show the player every single stat that you are tracking internally. Some good rules of thumb are:

  1. If you think the player is going to need to know the stat to make decisions about the character, then you should expose that stat to the player.
  2. If you think the player will be interested in the stat for reasons not directly related to decision-making, then you should at least consider exposing the stat to the player.
  3. If you think that exposing a stat to a player will make it possible to meta-game away the challenge, don’t show them.
  4. If you think that exposing a stat would show information that the character would not or should not typically have, don’t show the player.
  5. If you think that exposing a stat would clutter a player’s brainspace with unnecessary information, then don’t show it.

So, for instance, in a game about feedism, let’s say the character is a feedee, and your game is meant to be relatively realistic, but also include fantastical elements like magic. Often, magic ability is tied to intelligence, so you already immediately have a reason to expose intelligence to the player, so that they can make decisions about character advancement related to magic ability (rule of thumb 1). It’s a game about feeding so you’re going to be tracking weight, and maybe the player wants to know about weight (rule of thumb 2). On the other hand, maybe the character wouldn’t typically know their weight, so while you need to track it, the player doesn’t get to see it unless, for instance, they use a scale (rule 4). Maybe you also want to have a fullness system as well, and impose penalties regarding how full a character is. In this case, you probably want the food volume vs. stomach capacity to be a mystery and part of the game is trying to balance how much you feed a character vs. how much they can tolerate, including steadily increasing capacity over time. In this case, you don’t want to expose the actual statistics about stomach capacity or food volume, because that would allow the player to meta-game away the challenge (rule of thumb 3). Finally, for a realistic simulation, you may also want to track digestion speed in terms of volumes, calories and inefficiencies in the digestion process. This information might be interesting to players, but it’s far more likely that a player will just never use the info directly, and it would just muddy the interface (rule of thumb 5).

However, having said this, I would not use user experience as the first filter for statistics. Instead, I suggest you determine what you want the game engine to be doing first, and then select the stats you track based on that. I’ve seen quite a few games that use the basic D&D stat block, even though the engine never uses intelligence or wisdom.


#12

Based on my own attempts to craft a gaming system (all short lived, never went anywhere), I’d say that the number of different stats should be based, in large part, on what other systems you have in play, because that determines how important the stats are going to be.
If there’s going to be lots of ‘levels’ to character building (things like feats, advantages, character classes, the different pieces that stack up to make a character) then you can probably stick to a lower number of Attributes. Even something as simple as a Brains/Body stat could work, provided that you have details like ‘Education’, or ‘Acrobat’, or ‘Soldier’ to flesh things out.

If, on the other hand, you want to make the attributes the focus, then that’s another thing entirely. If a characters success or failure depends mostly on having a high number in the right attribute, then you may want to raise the number, so that every situation has an appropriate attribute to focus on.


#13

Currently for Corpus I’m designing with 7 in mind because I feel like 6-7 is a good sweet spot. Anything more and you start running into either the problem of useless stats or redundant stats. I think the entire Soulsborne series is a good example of this. As much as I love the entire series of games, It has some issues with it’s RPG mechanics. Demon’s Souls and Dark Souls both had 8 stats, but Luck and Resistance were useless, and Faith and Intelligence were practically the same stat for different types of magic. Both games you can condense to 6 actually distinct stats, and you could further combine intelligence and magic/atunement to streamline even further. DS2 decided to add a ninth stat in adaptability, which actually is too good and a terrible mechanic on it’s own, but you still have needless bloat with resistance and faith. But still, can be condensed to 7 stats with no significant gameplay change. Bloodborne has gotten it the closest in my personal opinion. The entire game is overall a drastically streamlined experience from the main souls series, in a good way. However, even then bloodtinge is still a pretty useless skill that doesn’t really need to be there. And considering the game’s hugely pared down weapon selection, dropping strength entirely wouldn’t have changed things much at all. So in some cases, you can go as low as 4 while still retaining leveling depth. Then in DS3 they returned to 9 stats again, and this time there’s a total of one pointless stat, one redundant stat, and one stat with questionable design. So again, 6 stats would still result in solid design without really compromising player choice.
In general I prefer to try to design by reduction. Just make a big list of every stat that you think might be useful, then start removing ones that are too similar, have little to no gameplay effect, or are “you just need to dump points in this for no reason because it’s too fucking good” stats. ESPECIALLY for action games, if a stat makes the game feel smoother or control more responsively or affects things like IFrames, just get rid of that bullshit. It’s not needed, just make the game feel the best possible from the start of the game.
Of course, this is entirely from a gameplay and systems design perspective, if you’re making something like a tabletop RPG system you have to factor in things like RP affect and arbitrary stat checks.


#14

A lot of good replies so far. I’ll ask a secondary question:

Is it better to have many attributes and no/few skills (like D&D’s Perception, Athletics, and so on), or few attributes and many skills?

Instinctually, I dislike the idea of skills. It’s got a lot of role-playing potential, but I feel like I’d rather have two separate attributes than an attribute and a skill in most cases. Plus, some skills having specific attributes they’re tied to seems arbitrary (like Perception and Wisdom).


#15

skills are nice in character creation where your class is less important; like if the archtypes of characters are far more basic, then more skills allows you to diversify that basic class into your ideal character. on the flip side, having more base skills allows for easier checks, such as strength checks being generalized to a lot of different things. more base skills connects well to more defined character roles, as your role in the story or in your party is clearer, and requires less diversity (as that has already been defined by your choice of class).

personally, I like having more open-ended choices and many more skills to choose, as I enjoy mixing and matching skills and abilities to suit my playstyle, or the current situation. I never like to play games with the same “loadout”, and while I have my favorite styles, I always like to tweak the specifics and see what happens.

ALSO, there’s the nature of some base abilities tying into skills. one of my fav RPGs, Arcanum, had a system where there were many skills you could learn, but your character needed the appropriate base ability to improve them. for example, the basic “melee” skill could be upgraded at dexterity 6, which was below average. however, the next upgrade required dexterity 9, and so on until the skill is maxed (which provides guaranteed hits against most enemies, compared to a 50/50 chance against weak enemies at the base level). obviously you don’t get near the max level until quite late in the game, but this gives a sense of progression and almost realism in the idea: you can’t fight any better until you are physically able to, and so on for other skills: can’t magic harder until you are wiser, can’t craft better until you are smarter, etc.

all this being said, for a fetish game such as what you’ll see around here, more basic attributes are probably more feasible, and easier to work with when your attention is drawn elsewhere. like MOP said, other statistics and skills come into play here that you won’t find in traditional RPGs. like obesity. :kissing:


#16

Base attributes must be used in most contexts, if a base attriute is rarely used, it shouldn’t be a base attribute.

For example, let’s say that one of your stats are evasion, but that all moves normally have 100% accuracy.
It doesn’t matter unless you’re in a special condition that happens to lower the accuracy of said moves.
Why would evasion be a base stat?


#17

Just because you have a stat doesn’t mean you necessarily have to use it. How often do barbarians make intelligence checks? :stuck_out_tongue:


#18

Regarding skills, I would say that skills are just another stat that may or may not be useful for the user, and really depend on the kind of game you’re trying to build and the user experience you want to create.

That being said, and while I do stand behind my previous answer and don’t want to tell anyone what to do with their games, I would caution against having large numbers of statistics. Of course, if you are trying for a highly realistic simulation-style RPG, then it’s going to be difficult to get around large number of stats. But, honestly, for the vast majority of use cases, much simpler systems will tend to work better in the long run.

The fewer mechanics you can get away with, the easier development is going to be and the more likely you are to finish the game. If you have a huge number of stats, then it can be confusing to the player and create a large learning curve to play and enjoy the game. This affects how popular the game is, and if a game has less support, then it’s less likely to end up getting finished. The more complicated your mechanics, the harder it is going to be to get other developers to be interested in helping you with your work, making it less likely that, you guessed it, the game will be finished.

Also, the more complicated the game mechanics, the harder it’s going to be to expand the content of the game in the future. The professional wrestling simulation I mentioned was, truly, a magical feat of modern software engineering, and I was thoroughly impressed by it. But, when I tried to create the GLOW characters in the game, the complexity of the system was so high that what should have been a simple user workflow turned into a massive undertaking, requiring changes in dozens of database tables at a minimum, and interaction with a database tool that was significantly less magical than the simulator itself.

I definitely don’t want to discourage people from making highly realistic gaining games. I would love to see something like that made. But if you are on the fence and just want to make a game that’s fun/sexy, works, and is easy for players to get into, I’d say reduce the complexity as much as you possibly can to still get the same user experience you imagine it should have.

And, yes, I was obsessed with the first season of GLOW.


#19

To Gonkulous

Depending on the game, anywhere from ‘never’ to ‘very often.’ In my experience, its better if the ratio leans towards more, rather than less. It’s helpful to balancing a game, where being weak at something affects the game just as much as being good at something.