charles@blackeagle.com>.
It was posted to rec.games.design in two parts on
May 1 and June 11, 1995. It is being kept here with permission
of the author, but it is copyrighted as follows:
This article is copyright 1995 Chameleon Eclectic Entertainment, Inc. I don't mind anyone reposting this article to bulletin boards or other virtual locations where it will remain temporarily, so long as author's credit (that's me) and this notice remain intact. (This copy is kept here with the author's permission -- JHK.) Anyone who wants to keep a copy for personal use or records is welcome to as well. I request, however, that this article not be uploaded to archive sites or otherwise permanently/indefinitely stored for distribution. As a professional designer, I do not want an unfinished work to be circulated out of context with my name on it, and I certainly do not want it circulated without credit. At some future time I may choose to polish it up into a real game system, and put it into the public domain. Until that time, however, it remains the intellectual property of Chameleon Eclectic.An outline follows:
What follows is an outline for a basic Description-Based character generation system. For the time being, it's fairly limited--I'm assuming a game set in a relatively familiar background, and I'm not getting into alien/humanoid races or other SF/fantasy elements. My intent here is to create a system for making players think about their characters in such detail that they end up with a character description concise enough for play--that is, concise enough that when the player and the GM each have to assess some aspect of the character's abilities, their assessments are in general agreement (at least so far as they might be in any other RPG). If we can get that far, we've got sufficient basis, I feel, for functional Description-Based game mechanics, which I'll cover in a later post. From this point forward, I've written the material as though it were actually appearing in a game book--though this is, in reality, little more than an outline, and I've put side notes in brackets throughout.
This method of creating Description-Based characters follows six steps:
The first step in creating a character is to establish a Concept Line. The Concept Line contains your character's name, age, gender, possibly race, and a few well-chosen adjectives that convey the immediate impression the character makes on others, perhaps reflecting a little of the character's essence as well. This idea is lifted from a similar practice employed in screenplays, in which characters are described in one or two lines when they first appear. An example from an actual screenplay:
"DR. PETER THOMOPOULOS, 48, the quirky scientist type, disheveled hair covering a growing bald spot, intelligent eyes behind thick glasses, a man whose brain seems to run at 90 miles and hour."There are a few important things to understand about the Concept Line. First of all, this first version is only a rough draft--as your character is refined, you may want to go back and revise the concept line. That's OK, so long as you don't make so many revisions that the Concept Line ceases to function as a useful guide during the character creation process. Second, the Concept Line may seem a little stilted, narrow, or even stereotyped. Again, that's OK--the Concept Line does not define the outer limits of your character, but is simply a starting point and a summation of the first impression people generally get. The fact that Dr. Thom is "the quirky scientist type" does not mean that there isn't more going on behind those thick glasses than at first meets the eye, or that he doesn't have surprising interests or a family or things in his past that haunt him or other parts of his life that expand on the stereotypical image.
[I'm going to use an example, which I'll carry over throughout this thread. I'm setting the example in the Star Wars game universe, for a couple of reasons: first, the game background is well understood by most readers; second, it may introduce elements beyond the real world (aliens and SF technology, for example); and third, I hope to demonstrate the practical utility of a Description-Based game by borrowing an existing game setting, rather than theorizing about one.] Here's our example character's Concept Line:
"Jave Gorvin, 12-year old human boy, a thin street kid with unkept blonde hair, a undeniable smile, quick eyes and an abundance of nervous energy." [an idea stolen directly from one of the templates in the Star Wars game book--for the reasons just mentioned]The second step is the Defining Element. This is a quick decision on the one (or perhaps two or three) aspect of the character's past that made the character who he or she is today. It may be a relationship with a family member, lover or spouse, or partner or friend. It may be a major event or trauma in the character's past. It may be a personal revelation, the source of a dark secret, or a turning point in the character's life in which an innate trait that was triggered by a specific, though minor, event.
The Defining Element affects the character's motivations, outlook, self-image, and potential, and becomes the conceptual basis for decisions on the specifics of the character's current capabilities and past history. What's important about a Defining Element is not its factual description, but how it formed and affects your character. Because of this, most of the information on your character's Defining Element is between you and your GM, and shouldn't be immediately shared with other players, even if the factual basis is public knowledge.
Defining Elements may be completely independent between characters, or they may link two or more characters or the entire group. Jave has two Defining Elements, one of which is unique to him, and the second of which involves another PC.
"Jave's parents, wealthy merchants and community leaders on a border world, were detained and presumably killed by Empire stormtroopers when Jave was about six. Jave escaped to the streets, where he's remained ever since. [the facts of the matter]
"Jave was too young to understand what was going on, and deep down inside, he blames his parents for abandoning him. The streets have made him wise for his years (although he still comes across as a 12-year-old), but he has great difficulty trusting others, and bears a searing enmity towards affluent, successful, and apparently happy families--people that remind him of his family. [the effects on outlook and motivation that resulted from the first Defining Element]
"Two years ago, Jave met Zil [an ex-bounty hunter and another PC]. Since then, they've mostly stayed and worked together, refining their individual fringe existences into one hell of a con-artist team. [again, the facts]
"Jave looks up to Zil, the only living person whose earned his respect and admiration. He's come to trust Zil, and has gained a sense of self-worth in that Zil trusts him too. [again, effect on outlook, self image, and potential]"Obviously, the factual material involving another PC must be established in coordination with the relevant player, as well as the GM. That doesn't mean, however, that the Jave/Zil partnership must be a defining element for Zil--it may be a relatively minor aspect of his development. Even as a major aspect of his life, it needn't have the critical effect on who he is that a Defining Element should have.
[At this point, we need an extensive list of rough ideas for Defining Elements. The list won't be comprehensive, of course--it couldn't be--but it will be sufficient to give players lots of different directions to explore. It will also be somewhat tailored to the game background and genre.]
The Defining Element and Concept Line go a long way in creating a character that is well conceived by the player and communicable to the GM and other players. Step three is to outline the character's Capabilities. This is where the rubber meets the road--where the decisions made will directly affect play and the character's success in his or her endeavors.
Your choices in Defining Elements began to establish some background for your character. Choosing Capabilities will require you build upon and refine your character's history.
There are two types of character Capabilities: Innate Capabilities, which are based on your character's inherent potentials (genetic, or based on early life experience); and Developed Capabilities, based on your character's education and life experience.
Start by thinking about your character's mental and physical makeup. Describe each, in terms of strengths and weaknesses. Stick to the basic innate qualities, modifying them only in very general terms to reflect what you know so far about your character's life experiences. When outlining mental Capabilities, think in terms of analytical versus intuitive thought, focus versus a scattered brain or absentmindedness, willpower, capability for social manipulation, and abstract conceptualization, or any other specific mental strengths or weaknesses you feel are appropriate.
For physical Capabilities, think about strength and its distribution, weight and power, endurance, resistance to illness, rapidity of healing, eye-hand coordination, bodily dexterity, ailments or disabilities, and other relevant issues that fit your character.
[There should be more examples of issues to think about, both physical and mental, but these were what I came up with off the top of my head.]
In both cases, use these issues to explore who your character is. Be sure to keep him or her reasonably balanced--either offset mental strengths with mental weaknesses, doing the same with your physical description, or balance overall strengths in one category with general weakness in the other. Here's Jave:
"Jave is a keen observer and a quick learner--although he's got the apparent attention span of a typical pre-teen, he catches almost everything going on around him. He's especially sensitive to social stimuli, a well-honed capability after years as an urchin and con artist. He works well with his hands, and picks up participatory (rather than abstracted) tasks very quickly, even when they're complicated or technical. He has little mind, however, for strategy, tactics, the sciences, or other theoretical or abstract pursuits. He's also extremely undisciplined mentally, setting his mind only to tasks that interest him.
"Physically, Jave is a kid. He's kind of thin, very lightweight (87 lbs), and not particularly strong, especially by adult standards. He's quick in body and hand, though, and pretty resilient to illness and injury."Those are the Innate Capabilities--now you're ready to move on to Developed Capabilities. This is where character background becomes important, because as you define your character's capabilities, you'll need to develop some idea of where they came from and how well-developed they are. That sense can be fairly rough at first--it will firm up through play and further development of your character--but having at least some basis is important both to your complete understanding and to the accurate communication of your character's capabilities to the GM and other players.
Start by thinking of three or four major elements of your character's education and life experience, that would lead to the development of specific skills or abilities. If you were creating a modern day character, for example, you might mention her college education, her athletic prowess in high school and college, and her love of the outdoors and outdoor activity.
[Here, we need some more data for the players to draw on--examples of educational opportunities, service with the military, espionage agencies, the Inquisition, or whatever organizations are relevant to the game background, and other examples that would give the players both the ideas for the types of career paths available to their characters, as well as the specific curricula for various education and job paths.]
Here's Jave:
"Jave has very little formal education--just what your typical wealthy kid would get up through age six. His life on the streets has had two phases: before and since Zil came along. Before, he was living by beggary [that's bEggary] and petty theft. Since, he's become an accomplished con artist, devising with Zil rather elaborate schemes to separate fools from their money and gain access to the homes and possessions of the wealthy."Once again, the information involving another PC was developed in conjunction with the other player.
Now that the major capability-effecting background elements of your character's life have been established, it's time to come up with some concrete Developed Capabilities. These choices and descriptions are very important, because more than any of the above, they're going to be the basis of your GM's assessment of success and failure (and degrees in between) when your character acts in the game.
Each Developed Capability should be covered with a brief description that includes three factors: the Capability's source; its breadth; and its depth. Choose one segment of the education and experience you just came up with for your character, and focus on it carefully, giving your character a couple of strong, well-defined Capabilities derived from it. For each of the additional segments, define one deeply developed but narrow, one shallow but broad, or two shallow but narrow, Capabilities. Remember your character's Innate Capabilities--if your Developed Capabilities expand on those, you can make them deeper than if they are unrelated to your character's inherent strengths.
Other basic skills need only be mentioned briefly, unless your character is missing something important or is especially skilled at a common task. [At this point, a list of basic skills appropriate to the game world should be covered--a modern-day game might list "driving a car," "reading and writing," etc. There should also be a fairly comprehensive list of ideas for Capabilities--something for the players to look at while they're mulling over what their characters have picked up over the years and what they should be able to do. The list might include "shoot a gun (or other weapons)," "Use a computer," "Fix mechanical things," etc. This is not a skill list, but just a list of ideas. To make these items functional in the game, the players must define their source, breadth, and depth--just like a made-up Capability.]
"In his early street days, Jave honed his survival skills. He became something of an escape artist, pretty darn good at dodging blows, avoiding grasping hands, creeping through shadows, and outmaneuvering stormtroopers in back alleyways. [a single, broadly-defined Capability with no one in-depth component, based on Jave's innate physical quickness and strong sense of perception.]
"After Zil came along, Jave developed a number of more specific skills. For one thing, he became a hell of a talker. With his innocent smile, child's eyes, and ability to always tell people what they want to hear, Jave can fast-talk just about anyone who understands Basic [the standard Star Wars language--not the programming language]. That's his real forte--the kid's got talent. He's also picked up moderate proficiency at several technical skills: droid repair (one of his and Zil's scams is to sell the same droid to several owners, which involves popping off a lot of restraining bolts and repairing a lot of abuse); droid programming (for largely the same reason); and vehicle driving (one never knows when, by what means, or how fast one will have to make one's escape). [one narrow, very strong Capability, with three fairly broad, related, and shallow skills, all related to Jave's Innate Capabilities.]"Now we're down the final step: defining a Weakness for your character. There are two ways to handle this: either create a specific, narrow, but exploitable weakness in your character (an Achilles' heel of sorts); or define and develop a broader though less specific weakness in your character's ability to succeed as an adventurer. Alcoholism, being blind an deaf on one side, or having a secret restraining code (in the case of a droid) known only by a few agents of the Empire would all be examples of the former. Being overweight (unable to run quickly or over distance and unfit for physical exertion), or being a real coward, are examples of the latter.
"Jave's skills are all defensive, or at best subversive. He has no real offensive capability, in hand-to-hand combat (where he'd be pummeled by even the weakest of adults), with firearms (sure, he knows which end of a blaster is which, and can figure out a safety pretty quick--but he's just not much of a shot), or in terms of tactics or smart moves. Jave is not a coward, but discretion is the better part of valor."Now you've got a complete character. You should have a fairly concrete idea of who that character is and what sorts of things he or she will or will not be successful at in play. More importantly, these ideas should also be well understood by your GM, and fairly well-documented for future reference.
However, no matter how hard you've thought about it, some aspects of your character concept are probably still a little unintentionally fuzzy, and they won't come into focus until your character goes into action. For that reason, there's the First Session rule. After the first session of your game, you may make alterations to any of the material you put together above, subject to the guidelines above and the approval of your GM. After that point, what you've got is final, and can only be improved or altered by your character's experiences in the game.
"While fleeing the prison barge in the stolen Imperial shuttle, Jave had to run the shields while Zil flew the thing and Betra manned the guns. The experience gave him a solid familiarity with shields, and, to a much lesser degree, shipboard systems. Too bad he didn't get the hang of it until about the time they crashed--but he'll be ready next time."
The following is Part Two of my experiment: an outline for the core task resolution rules of a D-B game. It was much harder for me to come up with these rules than it was to put together the character generation ideas--basically, all I had to do with them was refine a number of methods I was already using for lots of other games. When getting down to these mechanics, however, I had to really rethink what it was that I wanted, and how to get there. In the end, I settled on a system designed to process its descriptive input into descriptive output. That doesn't mean that mechanical results should be vague or ill-defined (one of my two playtests was =very= hard science fiction, so I really wanted to make sure I didn't necessarily promote a loose or cinematic style of play). I think it works in this regard, especially when tightly tied to the background material (the role of which will be the subject of a future post), but this system rarely provides the sort of yes/no success/failure answers that are the currency of most RPG skill systems.
Ironically, this system does rely on some quantification (it also uses dice, which I'll get to in a minute, although the dice need not use numbers. I took a couple of d10s and colored in the numbers with different colored markers--I read the color, not the number, when I roll). The sorting of task probabilities into one of seven shades of likelihood (this will make more sense when you read the rules) is inarguably a form of quantification, but since it doesn't require any quantification of the characters' abilities, or provide results on a quantitative scale, I feel it still qualifies, for all intents and purposes, as description-based.
On the subject of dice: I use them because they make my job as a GM easier. I'm absolutely uninterested in the relative merits of diced versus diceless play, and I expressly request that no-one start up that argument under this subject header. If you don't want to use dice, this system should be easily convertible to diceless play. For what it's worth, only the GM gets to handle the dice in this system, and my players generally didn't see them (and wouldn't know what the results meant if they did) during play, which makes many of the power/fairness/structure arguments moot anyway.
Like Part One, I wrote this material in the tone I would use for a real manuscript. Unlike the character generation notes, however, this narrative is directed at the GM, not the player. I've also provided fewer examples, as I felt they were less necessary to a full understanding of what I was doing.
A final note: this article is copyright 1995 Chameleon Eclectic Entertainment, Inc. (yes, I've been doing it on company time--aint bein a game designer great?). I had several email requests for permission to repost and/or archive the first article. I don't mind anyone reposting this article to bulletin boards or other virtual locations where it will remain temporarily, so long as author's credit (that's me) and this notice remain intact. Anyone who wants to keep a copy for personal use or records is welcome to as well. I request, however, that this article not be uploaded to archive sites or otherwise permanently/indefinitely stored for distribution. As a professional designer, I do not want an unfinished work to be circulated out of context with my name on it, and I certainly do not want it circulated without credit. At some future time I may choose to polish it up into a real game system, and put it into the public domain. Until that time, however, it remains the intellectual property of Chameleon Eclectic.
And now, on to the action. I hope you enjoy it. Please comment vigorously and constructively.
There are three steps to using these rules:
In fact, density can vary greatly between events within your adventures. In a dramatic swordfight at the climax of an adventure, you may wish to resolve events blow-by-blow, using the task resolution system below for each jab and parry. On the flip side, for events of low drama or marginal importance, a single test may be sufficient to represent hours of game-time efforts by the characters.
In general, you'll want a single test for each definitive action, or each time you need a single answer as to whether a character succeeds or fails in order to move on with the game. There are a couple of exceptions.
Some tasks, especially combat [which will be covered in more detail in a later section] pit two active participants against one another. In some cases, like for instance an arm-wrestling match, a single task test is probably sufficient. In situations, however, with ups and downs, dramatic ebbs and flows, or in which the initiative and tactics of the participants will create an ever-changing set of advantages and disadvantages, you'll probably want to have more than one test.
Some tasks are not well defined: a character climbing a mountain, for example, is continually testing his or her skills. In such cases, it's a good idea to start with a single test: respect a decisive result one way or the other, but require a second test if the first result was not concrete, modifying the situation and your assessment (the next step) for the second test based on the result of the first.
Finally, it helps to scale your density to the drama of the moment. A long, difficult, multi-segmented task such as breaking into a secure computer system might be best represented by a single test if it's not too important to the game and more attention will only slow things down. On the flip side, defusing a terrorists bomb is probably a much simpler task, requiring less time and fewer steps for the characters--but for purposes of building tension, you may want to break it out into three tests.
In any event, remember that the second step--your task assessment--depends on your mental picture of events in the game and your players' reactions to them. When dealing with multiple tests, you must think through and explain the results of one test and give the player(s) a chance to react to it before assessing the second test.
[I'd like to have more guidelines here--because the system is 100% scalable, it's really necessary. My playtests haven't imbued me with any more wisdom on the topic yet, though.]
[A published set of rules would contain a lot of real-world data (or genre-based data) on just what an average person really can accomplish, and what the extremes are possible. Basic things like how fast people and animals run, how far they can jump, how long they can swim underwater holding their breath, etc, etc, along with a lot more detailed info more specific to the type of game. This info would mirror a lot of what is covered in many game systems' mechanics, but would be explained entirely in the form of real-world data.]
Once you've got that idea clear in your mind, ask the player for his or her assessment of the character's chances, and for justification for the answer. The player should give you a reply based upon the character's Innate or Developed Capabilities, something along the lines of "well, Sheila's not particularly powerful, but she's pretty agile, and keeps up with her jui-jitsu. I think she'd be able to jump at least as far as an average person, if not a bit further..." (at this point, the player should be pointing to her character record, where the bit about the jui-jitsu is written).
Feel free to debate the issue with the player briefly, with the intent not so much to disprove any claim towards likely success, but to assure yourself and the players that the assessment is based on character concept and not on a simple desire to succeed. Don't waste a lot of time on the debate, and don't encourage a confrontational attitude. Instead, use the opportunity to sharpen both yours and the player's conceptualization of the character. If the answer is not well-defined by the existing character record, have the player note your conclusions on his or her character sheet.
Also, don't forget contextual factors. If Sheila's running away from some Cthuloid monster that's just eaten three of her friends, she's probably pretty motivated to perform, and would likely be a better jumper than if she were doing it as a drunken prank and thought the ground was only two feet down. Such additional factors should generally be minor in effect, taken into account only when you are having difficulty deciding between two success categories (the next step).
When one or more characters are working as a team, or assisting a primary character in a task, you'll probably think about increasing your success assessment. There are three possible ways in which assisting characters can affect your assessment. First, they can offer direct support, in which their efforts add directly to the likelihood of success. Say a boulder needs moving: two strong backs are better than one. Two characters trying to fix a broken truck engine are more likely to come up with the solution than one, assuming both know something about mechanics. Generally speaking, the addition of multiple helpers shouldn't increase the assessment more than one, maybe two gradations, assuming the helping characters are competent.
There are other forms of support: having players split a task may save time without affecting the likelihood of success; having multiple characters do the same task, checking one another's results won't save time, but should decrease the likelihood (or consequences) of failure. It's also possible for two or more characters to start messing each other up (too many cooks spoil the broth...). [I started in on mechanisms for dealing with these sorts of situations--they came up in my playtest--but didn't finalize them.]
When two characters are working in opposition (generally, but not always, a player character against a non-player character), you'll need to decide whether one or two task rolls are appropriate. The answer is based upon whether or not the two characters are actively engaged at the same time, which is largely dependent upon your density. For example, picture two characters involved in a highly-competitive game of chess. If you already decided on a density of a single test to decide the game, you'll just want to make one roll. If, on the other hand, you've decided to use a lower resolution, say three tests, you may want to alternate.
In either case, you've got to choose a primary character. That should generally be the player character (if competing against an NPC), but in some situations (combat, for instance), it may be the other character(s) involved if the dramatic spotlight is on them or they clearly have the initiative as events unfold. If you're going with a single test, base your assessment upon the primary character's odds, and your base your interpretations on the context of his or her actions. If you're going with multiple tests, base the first one on the primary, then the second on the opponent, then back to the primary, etc.
Once you've completed your success assessment, refer to the Action Result Table:
==Success== ==Failure==
Extreme none
Major none
Automatic Success Solid none
Near-certain Success Solid none
Likely Success Minor none
Even Odds Deceptive Deceptive
Likely Failure none Minor
Near-certain Failure none Solid
Automatic Failure none Solid
none Major
none Extreme
Roll two ten-sided dice, one of which applies to the success column (the
success die) and the other to the failure column (the failure die). On a
1 on either die, shift your result down two levels; on a 2 or 3, shift
down one level; on a 4 through 7, read straight across; on an 8 or 9,
shift up one level; and on a 10, shift up two levels. For example, go back to the chess game I just mentioned. You've decided to resolve it in a single test. According to Sheila's character sheet, she "loves strategy games and is a ranked chess player, someone who's played for years and can beat all of her friends. She won several regional competitions in college." Her opponent is a good player, if a bit cocky, and has underestimated Sheila. Your assessment of Sheila's odds is "Likely Success"--she's probably a better player, but the other guy is good, and Sheila's college victories were a few years back.
You roll your dice. The success die result is a "3," the failure die a "10." Reading the table across from "Likely Success," the result should be a minor success and no failure. The success die result, however, requires you to shift up one space on the success column, yielding a solid success. The failure die result indicates a shift down the failure column two spaces, to a minor failure.
As that example indicates, the Action Result Table generates a descriptive level of consequence for both success and failure for any roll. If your initial assessment was towards the successful end of the scale, chances are that there will be no failure (a "none" result), and a "minor" or better success consequence. Likewise, a failure assessment will probable produce no success consequence, and a minor or better failure consequence. Often, however, you'll get a result in both categories. That's OK; it simply means that the action was somewhat successful, but had unintended negative consequences as well.
It's up to you, based on the descriptive information you and your players have established concerning how events unfolded (and any additional information your players aren't aware of), to interpret the descriptive results of the Action Result Table. Here's a brief overview of the possible results:
When you're stumped on interpretation, here are some factors to consider:
There are some factors that can affect your use of the Action Result Table. First, there's the nature of the effort: how hard was the character trying, and how desperate was the pressure? If the character is either particularly cautious in the effort or particularly reckless or aggressive, apply the following modifiers to your reading of the table:
Well, that's it. I hope you enjoyed it. Please comment vigorously and constructively.