Archive for the 'Gaming Features' Category

Design Feature III: Expanding on Character Aspects

Welcome back once again to Ashe’s feature on designing your own game system.

So far we’ve talked about the fundamental aspects of a game system (Action Resolution, Effect Resolution and Special Cases) as well as the basics of character aspect designs and how they relate to the action resolution method of system design.

In this section, I’m going to try and deviate a bit from the hard technicalities of system design and talk a bit more about personal choice in character aspects. To do this, we must first analyze both the setting and focus of the game and the character as an individual.

First, you should begin putting some serious thought into the nature of your game setting. If you are looking into making a generic game, you will have to be considering all possible settings. Personally, in my experience, it is far better when starting out to choose a setting to focus on rather than beginning with all at once. Thing is, you can always expand on the system later. Building with the the generic system in mind may seem preemptive, but in reality may also cause you to overcomplicate and over-consider
when designing. If you want a fantasy setting then you will have different considerations for aspects and characters than you would for science fiction (high sci-fi, as in Herbert’s Dune or the works of Philip K. Dick). Also, you have to consider subject matter and themes in these designs. Why? Consider that campaigns that draw quite a bit of horror influence should consider fear and psychology beyond that of a standard resistance to terror effects. Such a theme might require the consideration of psychological
derangement. How much drama do you want the game to focus on?

Second, you need to look at what makes a character, a created individual, tick. Or what in your mind does and how you want your game system to reflect this. In the last feature, we talked about core attributes (Primal Aspects in seven13 terms) and the necessity of relating them to the character’s skills, but how far do you go beyond there?

The first consideration to creating a system of character aspects is classification. In a sense, every viable, usable thing of any sort that can relate to a character taking action, receiving effects or modifying outcomes can be an aspect. This goes far beyond the core aspects of the character and may even include aspects which actually represent trained specific or unique things the character is able to do. As an example of this last, Dungeons and Dragons employs a system of Feats, which are learned by characters
and can add modifiers to many actions. This type of system is essential to D&D’s target number method of system design. At the inverse lies the dice-pool method, which should include far less dice-pool modifying factors as one does not want the character to be rolling an entire bag of dice for a single action outcome. With a percentile system, such modifying aspects can be use to increase or decrease the character’s percentage by a slight margin.

So, the key here is determining how you wish to classify character aspects and how you wish to consider working them into your game system design. Let’s take a look at some different possible classifications for aspects:
Core Attributes/Aspects are those centralized aspects that you will expect all playable characters, or even NPCs in your game, to possess. Strength, Agility, Mind or others are examples. You may also wish to classify these into categories, such as Physical Core Aspects, Mental Core Aspects, Social Core Aspects or Supernatural Core Aspects.
Skills or learned talents, represent areas of study, expertise or proficiency in which the character is trained and generally cover a broad range of action rather than that of a specific one, such as that of a combat maneuver. Some examples of skills might be Unarmed or Melee Combat, Acrobatics or Abnormal Psychology. With skills, it is up to you who detailed or in-depth you want your skills to be.
This should, however, reflect your system. If your system will be more in-depth and complex your skills should be as well; the inverse is also true. Either way, your skills should link in some way to the characters core aspects so as not to allow a character with a Dexterity of minimum score to possess an acrobatics of maximum. Such links also allow the character to attempt actions from the range of a skill he may not possess, based solely on his relevant natural skill.
Psychological Aspects refer to aspects of the character that measure or affect his mental well-being. In the classic The Call of Cthulhu, the character’s psychology is represented by a number of Sanity Points, a simplistic but effective system. Psychological aspects may also be only negative and gained as a result of mental trauma, such as Derangements present in the World of Darkness by White Wolf
studios.
Specific Aspects is a term used to refer to very specific use aspects such as combat maneuvers or the Feats present in Dungeons & Dragons. These aspects may be learned as a progression along a path of study or may be racial in nature among any number of factors. Specific Aspects generally fall into the special cases section of system design. In part two, when discussing examples of systems, the
combat maneuvers used by the example characters could be examples of specific aspects.
Supernatural Aspects or powers may refer to specific abilities of the character that set him beyond the mundane, such as the ability to command magic or super powers. Such aspects may be treated as skills or might be handled in a similar fashion to specific aspects. The ability to fly or casting spells from certain schools of magic are examples of supernatural aspects.
Unique Aspects represent special aspects that may modify the character’s actions in a positive or negative way and help make him unique. These are classically called Advantages and Disadvantages in many game system (though we call them Gifts and Frailties in seven13). Unique aspects in any form exist to breathe a bit more life into the character and are often considered themselves special cases in the
system, usually revolving around modifiers to actions or specific role-play functions.
Now, with the exception of Specific and Unique aspects, all of these are aspects that deal almost exclusively with action resolution factors. You must also consider aspects which determine how much physical punishment the character can withstand in combat and other effect resolution considerations, which we will discuss soon.
For now, it is best to begin taking some notes on how you may wish to classify aspects for characters under your system and how they may have an effect on your game mechanic. In my next feature, we will begin to discuss how effect resolution functions in the game system and what methods and devices may work for what types of game mechanics. Beyond that, we will eventually discuss special cases, game balancing, combining
mechanics and overall world and metaplot design. Until then -
– Ashe

Design Feature II: Aspects and Actions

Yeah I know it’s been a while since the first one, I’ve spent far too much time doing other things.

In my first feature about game design, I talked about the fundamentals of creating a game system: deciding the mechanic and considering the setting you will use. In this feature, I will discuss the first and primary function your game system will have to resolve: actions.

Characters in the game take actions constantly. If a character elects to do anything in the game, the character is taking an action. Whether this is as simple as opening a door or as complex as disarming a bomb with 10 seconds left on the clock in a fire fight, the end result is the same: the character is either successful or unsuccessful. Now beyond that you may want a system to determine how successful or unsuccessful the character is, but I always urge anyone designing to think simple primarily. Things can get really complex and run away with you in game design and its important to always have an end-all reference point for what it is you’re really trying to do.

So how does the character go about taking an action? How do we know if he is capable of taking said action and, if so, how adept or skilled he is at the attempt? The answer is Character Aspects. Every role-playing game you’ve ever played, table-top or video game, possesses character aspects. What these determine is up to you, characters in game may possess as many different aspects as you like. Different game systems break them down in different ways, and there is no real wrong or right way to handle this.
One way to handle character aspects is to have all be independent, that is, each aspect will roll individually without consideration for the others. This can make things simpler early-on in the design process, but runs into serious problems when you consider realism (if that is one of your aims). For example, let’s say our game system rates character aspects from 1-12 and all aspects are independent. A character might have a Flexibility aspect rated at 4 and an Acrobatics/Gymnast aspect rated at 10? How did this happen? Obviously Acrobatics/Gymnast requires an extreme amount of flexibility to excel at, so how does a character with so little flexibility accomplish such a high rating? When it comes down to it, it simply doesn’t work for realism purposes. It’s for that reason that I personally recommend (and use in my designs) classified aspects that link to one another. Let me elaborate.

In any game system, you should be working from centralized core-concepts that work throughout the game and aspects should follow this as well. Simplicity is the building block; you can decide where you want to go with expanding rules from there. First we have to find a way to centralize our character aspects. We can postulate here that while characters of different races, cultures and species may possess drastically differnt skills, training or powers, there are inherent physical aspects about them that may be determined to be similar. This is where the core aspects, statistics or whatever (in Seven13 we call them Primal Aspects) come into play. Core attributes or character aspects provide a central focus describing the ability of characters in the game system, but also in a way provide the groundwork for a generic system (should you choose to take that route). Basically you need to cover at least the bases of Physical attributes and Mental attributes. Optional Attributes for your design may include those related to innate supernatural or social talents, but you could also simply use those as aspects elsewhere. Since we can assume that the characters think (at least to some degree) and move, the core aspects must decide their end-all potential for these things. The two classic physical aspects used in most every game system I’ve seen are Strength (physical muscle potential) and Dexterity (flexibility and grace of motion) to give examples. Mental aspects generally measure the characters cognitive intelligence potential and sometimes his actual worldliness and knowledge gained through personal experience (such as the Wisdom score in Dungeons & Dragons). You may or may not wish to make this distinction. All you really need to understand here at this point is that core attributes are designed to be applied to almost any character or creature in the game system, whether that creature or character possesses any trained/learned abilities or not.

Next, there are any number of different aspect classifications you may create for the character. You could simply have the core aspects and chuck all of the rest into a classification called “character talents” or something, or you could break them down into Skills, Powers, Special Maneuvers or any number of things. Here is where the groundwork laid down in the first part of this feature begins to come into play. Here you will begin to see some of the Effect resolution and Special Cases ideas of system design come into focus. It starts to get complicated here, folks I must warn you, and I may not be able to explain all of this in this part, but I’ll try to give you the gist.

Pretty much everything that the character may possess that relates to the system that may fluctuate during the campaign or be used from a system stance is an aspect. This includes (but is not limited to): skills, supernatural powers, wounding and healing potential, combat maneuvers, special distinctions/advantages and psychological traits. Here is where your core game mechanic will come into play. Therefore, It’s probably a good time to elaborate on the three core game mechanics we talked about in part one and how they will relate to character aspects and begin to form the real core of your game system. In the examples that follow, I’ll examine these examples from a basic standpoint and display a punch/dodge scenario. At this point I will be including very little special cases other than simple modifiers. Hopefully, this will give you a bit of a framework for the very basic ways these core mechanics may function.

Target Number game system mechanics, most often, will be adding character aspects together to create a value that will be modified by the situation, added to a dice roll and then compared to a target number. For example, in the case of throwing a punch, you might have a character with a Dexterity aspect added to an Unarmed Combat aspect which might also add a bonus for a combat maneuver and a dice roll compared against a target number to beat (overpower or have a higher end value), in this case likely an opponent’s resisting aspects total (we’ll call this Defense Value, or DV).
For Example: On a target number system that rates aspects from 1-12 and rolls 1D12 for attacks, we have a character with Dexterity 7, Brawling 6 using a special combat maneuver (we’ll call is Fists of Fury) that adds +4 to his attack. Therefore, before the roll is made, this characters total ability (We’ll call this Attack Value, or AV) is 17. This character will be attacking an opponent with a DV of 21 (we’ll say this antagonist has Dexterity 9, Dodge 7 and is employing a supernatural aspect called Phase that adds +5 to evading maneuvers). So now we have Character 1 punching (AV 17) vs. Character 2 evading (DV 21). Both will roll 1D12 and add to their totals. Char 1 rolls 9 (+AV17=26 total) and Char2 rolls 10 (+DV21=31). We have therefore determined by this action resolution method that Char 2 has dodged the attack of Char 1.

Dice Pool game system mechanics will be adding up values in the various aspects of the character to create a “Dice Pool” or number of physical dice to be rolled in an effort to accumulate multiple instances of success, rolling higher than a target number on each dice. For this example mechanic we will pool D6’s and say that any roll 4 or higher (4,5, or 6) ends in success. We will use the same example given above (Char 1 punches Char 2 who elects to dodge). In this example, our character aspects will be rated 1-7, Fits of Fury will add 1 success to the final total and Phase will add 2 successes to the final total. Character 1 (attacker, Punch, evoking Fists of Fury, +1) has a Dexterity of 3 and a Brawling of 3 for a total of 6 dice to be rolled. Character 2 (defender, Dodge, evoking Phase, +2) has a Dexterity of 4 and a Dodge of 4 for a total of 8 dice to be rolled. When the rolls are made, Char 1 will have 1 instant success and Character 2 will have 2 instant successes, giving character 2 the advantage here. Character 1 (rolling 6D6) rolls 1,4,5,5,3, and 4; for 4+1 (5 total successes). Character 2 (rolling 8D6) rolls 1,2,2,3,4,6,6, and 5; for 4+2 (6 total successes). Once again, Char 2 evades the punch here.

Percentile game systems use percentile dice (d% or d100) where one die represents the “tens” place and the other the “ones” place in a number from either 00-99 or 01-100. In percentile dice systems, rolling lower is better. The character’s end value, or percentage chance, represents the number to roll beneath for success. Seven13 uses a percentile system variant, but here I will discuss the classical percentile mechanic. In our example, using the classical percentile mechanic, the characters’ Dexterity will have no bearing on the attack/defense. Here, these core values will possibly either have helped to determine the Brawling/Dodge skills’ values, or will operate independently. Using our special combat maneuvers here we will say that Fists of Fury grants a +2% bonus and Phase grants a +7% bonus to their respective declared actions. We will say in this case that Character 1 has a Brawling of 38 (+2=40%) and Character 2 has a Dodge of 45 (+7=52%). Character 1 rolls 20, success. Character 2 rolls 51, also success.
Herein lies the problem with the percentile mechanic: both characters are successful, technically, in their rolls, so what happened in the end? As the designer, you must decide to specify this ahead of time here.

In these three examples, I have tried to provide a fairly simple idea of how character aspects function in the classical sense with these different game mechanics. At this point, you should be considering how you view each of these mechanics and continuing to lay out the basis for your game system. There is a lot more I have yet to discuss and things are already going to be getting complicated for some her. Not to discourage, but if this section was too complicated for you to follow, you should either start working together with someone on your game system or decide to be content playing, because it only gets more tricky from here. Then again, if I were you, I would completely ignore that last sentence and go on anyways. After all, that’s what I did, and my book goes worldwide next year.

That’s all for now though folks. I figure I’ll quit there to let those examples sink in. In the next part of this feature, I will provide a bit more insight into classifications of character aspects and some different things you might be interested to try. After that we get into the glories of effect resolution and special cases, which will get tricky big-time. Until then, your questions and comments are always welcome.

– Ashe

Design Feature: The Fundamentals

I suppose that the beast way to start the features is to start from the core aspects of what we will be talking about. Nearly all of the features in one way or another will deal with either the 7/13 generic engine itself or with the CoE perception of reality.

This first feature is about designing role-playing games in general. After this many years being around everything, I’ve always observed that people who play RPGs generally, at least one time or another, put some thought into designing their own game. I’ll tell you first off, it’s not as easy as it sounds and there are probably many of you out there who already understand this. The key there is actually the inverse: it’s not that the design aspect is really all that difficult (or at least it shouldn’t be) – it’s
that getting the simplistic aspect to a game engine, the flow of the game, is what poses the greatest amount of difficulty.

For any of you out there who have aspirations about designing your own game I strongly urge you to do it. I know there are a lot of folks in the industry who are actually pretty negative on this point (I’ve seen them beating down new designers often on forums or otherwise), but I think there is a lot to be had from new designers. I was privileged to have played in the demo of a new game out in Austin Texas that was a fabulous, very original concept that worked very well and this would never have been possible
if those creating it had bowed down to the concept of writing for d20 or another game system. If you want to do that, to write for another system then that’s fine, but designing your own game system is important I think at least to truly understand the mechanics of game design – the technical work.

There is actually quite a bit of insight into design hidden here and there in 7/13:CoE…I’m not secretive at all about how I designed the game engine – I’m always up for a new game engine to read or play. What I’m working on here is a bit of insight for you, the players, into some good practices for game design. As a secondary factor, this feature (and the ones I will write in relation to it) refer to how seven13 was created. If you can’t tell by now, I’m fairly long-winded in my writing, but I get fairly thorough
to my credit, so bear with me.

The first and most important thing to consider about any game system is the Big Three: Action Resolution (AR), Effect Resolution (ER) and Special Cases (SC). Action resolution refers to the systems that help determine the results of characters taking actions in the game, effect resolution refers to what happens as a result of the action succeeding or failing, and special cases effect both based on situations and factors effecting the action or effect. It’s really not that complicated at the core, but it can get
really complicated fast – so it’s always important to remember those big three and that at the absolute core, that’s all there is to the system. Simplicity is the key to designing a game system that will do well – it’s easy for people to build on the rules, but you may find often that players are for some reason less likely to remove rules. I’m not sure why that is, but trust me, it’s true.

Now, to tangent, there are a lot of paradoxes and balance to everything I will say here, but there is a point to it. While I’ve just talked about simplicity being the key, it is a final goal. Your game system should be thorough enough to include rules for most foreseeable situations that will affect the game, but with so many considerations to take into account that idea can come crashing down and overpower the game with rules very quickly. The key is to design based on centralized core concepts. The best programmers
in the world often are not determined by whether or not they can make something great, but how precise they are in doing it. The difference between a program written by a novice and a master that are virtually the same is usually found in the master’s code: it is much more direct, crunched down and simplistic and there is less of it.

But let’s get back to the fundamentals. Our first and primary consideration for a game system has nothing to do with rules at all; it has to do with style. The first thing you have to figure out before you even consider the system aspects of the design are what you as the designer want to create. The easiest decision here is whether or not you want a diceless system (one that requires no rolling and determines AR and ER by character aspects and story alone) or the classic dice-rolling based system. Personally
I prefer dice-based systems so I’ll be using that concept as we move on. I’ll create at least one feature in this chain that involves diceless design, but for now I’m going to start on the traditional angle. The next thing to consider is what your core mechanic will be. This will determine almost every aspect of your system related efforts. Let’s go through some of the classical game mechanics:

  • Target Number: Relevant character aspects are combined with the roll of a die (or dice) and added all together against a Target Number to determine success. This is seen currently in the d20 system among others.
  • Dice Pool: Character aspects determine a number of similar dice (d6 or d10 usually to roll), requiring a number of rolls tat are higher than a certain value (successes). This is seen in the World of Darkness game system among others.
  • Percentile: Character aspects are ranked up to 100 and percentile dice (d100 or d%) are used with the concept of rolling beneath the character’s value or target value of 1-100 (% chance). Seven13 uses this method, as well as Call of Cthulhu and many other games.

Now these are only three core mechanics, but they are the most common and most stable. Also, I should note that these are only ideas. While 7/13 uses the Percentile mechanic for resolution, it has many other aspects that differ from standard percentile system. None of these methods are better than the others, it is simply a matter of taste. All can be made into perfectly functional game systems. In my opinion at the heart of it all Target Number is a mechanic that serves more strategic, technical games best,
Dice Pool serves heavily narrative games best, and percentile sits somewhere in between. Then again, all could be used to any purpose with the proper design and each could be combined with the others for certain situations in game.My recommendation is to start with the form you are comfortable with and work from there. I have a heavy background in Call of Cthulhu and 1st Edition Warhammer Fantasy Roleplay, so the Percentile mechanic came easily for me.

Secondly you should consider what type of game you are designing as this creates a good basis for what types of rules you will need. This, primarily, means determining your setting. I personally do not recommend starting on the basis of creating a generic game engine, as the work and tweaking there is very heavy and involved and can easily be worked up to later. Personally I started with high fantasy long before Seven13 was anywhere near it’s current self, but you might be more inclined toward a modern setting
or one of Science Fiction. Once you have this figured out, you have already done a lot of work toward your design layout.

So let’s rehash: The fundamentals of the game system design are basically the mechanic and the style. The mechanic will determine the basis of how the game will run from the technical side, and the style will help in the future with understanding what the rules need to do. For example, a high fantasy style will not require rules for automatic firearms. Once you have these set in mind, you have a good place to start designing your own game, or at least for understanding the way systems are being designed.

In the next section of this feature, I’ll start tackling character aspects and systems for actions, but for now mull over this for a while. Your questions, comments and suggestions are always welcome here.

- Ashe