The Travels of Mendes Pinto: Team Game
System as LanguageSergio Mascarenhas
Edited by Stephen Barringer
September 27, 2001
The Travels of Mendes Pinto: Team Game
System as LanguageSergio Mascarenhas
Edited by Stephen Barringer
September 27, 2001
BEFORE WE START: A CHANGE OF COURSE
By the end of last month's column, I stated that this month I was going to present the setting for The Travels of Mendes Pinto. Furthermore, I remarked: "Of course, I may deal with several topics in a single column, and deal with a single topic in several columns. And I may change the order as the columns unfold." It seems it didn't take long for this to happen. Not even a column! In fact, this month I'm going to deal with a completely different issue from the one I promised to examine. I will not present the setting; instead, I'll start to develop the system. Why, you may ask, did I change my mind?
I wrote the previous column about four months ago. Furthermore, I have several of the upcoming columns unfinished, and many papers and mental notes on how I envision AB01. Over the course of time I've been thinking about the game, both system and setting. As I said in the very first of these columns, I really think that these two are highly intertwined. Yet, when I developed my working plan, I chose a rather conservative approach. Bear with me while I develop this train of thought a little.
RuneQuest 2 was my first RPG. I have a lot of respect for Chaosium and the excellent games they've published, one after the other. For many years their work was my reference in terms of RPG design. I've seen other games and other approaches to RPG design since, but I still think that the Chaosium approach is very good. In this approach -- at least as presented in their original game RuneQuest 2, but also in other games -- the structure of a game book is more or less like the one I proposed in my last column. It works, and it works effectively. Concerning the balance between system and setting, this structure presents that material in this combination:
The first section presents the setting. This section has no system-specific content.
The second and following sections detail the system. These will also include setting elements as well, either because setting and system match, or because the setting elements are used in examples, or because the setting defines implicit boundaries for the system.
I must explain more clearly at this point how I define "setting material" and "system material". Setting material is what provides knowledge and understanding of the setting. It presents the gameworld in all its facets. This is narrative, descriptive data. System material is everything that tells you how to play an RPG within the setting. This is conventional data: it is only meaningful in the context of RPGing, and, of course, in relation to the setting. It is the algorithm that allows us to operationalize the game, the dynamic element to the setting's essentially static information.
Setting material can be developed without a game in mind. For instance, The Book of Mendes Pinto, the volume you can buy for yourself in a bookshop, wasn't written to be an RPG setting. The question is: does such a resource provide system material as well? Even if it was not intended to when written? The answer, surprisingly, is: Yes, it does. Or, to be more precise, it acquires it when inserted within an RPG context. Not explicitly or formally, but implicitly, and in a free-form, common-sense way. If the setting is based on Mendes Pinto's book, we don't need rules for nuclear science, eldritch magic, alien races, and so on.
That's why games like RQ2 start with a section on the setting -- so that the framework underlying the following system sections is stated at the outset. Based on the setting, the players know what to expect from the system, and what not to expect. Thus the setting, as I noted above, sets implicit boundaries for the system; this can be called the implicit interaction between setting and system.
But what about explicit interactions? By this, I mean any situation where a presentation of setting content has direct and explicit system implications, and likewise where a presentation of system content has direct and explicit setting links. This is easy to identify when we consider the presentation of the system's content. Take, for instance, the classic races and classes of Dungeons & Dragons. The authors of D&D based the rules on their understanding of a cluster of settings that can be collectively referred to as "medieval fantasy". While defining their system, they picked up and built into that system a terminology directly taken from that cluster of settings. In another example, the description of the cults in RQ, while done in the corresponding system section, is also a presentation of setting material.
In situations like this the game explicitly presents both setting and system. If one only wants to know that part of the setting, reading those bits is still useful (even if the information is "marred" by system material that's irrelevant to someone who isn't going to play the game). And if one wants to know that part of the system, you have to know the setting elements to which those rules apply.
That's why, months ago, I decided to approach the presentation of both setting and system in a conventional way. After all, if it isn't broken, why try to fix it? That's where my musings in game design and the game Hero Wars come in. You see, no matter how much I love RQ, there are still a lot of things that my Ideal Game would do differently. Some of those things can be found in other games, some of which I know, others I've heard about. But what I can find there still doesn't match my ideal. That's why I'm trying to come out with my own system.
For instance, I want a game system that's more qualitative and less quantitative. In other words, the system uses concepts to express system entities instead of numbers. On the other hand, despite all its flaws (you may want to read my review of the basic book here at RPGnet), Hero Wars opened my mind to other ways of integrating setting and system -- ways that are less formal, less structured, more close-knit. After much thought, I figured the bottom line was: I wanted a game where there's an extensive, explicit interaction between system and setting, on a much longer and more elaborate scale than I've seen in the other games I know.
If this is to be so, the balance between setting and system, and between implicit and explicit links among the two, that's found in games like the ones that initially inspired my book structure and game development plan -- i.e. setting first with no reference to system, then system with only necessary references to setting -- may not be adequate to my purposes. Hence, a change of course. My problem is not to conceive a setting; it already exists. I have all the reference material I need. Based on that, I want to write a game book. So, before starting to write it, I'd better concentrate my efforts in the system. And that's what I'm starting to do this month.
You, my reader, may think that this is unfair to you -- I promised a setting, and now I'm not delivering it when I said I would. Besides, I made a point of stating that I think, when designing an RPG, that it's critical to respect the "system follows setting" template. How can I move to the system without being more specific about the setting? Because... well... in past columns I provided some links that may serve as an introduction to the setting (and some of the posters added other links to mine). Furthermore, you may not know much about Portuguese adventurers in 16th century Asia, but I'm sure you know something about Renaissance Europeans, or the Spanish Conquistadores. Basically, the former are a subset of the second, and pretty similar to the latter. Hopefully this provides you with enough references to understand what I'll be discussing in upcoming columns.
SYSTEM AS LANGUAGE
Did I say "system"? I did. After all, if there's something we may be sure about, it's no system, no RPG. All RPGs have a system, and all of them mean the same basic thing: a set of rules that allow people to turn a setting into a roleplaying experience. To do this, to turn something merely described into something acted upon, we use the same basic tool: language.
In the case of the setting, we use language to present and describe it, be it written language or pictorial language (or even sound, recorded music or any other form of communication). In the case of the system, we also use language (primarily the written word) to present it, but the system has recourse to language in another, very different sense. Because, you see, a system is a language, a special language devised specifically to describe the setting in playable terms. In other words, each game has a special, conventional language to handle the game's concepts.
Usually, such languages are restricted (they have a limited vocabulary), structured (they set the exact relationships between the different components of the said language), and more or less predefined (the set of valid system terms and concepts is defined before the actual game begins, and remains essentially static during real time gaming -- even when not actively playing, the system terms and concepts are not usually changed much unless the system provides for the modification of its language).
Furthermore, they are often quantitatively oriented, since they tend to express concepts using quantities instead of qualities, numbers instead of words. (Of course, the core concepts must be expressed in qualitative terms, otherwise it would be impossible to relate the system to the setting; furthermore, this quantification serves the important purpose of facilitating the derivation of algorithms to deal with game situations.) For instance, think about a character from RuneQuest, or Call of Cthulhu, or any BRP System (1) game:
The character is described in terms of a limited set of attributes and skills -- granted, this set can be expanded, but it's not easy, it's not encouraged, and there are no clear instructions on how, when or why to do it. This is the restricted language of the game.
The usage of those terms is structured, both in terms of how they relate to each other (for instance, the way we can derive certain attributes from others; the way attributes influence skills; etc.), and the conditions where each is to be used in game situations.
That language is almost predefined. Yes, there's the possibility of adding new skills (on the other hand, adding new attributes is much more difficult). But there are no clear guidelines for doing this. It's very hard to change the language while playing -- it can be done, but this is seen as a meta-game activity not to be done on the fly, in "real time".
It's highly quantified. True, skills and attributes are designated and conceptualized in qualitative terms (Strength, Research, etc.). But to be used in the game, they are translated into a quantity, and for game purposes the quantity is the key reference for any specific application of the attribute or skill.
This is a set of characteristics that RQ inherited from, and shares with, D&D. Interestingly enough, the people currently behind D&D decided to take this principle to heart, and devised a meta-system that attempts to make explicit the restrictions, structures, and boundaries of their game language. This is the famous OGL that everybody's talking about (well, everybody except me -- I've never read the thing, I'm going by hearsay).
Previous to that, games like FUDGE attempted to break the mindset on game languages inherited from D&D. FUDGE encourages the creation of setting-specific system languages -- gamers are instructed to name and set the attributes, skills, gifts and faults that they'll need, and not to bother with elements they don't need or want. In fact, FUDGE can be described as a meta-game system game-language development tool. It also attempts to limit the quantitative orientation of systems like BRP or D&D by introducing qualitative scales -- FUDGE stats are rated not in numbers but on a seven-level verbal descriptive scale (the now famous Terrible, Poor, Mediocre, Fair, Good, Great and Superb). Yet, once the game developer decides on the vocabulary for a setting, a FUDGE game can become almost as restricted, structured, and predefined as RQ or D&D.
In Hero Wars, Robin D. Laws decided to try a different path. His reasoning was (or seems to have been, since this is my interpretation of his design process) that, if you know the setting well, you can use setting materials directly to create the system's language -- that whatever can be said about the setting can validly be used and be meaningful within the system. The system language is only restricted by the setting language. This means that it is not directly predefined.
Hero Wars has lists of terms that are used to describe characters (called keywords), but these are 1) also important to describe the setting, and 2) indicative, rather than restrictive, since the players can use those terms or not as they see fit. This is a vast improvement, since we don't have system-specific restrictions, we only have setting restrictions. (Notwithstanding, Hero Wars does keep a set of restricted and predefined concepts, but these are reserved for the functional algorithms of the game, not the definition of system entities. Finally, Hero Wars keeps a good deal of quantification.)
For The Travels of Mendes Pinto, I will attempt to produce a system that is as unrestricted and loosely structured as Hero Wars, that can live without predefined system-specific entities, and is even more qualitatively oriented than FUDGE. I'll attempt to do this, not because I think it's trendy or innovative, but because this is how I envision my ideal system and, more to the point, because I believe it suits the setting. But, to reach that stage, it will be useful to start by looking at the way other game systems work. After all, my ideas about systems resulted from my own reflections on the systems I know.
RPG systems handle game entities through what we may call descriptors, concepts that cover a particular aspect of the setting in a way that's playable. Descriptors are the lexicon and vocabulary of the game; the way they are set is the game's grammar. All games use descriptors, but they do it in very different ways. The alternatives are endless. It all depends on the whims or objectives of the game designers. Systems also use decision mechanics, mechanisms that provide dynamics to the static description provided by the descriptors, and allow the players to translate their meta-setting decisions (since the decision of a player is something that happens always at a meta-setting level) into events within the setting. In the present column I'll focus the attention in a particular subset of descriptors, those used to handle characters. The reason is simple: characters are the center of any RPG, and character descriptors are the bulk of those that can be found in any RPG system.
DID I SAY... CHARACTER?
(Part I - A character is... I mean... look... hmmmm)
How exactly does one conceive a character for the purposes of an RPG? In other words, how do we frame the description of a character (2)? If we isolate the setting from the system, it's easy to answer the question: setting-wise, we frame the character within a description, we describe him. This is done linguistically or visually within the conventions of natural language or visual media.
Things take a different turn when we move from setting to system. Here we enter the field of the game language. What we'll discuss in this section is how we may frame a system's language to handle characters, starting with examples taken from existing games, so that we may develop the conventions we'll use for this purpose in TToMP.
Different games vary according to how many and which classes of descriptors they incorporate. But they also vary according to the descriptors they incorporate in each class, the way they structure each class, and how they relate the classes of descriptors among and to each other.
In fact, each class of descriptors incorporates a set of descriptors (for instance, the class of "Attributes" in D&D incorporates Strength, Dexterity, Wisdom, Intelligence, etc). But how are the descriptors structured? The bare minimum must be a designation (like Strength), and a description ("strength is... and represents..."). Furthermore, descriptors may incorporate a scale of possible values to represent the individual differences among the set of entities that share that descriptor (in D&D, the classic 3-18 range of starting human characters). Scaling descriptors can be done in many different ways, but the basic divide is between:
Quantitative scaling. In this case, the values in the scale are expressed in quantitative form. Quantitative scales have the advantage of being easily usable in a decision mechanic, especially if that decision mechanic uses dice as quantitative randomizers.
Qualitative scaling. Here the values are expressed qualitatively, either verbally by nouns and adjectives, or visually by colors or icons. Working purely with qualitative scales is harder, because one must either use a non-random determination system or deal with the scarcity of devices which generate random qualitative values -- the game designer may have to resort to a special-purpose device, like special sets of dice or cards that use words or icons instead of numbers. Some games on the market, like the DragonLance SAGA System or the DC Universe Roleplaying System, have already done this, producing game-specific decks of cards or sets of dice; the problem here, of course, is that we're trying to create an inexpensive and easy-to-produce homebrew system.
Combined scaling. This option uses both a qualitative and a quantitative scale, like FUDGE, where stats are rated both verbally and numerically (Terrible --3, Poor --2, Mediocre --1, Fair 0, Good +1, Great +2, Superb +3). (3)
If we have scales, we also have to decide on their granularity: how many values we will consider in each scale. High granularity means that there are many values, with little difference between each step in value (in a percentile system like BRP, the difference between Research 87 and Research 88 is negligible). Low granularity means that there is a limited number of values, with the consequence that a single step in the scale may have a sizable impact (a +1 bonus in FUDGE moves you from Good to Great!). Quantitative scales lend themselves better to high granularity, while qualitative scales usually only allow low levels of granularity.
Another point concerns the way different classes of descriptors relate. This is specially important on what concerns the usage of different classes of descriptors in the decision mechanics. Actually the easiest way to handle it is by not having interrelations among descriptors of different classes. But there are other possibilities:
Modification. Descriptors of a given class change the values of the descriptors in another class. In RQ (and some other BRP games) the value of attributes (expressed in an integer scale) allows us to compute modifiers to skills (expressed in a percentage scale).
Combination. In this case, descriptors in two or more classes are used to handle a situation. This is typical of systems where situations are handled through the computation of attribute + skill + dice.
Articulation. In this case the game designer made an analysis of the overall situation and decided to break it into smaller units, assigning a type of descriptor to handle part of the situation, and another type of descriptor to handle another part of the situation. For example, skills might be used for the action (say, to make an attack), and attributes to handle the outcome (damage, or resistance to damage).
A combination of the above.
Let's sum it up: to describe a character we use descriptors. That means we need to settle on:
CLASSES OF CHARACTER DESCRIPTORS
Differences in characters' descriptors used in RPGs are both a consequence of the inherent complexity of a character, and of different approaches to character design. Here are some categories of descriptors found in two classical RPG systems, D&D and RQ:
Race. The name says it all. I guess anybody that knows the concept of roleplaying games knows the concept of RPG races. Funny enough, in this context "race" does not refer to the common sense of the word, but instead to "species". This is a minor question, though. (4)
Basic data. This is the ID card of the character. It states things like the character's name, family, origin (geographical and ethnic), age, titles, etc.
Attributes. These are the intrinsic "assets" of the character -- qualities or abilities that usually the character must have have to be a creature (at least, a creature of race X). Since these are inherent to the character, they usually don't change easily. Attributes are usually about physical and mental qualities.
Experience field. This is what the character's done and learned so far during his or her life (and may keep doing in the future), which has shaped what he or she is able to accomplish now. In D&D, this descriptor is called the Character Class. In other games it may be called a Profession, or something like that. The importance of this (in terms of system, of course) varies from game to game. In D&D it plays a crucial role, defining the path or set of paths the player can choose for his character both during creation and all subsequent gameplay. In games like RQ, its importance is mainly limited to character creation.
Skills. These are the capabilities that the character may learn or develop during his or her life. If attributes represent the inherited, skills represent the acquired (5).
Personality. While D&D set a mold where attributes represented physical and mental qualities, it was also D&D that introduced a separate category of descriptors for emotional and ethical qualities, with the infamous Alignment trait. But the company that really took this seriously was Chaosium with three games: RuneQuest (in a very loose way, since to be member of a cult one had to possess certain personality traits); Call of Cthulhu, with its Sanity (SAN) attribute; and Pendragon, with its system of traits and passions (in fact an outgrowth of a previous system developed in the RuneQuest campaign "Griffin Mountain").
Advantages / disadvantages. Don't ask me which game introduced this loose and unsystematic approach to descriptors. I really don't know. While the other categories of descriptors strive for internal consistency, the idea behind ads/disads is precisely to have a category where anything can go.
Magic. The word says it all.
Assets. Yes, I know, technically speaking this isn't a category of descriptors of the character himself, but of what he has, be it money, goods, or land. Yet, ain't it true that we are what we have?
Not all the games have all the categories mentioned above. Some do away with one or more. Some fuse two or more of these categories into one. Ultimately, a game may only have a single category of descriptors that's used for all purposes. So, let's just look at some examples (basic data and assets are not considered because any game must consider these):
D&D: attributes + race + experience field + magic + personality (alignments, remember?), where race and experience field incorporate what's covered by skills and ads/disads in other games.
BRP: race + attributes + skills + magic. Experience field is an added layer above the ones mentioned, used solely for character creation purposes.
Pendragon: similar to BRP + personality traits.
GURPS: loosely equal to BRP + ads/disads.
Hero Wars: keywords. Keywords incorporate all the categories mentioned above under a single concept.
Let's-Pretend: it's your game, dude/babe; do what you want.
What about TToMP? If we follow the pattern set in the design matrix, the answer can only be "all of them" (meaning we are moving from a nonexistent system development effort to a chaotic one).
DESCRIPTORS IN TToMP: THE CASE FOR ATTRIBUTES
Needless to say, TToMP must incorporate basic data and asset descriptors. Furthermore it does not require race (in the sense of species mentioned above) or magic, since the game is based on our historical real world. It will not have ads/disads, since I don't like character design that works by accumulating "cool", "nice", or "funny" ideas that just pop up in the game designer's mind -- I prefer tidiness and internal consistency within a set of descriptors. Neither will it have experience fields, if these are considered in terms of functional patterns of capabilities developed for system purposes (think D&D classes here). That means that I'll reduce my field of analysis to attributes, skills, and personality traits.
Let's start with RuneQuest, my first RPG. What does it have to offer in terms of attributes? Seven: Constitution, Dexterity, Size, Strength, Intelligence, Power, Charisma (RQ2) or Presence (RQ3). Let's also consider D&D (after all, BRP's set of attributes was derived from D&D): Strength, Dexterity, Constitution, Intelligence, Wisdom, and Charisma.
What a mess. It's time to bring some order to this chaos. We can reduce the two lists to one with nine items: Size, Strength, Adroitness (a better name for "Dexterity" since the attribute incorporates both dexterity and agility), Constitution, Intelligence, Wisdom, Power, Charisma, and Presence. Should I keep this list? Should I omit some of these attributes? Should I add some missing ones? Let's see:
Wisdom I would rather consider a question of personality. Drop one.
Power is a magical attribute. But there's no magic in TToMP (at least in the sense things like "Power" are supposed to handle it). Drop another.
Adroitness can be split into two: Dexterity and Agility. But really, anything that can be said about Dexterity can be said about Agility, so it's more economical to keep both under Adroitness. And we can always split it with advanced rules. Keep one.
Correct me if I'm wrong, but Strength is the product of mass and work. In game terms mass is Size, while work is Adroitness. So there's no point in having an attribute to represent strength separated from Size and Adroitness. All we need is a rule to derive strength from a combination of the other two. Drop a third.
Charisma. Since I'm tentatively planning to separate attributes from personality traits, where should I put charisma? I guess it belongs in the personality bowl. Drop a fourth.
I always felt that Perception was a must have in any self-respecting list of attributes. Add one.
So far our revised list keeps six attributes: Intellect (formerly Intelligence), Perception, Appearance (also called Presence), Size, Adroitness, and Constitution. Tidy, huh? But does it fit? To answer that question, a good knowledge of the setting is a must. I think you will have to rely on me for this one:
Intellect. The Renaissance produced a good deal of genius. But what's in a genius? Something personal, of course, something we can call talent. But also hard work to learn its craft. And a good environment in which to flourish. Work and environment don't fit the concept of the attribute as presented, but they may be covered by skills. We are left with talent. Do we see a lot of variance in terms of intellectual abilities in Mendes Pinto's book? Nah. It's not a game about talented people, but about the common man. Drop one. (And if you really want it, advanced rules may provide a space for the concept.)
Perception. The analysis applied to Adroitness (see below) fits here like a glove. Furthermore, in a group of people perception is usually used collectively. Drop another.
Appearance. Of whom? The characters? That bunch of losers subject to getting slashed, impaled or crushed by their enemies, broken with hardships, beaten by nature and man? There's no place for pretty faces here. At least at the level of the standard rules. Advanced rules may bring it to the fore, but that's another issue. Drop three.
Size. How many times does Mendes Pinto mention size as a relevant characteristic of the personalities he presents in his book? Not many. Maybe none. Furthermore, did you ever go to a place inhabited by people that still live according to pre-modern standards (meaning, no advanced medicine, no extensive functional specialization, food scarcity, a lot of physical activity for everybody)? Did you notice how most people seemed to stick to the norm in their overall physical aspects (size, mass, etc.)? The bottom line: Size is a non-issue in TToMP. Drop four.
Adroitness. How many times does Mendes Pinto point to a character because of his or her prowess in dexterity or agility? Can't remember? Neither do I. Now, try to locate the list of results in the first Olympic games. Not impressive, hm? The truth is, again, in pre-modern societies most people stick to the average in terms of adroitness. So there's no point in making an issue out of it. Drop five.
Constitution. Characters in TToMP are Europeans. These men (and the occasional woman) had to survive from childhood in really adverse conditions; had to sail in an insalubrious boat for months in the trip to Asia;,where they found a very hostile environment full of new and strange sicknesses - with no proper medicines to cure their pains. And yet they survived. The reason is simple: they had a very good constitution. Point. Drop six.
Let's see, we're left with, hmm, certo, 6 minus 6 = nada. No attributes. Zero.
Outrageous. Impossible. Do I really mean... no attributes? Especially no physical attributes like size, adroitness or constitution?
Well, look at it this way:
The functional effect of size and adroitness may be incorporated into "skills", or the equivalent (if there are any "skills" in TtoMP; at the present rate, I wonder). The same applies to intellect and perception.
Constitution does not exist in the game as an express attribute, but the book of Mendes Pinto is full of people getting sick or hurt (yes, there are fights in this game). There must be a way to handle this, a way that does not require a constitution stat. We won't miss it.
Another thing that's often mentioned in the book - and other sources - is the importance of being (or rather not being) physically impaired. Since this comes straight from the setting material, the game must take notice of it. Ditto for aging, albeit to a lesser extent. Yet again, there is no need of a stat to handle this.
So the game has space to handle all aspects incorporated in the cited attributes. It just happens that this is not done openly, but implicitly. We must assume that beginning characters have a good constitution, a more or less standard size and adroitness, etc. They have these qualities because they live in an environment that doesn't favor under-performers in these fields (it's called natural selection), nor has incentives to develop over-performers (it's called lack of advanced specialization).
This is not new. There are games that did this. I just felt the need to explain why TToMP would follow that path.
Conclusion: in my first instance in attempting a match between setting and system all I got was an empty hand. Let's see what the future brings. Next week it's up to skills. Will they survive the test?
(1) You don't know what BRP means? Creature, that makes me feel old. Go ask Steve Dempsey, he can enlighten you. He loves it. (Ed. Note: BRP stands for Basic Role-Playing System, Chaosium's master rules mechanics used for most Chaosium games including RuneQuest, Call of Cthulhu, Chivalry & Sorcery and others.)
(2) In other words, which descriptors are used, knowing that in the context of the present column "descriptor" refers to any system used to describe a character.
(3) The game that really opened my eyes to the possibility of combined scaling was SkyRealms of Jorune. This game incorporates what could be called a one-to-many match between the qualitative and the quantitative scales. This means a value in the qualitative scale aggregates several values in the quantitative scale. For instance, a "Veteran" in Jorune's qualitative scale is equal to levels 7, 8 or 9 in the quantitative scale (if I recall correctly). In the case of FUDGE, the match is one-to-one: each value in the qualitative scale matches a value in the quantitative scale. Several years ago I was discussing qualitative scales in a discussion list, and being over-enthusiastic about it (since I had come up with the concept independently and didn't know there were already games in the market using it). My idea was to use a single qualitative scale where each value would require a certain combination of dice. Someone pointed out to me that functionally, this just amounted to a quantitative scale with nice but useless labels attached. This is a problem I'll discuss in the future.
(4) Given that in TToMP all characters will be human beings, we needn't bother considering "race" as a class of descriptors.
(5) Furthermore, there's an overlap between Experience Field and Skills. To a certain extent they deal with the same reality, they just choose completely different paths to do so. If an Experience Field is a broad view of interrelated abilities, Skills are concrete, discrete abilities.