Skills, the grouping and arranging of - Responses?

[Autocrat]

Alright then, second attempt, this one a little more detailed..... hopefully!


SO, my questions are;
*If playing this system, how do you think you would find the rules outlined below?  Would they be acceptable, enjoyable, or plain naff?
*Do you think the organisation is useful, both for locating and for play using the defaulting rules outlined below?
I*s there anything specific that you consider incorrect, wrong or that is likely to have a negative affect on play?
*Have you seen similar, did it work, or can you give me details regarding it?
*Any pointers you would care to make?

OK, I have a System ,(INI), that is very broard and has a large amount of scope.  It is intended to permit players to enjoy a varity of gaming styles.  The method of organising the skills and how they work is meant to loosely resemble our reality, yet is more considerate towrds gameplay, application of skills and chances of successfully attempting tasks.  The groupings are flexible, permit crossovers and repeatitions of skills in different groups.  The groups aren't meant to be Classed or stereotypical in the Class/Kit sense, yet are meant to follow logical and obvious routes as to what goes where.

MY personal preference is detailed, yet not complex.  Below is an example of how skills work;


Skill Mechanics.
All Skills are related to a Character Statistic/Attribute, (which is listed next to the skill!).  Together, these form the base Score/Chancess for success, (Stat + SKill).  Every LEvel of Skill is equal to +10%, thus having a Stat of 20 and a Skill of 4 would equal a base score of 60% ,(ST 20% + SK 40% = BBS 60%), which is then modified by difficulty, (Diff), which ranges from Diff 0, (Easy at +15%), through to 10, (nigh impossible at -70%).  When you apply the Diff to the ST + SK, then you have the bsaic formula for figuring the Target Number, (TN), to successfully attempt the task at hand.  You merely roll a D100, any result of equal or lwer value than the TN is a success.

Example: 1.  (Mechanics)

ST 20, Sk 3, Diff 5 =
ST 20% + SK 30% + Diff -30% = TN 20%, (1 to 20 is a success!).


Layout.
Skills are formed into loose groups, called Title Groups.  These are simply a way or gathering together a large number os detailed skills so that locating them should be somewhat easier for Players.  These groups are then divided and sub-divded several tiomes, each group getting more detailed and specific.  See the example below to see what I mean;

EXAMPLE: 2a.  (General Layout)

TITLE GROUP
*...Main Group
**......Sub-Group   (Associated Skills)
***.........Individual/Specific Skill   (Related Skills)


EXAMPLE: 2b.  (Layout)

Weapon Skills
*...Swords
**......Large Swords
***.........Flamberge
***.........Claymore
***.........Two-Hander
**......Medium Swords
***.........Long Sword
***.........Cutlass
***.........Sabre


Basic/Advanced/Optional use of Skills.
Depending on Player Preference, Either the Sub-group OR the Individual SKills can be used as the main way of generating a Base Chance of Success.  This means that if Players want to play Basic Rules, or to save time, then they simply learn the Sub-Groups, so they could learn Large Swords, Sport Car, Riding Land based Animals, etc.  If on the other hand they want to play with more detail, then they can learn the Individual SKills instead, (those that appear within a Sub-group!).
The simple reason for this is that different people want different things.  Further, depending on how people play, it permits different emphasis to be applied to the game.  Combat based games may have high detail, )individual skills) for Combat, yet have low detail, )sub-groups_ for non-combat skills.
Addiotionally, it is possible to go even further, and advance into tailored or specific skills, such as not just having the Individual skill of Gem Cutting, but you could specialise in Diamond Cutting, thuis you could get Gems, yet would be better with diamons etc.

Defaulting.
There is an optional rule called defaulting.  This means that if a Character is attempting a Task they lack the skill for, then they still have a chance at success.  There are several different methods of defaultiong.
Stat Default: - This means that the Character relies on the related Stat for their base chance of succes, without any skill Modify.  SO for weapon usage, they would use only their Attack Rating Stat, for picking a lock, they would use their Co-ordination Stat, or for using a Psionic power, they would use their Focus Stat.  Any such attempt at defaulting to stat also incurs a Unskilled Penalty, lowering the chances of success and reflecting the affects of lacking any skill whatso ever!
Related Default: -This means that the Character lacks the relevant skill, yet has one in the same Sub-group, which they can default too.  So, though skilled in the long sword, the only weapon to hand is a sabre, so they may attempt to attack with the sabre, yet using their long sword skill, at a slightly lower level as a penalty for the lack of specific skkil in that weapon.
Associated Default: - This means that the Character is attempting a Task they lack the relevant skill for, yet they have a skill in a sub-group under the same main group, foe example, they may attempt using a Short Sword whilst having skill in a Log Sword, (two seperate Sub-Gropups under the same main group!).  THus results inthem using the stated skill whilst using a different weapon, and receiving a moderate penalty for doing so!
Obviously, considering the Hi/Lo detail for skills, certain forms of defaulting may not be available!



There, that make more sense?
Is that better?

To repeat the questions......
SO, my questions are;
*If playing this system, how do you think you would find the rules outlined below?  Would they be acceptable, enjoyable, or plain naff?
*Do you think the organisation is useful, both for locating and for play using the defaulting rules outlined below?
I*s there anything specific that you consider incorrect, wrong or that is likely to have a negative affect on play?
*Have you seen similar, did it work, or can you give me details regarding it?
*Any pointers you would care to make?

[montag]

To repeat the questions......
SO, my questions are;
*If playing this system, how do you think you would find the rules outlined below?  Would they be acceptable, enjoyable, or plain naff?
*Do you think the organisation is useful, both for locating and for play using the defaulting rules outlined below?
I*s there anything specific that you consider incorrect, wrong or that is likely to have a negative affect on play?
*Have you seen similar, did it work, or can you give me details regarding it?
*Any pointers you would care to make?

The rules are ok AFAICT, with the exception of skills, where the multiplication seems unnecessary. Why not have them going from 1-100 as well? I definitively wouldn't want to play the game though.
The organisation is ok, any organisation of lengthy skill lists is arbitrary to a certain degree.
I found long skill lists have a negative effect on my play since too much time is spent finding the relevant skill for a particular situation.
Similarities: AFAIK GURPS, Rolemaster, Multiverser, OSIRIS (German), possibly JAGS

As I said, I definitively wouldn't want to play (a) because I don't like lengthy systems (complexity is another issue) (b) I'd pick up one of the aforementioned systems if I wanted something like this, after all, why shouldn't I? In which case I'd take GURPS, simply because I loathe the uniform distribution the d100 produces.
<This post on personal preferences is almost certainly totally useless, in marked contrast to the good advice offered to you in that other thread. I merely replied to be friendly and perhaps make you see the point of the earlier suggestions, once you realise the dubious to nonexistent value of my personal preferences to your design. Good luck!>

[Shreyas Sampat]

Can you provide a more rigorous definition of a title group?

If each Individual Skill appears under only one category (that is, the skill groups branch, they aren't alternative paths to the same destinations), then it would be helpful to know exactly what a skill group means, so I know exactly where in my skill list to look.

[Walt Freitag]

I dislike the skill systems of this general type that I've tried, because sooner or later (usually sooner) I'm going to run into situations where the system says one thing and common sense says another. Then I either go with common sense or I don't -- and in either case, what good is the system doing me?

Suppose a character has a "drag racing" skill, and another has the "highway patrolman" skill at the same level. Neither character has the "NASCAR racing" skill. Both attempt to drive in a NASCAR race. Who should have a better chance of performing well (not winning, of course, which should be practically impossible for either one, but let's say successfully impersonating a real low-ranking NASCAR driver)? Chances are, your default system will give the better odds to the drag racer, because it appears when you're working out the skill tree that drag racing is more closely related to NASCAR racing than being a highway patrolman is. (And for many situations, that's true. The drag racer would probably have a pretty good idea of how to assemble a good pit crew and negotiate with sponsors to finance a race entry, while the highway patrolman would have no clue.) But in this case that's wrong. The highway patrolman probably has a better grasp of the basic driving skills used in a NASCAR race (negotiating curves, controlling slides, defensive maneuvering, etc.) than the drag racer does.

The lesson here is that the applicability of a "related skill" to a challenge depends a whole lot on the exact nature of the task. To give a real-life example, I know some programming languages and don't know others. (This would presumably be title group: cybernetics, Main Group: programming; Sub-group: the type of programming [system, database, applications, etc.]; Individual: the programming language -- or the last two could be reversed in the hierarchy.) If you give me a task of reading source code in a language I don't know, to figure out what the code does and how to alter it, I will be nearly as good at it as someone who does have experience in that language, because most languages have fundamental similarities. If you give me the task of writing a program in a language I don't know, from scratch, with no manual, I will suck at it compared with the person with experience in that language, because all languages have fiddly little details that have to be done right to get a program to work. In the first task, the fiddly little details don't happen to matter much; in the second, the fundamental similarities don't happen to matter much.

Note that this is not simply a case of one task being more inherently difficult than the other. Either task could be of any inherent difficulty. It's that one task is more dependent on more specialized ability than the other. So one task is relatively more difficult for me, compared with someone with a more specific expertise, than the other one is.

So why is this a problem? Do these sorts of differences in skill cross-applicability for different tasks really cause problems in play? Well, in my experience, usually not. What usually happens is that the GM takes into account any difference between the applicability of the related skill based on common sense, and the applicability of the related skill as suggested by the system, by adjusting the difficulty rating. "You're a champion drag racer, but this NASCAR race is on a track with lots of challenging curves, so the difficulty is 5 for you." Or: "You've never raced professionally before, but your experience with high-speed chases on Mulholland Drive makes this crowded curvy track seem just like Beggar's Canyon back home, so to speak, so the difficulty is only 3 for you."

But if I'm going to make those judgment calls as a GM, what's the benefit of having all the detailed skill ratings in the first place? Let the highway patrolman, the drag racer, and the NASCAR driver all have some level in "vehicle," and I can make the same kind of adjustments to difficulty on the fly to take each character's actual background and skill specialization profile, and the nature of the task, into account. It comes out the same (and, to use some newly coined terminology, involves the same amount of "back sourcing").

The other frequent problem with skill hierarchy systems is that players who create characters with a group of skills that happen to match the way the hierarchy has chosen to group skills get a big effectiveness advantage over characters with an equally conceptually unified group of skills that happen to fall into many different categories. Usually such systems give a purchasing discount to multiple skills in the same branch of the tree (by discounting skills related to skills already purchased, or by permitting a whole group of related skills to be purchased at a higher price but a better deal overall). Or they allow free use of skills related to skills already purchased at a slightly reduced effectiveness level, as your default mechanism does. So one player has a character concept "guy who shoots guns a lot," while another has "detective." The gun nut buys a lot of "shoot little guns" skill and thereby also gets a lot of "shoot bigger guns" skill for free (using default) or at a reduced price (using discount purchasing for "related" skills). The detective also buys "shoot little guns" and therefore in theory he could also shoot bigger guns pretty well (or acquire the shoot bigger guns skill very cheaply), but he doesn't want to. He wants to do other detective stuff like "find info from the records at City Hall" or "identify fiber traces." Too bad for him, those skills are in entirely separate categories. He has to pay full price for them (or equivalently, he gets no default opportunity between one and another). So the every-size-gun guy will advance much faster than the detective, whose plausible skill set happens to be more widely dispersed in the taxonomy.

This all happens because the system designer has decided that "different size guns" is a more important commonality between skills than "different things a detective can do." It's not. It's. Just. Not.

Now, I'm not saying your system has these problems. I don't know enough details about it to tell. But these are the reasons I haven't found rigid skill taxonomies to be useful in systems I've tried that had them.

- Walt

[M. J. Young]

O.K., here are some of my thoughts/responses.

Stat+Skill: is there a particular reason why you are doing it this way, or is it merely that's how these things are done? Note that I'm not against this approach--Multiverser uses it. The problem is that particularly if you've got a very large skill base, it leads to system quirks in which it is best to buy your skills at low levels and kick your attributes up to high levels. (Multiverser overcomes this by putting certain aspects of skill use, such as speed of use, in the skill ratings only, so a level 2 skill/level 1 attribute will be faster than a level 1 skill/level 2 attribute, even though chance of success will be the same). In general, you should have a reason for this as a design decision, because it's easy to break and popular enough that most players know how to break it.

20%: I trust that example is not expected to be typical. That's a high whiff factor. I think any game in which a rank amateur of ordinary ability has much less than a 50% chance of success at typical game tasks has got a problem. Check how hard you're making it, because it is possible to create a design situation in which the characters succeed so rarely they can't progress.

Subgroup versus Skill: is this something that has to be agreed by the group, or is it possible for different players in the same game to play together effectively if they're using different granularity here?

Let me point to Multiverser's narrowing of scope rules. Similar to yours, there is a general, a sub-group, and a specific level. With swords, it would be Swords-->Katanas-->My Katana (with non-weapon skills it is looser, such as Motor Vehicles-->Race Cars-->Dragsters). A skill at the lowest levels is always in the general group; it moves to the subgroup when it reaches "professional" level and to the specific level when it reaches "expert" level. Thus the granularity is consistent for all players, without conflict--someone not terribly interested in being great with swords can just be "sword" skilled, while someone for whom this is an important part of play can develop high levels of skill in specific weapons.

(Forgive me for constantly pointing to Multiverser. I addressed a lot of the questions you seem to be asking when I worked on that, so I'm very familiar with the answers we gave to them.)

I hope this is helpful.

--M. J. Young

[komradebob]

If you can get your hands on a copy of 1st ed Paranoia with its skill trees, you might find some kindred spirits in its designers. OTOH, you might want to check out the designer comments from 2nd ed to see why they revised that system.

[John Kim]

*If playing this system, how do you think you would find the rules outlined below?  Would they be acceptable, enjoyable, or plain naff?
*Do you think the organisation is useful, both for locating and for play using the defaulting rules outlined below?
I*s there anything specific that you consider incorrect, wrong or that is likely to have a negative affect on play?
*Have you seen similar, did it work, or can you give me details regarding it?
*Any pointers you would care to make?

I agree with other commenters that the three-level tree tends to result in counter-intuitive relation of skills.  I dealt with this in CORPS, which has similar trees of primary, secondary, and tertiary skills.  One problem I find is that when you create a real set of categories, there is usually a lot of cross-fertilization which should appear (i.e. a narrow skill which is influenced by more than one broad category).  In other words, real skill diagrams are more like webs than neat hierarchies, in my opinion.  Two levels is OK, in my experience, but three starts to show holes.  Of course, Shadowrun explicitly has a web approach, but that gets complicated very fast.  

CORPS has the added problem of forced detailing.  Because of how the point system worjs (cost = square of skill), it is helpful to advance on all three levels for even moderate skills.  This means that character sheets turned into quite a mess.  

Also, I would be wary of aesthetic demands vs functional demands.  For example, a lot of modern games insist that, say, languages have the same ratings and mechanics as combat skills.  Now, aesthetics can be important, but I think it is good to question this.  IMO, having a separate case for languages can be simpler and more intuitive than trying to explain how to use the same mechanics for both languages and combat skills.  The point for your game: trying to get all conceivable types of human knowledge and activities to fit into a consistent three-tiered hierarchy can lead to some mental acrobatics to make everything fit.  Be sure that this really fits with how you want your system to work.  

In practice, the more system-defined skills you have, the more work it is to write them and the harder they are to learn.  If the skill isn't actually any more detailed or described than just a name, then in practice there is very little difference from freeform skills like Over the Edge, Unknown Armies, etc.

In short, I'd recommend broader categories and two levels instead of three.  However, I have my own biases on that.  It's the logic of trade-offs that I explain which is important.  If you think the trade-off is worth it, then obviously you should go with what you're most comfortable with.

[Autocrat]

Thank you....a much more pleasurable set of responses...lovely!

now then, in order......

... montag ...

"... I found long skill lists have a negative effect on my play since too much time is spent finding the relevant skill for a particular situation. ..."

  Yep, I can see that is a potential problem.  The only solutions I can think of are 1) create the groupings to follow obvious logic ,(yeah, right! LOL), or 2) provide the DM's book with an alphabetical listing of skills, accompanied by the related stats!

"... GURPS, Rolemaster, Multiverser, OSIRIS (German), possibly JAGS ..."

  Well, I liked Gurps ( + Murps), looked at OSIRIS, and JAGS was OK, yet my bugbear with them was they tended to be complicated on the workings out, with odd little equations, compounded and extrapolated modifiers etc.  Prefer simple A + B +C = D, easier and quicker.  Yet Gurps, as well as Shadowrun, Fallout and AD&D are the main influencers for me, (both good and bad!).


... Shreyas Sampat ...

TITLE GROUP.
  Merely the label used for a generalisation of the Main/Sub/Ind Skills contained.  Examples are COMBAT, VEHICLE, SURVIVAL and SOCIAL as Title Groups.

MAIN GROUP.
  This is a collection of Sub-Groups and the Individual Skills contained in each Sub-Group.  Some Examples include Swords, Aero-vehicles, Basic Survival and Public Communication.
  Main Groups tend to have several Sub-groups that are related to each other, thus under Swords, you would have Large, Small, Fencing etc.  These are termed as associated.

SUB-GROUPS.
  These are the more defined groupings of individual skills.  Sub-groups are collectiones of related Individual skills, some examples would be Small Swords, Cars, Subsistence and Public Speaking.

INDIVIDUAL.
  These are the detailed and distinct Skills, contained within a Sub-GRoup.  Some examples would be Short Sword, Saloon Car, Hunting and Oratory.
  Individual SKills within a Sub-Group are termed as related, and are considered to be closely interlinked, requiring similar application of motion and thought.


... Walt Freitag ...

OK, brilliant explanaitions.  Yet I wouldn't have the groupings as you suggested.  To me, any form of vehivcle use like that would appear in the same skill Sub-Group, so both Highway man and Drag Man would get the same modifier for Defaulting skills.  Further, the Difficulty would probably vary, depedning on the experience of each and the DM's decisions.  If defaulting, then a base Modifier is used for Difficulty, otherwise you'd have to list umpteen different difficulties for different terrains bsaed upon different skills.
So, the check would be bsaed upon the Skill, the base Stat, then the Driving difficulty of the vehicle they use, (optional), and the difficulty of the race/track.  The person with NASCAR would get Difficulty AAA becuase thats the difficulty set for the race/track.  Highway Man and Drag MAn both get the same difficulty, yet suffer a negative modifier due to their defaulting... so even if all had Level 5 in their respective skills, the NASCAR Man is more likely to succeed due to having less negatives against him!
Make sense?

The programming one I liked too.... it highlights a major problem with most RPG's, no matter the skill system... It shows that no matter the balance of detail to generalisation, theres always a slip up compared to reality, and the only way to have it exactly is to have so much detail you'd use a tree just for the skill section of the rule book!
So instead, you generate mechanics that cover it, right?  Or leave it for adjudication of the DM, Right?
So, why not have a Modifier based on reference/Knowledge material to hand, as well as the appropriate skill.  That way, if you have source code, you can default to your skill, and suffer a default modifier thats negative, gain a slight positive modifier for the refrence/knowledge of the code, and have a moderated success chance, or you could attempt to do it without reference,m and have a greatly reduced chance due to attempting to default and having a high difficulty!
Make sense?
Or you can let the DM decide.

As for the problems with skill groups etc....not to sure that I agree.  I can understand people assuming that the rules favour certain actions, yet when you default, its at a reduced affectiveness.  Further, the different types of defaulting result in more negative modifiers, (Related =-2, Associated= -3, Stat = -4 or whatever!).
Also, those that wish for certain skills should have them.  If defaulting is used, the more skills you have in different sub-groups and main groups, the bigger selection of skills you can default to.  It's those that specialise and spend CP's purchasing lots of different Little Gun skills that should suffer, right?  Well, not exactly, becuase if they defalut to a different little gun skill, then they still have a fair degree of chance with it, as they are likely to know it, or have such high skill that the defalut modifier will leave them with a good chance of success anyway due to how skilled they are!
Have considered enforced purchasing, having to buy into different groups etc., yet this means requisites, which are unfair and result in skill specialisations, as you would loose a lot of Points just to get the odd skill here and there, where as you can save them if you only choose skills from those groups you've already bought into!
Further more, you assume that the skills lean towards weapons.  The reason for this post is to ask and recieve feed back on the types of skills and groupings of them that people feel games should have yet often lack!


... M. J. Young ...


STAT + SKILL.
The reason is simple, it covers both sides of Nature vs. Nurture, it reflects what I feel is corect about natural talent and training, and it's simply calculated.
As for breaking it...difficult to predict.  Yet to help prevent it, skills range in cost between 2 and 12 CP's, (depending on the skill and its uses, the time period, commanility etc.), plus the skill cost increase with each level.  The Stats cost a set amount, (currently 10), so at least to begin with, the skills are cheaper and will have more immediate affect.
Further, increasing a skill grants a +10% Modifier per level, where as increasing a stat only grants a +1 Modifier...so which would you go for?
(the math is simple, skills are more affective, show greater improvement more rapidly and get you where you want fast...stats take time, improve a lot of things by only a little, and take far to many Points to change enough to warrant it to often).
Thegame should permit Characters to improve Stats, yet only by a little, (unless its a super game, in which things might be different!).

20%.
Well, the thing is, you don't roll unless necessary.  Having no skill, (0), means you have to try and see, or you just can't.  having a little skill (1-3), means you can do the basics without worry, yet difficult things you may have to roll for.  Any higher than 3 means you are going above standard skill levels, reaching into mastery etc., so normal and slightly difficult tasks are needed for rolling, yet very difficulkt etc. can still be rolled.
It's basically using common sense...having the DRIVE CAR skill and rolling every time you start the ignition is stupid.  Only roll if they have to avoid an accident, or race, or do something flash or diffiuclt.
Make sense?

Individual vs. Sub-group.
Not sure on this one.  I know that every one using the same is fine.
I know that it's possible to "bulk purchase" a sub-group.
In theory, we have it so you can use both at the same time, yet having tested it properly yet!

As for the example you provided, am I right in saying that you are general to begin with, yet get more detailes/specialised as you increase in level?
If so, what happens if you want to have several skills branch of together, so you are skill with several weapons simlar to Katana's?  Or if you want to stay generalised, yet keep improving?


... John Kim ...

It really depends on how definitive you are, and how you categorise the skills.  By having the TITLE GROUPS fairly well defined, it makes life easier.  You shouldn't find Combat skills in SOcial groups etc.
What you should and will find is individual skills appearing in several Main and Sub-groups, as this is natural... for example, intimidation might appear in several groups, such as interrogation, private interaction and public interaction, as it is likely to be used in various social occassions and environments.
As for shadowrun, I liked it alot, yet found the rules to be convulted and difficult at best, as there was little in the way of explanation or example.  once you figured it out, it was really quite simple, yet covered with a lot of unnecessary text! LOL

Forced tiering is a slight problem, as we tend to categorise and detail things differently.  The trick is figuring base common factors and working from their.  The real problem is that things fit better into four and five levels than in three's, yet that was just far to much and to many levels for people to grasp easily enough!

As for broad and general, thats why I have it that you can use  the Sub-groups instead.  I know that somepeople prefer the more general approach, and so have provided it, with a fairly simple addition for those that want ore detail.
Does that saound


ok, as some people seem to think you should only do one or the other?


well, thak you all again!
still, if there are any suggestions or alternatives, plese suggest them.  I am rethinking the system over, and am willing to make changes, yet i must state that I do like what i have, and have found it to work!  (as yet, I don't seem to have had the majority of the problems people have suggested, guess I'm just lucky in the way I grouped things!)
Yet if someone can make a case for something different, then i am willing to listen.

[Jason Lee]

I agree with other commenters that the three-level tree tends to result in counter-intuitive relation of skills.  I dealt with this in CORPS, which has similar trees of primary, secondary, and tertiary skills.  One problem I find is that when you create a real set of categories, there is usually a lot of cross-fertilization which should appear (i.e. a narrow skill which is influenced by more than one broad category).  In other words, real skill diagrams are more like webs than neat hierarchies, in my opinion.  Two levels is OK, in my experience, but three starts to show holes.  Of course, Shadowrun explicitly has a web approach, but that gets complicated very fast.  

CORPS has the added problem of forced detailing.  Because of how the point system worjs (cost = square of skill), it is helpful to advance on all three levels for even moderate skills.  This means that character sheets turned into quite a mess.  

Also, I would be wary of aesthetic demands vs functional demands.  For example, a lot of modern games insist that, say, languages have the same ratings and mechanics as combat skills.  Now, aesthetics can be important, but I think it is good to question this.  IMO, having a separate case for languages can be simpler and more intuitive than trying to explain how to use the same mechanics for both languages and combat skills.  The point for your game: trying to get all conceivable types of human knowledge and activities to fit into a consistent three-tiered hierarchy can lead to some mental acrobatics to make everything fit.  Be sure that this really fits with how you want your system to work.  

In practice, the more system-defined skills you have, the more work it is to write them and the harder they are to learn.  If the skill isn't actually any more detailed or described than just a name, then in practice there is very little difference from freeform skills like Over the Edge, Unknown Armies, etc.

In short, I'd recommend broader categories and two levels instead of three.  However, I have my own biases on that.  It's the logic of trade-offs that I explain which is important.  If you think the trade-off is worth it, then obviously you should go with what you're most comfortable with.

I'm in agreement that two is better than three.  Third tier skills tend toward either a skill that is relatively useless (Hearth:Child Care:Toddlers), or toward a skill that is functionally identical to the preceding tier except cheaper (Firearms:Handguns:Revolver).

The approach we are currently using is two tiered. The first tier being very broad, with the option of multiple second tier skills that are open to player definition.  Such that normally, you might have: Survival 2:(Tracking 3, Jungle 4), but you would also be allowed to have Survival 2:(Dinner Parties 5) - lame though I think that might be.

As for languages, I agree handling them differently is often easier on the brain.  We've decided to treat them as a special case by just skipped the first tier and making them equivalent to second tier skills, permitting purchase of however many you like.

Response to this approach in our group has been mixed so far, but those are our solutions to some of the issues with skills tiers that have been raised.

EDIT:  Oh, BTW - John's right.  Character sheet design is a pain in the ass for skill tiered systems.  As I think user interface is very important, that's another good reason for only two tiers.

[M. J. Young]

TITLE GROUP.
  Merely the label used for a generalisation of the Main/Sub/Ind Skills contained.  Examples are COMBAT, VEHICLE, SURVIVAL and SOCIAL as Title Groups.

You've still got the problem that these "Title Groups" mean different things.

I was going to use intimidation as an example, noting that in your response to John Kim

You shouldn't find Combat skills in SOcial groups etc.

I immediately thought of the samurai facing each other in the street without drawing weapons until one backs down, conceding defeat; and the corresponding face-off between the lover and the husband staring each other down at the cocktail party until one blushes and turns away. Both are intimidation, but is the skill combat or social, and is it significantly different either way? That is, if the samurai were the husband and lover, would they use the same skill at the party that they would in the street, or a different one?

I see the same overlap between combat and vehicle. I knew a guy who played a hunter in a Vampire game, and "vehicular combat" was one of his skills. In essence, he knew how to kill a vampire by attacking it with a car. Is that vehicle, or combat?

Your problem is still that these are not the same kinds of categories. They're like dividing animals thus:

[*]Animals that can be domesticated.[*]Carnivores.[*]Animals that live in water.[*]Animals that fly.[*]Animals smaller than a large coin.[/list:u]A lot of animals land in several categories because the categories themselves are based on completely unrelated factors. Divide animals by food source or habitat or size or abilities, but don't mix categories. So, too, divide skills into categories that are all based on the same concept. Don't have "combat skill"; have "weapons skill". Make all skills about what is used. Or else, keep "combat skill" and recognize that you are dividing skills by purpose; so discard "vehicle" in favor of "transportation", and put "manipulative" for "social"--get it clear what the core element is that makes a category one of the top divisions, or the top divisions are worthless due to excessive overlap (too many skills can be in every category).

Now for the question you asked me.

As for the example you provided, am I right in saying that you are general to begin with, yet get more detailes/specialised as you increase in level?
If so, what happens if you want to have several skills branch of together, so you are skill with several weapons simlar to Katana's?  Or if you want to stay generalised, yet keep improving?

You are correct.

Using swords as an example, the game assumes that to a certain point in your learning, a sword is a sword. Whether it's a katana or a claymore or a rapier isn't going to make that much difference in your ability to weild it. However, when you get past that point--if you become professional, in game terms--suddenly it matters. If you've practiced with a katana all this time, you are not going to be as good with a claymore. You're still going to be good (because of the skill narrowing, your professional skill with the katana inherently means a high amateur skill with sword), but if you've never even used a rapier you can't pick it up and expect to have that level of skill with it.

Now, if you've got the rapier and the claymore in addition to the katana, and you want to be good at all three, that's fine--as long as you work with each of them to improve your technique with them. You're still going to be an amateur (a good one, but not near your skill with the others) the first time you pick up a saber, though--it's an unfamiliar weapon, although it's still a sword.

It is also assumed that specialization is inherent in mastery. For example, the head of my department in Biblical Studies at Gordon got his Ph.D. in the use of a particular Hebrew particle in the Psalms. He probably has a better grasp of a very narrow area of that language than most experts (and has been called upon to assist in modern translation efforts). That's not the limits of his knowledge of Hebrew, obviously, but the further he gets from the center of his expertise the more likely it is that there's someone available to whom he would defer as better. Leave the Hebrew portions of the text and he's not in any way lost, but he's no longer an expert.

It is said that a specialist is one who learns more and more about less and less until he knows everything about nothing, and that a generalist is one who learns less and less about more and more until he knows nothing about everything. I'm a generalist. I'm not ashamed to admit it--there is nothing in all my realms of knowledge on which I would be your best authority (well, Multiverser questions, I guess; that seems to be a bit like saying I'm an expert on my own life). I can see quite clearly that becoming expert in one area means sacrificing others; specialization is about narrowing the scope of the subject for the purpose of refining the ability. Sure, Etienne de Navarre can fight incredibly well with any sword; but give him the one that has been in his family for generations and he cannot be beaten.

That's how the narrowing works. If you still want to diversify and reach such levels of ability, you must improve each skill independently; and we then perfectly expect that you may be professional in your ability in several different kinds of swords, but better at one than another.

Helpful?

--M. J. Young

[Autocrat]

Now you see, this is the point when I get really confused, and admittedly, highly annoyed.

You see, from day one, the primary thought of the design was to permit flexibility.  we decided that the main areas to be flexible and permit differences were
1) SKills  (general and detailed)
2) Amount of Stat Detail for Equipment (basic and advanced)
3) Stats (Basic and Detailed)
4) Resolution Method.  (D100, Multiple Die, Diceless etc.)

So thats what we did.
There are two main reasons for this.
1) We wanted these things.
2) We kept hearing others say how they wanted these things.

Yet, now that I have rumaged, pushed, tweaked, rewrote and juggled things, (actually I'm exaggerating, it was actually quite simple ! LOL), all I get is 2 types of response.... 1 group say its too detailed, and to specific and too much work, the other group says not enough, why have basic etc.

So the only answer I can conclude is that every one is different, they prefer their own works and don't like seeing others do something different.

To the point, I've even had people slam me, then they have posted an almost identicall approach!

So, is this the normal occurence of such things?




... Cruciel ...

Now you see, what you suggested I have seen a lot, take Shadowrun for example, or Alternacy, or a host of others.  Yet I've noticed that they tend to either be really general and broad, with little actually stating what covers what, and relying on the players to decide, or they are open ended, and leave it to the players to decide what does what and how.
This is fine for people that have played and are used to RPG's , for newbies or those that prefer hard rules, it's of little use from my experience.

Also, you mentioned having languages as handled differently, yet all I hear is people moaning about extra mechanics, so many different ways of doing things, yet people keep generating different methods of handling similar stuff.
If you handle the other skills as 2 tier, why not languages?  If you give me some examples of how you use languages, it shouldn't be hard to figure  a simp[le 2 tier approach!


... M. J. Young ...


Ah, now you've hit on a difficult point....all skills can be used for different purposes than originally intended...particularly for violence.  Yet the example you gave of intimidation and samuria is not a combat skill, it is before combat occurs, and it relates to two people interacting, so definitely social....see?

Yet the point you made still stands.  The real problem is figuring what goes with what, and how.
So you relate by implementation.  If it is specifically or initially tened towards a thing, that is the group it belongs in, thus vehicle combat comes under vehicles.  Weapons under weapons, fighting styles etc. under combat, social skills under social etc.

Whether using a single, double, triple tier system or not, it still works the same, right?

Animals is a pain, yet I think they are currently organised the same as vehicles, by terrain type..... I klnow I have an old list by species type, (mammal-feline, mammal-canine etc.), somewhere on a CD though!



So, by going from what I put at the start of this post, I feel I'm rapidly comming to the point where I'm just going to say stuff it, as I can't seem to put things across in the right manner to evoke the responses I am after with out bending over backwards all of the time, I just get to much #### thrown at me first to warrant it.

So, thank you for the posts that were helpful and pointed out problems... I really do appreciate it when there are pleasent people out there!

[Eero Tuovinen]

So, by going from what I put at the start of this post, I feel I'm rapidly comming to the point where I'm just going to say stuff it, as I can't seem to put things across in the right manner to evoke the responses I am after with out bending over backwards all of the time, I just get to much #### thrown at me first to warrant it.

Hey, I don't see anyone throwing anything. People are just pointing out things they see as problems. It might be that they don't understand what you are going after, but then, it's a good place to practice, isn't it? You'll have to put your stuff in words at some point, if you want someone to understand your system.

Anyway. From what I've read here, it seems that the main problem people have with your model is that they see it as terribly old-fashioned. This is an approach that, as far as people here see it, has been used and proven unsuitable for most things they want from a game. Don't you see them bending backwards about it, how they try to point out objective reasons for not doing another overcomplicated sim exercise?

For the record, I designed a while ago a similar, skill based sim system. I offer for my defense that the layers are optional, skills are player defined, there's no stats and there's strong methods for genre simulation as well, traditionally lacking from these. But I can understand what you are going for, sort of. I of course think my own approach superior ;)

The point is that your kind of system really isn't new, exciting or useful for these guys. Almost all people in Forge have been hooked with highly specific, economic design philosophy. What you're doing is just not fashionable here, just check out what gets written about and what doesn't. After a certain point, if you prefer your own design, you should just go with it. These people have pointed out what they think could be improved, but you cannot make them love your game.

This isn't to disparage your system, by the way. Although Forge is technically for all indie design, in practice it, like all forums, has limits in it's participant base. We just don't seem to draw too many people who go for this kind of thing. You have to decide for yourself if that's because your system really isn't as good as it could, or if we just don't have your kind of experts.

I'll answer your original questions as well, while I'm at it.

SO, my questions are;
*If playing this system, how do you think you would find the rules outlined below? Would they be acceptable, enjoyable, or plain naff?
*Do you think the organisation is useful, both for locating and for play using the defaulting rules outlined below?
I*s there anything specific that you consider incorrect, wrong or that is likely to have a negative affect on play?
*Have you seen similar, did it work, or can you give me details regarding it?
*Any pointers you would care to make?

I've played these kinds of system, both in the sense of being generic and in the sense of being many tiered. The problem is that it isn't very colourful. You lose all players who are ready and willing to change systems, and there's surprisingly many of those. If you design generic your game will lose to every system there is when it comes to the thing the other system is designed for. Your game will be worse than D&D for dungeons, worse than Sorcerer for demonology, worse than HQ for heroic fantasy, worse than Cyberpunk for cyberpunk, worse than Hero for superheroes... That's a telling point for many players, and a reason I never would use your system. Nowadays, if I get an urge to play a certain kind of game, I most likely can find a beautiful system that does it brilliantly. If not, I'll know what I'm designing next.

The kind of player you get with a generic system are largely broad scale simulationists, who like the idea of simming anything and everything, or just our world. The game most likely will be espionage or similar, today or near future. The problem is, those people play GURPS, which is very good at what it does, if you like that sort of thing. It's easy to tinker with, to boot. Just ask any fan, and they'll tell you with absolute conviction that you don't need any other system at all, as GURPS can simulate your grandmother if the experience rules for toughness are tweaked just a little bit... How can you compete with that?

Taking your first question a little more literally, how would I find your rules personally? They'd be too complex mathematically for what they do, the stats are redundant with a many tiered skill system (just add a fourth tier with really slow development) and the probability of success swings too unpredictably, with too many low success situations for cinematic or even realistic play, if I guess right at the kind of character creation you have. Additionally, a flat probability curve would make most of the skill range unplayable and the task resolution places too heavy a responsibility (albeit the same all these old systems do) on the shoulders of the GM.

I'd personally use HeroQuest for the kind of game this system supports, to name a published game. Of course, to tell the truth, your system doesn't inspire any kind of game play, being totally devoid of any color at all. That's when I use HeroQuest, you see ;)

Let's return to your latest post. You cite flexibility as a design goal. Why are you so against user defined skill lists? They are the most flexible thing there is, as everyone can have the skills exactly like they make sense to them. Then even multitiered skill layers are not a problem, as every player can have his own tier system. I could have
Archery
..Aimed
..Intuitive
while you could have
Archery
..Short Bow
..Long Bow
without any balance problems at all. Let GM veto anything he deems unrealistic, and you're set. If somebody thinks the system is too complex, tell them to use only the highest level groups, which amount to abilities. If someone thinks more detail is needed, they probably already have an idea about what subskills are needed.

Who do you think will use the system? You cite "newbies and those who prefer hard rules", but is it so? At least newbies would probably like something simpler, one would think. Maybe only one stat, how about? Or three? As for people who like hard rules, why cannot you make a simple system with ironclad rules? Others have managed, why not you? I won't cite examples, as I happen to think that majority of published games have quite clear rules. The ones having problems are usually too complex to adequately handle their chosen level of detail.

Actually, this'd be a good place for a deep, probing question. Here goes: How do you have fun in a roleplaying game? If the answer isn't "By seeing the system executing flawlessly over many different situations, elegantly taking into account any result-affecting details we as a group prefer including." or something equivalent, ditch the design. If it is, by all means, move onward to playtesting. My advice is to build a situation generating subsystem into the design as well, to produce the situations the system will be applied for.

Most people just couldn't care less about the above goal. They go "I want to immerse in a fantasy world." or "I want to explore the moral dimensions of being an assassin." or something else. That's probably why you generate excitement in relatively few people (and those likely not very happy with actual play in general, if you catch my drift).

[M. J. Young]

Almost all people in Forge have been hooked with highly specific, economic design philosophy. What you're doing is just not fashionable here, just check out what gets written about and what doesn't. After a certain point, if you prefer your own design, you should just go with it. These people have pointed out what they think could be improved, but you cannot make them love your game.

Euro, I think this does a bit of a disservice to The Forge.

I like to think of Multiverser's core engine as simple, and from one perspective it is--a very few mechanics run everything. On the other hand, there is nothing simple about a five and a half hundred page rule book which enables you to convert real people into role playing game entities and move them from universe to universe in a manner that feels plausible. From that perspective it may be the most complex game system published in the past decade still in print (I haven't seen all the competition). Yet I don't find the people here to be averse to my game concept or execution (many have praised it), and I don't find that there is any negativity toward complex systems per se.

What I do find is an objection to unjustified complexity. One of the overriding priorities in design here is to avoid doing that which is not necessary. That underlies most of the rants we encounter, many of the articles, and a good number of the core concepts that you find here. For example, anyone who says that they are going to use a attribute+skill basis for resolution is going to be asked why they are doing that, and are going to have the inherent problems pointed out to them. Even I will do so--and my design uses an attribute+skill system which I am ready to defend as the best approach for that game. I just don't think it's the best approach for every game, and there is a strong tendency for people to use it for such shallow reasons as that it's familiar, or it seems realistic, or it's usually done that way. If you don't have a solid reason why attribute+skill works for your game, then you don't have a reason not to explore attribute-only systems, or skill-only systems, or substitutionary systems, or any of a variety of others that frequently do a better job of meeting game goals at significant economy in-game.

Similarly, Multiverser spends half its text organizing, listing, defining, describing, and explaining skills--everything from lighting a fire to building a T.A.R.D.I.S., reading minds to summoning gods, crawling on your belly to walking between dimensions. Yet this structure is there because it serves critical functions of the game design: the bias structure that makes skills easier in one universe and harder or impossible in another, so that characters can move between fantasy and science fiction and other types of worlds and remain faithful to who and what they are without destroying the integrity of the world they've entered. If you're going to have a highly structured skill system in your game, I'm certainly in no position to object to such a thing. I think it can be a good idea if it serves a clear function in meeting the game objectives.

I've seen no compelling reason why Autocrat's game needs either of these things. As you've observed, for all the difference it makes to game structure it would be as well served by providing a few examples and letting players invent their own skills subject to referee approval--and would save him two to three hundred pages of text and lower his printing costs by maybe as much as seven or eight dollars per copy. I see nothing that suggests an attribute+skill system serves this game better than a skill-only system; the one desire, that characters would have better innate ability at some things, is easily served by establishing varying starting points--character A starts all intellectual skills at level 3, all physical skills at level 1; character B starts all physical skills at level 2, all intellectual skills at level 2. The other desire, that there be a default roll for skills that should be possible to do without skill, is simply addressed by creating a standard default roll for all skills that should be able to be performed without skill. The inherent problems of an attribute+skill system are eliminated. There really isn't anything else he gains from that that he has been able to explain.

Admittedly, he's been giving us his system in drips and drabs (which has definitely negatively impacted our ability to respond to him--it's like saying, "what color paint do you all think I should use?" without telling us what it is you're trying to paint). I could easily have missed the reason these parts of the system help the game meet its real objectives (which are unclear to me, unless it's an attempt to recreate GURPS).

So I don't think we're opposed to complexity per se, but to complexity that does not serve a functional purpose in achieving clearly defined game design objectives.

That's really the problem here.

--M. J. Young

[Eero Tuovinen]

Almost all people in Forge have been hooked with highly specific, economic design philosophy. What you're doing is just not fashionable here, just check out what gets written about and what doesn't. After a certain point, if you prefer your own design, you should just go with it. These people have pointed out what they think could be improved, but you cannot make them love your game.

Euro, I think this does a bit of a disservice to The Forge.

OK, my name'll be Euro from now one, as everyone calls me that anyway. Works for me ;) If Clinton just would change the handle, all would be well.

And I confess to simplifying the stylistic situation somewhat, but that was in service of not doing a disservice to Autocrats design. It's a fact that a place like Forge will tend to form communal tendencies in critique - similarly thinking people group together. You and I will of course characterize this tendency as liking good games and disliking bad ones. I will gladly spar with anyone about how Autocrat's design solutions make for a bad game, but that hardly is constructive to say after what has already been written. It's better to stay overly objective towards him, as doing otherwise would be disrespective.

Let me rephrase: most of the writers here think your game is (probably) bad or at least mediocre, Autocrat. We give it the benefit of objectivity in form of assuming that you yourself get something out of it, but it doesn't fit in, for example, my preferences. Thus what you do "is not fashionable here" and to a certain extent, you have to either sell it to us, change your own opinion on what's good, or search for acceptance somewhere else. What I tried to say is that world doesn't end in the Forge and if you yourself have absolute convinction in your game's quality, you should try to look for a more receptive audience instead of wallowing with our lukewarm commentary.

Mr. Young: I think I'll have to get me some Multiverser when the next pretext comes around. You use the game frequently in your examples, and it indeed is a premiere example of pervy simulationism in Forge style, precede the forum though it does. I'd expect it to be an engrossing read, regardless of whether I'd ever end up playing it (I mostly GM, and though I'd love some plain simulationist play from player point of view, I never get to).

So I don't think we're opposed to complexity per se, but to complexity that does not serve a functional purpose in achieving clearly defined game design objectives.

True, that's a more accurate way of putting it. Thanks for the clarification.

[Rich Forest]

Autocrat (I'm sorry, I may have missed it, but do you mind if I use your real name?),

I have a slightly different bit of advice from Euro, who has said that if you don't like the kind of feedback you get at the Forge, you might want to try someplace else to see if you get the kind of feedback you're looking for.

I think you should do the opposite. I think you should engage with the feedback here. Here's why: it's useful because it is not what you're looking for. It is stuff you wouldn't have heard if you just got what you were looking for.
Now I haven't been part of this thread yet. I've been just an observer, so I'm not emotionally committed to any particular choices you make in your design. I was only prompted to join because you expressed the sense that you were being attacked. But before Euro's fairly blunt comments about his (and remember that it's just one person's) sense of the quality of the game, well, nothing was said in this thread that I could see as any kind of attack. Certainly, there were a lot of critical comments. But isn't that why you asked for feedback?

Look at it this way--these people have written some very long and very thought out responses to your query for feedback. I've seen games get very little in the way of response, so you should be thankful for the sheer amount of interest people are showing and the work they are putting in to reply to you. But they are not here to tell you what you want to hear. It isn't fair to ask for critique and then become annoyed by critique, honestly. It also isn't fair to ask everyone to give you the same advice. Of course different people will have different insights. That's why you ask more than one person.

If you already have the answers, then don't ask the questions. You will never be happy with the responses you get. You must be ready to really, seriously, and honestly engage with the feedback. It is not personal. It is not feedback about you. It is feedback about the game. Now I can't tell whether you are honestly engaging with the feedback or whether you are instinctively defending your game against it. You seem to be doing the latter, not to be stepping back from the product and distancing yourself from it. But it is absolutely necessary to step back and distance yourself from the game if you want to produce the best product. Maybe you are already doing this, which is good--maybe you have a defense for each piece of feedback because after careful consideration you really have found better answers. It is possible. I can't read your mind. But you should not need a defense against anything--this feedback is not a set of attacks. If you're defending yourself and your game against the comments you receive, you probably aren't genuinely engaging with the comments in a useful way.

Rich