Task Based Traits vs Descriptor Based Traits

[Jason Lee]

Well, as part of my big user interface kick I've hit an imponderable.

In my mind I can see character traits (stats/skill) falling into two basic categories.

Task based:
The definition and range of abilities of the trait is based upon an in-game task; based upon the use of the trait; verb-like.
Influence is used to effect another socially, and Strike is used to hit someone.

Descriptor based:
The definition and range of abilities of the trait is based upon a descriptive element of the character; based upon a quality of the character; adjective-like.
Charisma reflects how charming the character is and is used for tasks where how charming the character is matters, and Martial Arts reflects training in hand to hand combat and is used in situations where this ability would apply.

Many games I'm familiar with have some mix of these two types, seemingly at random.  Perhaps it never occured to them, or was just too much of a hassle to try to adhear to a single approach.

So, what pros and cons does each approach offer?  Here are my opinions.

Task based pros:
I feel it is more clear for resolving in-game tasks.
When sneaking through a crowd I roll Sneak; instead of trying to decide between Stealth and Streetwise.
A task based trait is easier to describe and remember the definition of.
Roll Sneak to sneak; as opposed to roll Stealth for tasks involving camoflauge, shadowing, sneaking, and hiding.
Task based traits release restrictions on character concept the descriptor based traits impose.
I can be Influential by being manipulative, charming, intimidating or whatever I feel is appropriate to the character; instead of behind bound to being charismatic with my high Charisma rating.

Descriptor based pros:
Descriptor based traits allow you to define your character better via the character sheet.
By taking a high Martial Arts score my character is defined as a martial artist; giving him a high Strike rating says very little about the character other than he's got a mean swing with a brick.
Descriptor based traits are much easier to conceive of and organize, because they often fall along career lines.
If I'm expecting people to play a brick layer in my game I can have a Masonry trait; how does one divide this into tasks, Carry Brick and Make Concrete?
Descriptor based traits can be made less generic, tailoring them to a specific setting so the system supports the setting better.
Fighter, Thief, Wizard; instead of Strike, Sneak, Spell Cast

Hmm...I guess all my pros for descriptor based are basically the same: Translates more directly from concept to character sheet.

[Mike Holmes]

Are these selected from a list, or built by the character? It's crucial, Cruciel.

Mike

[Jason Lee]

I wasn't really thinking in terms of a specific system, but selected from a good ole fashioned list I suppose.  Built by the character (player?) would be up to the person and could end up being whatever, despite system recommendations, so I guess such a system wouldn't really apply to the discussion (if I'm catching your drift).

I guess in there I'm also implying a standard Stat, Skill, or Stat+Skill resolution system.

[Mike Holmes]

That's what I thought.

Given a standard list, I'd go with task based. Yes, chargen is slightly more complicated. But that can be done at a leisurely pace. But in play, when it really counts, it's speedier to have the task traits.

I suppose an interesting system could have a description based set that, when filled, changed names to a task based enumeration.

Sounds like a CRPG idea.

Mike

[Jason Lee]

Hmmm...that is kind of interesting.

If you did it with a skill tier system (Firearms -> Rifle -> Smith & Wesson) you could make the first tier descriptor based and the second tier task based (Firearms -> Shoot).  Though, like any comprise it might gain you all the faults of both approaches and none of the benefits of either.

[Mark Johnson]

To overly simplify...

task systems tend toward the reductionist
descriptor systems tend toward the holist

Most systems, as you note, muddle somewhere in between.  Sometimes attributes are given descriptors and skills tasks, that is a rather nice distinction if that is your thing.

[Johannes]

I'm currently working on a homebrew descriptor based system. For me the designing process is sort of mental exercise of thinking it again as I have been playing task (skill) based games (Rolemaster, Harnmaster and the like) most of my life.

The reason I changed camps to descriptor based is that I grew frustrated with the endless skill lists (think of RM for example). It's very hard to decide which should have it's own skill and what activity belongs to which skill. There are billions of things to do in a world and it's hopeless to try to skillify everything - there will always be somthing that is not covered by your lists.

At least Harnmaster and RQ respond to this problem with some skills that are more descriptor-like: RQ craft skills and similar "occupation" skills in HM (like masonry or locksmith). This is a working solution but why not do it with other skills too and avoid the problem in the first place?

The proble that I have with designing a descriptor based system is that slow character improvement by experience and learning (similar to improvement systems in RQ and HM) is hard to do. Here is an example:

Matti is a scribe. His only descritors are "Scribe" and "Intelligent". These are not taken from a list; Matti's player came up with them during character creation. Now Matti has been involved in a street fight and given wrestling instruction by his fellow Teppo the Warrior. What kind of descriptor should be added? "Warrior" - no, because Matti has only learned to wrestle. He has no clue about tactics or standing in guard or any other warrior activities. Would it be better to give him "Wrestler" instead - cool it describes precisely what Matti has learned! ... but hey this is will make the system skill based after all and all the problems associated with that will come along.

It's interesting that both approaches have to make compromises towards the other. Task systems have to move towards desriptor systems and vice versa. This is of course a personal preference issue and I'm aware that people who want different things will disagree with me but these are the pro's and con's for me.

[Johannes]

Hi,

Doing some research on postmodern for my RPG thesis I came accross something that is of entertainment value to this thread and might also demand some thought:

In "The Analytical Language of  John Wilkins," Borges describes 'a certain Chinese Encyclopedia,' the Celestial Emporium of Benevolent Knowledge, in which it is written that animals are divided into:

1. those that belong to the Emperor,
2. embalmed ones,
3. those that are trained,
4. suckling pigs,
5. mermaids,
6. fabulous ones,
7. stray dogs,
8. those included in the present classification,
9. those that tremble as if they were mad,
10. innumerable ones,
11. those drawn with a very fine camelhair brush,
12. others,
13. those that have just broken a flower vase,
14. those that from a long way off look like flies.

(from http://www.multicians.org/thvv/borges-animals.html)

Great list of descriptors. If someone makes the game that uses this list I will buy it!

[Jason Lee]

[snip]

Matti is a scribe. His only descritors are "Scribe" and "Intelligent". These are not taken from a list; Matti's player came up with them during character creation. Now Matti has been involved in a street fight and given wrestling instruction by his fellow Teppo the Warrior. What kind of descriptor should be added? "Warrior" - no, because Matti has only learned to wrestle. He has no clue about tactics or standing in guard or any other warrior activities. Would it be better to give him "Wrestler" instead - cool it describes precisely what Matti has learned! ... but hey this is will make the system skill based after all and all the problems associated with that will come along.

This is a little different than what I'm talking about.  You seem to be implying that the difference between task and descriptor based skills is mainly scope (task = narrow, descriptor = wide).  Which, I suppose, can certainly happen, but the difference I'm talking about is a lot more subtle.

I would consider Wrestling a descriptor based trait.  A task based trait of equivalent scope would be Grapple.  Though, the classification of Wrestling can be kind of dependent upon how you define it ('wrestling ability', or 'to wrestle'?).  A task based trait of equivalent scope to a Scribe skill would have to be pretty abstract, like Academic Task (pretty lame trait, IMO).  Hmmm, there's a pro for descriptor based - it is easier to define traits of greater scope (ya know, like stats - as Mark mentioned).

As an example lets use two traits of equivalent scope that are functionally identical:  Alertness (descriptor) and Notice (task).  What's the difference?  They'd end up being used for all the same things in most instances.  The main difference is how the player interacts with them during play.  Alert is something his character is, and Notice is something his character does.  So, when it becomes time for the character to do something during game he has to either determine what allows him to do it (descriptor) or what exactly he's doing (task).  With a task based trait you pull the verb out a player's statement of intent to determine what trait applies.  ('I want to find a book on underwater basket weaving in the library'.  'Roll Search')

Does that make sense?  Am I over explaining?

[JMendes]

Ahoy, :)

Cruciel, not only are you not overexplaining, you have come up with a thread that, I expect, will be referenced elsewhere for years to come.

A stab at the negative side of things:
-A closed list of task-based skills is either glaringly incomplete or extremely hard to make consistent;
-A closed list of descriptor-based skills is, imho, either an impossibility or simply a (small) list of stats, which appears to be overly generic for what you are talking about.

I'd have to agree with Mike in that, given the choice, I'd rather optimize actual play over chargen. (And before it crosses anyone's mind, let's not go into that discussion again...;)

Expanding on the CRPG idea, it doesn't seem too hard to come up with a chargen help-guide that translates descriptor-based skills into task-based ones, much like templates, training packages or skill packages do.

Ultimately, however, it comes to this: what, if anything, are you trying to model? This might seem like a 'matter-of-preference' point, but it's not. I might use task-based for one game, then turn around and used desc-based for another, simply because the focus is different. In other words, I cosider this a major design decision.

The fact that the point didn't even occur to me before I read it here is why I think this thread will be referred to for generations to come.

Cheers,

J.

[Andrew Martin]

Hmm...I guess all my pros for descriptor based are basically the same: Translates more directly from concept to character sheet.

Why not simply use character description as the character sheet? In other words, when the character has to do a task, the player finds the relevant description and uses that as the character's values in the game system. This then allows easy incorporation of historical people, and fictional characters into a game. It also allows very easy access for novice players, I feel.

[Jason Lee]

J,

Yeah, I definately agree with the con's you threw out - both represent snags you'll hit when trying to build a closed list of traits.  Which, looking at it from this angle highlights a big con for a closed list of traits.  Huh, fascinating, gonna hafta think about that (yet another imponderable I can torture myself with).


Andrew,

That definately highlights the greater scope pro for descriptor based, and adds ease of use during character design for new gamers to the list of pros (which I guess is just 'translates more directly from concept to sheet' reworded again).  The way I see it, this character description is essentially a single trait.  I can't think of a decent way to do a single trait character with task based traits, Do Something seems like a pretty stupid trait (Heh, well, maybe Smurf - after all smurfing is all a Smurf ever does, right?)