Being an engineer by training and a software developer by trade, I have often thought that the tools of the software industry could apply to role-playing game design.  In fact, software design practices influenced much of Legendary Quest’s design, so I know at least some of it is germane. One of the most potent tools in a software developer’s toolbox is the concept of Design Patterns. Design Patterns are well-considered approaches to difficult problems whose solutions have been observed in previous works.  A little over a year ago, it occurred to me that the Design Pattern approach would work equally well in role-playing game design.  So, over the last year, I performed a study of various role-playing games in hopes of gleaning patterns.  Many of the games I examined were designed and written by this forum’s contributors.

Writing a book is an excellent way to force oneself to learn a subject, which I wished to do while preparing to tackle the 8th edition of Legendary Quest.  And, since browsing these forums has enriched my life over the years, I want to contribute something back. 

So, with some guidance from Mike Holmes, I wrote a book: “Design Patterns of Successful Role-Playing Games”.  The book contains patterns, both good and bad, that I encountered in my study.  It also contains design summaries of the various games I scrutinized.  The book is not done yet, but I think there’s enough there to illustrate what I envision.  I also think that it’s sufficiently complete to help out game designers to some degree.  You can download a draft version of the book from the Downloads page of my website at http://legendaryquest.com. 

I’d like to get feedback about the direction I’m heading with it.  I’d like this thread to focus on the concept of Design Patterns as it applies to role-playing game design.  Are Design Patterns something that can further our understanding of game design?  Should I tweak my approach to make it more pertinent to the needs of the game designer community?  Is this a reasonable step in the direction of RPG engineering?  Or, am I just way off base with this?

If you have questions or comments about a specific Design Pattern or Game Summary, I’ll be happy to respond.  But, please split those issues out into their own separate threads so we can keep this one scoped to a manageable level.  Including the term “Pattern”, “Anti-pattern”, or “Summary” in your thread’s title will help me identify it as something pertinent to this topic.

One final note:  Mike Holmes gave me a great deal of excellent feedback while writing this book, and I’d like to publicly thank him for that.  But, he hasn’t seen all of it yet at the time of this posting.  So, please attribute any blatantly idiotic blunders to me.

I think this a fantastic approach that will likely/hopefully produce games that are more purposefully, rather than inspirationally, assembled.  Bravo.  I've only scanned the document but it looks fantastic to me.  On the down side, this sort of analysis has been consistently stamped on to date and we shall have to see what happens.

This is an awesome piece of work! I can't even begin to imagine the amount of research and work that must have gone into this.

Respect :)

Per

Extremely impressive, John. That's a piece of work that is going to be extremely useful for design, with a side bonus of providing excellent summaries for people considering buying any of the games you describe. You're on a very good path with it.

Here's some small criticism, though:

- The only really significant problem I had with your text was that it constantly changes in style, from analytic to friendly chat to occasional moments of pedagogic condescension. If you have the time and the energy, tone the language a bit towards a more uniform structure (I'd personally prefer increasing the friendly how-to -guide style over the academic tone). Also give some consideration to how you reference the works of people you highly respect; a courteous "credit where credit is due" is better than the nearly fawning tone you occasionally use in those cases. (Not often, but still enough many times that it creates an illusion of not being completely objective, which you actually IMO are.)
- A bit more emphasis on the fact that you're dealing with just tabletop rpg would be nice. You mention it briefly on p. 4, but I think a separate disclaimer paragraph very early on would be good.
- A bibliography on non-game resources at the end would be welcome, and explain the background further. If you add one, consider also moving the ludography from page 4 to the end, but preserving it as a separate list.
- Some reference to Wraith: the Oblivion's Shadow system might be a good addition to the Conflicted Gauge segment.
- Add something to either Endgame, Structured Story, or both on how some games basically deal with just one story concept played over and over while others are broader - or just pretend that they are.
- One reward system that's missing is that some games give bonuses for expressing a character or the game's genre logic. It can be seen as a part of Narrative Reward, yes, but given the excellent precision you use in differentiating things like health/damage systems, this distinction might also be worth making.

All in all, a very good book, and something that I know I'll often be referencing in the future.

-Jiituomas

J. wrote:
which you actually IMO are

Wow! Just wow! Great stuff, John. I'll try and get you some more meaningful feedback when I get time to read and digest.

New daily commute reading. Thanks!

Hi,

Though I've only skimmed and read bits and parts, this is an incredible document.  I suspect that this will find influence outside of the Forge in a BIG way, due to it's accessibility and focus on the mechanics.  Even at this stage, this document is the sort of analysis that few people have applied to any game, even one they're designing (sadly), much less across several.

I'll drop more feedback as I read deeper.

Chris

I just read the introduction and took a brief look at the contents. It looks awesome!

I was wondering if you regard Ritual as a design pattern (Polaris comes to mind). If yes, and since this is still a draft, please consider talking about it, I'd be very interested in a discussion about that.

All the best for your project!

I second everything that's been said.  This looks awesome.

As for Polaris, I was going to bring that up for structured or ritualized drama resolution.  I think it's unique at this point, so it's not a pattern yet, but keep an eye out for more games that learn from it in the future.

What an opus! I don't have anything intelligent to say yet, only that I'm enthusiastic.

Hello.

It really is impressive.  I started to skim read and then got sucked in to properly reading sections.  I'm going to have to try and get it printed out as I find it difficult to read on screen for such an amount of material!

I love the fact that you've gone for a kind of descriptive analysis of what the games actually do, it's really helpful to some one like me who's only just starting to think deeply about rules and mechanics.

wow.

Drew

I appreciate all of the positive responses.  Thank you all!  I must say that I wasn't expecting so much enthusiasm so quickly, but am gratified nonetheless.

J. wrote:
- The only really significant problem I had with your text was that it constantly changes in style, from analytic to friendly chat to occasional moments of pedagogic condescension. If you have the time and the energy, tone the language a bit towards a more uniform structure (I'd personally prefer increasing the friendly how-to -guide style over the academic tone). Also give some consideration to how you reference the works of people you highly respect; a courteous "credit where credit is due" is better than the nearly fawning tone you occasionally use in those cases. (Not often, but still enough many times that it creates an illusion of not being completely objective, which you actually IMO are.)
- A bit more emphasis on the fact that you're dealing with just tabletop rpg would be nice. You mention it briefly on p. 4, but I think a separate disclaimer paragraph very early on would be good.
- A bibliography on non-game resources at the end would be welcome, and explain the background further. If you add one, consider also moving the ludography from page 4 to the end, but preserving it as a separate list.
- Some reference to Wraith: the Oblivion's Shadow system might be a good addition to the Conflicted Gauge segment.
- Add something to either Endgame, Structured Story, or both on how some games basically deal with just one story concept played over and over while others are broader - or just pretend that they are.
- One reward system that's missing is that some games give bonuses for expressing a character or the game's genre logic. It can be seen as a part of Narrative Reward, yes, but given the excellent precision you use in differentiating things like health/damage systems, this distinction might also be worth making.

Artanis wrote:
I was wondering if you regard Ritual as a design pattern (Polaris comes to mind).

John wrote:
I

Artanis wrote:
I was wondering if you regard Ritual as a design pattern (Polaris comes to mind).

This actually brings up a very important point concerning Design Patterns in general.  The term "Ritual" as used here on the Forge seems rather fuzzy to me.  That's not a bad thing, it merely indicates that "Ritual" is an abstract concept.  Design Patterns, on the other hand, are concrete methods to represent or support abstract concepts.  For example, a character's "good looks" and "sociability" are abstract concepts.  But, in role-playing games they are often represented concretely via a "Charisma" gauge.  My feeling is that a number of different design patterns may eventually appear to support or encourage "Ritual", but it is not itself a design pattern.  Sorrowfully, I haven't read Polaris yet.  But, perhaps it does contain the first use of a form of drama resolution that will eventually be recognized as a design pattern.

Blankshield wrote:
John, take a look at Meguey's excellent post about ritual here.  It may give some strong insight into how ritual pattern may tie into design.

Meguey wrote:
Ritual has a definite pattern, and if a part of the pattern is missing, the ritual will feel hollow, incomplete, or simply not work. It's an X or hourglass shape, and it flows like this.

John wrote:
We should also be aware that a game may try to satisfy the design goal of creating intensity in some fashion entirely unrelated to Ritual.

First of all, great work. I mean it!

As for feedback, here goes. Make what you will of it.

1. Why not, for each game, get some feedback from the actual fans on the question "Why does the game work for you?" You could post "Why does Rifts work for you?" on a Rift forum, "Why does CoC work?" on the CoC forum. ron thge responses you can than select the most telling ones.

The reason I suggest this is that, while I perfectly understand you not wanting to make subjective value judgements on specific games, the analysis of each game seems to lack a bit of punch, some sort of final verdict. So the reader just sees the theory but does not get any feel for how this works in practice.

2. This may seem a strange thing to say, given the context, but I thought it was a bit odd that there were so many "Forge" games in the list in the draft. Oaky, in a way I can understand this choice. There is so much more innovation real design work going on in the new indie game world compared to the often very conservative, even derivative, world of mainstream rpgs (not much point looking in detail at 30 different D&D clones), but it just feels a bit partisan, not very representative. Maybe you can add a few more mainstream games to your anaylsis. Games like Amber, Castle Falkenstien, Over the Edge and Feng Shui all had some pretty unique design ideas to disucss. And no, I am not just plugging "my personal favorites" (Amber is the only one of those I've played extensively, and that was a long time ago).

3. I do echo the previous remark that the tone swaps from technical to informal far too often.

gsoylent wrote:
The reason I suggest this is that, while I perfectly understand you not wanting to make subjective value judgements on specific games, the analysis of each game seems to lack a bit of punch, some sort of final verdict. So the reader just sees the theory but does not get any feel for how this works in practice.

OK, I've read up to about page 70, and flicked through the descriptions of games (paying close attention, obviously, to Great Ork Gods). And I've a few comments on what I've read so far:

1. To echo J. Tuomas, the tone does oscilate seemingly randomly from dryly academic to jovial and chatty. This isn't entirely a bad thing - the Gang of Four's Design Pattern book is one of the most turgid and unreadable books I've come accross, whereas your work is eminently readable. While it's important you don't lose the technical manual feel of it, it's also important that it remains readable.

2. I found some of the comments overly subjective and judgemental, in places stating that a different approach would be better rather than simply enumerated strengths and weaknesses. I think you should avoid this kind of comment in the Pattern descriptions.

3. You don't seem to me to have met your own criteria for identifying patterns. In particular you don't seem to have stuck to only having positive design features. Also, a few of the patterns seem out of place (Anonymous rule comes under both these objections).

But these are really just picking the nits, great work.

gsoylent wrote:
1. Why not, for each game, get some feedback from the actual fans on the question "Why does the game work for you?" You could post "Why does Rifts work for you?" on a Rift forum, "Why does CoC work?" on the CoC forum. ron thge responses you can than select the most telling ones.

The reason I suggest this is that, while I perfectly understand you not wanting to make subjective value judgements on specific games, the analysis of each game seems to lack a bit of punch, some sort of final verdict. So the reader just sees the theory but does not get any feel for how this works in practice.

2. This may seem a strange thing to say, given the context, but I thought it was a bit odd that there were so many "Forge" games in the list in the draft. Oaky, in a way I can understand this choice. There is so much more innovation real design work going on in the new indie game world compared to the often very conservative, even derivative, world of mainstream rpgs (not much point looking in detail at 30 different D&D clones), but it just feels a bit partisan, not very representative. Maybe you can add a few more mainstream games to your anaylsis. Games like Amber, Castle Falkenstien, Over the Edge and Feng Shui all had some pretty unique design ideas to disucss. And no, I am not just plugging "my personal favorites" (Amber is the only one of those I've played extensively, and that was a long time ago).

3. I do echo the previous remark that the tone swaps from technical to informal far too often.

Jack wrote:
2. I found some of the comments overly subjective and judgemental, in places stating that a different approach would be better rather than simply enumerated strengths and weaknesses. I think you should avoid this kind of comment in the Pattern descriptions.

3. You don't seem to me to have met your own criteria for identifying patterns. In particular you don't seem to have stuck to only having positive design features. Also, a few of the patterns seem out of place (Anonymous rule comes under both these objections).

This is a remarkable document. It goes beyond cataloging and really gets at the heart and soul of the patterns. I am impressed with your insight into the implementation challenges each pattern presents.

I won't repeat what others have said but I agree with most of their comments.

In addition, I think the book would benefit from a cross-index for pattern aliases. I went looking to find "conflict resolution" and it took me a while to discover it as an "also known as" for one of the types of contests.

The gauge diagrams remind me much of systems thinking models. I like your diagramming conventions but find it a little hard to know at a glance what is an add relationship and what is a subtract relationship. Check out the web site (especially Gene's introduction) and consider using some of his diagramming conventions. At the least, consider those ideas about reinforcing loops and balancing loops and what they mean to game design.

Again, an amazing feat of analysis and writing. Its use will be a part of my game design process for years to come.

Bravo!

This is exactly the sort of bottom-up approach that's been lacking. I think this sort of analysis is what will produce real, fruitful RPG theory with potentially predictive results.

Good job!

-Marco

It's interesting to me that the Gang of Four weren't interested in analyzing why projects fail, because damn if that isn't what I'm most interested in seeing now, some comparison between successful and unsuccessful games with similar macro-level architectures of patterns. (For instance, I'd love to see the architecture of The Last Exodus compared to a "successful" game with a similar architecture.)

John, or someone, can you convince me why I shouldn't care?

Paul

The only thing that I really noted that was missing form this was different dice mechanics.
In the appendix you mention the die pools, margins of success, and similar so the book is not completely lacking in such but I can see reason for more detail either in this book or another to give a run down on dice mechanics.

Aside from that small complaint this is a wonderful resource here and a very interesting read (I finished the day you posted it myself.).

The review of the game systems at the end is really helpful for people who have not played those games before and have been told to check them out.

Adam wrote:
The gauge diagrams remind me much of systems thinking models. I like your diagramming conventions but find it a little hard to know at a glance what is an add relationship and what is a subtract relationship. Check out the web site (especially Gene's introduction) and consider using some of his diagramming conventions. At the least, consider those ideas about reinforcing loops and balancing loops and what they mean to game design.

Paul wrote:
It's interesting to me that the Gang of Four weren't interested in analyzing why projects fail, because damn if that isn't what I'm most interested in seeing now, some comparison between successful and unsuccessful games with similar macro-level architectures of patterns. (For instance, I'd love to see the architecture of The Last Exodus compared to a "successful" game with a similar architecture.)

John, or someone, can you convince me why I shouldn't care?

John wrote:
tj333, 

Yes, I need to cover dice mechanics.  Unfortunately, the muse of dice mechanics writing has not yet landed on my keyboard.  I'll probably get around to it eventually.  I just haven't thought of much interesting to say about the topic yet.

John Kim did a very food overview of a whole range of dice methods used in rpgs. Have a look at http://www.darkshire.net/%7Ejhkim/rpg/systemdesign/dice-motive.html

Three comments: 

(1) I have been making my way through "Design Patterns" and think it's a great piece of work.  I've begun to try to map out the design on my own current project; I already recognize some "anonymous rules" that deserve splitting out.  So it's at the very minimum a useful heuristic device.  Thanks, John.

(2) Another emergent pattern to keep your eye on could be called the "Tarot" pattern.  This is where a card-draw gauge informs a fuzzy gauge of some kind.  In plain English, a card is drawn and its "meaning" (perhaps with an intervening table look-up) is used to shape the in-game situation in some way.  Recent implementations include Chris Lehrich's Shadows in the Fog and Jason Morningstar's Shab-al-Hiri Roach.  In the former, interpretation of Tarot cards by the players maps on to magical events or mystical confluences in the game-world.  In the latter, the card a player draws is read to determine the sort of action his or her character will take (and the card is read differently depending on whether or not the character is possessed by the game's eponymous insect).  AD&D's Deck of Many Things may be the earliest implementation of this pattern.  The DM would present players with a deck cards from which they could choose to draw up to three cards; the various cards caused different circumstances to occur in-game (e.g., lose all of your treasure, inherit a small keep, have a trusted henchman turn against you, etc.).  Like the "Ritual" pattern discussed above, we may see more of this sort of thing in the future.

(3) Minor typo fix:  Call Mike Holmes's prefatory remarks a "Foreword."

Bill

I'm reading through this now. One of the only things I haven't liked is when your editorial tone -- "this is a stupid idea", in effect -- comes through.  Rather than examining the pluses and minuses of certain ways of doing things, there are several sections which just seem outright dismissive.  Perhaps because Alignment came first in alphabetical order this stands out more.

The other thing that was a bit of an annoyance was an over-reliance on referencing pretty obscure games, most of which are from Forge contributors. It seems to limit the discussion a lot when half of the games are relative unknowns, and almost seems like you're mentioning/praising them to either advertise them or curry favor.

tj333,

I appreciate the enthusiasm.  You actually do not need to ask my permission since I have already given it via the Creative Commons License under which I released the book.  Since a lengthy explanation of what is allowable and what is not does not directly relate to the topic of this thread, I split those issues out into another thread here.

By the way, do you have a name?  It is somewhat disconcerting to speak to a couple of initials and a number, although my employer has the opposite opinion.

Bill_White wrote:
Three comments:

(1) I have been making my way through "Design Patterns" and think it's a great piece of work. I've begun to try to map out the design on my own current project; I already recognize some "anonymous rules" that deserve splitting out. So it's at the very minimum a useful heuristic device. Thanks, John.

(2) Another emergent pattern to keep your eye on could be called the "Tarot" pattern. This is where a card-draw gauge informs a fuzzy gauge of some kind. In plain English, a card is drawn and its "meaning" (perhaps with an intervening table look-up) is used to shape the in-game situation in some way. Recent implementations include Chris Lehrich's Shadows in the Fog and Jason Morningstar's Shab-al-Hiri Roach. In the former, interpretation of Tarot cards by the players maps on to magical events or mystical confluences in the game-world. In the latter, the card a player draws is read to determine the sort of action his or her character will take (and the card is read differently depending on whether or not the character is possessed by the game's eponymous insect). AD&D's Deck of Many Things may be the earliest implementation of this pattern. The DM would present players with a deck cards from which they could choose to draw up to three cards; the various cards caused different circumstances to occur in-game (e.g., lose all of your treasure, inherit a small keep, have a trusted henchman turn against you, etc.). Like the "Ritual" pattern discussed above, we may see more of this sort of thing in the future.

(3) Minor typo fix: Call Mike Holmes's prefatory remarks a "Foreword."

Bill

Kynn wrote:
I'm reading through this now. One of the only things I haven't liked is when your editorial tone -- "this is a stupid idea", in effect -- comes through. Rather than examining the pluses and minuses of certain ways of doing things, there are several sections which just seem outright dismissive. Perhaps because Alignment came first in alphabetical order this stands out more.

Kynn wrote:
The other thing that was a bit of an annoyance was an over-reliance on referencing pretty obscure games, most of which are from Forge contributors. It seems to limit the discussion a lot when half of the games are relative unknowns, and almost seems like you're mentioning/praising them to either advertise them or curry favor.

John wrote:
tj333,

By the way, do you have a name?  It is somewhat disconcerting to speak to a couple of initials and a number, although my employer has the opposite opinion.

I would just like to say that I, too, thoroughly enjoyed looking through your book.  I haven't read it all yet, but it definitely seems interesting.

Also, I want to echo the desire to see some explanation of dice mechanics, and/or of fortune mechanics in general.  Though that might be a large enough topic for an entire sequel!

Hmm, I haven't read this book yet, but at a quick browse I concluded that the approach is quite similar to Game Design Patterns approach advocated by Staffan Björk and Jussi Holopainen. Their main collection of game design patterns has been published recently as a book, containing some 300 or 500 patterns -- including such as "role-playing" and "character". (There are also some conference publications on their website).

Oh dear, I wonder when I get the time to read 260 more pages. :-)

- Markus

John,
I've finally had a change to look at your book this weekend. Wow. That's an impressive achievement.

My one nit at this point is one that's been pointed out before, namely the change of voice. I don't actually think the voice changes themselves represent a serious problem, the high overall quality of your writing ensures that, but in many places they are symptomatic of a change from objective description to subjective opinion. Since, as you argue eloquently in the introduction, a pattern is neither good nor bad without context, it follows that either your opinion as stated is not valid, or the thing described is not actually a pattern.

So I would recommend going over these places and adding context to your opinion (i.e. from "pattern X is foo" to "pattern X is foo when either Y or Z"). You'll probably find that tones down the informality automatically, so you'll be killing two birds with one stone. If it turns out that, actually, pattern X is always foo, then you've got anti-pattern on your hands.

SR
--

John, if you are interested in the Tarot pattern, you might want to check Engel by Feder&Schwert. The game is published with two sets of rules: D20 and the Arcana System.

In the latter the only gauges are the fuzzy ones created by a set of cards and the equally fuzzy effects of the characters' supernatural gifts.

The game was translated by White Wolf.

((Why can't I edit my posts?))

I've just started to dip into this, excellent work. One thought on adding additional games that demonstrate the patterns you've already identified:

While I understand your desire to get the most patterns for the least number of games described, I think it is worthwhile including more mainstream games, and also very well known examples of particular patterns. People will be better able to relate to the ideas the more of the games they are familiar with.

Identifying first occurence of each pattern would be interesting, but I agree it's value might not be high. It might be interesting though to see how the patterns developed, and maybe there's something to extract there. Perhaps such a study would make a nice paper for someone to write.

Frank

Montola wrote:
Hmm, I haven't read this book yet, but at a quick browse I concluded that the approach is quite similar to Game Design Patterns approach advocated by Staffan Björk and Jussi Holopainen. Their main collection of game design patterns has been published recently as a book, containing some 300 or 500 patterns -- including such as "role-playing" and "character".

Stefan wrote:
John, if you are interested in the Tarot pattern, you might want to check Engel by Feder&Schwert. The game is published with two sets of rules: D20 and the Arcana System.

In the latter the only gauges are the fuzzy ones created by a set of cards and the equally fuzzy effects of the characters' supernatural gifts.

ffilz wrote:
One thought on adding additional games that demonstrate the patterns you've already identified:

While I understand your desire to get the most patterns for the least number of games described, I think it is worthwhile including more mainstream games, and also very well known examples of particular patterns. People will be better able to relate to the ideas the more of the games they are familiar with.

John wrote:
Is this a drama-based resolution system then?

John,

First off, extraordinary. It's a real contribution to the hobby (dare I say "the art"?) that someone has attempted for techniques (as you put it, the engineering) what Ron Edwards & co. have attempted for the theory: systematically look through what's out there, identify patterns, and suggest a common framework and terminology.

Second, I want to suggest more work for you to do. (Of course). From my still-partial reading of the book, your patterns are overwhelmingly concerned with (a) how characters are built, i.e. "chargen" and (b) how characters interact with the game-world, i.e. "task resolution"/"conflict resolution" -- which is of course what the vast majority of games spend the vast majority of their rules discussing. But I would argue that the pattern you identify as "Structured Story" (e.g. My Life with Master) actually belongs to another and poorly-understand category of patterns altogether, a category of which it is not the sole examplar: These are Patterns about how the game-world is set up, not just in terms of general "setting" but in terms of the specific environment that the player-characters must then interact with in play -- what we might call (c) "scenario design" or (to use the Forge term) "Situation design."

Now, most games are frankly very weak on structured, patterned scenario/situation design. They include what amounts to general advice ("rising action precedes the climax" or "don't kill the party in the second room") as opposed to specific, concrete procedure for constructing Situation. Vincent Baker's Dogs in the Vineyard is one of the few examples: Look at the "Town Creation" and "NPC creation" section and note how clearly defined the steps are, how constrained the GM's resources are, how focused the whole procedure is on a particular end result, and then compare with the vague "GM advice" in most RPGs. This isn't quite "Structured Story" -- the sequence of in-play events is not structured, but rather a sequence of pre-play decisions -- but it is clearly akin.

Are there other examples of situation/scenario design Patterns?
- I would suspect that much-maligned Dungeons & Dragons, with its linkage of player-character level to dungeon level to monster level in early editions, and the whole "challenge rating" system in later editions, is one of the few games besides Baker's to attempt comparably clear procedures for scenario design.
- There was an interesting discussion of how to create formal rules for how general setting translates into specific situations on Vincent Baker's website www.lumpley.com, which I link to and summarize in this Forge discussion which I shamelessly threadjacked. But this "rules of derivation" mechanic hasn't been identified in any published game I know of.

Now, you're familiar with far more games than I, so you may be able to come up with more examples of this family of Patterns if you consciously look for them. In practice, since so few games actually do this, I suspect it'd be fairly easy to add another Pattern or two to the list and amend the existing entries (e.g. for Dogs) to show their specific implementations. Obviously, this is, as I said, me saying "Good job! Do more!" but I think it would add an important additional layer to what's already a great contribution.

Just wanted to say "yay!". And "fsck, now I have even more stuff to read". Amazing work, John!

@Sydney:

Just off the top of my head, here are two more examples of games with situation-structure:

My Life with Master is chock-full of them: The Horror Revealed, Overture scenes on errands for the master, Endgame and probably more.

Polaris has them as well, with the Zeal gauge gently going into Weariness. A knight can only die after having reached enough Weariness. This can also give rise to a confrontation with the knight of Polaris.

Ah, yes, how could I have forgotten Polaris -- John, I'm afraid that's required reading on several fronts now.

But to proceed to quibble with you, Christoph: I think a mechanically predetermined story arc during play, a la Polaris or My Life with Master, is a subtly but significantly different thing from a mechanical procedure to generate backstory prior to play, a la Dogs in the Vineyard.

Note that Dogs play does have a loosely predetermined story arc of "arrive, investigate, understand, and judge," but that's a separate thing from the Town Creation rules.

Note also, now that I think of it, that My Life with Master may exemplify both these Patterns, which may help me explain the elusive difference:

1) Structured Situation: The rules for Master specifically instruct the players to brainstorm together to come up with the Master, without the sequential steps of Dogs but with specified issues to consider, e.g. Brain/Beast, Feeder/Collector/Breeder/Teacher, The Others, Need, and Want. The game also specifies the Master's relationship to the Village and mechanically embodies it in the Fear and Reason scores, which again are set pre-game.

2) Structured Story: Once Master play begins, the fact that Self-Loathing and Weariness values can only go up, while Love goes both up and down, and the rules for scene-framing keyed to those values (including the Master's commands, Overtures to beloved Connections, Horror Revealed, and Endgame), all combine to produce a back-and-forth between Master and Minions over the fate of the village generally and their loved ones specifically until the Minions rebel, and the master dies.

Sydney wrote:
From my still-partial reading of the book, your patterns are overwhelmingly concerned with (a) how characters are built, i.e. "chargen" and (b) how characters interact with the game-world, i.e. "task resolution"/"conflict resolution" -- which is of course what the vast majority of games spend the vast majority of their rules discussing. But I would argue that the pattern you identify as "Structured Story" (e.g. My Life with Master) actually belongs to another and poorly-understand category of patterns altogether, a category of which it is not the sole examplar: These are Patterns about how the game-world is set up, not just in terms of general "setting" but in terms of the specific environment that the player-characters must then interact with in play -- what we might call (c) "scenario design" or (to use the Forge term) "Situation design."

Sydney wrote:
Ah, yes, how could I have forgotten Polaris -- John, I'm afraid that's required reading on several fronts now.

You can get a pdf of Falkenstein at DriveThru:
http://tinyurl.com/cblgz

Engel, too:
http://tinyurl.com/bve6g

Does the scene requesting/framing element of play in Primetime Adventures qualify as a design pattern?
Does PTA also fit both the Structured Story/Situation Design along with My Life With Master?

John, I'm glad to be of use to you in such an important project. And, yes, yes, this "family" of Patterns might indeed be where Ritual fits in.

In response to Darren:

PTA's emphasis on collective brainstorming of characters, setting, etc. does seem like a very loose form of Structured Scenario. Perhaps the loosest form of this Pattern would be a rule that explicitly tells the players (and GM) "everyone sit down and think about these [#] things: [1], [2], [3]...." as in PTA; then My Life with Master and Dogs in the Vineyard would represent tighter and more structured manifestations of the same thing. But perhaps the degree of structure is simply too different in these cases? Perhaps PTA-style "Brainstorming" is a different (albeit related) Pattern altogether, just as Traits are a different Pattern from Skills?

Also, PTA's Issues/Story Arc mechanic does seem like a kind of Structured Story to me, albeit a very flexible one.

As for PTA's scene-framing rules -- hmm; that seems different from either Structured Story or structured scenario/backstory/situation/whatever. Perhaps having explicit rules for scene-framing is a Pattern unto itself? Of course, all games (that I know of) require some kind of scene-setting and scene-framing, but I've only seen explicit guidance and rules in the Forge games.

Engel, too:
http://tinyurl.com/bve6g

That's OGL Engel, right? So, basically d20 structurally? I think what John needs is the Arcana rules, which were not included in the translated English edition. Feder&Schwert did release a translation of the Arcana rules as a free pdf, but I'm not having any luck finding it on their website.

Paul

About OGL Engel: Oops - I didn't notice that.

I was able to obtain Castle Falkenstein.  Thanks.  I also ordered Prime Time Adventures.  I'd like to keep this thread from drifting into a linkfest, though.  So, please PM me with any further links to either Amber or the Arcana version of Engel.

In fact, I believe that the purpose of this thread has been very well served.  The excellent feedback I've gotten will keep me very busy for a long while.  Thank you all.

If someone has something more to say about RPG Design Patterns in general, I'd be happy to respond.  But I think any further discussion about Ritual, Structured Scenarios, or other specific design patterns should be split off into other threads.  If someone has the inspiration to do so, I'll jump into the discussion.

Thanks again!

its kinda hard to navigate to use practically, like as a tool kit for games design. It would helpful if you could supply some kind of categories for these patterns, meaning the problems that these solutions solve.

So, I'm Joe Designer and I want mechanics to help regulate what choices my players make (to put them more in line with the genre of the game or their character's described personalities or just to take the damn game seriously), so I look at:
"Behaviour: Alignment, Attendance Reward, Idiom, Narrative Reward, Structured Story"
and go look up those individual patterns and see what suits.
Later on I get so miffed at my players bad behaviour i research:
"Damage: Hit Points, Trauma Guage, Wound Trait"

I dunno how easy that would be to implement but it sure would be useful, especially as the list of patterns gets bigger and more wide-ranging.

Absolutely fascinating: I am reading through the patterms, and thinking about Conlicted Guage Surely the 12 binary oppositions which form Personality Traits in the rpg system Pendragon (1985) by Greg Stafford are fine examples of this?  It's interesting how often Pendragon's many unique (for the time) design patterms like modelling Relationships as well as other attributes are over looked.

I shall comment on the whole book once I have completed reading it, but enjoyibng what I have seen so far.

cj x

Montola wrote:
Hmm, I haven't read this book yet, but at a quick browse I concluded that the approach is quite similar to Game Design Patterns approach advocated by Staffan Björk and Jussi Holopainen. Their main collection of game design patterns has been published recently as a book, containing some 300 or 500 patterns -- including such as "role-playing" and "character".

John wrote: I read the book a couple of months ago.  You can imagine my nervous anticipation as I waited for Amazon to ship it to me.  Yes, the approaches are similar but attack the problem from different angles.  Their book mainly focuses on computer games, although some of it is applicable to tabletop RPG's and other games as well.  I counted 166 patterns, actually.  My book focuses on tabletop RPGs, although some of it is applicable to computer RPG's as well.  I'm trying to keep the number of patterns down to less than 50.  The primary difference, though, is that most of their patterns are more abstract than mine.  (As you say, "roleplaying" is a pattern in their book.)  Perhaps because of their more abstract thrust, they omit the "Samples" section that I feel is vital to convey how a pattern is used in practice.  And, it's probably why the book contains no diagrams.  Even so, I'm sure it is quite useful in computer game design and promises to give game programmers a well-defined terminology.

Great Work! I stumbled across your book yesterday and I had to download it at once!

I have just read 20 or so pages, but I keeps me so enthralled I don't want to work right now (although I should!).

I am designing an rpg-system by myself (sorry, only in german so far) and I will reconsider my set of rules by reading this book.

I am a student of computer science (with focus on software engineering), so the idea to transfer knowledge from software engineering to rpg-engineering was a thought I had before, too. But I focused more on software-engineering-like project management (because my system consists of a core rule book and projects which enhance the core rules). I highly appreciate your work and I will try to contribute when I read your book. ^__^

I found a copy of the enflish arcana rules here:

http://www.birdsgate.de/federgalerie/Extras/ArkanaRulesUS.zip

Regards,
    Harald

oreso wrote:
its kinda hard to navigate to use practically, like as a tool kit for games design. It would helpful if you could supply some kind of categories for these patterns, meaning the problems that these solutions solve.

So, I'm Joe Designer and I want mechanics to help regulate what choices my players make (to put them more in line with the genre of the game or their character's described personalities or just to take the damn game seriously), so I look at:
"Behaviour: Alignment, Attendance Reward, Idiom, Narrative Reward, Structured Story"
and go look up those individual patterns and see what suits.
Later on I get so miffed at my players bad behaviour i research:
"Damage: Hit Points, Trauma Guage, Wound Trait"

I dunno how easy that would be to implement but it sure would be useful, especially as the list of patterns gets bigger and more wide-ranging.

oliof wrote:
I found a copy of the enflish arcana rules here:

http://www.birdsgate.de/federgalerie/Extras/ArkanaRulesUS.zip

John wrote:
Does anyone have suggestions for a small set of categories that covers the entire breadth of patterns which helps convey their utility?

John,

I'd certainly find categories useful in reading and referencing the book, with patterns alphabetized within each category.  I haven't finished reading the text yet, but Sydney's categories seem to cover what I've seen so far.  If you combine this with an index, you'd pretty much cover all your bases.

As a side note, the "Setting/Scenario/Situation Generation" idea, pattern-wise, is an interesting idea; it seems to me that it's really only in the indie-game world that that aspect of games has become hard-wired into the rules themselves.  I gotta hurry up and finish reading...

btw, as many have said elswhere in this thread, thanks so much for this book!  I'm a big fan of Christopher Alexander, and have wondered if his ideas could be applied to gaming somehow (though I was always thinking of System...)  You've certainly shown that they can!

Aaron

The pdf was definately interesting.  I've made a few collections of rules ideas in the past but never really formalized them.  It would be great if game designers could go to a page or pull up a document and have a layout of common questions and solutions.  This file definately puts us a lot closer to that.

As far as categories go, you may want to start with something for general components.  For example, gauges, traits, and skills are pretty general items that can be used in character creation as well as conflict resolution.

Alternately, you can simply choose one scheme, whether alphabetic or categorical, and povided lists elsewhere to support other schemes.  I agree a list on common topics with names of applicable elements would be useful.  That way you can more quickly consider the options that relate to what your working on.  The experimental types could also use this to avoid common patterns and come up with something a bit different.

Donjon has an interesting story structure.  All adventurers start in "town" (an area of safety).  From there the party enters the "dungeon" (adventure areas).  The party is free to roam around this area and do pretty much what ever they want.  However, they won't pass into the next area until they finish all the checkpoints in the area.  These checkpoints are events and areas that  the gm can introduce at any time.  I'll have to check and see if this structure has been broken down in the patterns document, but it is part of the game rules.

Btw, thanks for the welcome in the alignment thread, John.  I forgot to thank you on my last reply there as I got so focused on breaking down alignment.

Not to make more work for you, but a taxonomical structuring might be more practical in many ways. You would have to devise the taxonomy, of course, but doing so might make the book more useful.

By this I mean something like "These things are all A's. An A is defined thus. The AA is an A distinguished by A; the AB is also an A, but different from the AA thus."

It would also give clearer definitions of the various elements, although it would require you to make some arguable choices--e.g., what you think is an A influenced by B someone else would label a B influenced by A--but if you think it through you should be able to devise a workable taxonomy.

This is very theoretical on my part, I must say.  I've downloaded the file and two of the proposed revisions, but as yet have not had time to unzip it.

--M. J. Young

Kesher wrote:
the "Setting/Scenario/Situation Generation" idea, pattern-wise, is an interesting idea; it seems to me that it's really only in the indie-game world that that aspect of games has become hard-wired into the rules themselves.

Shimeran wrote:
Donjon has an interesting story structure.  All adventurers start in "town" (an area of safety).  From there the party enters the "dungeon" (adventure areas).  The party is free to roam around this area and do pretty much what ever they want.

Yes, Donjon does produce dungeon crawl stories, but that is what it's designed to do.  Perhaps stroy structure is the wrong term.  Let me try again.

Most games provide rules for conflict resolution and character creation.  However, to provide little more than guidelines when it comes to setting up a given session.  What's interesting is that Donjon formalizes a fairly standard set-up by breaking it up into definate chunks.  Granted, the game flow may be similiar, but it's worth noting the difference between a formal and informal session structure for a given game.  Informal structure are more open ended, while formal ones tend to have a stronger focus.

I also found the checkpoint system interesting.  In many games with pregenerated content, events are in fixed locations.  Instead of trying to bring the players to the key locations, Donjon places them in front of where the players happen to be going.

Anyway, it does seem that most game rules focus on resolving actions or handling character creation and developement.  A few  more examples of games that provide rules for session and story handling would be good.

What about meta-game awards?  Plenty of games will give points for showing up, doing something entertaining, ect..  The idea is that the character is awarded for something with no game world context. (xp awards for amusement -> "Wow, I really made a fool of  myself back there, but now I can play the piano.")  I'm not so much saying they're a bad thing as wondering how they fit into this design pattern scheme.

This is an exceptional book -- with polish, I genuinely think it may be the most important single work on RPG design ever.  Kudos!

A few comments:

1. As others have said, the authorial tone wavers inexplicably and gets in the way.  This is particularly annoying when it combines with your fairly overt biases: you dislike Alignment systems, for example.  (Note: I said bias rather than prejudice because you have clearly made a decision on a solid, analytical basis.  Nevertheless your handling of Alignment is one example of a point at which the voice breaks down.)

2. I would like to see a table (appendix 2?) of quick-and-dirty versions of the Patterns.  If you want the book to be especially useful for designers, lay it out horizontally (landscape, or whatever) and leave a big blank on one side for notes by the user.  Be sure to include a page reference to each Pattern in the table.  I think this would help the careful reader to use and reuse the book until it's falling apart and covered with notes, which is surely what you want.

3. As a conclusion chapter, let me suggest that you sketch an outline of how one might use the book to make design decisions.  Keep it short, keep it simple, and so forth, but give us some idea of how you think an RPG-engineer might sit down and approach design problems.  Those of us who aren't engineers will bless you.

Love it!