WIXLIB

Introduction1IntroductionIn the 1960s, Christopher Alexander, an architect, proposed a practical new way toundertake urban planning. His idea was to first study the best examples ofcontemporary urban plans and buildings with the goal of finding common patterns intheir designs. Once identified, these patterns could be exploited in future designs. Hedescribed this process of design by pattern (or, in his terms, diagrams) in his workNotes on the Synthesis of Form. In this text, Alexander describes patterns as being notmerely informal guidelines, but as a formalized arena of discourse. Once a pattern isidentified and formalized, it can be easily referenced by domain experts and objectivelycompared to other formalized patterns in its ability to satisfy design goals.In 1987, Christopher Alexander’s ideas were first applied to software when WardCunningham and Kent Beck wrote a paper entitled "Using Pattern Languages forObject-Oriented Programs." This paper presented five patterns that could be used tosolve problems in graphical user interface (GUI) design. The software community sawthe potential of design patterns and a great deal of discussion ensued in articles andworkshops.Seven years later (1995), the book Design Patterns: Elements of Reusable ObjectOriented Software was published. This book was the first to bring the concept of designpatterns to the software development community at large. In so doing, the bookrevolutionized how modern software is written. The book is so well respected that thefour authors who wrote it are known simply as “The Gang of Four” by developerssubscribing to the design pattern philosophy. The book consists of 24 design patternsthat instruct the reader in excellent solutions to common software problems. The bookis considered seminal and its pattern names have become common industry jargon.The authors of Design Patterns looked at the designs of many, many successful softwaresystems and interviewed their programmers concerning their design decisions. Notethat only successful programs were investigated, since they weren’t trying to analyzewhy projects fail, but merely to find common characteristics of successful designs. Nomatter how inventive a solution, though, the authors would not call it a “pattern” unlessit clearly appeared in at least two independent systems.In all of their analyses, a number of patterns emerged. Certain solutions were foundagain and again. The authors took their results and formally wrote up detaileddescriptions of the patterns and the problems they solved. By doing so, they elevatedthe “rules of thumb” they encountered to fundamental design principles. Once theirbook was published, even the gurus benefited, since they now had access to a treasuretrove of world-class design solutions, many of which would have been new to even thebest of them.Although my formal training is in Engineering, I am a software developer by trade withmany years of experience in architecting software systems. It is probably no surprise,then, that my primary role-playing game design project, Legendary Quest, has been

2Introductionheavily influenced by software design concepts. I believe that role-playing games ingeneral can profit by the lessons learned by the software industry. Consequently, Ifirmly believe that role-playing games can benefit from the same kind of design patternanalysis undertaken by the Gang of Four. It seems obvious to me that patterns exist inthe design of role-playing games. If we analyze successful games, we should be able toidentify Role-Playing Game (RPG) design patterns that could be re-used in future gamedesigns.Software design patterns do not form the basis for any software theory, although theymay exploit theoretical concepts such as object orientation. Similarly, RPG designpatterns will not likely form the basis for any new RPG theory, such asGamism/Narrativism/Simulationism (GNS), Game/Drama/Simulation (GDS), The BigModel, or any other. (If you don’t know what any of those terms mean, don’t worry,you don’t need them to understand this book. If you want to learn more about RPGtheory, though, visit The Forge website at http://www.indie-rpgs.com.)RPG design patterns are not about deciding upon a creative agenda, genre, or evenhelping you clarify your design goals. RPG design patterns are about formalizing themechanics observed in existing pen-and-paper role-playing games, the kind of gameswhere the players sit around a table and actually talk to one another. Each patterndescription discusses its particular strengths and weaknesses, and educates gamedesigners interested in using the same techniques on how to properly implement them.This study focuses exclusively on the nitty-gritty structure and mechanical design oftable-top role-playing systems. RPG design patterns have nothing to do with mood orsetting, although these issues are obviously quite important to many games. In otherwords, design patterns approach game development at a micro level rather than a macrolevel. For example, if you have decided that you want to abandon hit points as a meansto measure character survivability in your fledgling game, what are your other options?What about alignment? Are there better ways to guide character behavior? Arecharacter classes the best option for your design goals? If so, what pitfalls should youavoid in implementing them? If not, what are the alternatives? How should conflicts beresolved? Is there more than one approach?RPG design patterns should be kept as independent as possible from over-arching gametheories. Design patterns fall into the realm of RPG engineering rather than RPGtheory. So, design patterns should be viewed as complementary to theory rather thancompetitive. Most patterns will be at a very low level. The only assumption RPGdesign patterns should make is that the designs of good role-playing games re-usecommon patterns that can be identified and exploited in the designs of future games.Understanding design patterns, then, helps a game designer avoid repeating the samelow-level mechanical mistakes others have made in the past. RPG Theory, on the otherhand, looks at the whole problem of game design from a high level. It analyzes broaderissues such as the differences between games that emphasize story creation overcompetition, and how these differences impact play.

The First Step in Designing an RPG3The First Step in Designing an RPGDesign Patterns won’t help you to design anything if you don’t have an idea of what itis you are designing. First of all, let’s suppose you have the following goals:1) You want to design a “pen and paper” role-playing game, where real people sitaround a real table and talk to one another face to face.2) You want the game to be fun.Good. That narrows down the scope of things you might be designing from, say, ahydraulic back hoe to something that this book can help you with. But, while thosegoals certainly help get us into this particular ballpark, they aren’t sufficient for thisbook to do you any real good. Before you start looking at specific design patterns, youneed to have some clear idea of exactly what kind of game you are going aboutdesigning. RPG design patterns help you objectively decide what to include in yourgame based on your design goals. Without those goals, you’ve got nothing to guideyou.So, before you start, sit down and figure out precisely what it is that your game is goingto be about. What are you trying to accomplish? What mood are you trying to evoke?What do the characters do? More importantly, what do the players do? What literarygenre corresponds to your concept? What age group does your game target? What kindof activities do you want to reward and what kinds of rewards do you want to provide?Are you concerned about implementing this game in a computer at any point in thefuture? Are you expecting your game sequences to extend for many sessions or willstories play out relatively quickly? Do you envision a game that can be easily extendedwith numerous supplements or are you more interested in creating a single, selfcontained book of simple rules? The more specific you are in stating your goals, thebetter off you’ll be and the more useful advice this book can provide.DefinitionsNeedless to say, the research for this book entailed reading a lot of role-playing games.But, comprehension did not come easily. Picking up a new game and thumbing throughits pages to extract the important bits was often painful. Game authors use popularterms like “attribute,” “skill,” and “trait” inconsistently. So, understanding an author’sintent required digging through the game text and then translating the terms into acommon vernacular. Note that some of these terms are written up as full-blown designpatterns.Attribute: A gauge that is a common characteristic, a commonality. (See, gaugedefinition, Attribute design pattern.)Character: A persona in a game portrayed by a player, including possibly the GameMaster.Characteristic: An aspect of a character. A character’s name, height, age, beauty, andstrength are some possible characteristics.

4IntroductionCommon Characteristic (Attribute or Commonality): A characteristic common to allcharacters of a given type in a game. A character’s name, height, age, beauty, andstrength are frequently common characteristics. Most games directly state theattributes and other commonalities characters possess. Some games providedifferent sets of attributes for player and non-player characters. Such gamespartition PC’s and NPC’s into different types.Conflict: Contention between characters, players, and/or game forces, especiallycontention that shapes the game’s plot. This includes opposition between two ormore players concerning what facts should be introduced into a game world.Contest: A conflict that is resolved through mechanical means (e.g., dice rolls,comparing numbers, etc.).Derived Attribute: An attribute whose value is determined by a formula. Typicallythe formula uses other attribute values to generate a number.Drama: An outcome based purely on story considerations. A drama based conflictrolls no dice and compares no numbers. Outcomes are exclusively determined bywhat would be most entertaining for the participants.Flaw: A selected characteristic that is specifically not also a gauge. A character eitherhas a flaw or he does not. Flaws are structurally very similar to gifts. But, flawsare generally considered detrimental to a character rather than beneficial.Fortune: An outcome that is at least partly based on random factors. This may includerolling dice, drawing cards, or some other random value generator.Game Master (GM): A player assigned responsibilities different from other players.These responsibilities commonly include acting as the final authority in disputes,playing NPC’s, describing scenes, etc. Some games have no Game Master. (Seethe Game Master design pattern.)Gauge: A graduated value generally associated with a name. Commonly the graduatedvalues are numbers, but this is not always the case. (See the Gauge design pattern.)Gift: A selected characteristic that is specifically not also a gauge. A character eitherhas a gift or he does not. In general, gifts are considered beneficial to a character’swell-being. (See the Gift design pattern.)Handicap: A selected c

Object-Oriented Programs." This paper presented five patterns that could be used to solve problems in graphical user interface (GUI) design. The software community saw the potential of design patterns and a great deal of discussion ensued in articles and workshops. Seven years later (1995), the book Design Patterns: Elements of Reusable Object-