In my recent call for playtesters, Paul Czege asked me how I went about designing Gnostigmata:

Paul wrote:
Hey John,

I started writing the game as an appendix for my RPG Design Patterns book. The intent was simply to provide an example of how RPG Design Patterns can be used in game design.

I have a question. How did your design patterns work play into the designing of Gnostigmata? Were the design patterns more like building blocks that you fused together to achieve your design goals? Or did you mostly conceptualize the way you wanted the game to work and then analyze it post-facto and use the design patterns to validate and improve the mechanical structure?

Can you maybe take me through the process you used, with reference to a mechanic from the game?

I figured I should split this out into its own separate thread, since the answer is rather lengthy and has nothing to do with getting playtesters.

In short: yes to both questions.  I used design patterns to build an initial design, and then after some playtesting, I used different ones to fix the problems that I perceived (those fixes have yet to be playtested).  Design Patterns help link goals to design, but game design is still an iterative process with or without them.

I'll give you two design decision examples.  But first, you have to know my design goals or you won't understand their context:

1) I wanted to model the Gnostic world-view in a game.
2) I wanted the game to be a real game that people would find entertaining.
3) I wanted a small but complete game that would fit in an appendix.
4) I wanted Gnostigmata to be as different as possible from Legendary Quest.

(There were some other goals, but they aren't germane to the mechanics I describe below.)

The first goal arose because I had just finished re-watching the Matrix series on DVD and it struck me how well the movies fit the Gnostic perspective, which I had just researched for Legendary Quest materials.  I'm sure most people would question the interest level that a Gnostic game would generate.  But, anyone that knows how much of a mythology nut I am wouldn't find it surprising that I would pick such a topic.  You gotta go with what interests you and that's what I did.  At first, I was looking at tabloids to provide source material for the game, so I thought of the game as a mix of "The Matrix" and "X-Files".  I have since dropped the tabloids (due to Paul Czege's suggestion), and I think the game is far better focused as a consequence.

The second goal is fairly obvious for any game.  But, just to be clear, I wanted to treat the example I was putting forth seriously.  There's not much point in providing a lame example.  The game has not yet been playtested in its current form, so the suckage factor of Gnostigmata is still in question.  The use of design patterns does not guarantee you'll end up with a good game.

I didn't actually accomplish the third goal, I know.  40 pages is a tad too long for an appendix.  But, give me a break.  My other game is 1400 pages long.  And, I'm still whittling Gnostigmata down.  It's still possible I'll be able to boil it down to a more manageable size.  Even if I can't, I think it's more important to develop a complete game than a short one.

The fourth goal was simply to allow me to exercise my design muscles in ways that I had never done before.  I believe this goal was met admirably since the exercise has helped me tremendously in understanding Design Patterns.

The Three Conflicting Attributes of Gnosis, Delusion, and Fate
Okay, to start, I had the vision that I wanted to model the Gnostic world-view.  The core idea I had at first was that I needed a Delusion attribute and a Gnosis attribute that conflicted with one another somehow.  But, it didn't take me long to decide that having just two attributes conflicting with each other wasn't quite enough to make an interesting game.  I also had a vague idea that I'd like the game to have no Game Master (to help satisfy goal #4), but didn't really have a firm grasp on how to do that[sup]1[/sup].  In any case, I figured adding another attribute into the mix that allowed a player to influence the game-world independent of his character would be a good start.  I called it "Fate".  I then drew arrows between these three attributes in a circle to show the "direction" in which they conflicted, although I still didn't know mechanically how they would conflict at that point.  What I had learned in my game studies, though, is that it is the relationships between gauges that give a gauge its meaning.  An individual gauge with no relationship to any other gauge is pointless, regardless of what it is called.

Also, I knew that a small, complete game needed to be "dense".  If you look at many of the more modern games, you will notice that many of the gauges in the games serve multiple purposes.  From a Design Patterns perspective, these gauges are simply implementing basic design patterns, but several different patterns are overlaid on top of one another giving the gauges unique characteristics[sup]2[/sup].  For example, TROS's Spiritual Attributes follow both the Trait and Resource patterns. Sorcerer's Humanity attribute is a Conflicted Attribute, Idiom, and Resource.  Both are examples of very potent game-defining gauges.

So, I quickly decided that the game's reward system would be provided through the three attributes rather than add another gauge to handle this.  Using an attribute in a contest would raise the attribute somehow and the attributes could then be spent on Trait ranks (Traits are really the only way to go for a game intended to be put in an appendix.  Skills and Gifts require a much larger page count.)  Because of goal #4, I decided to use a dice pool for contests (LQ uses a single die).  It didn't take me long, then, to decide that the conflicting attribute would merely set a threshold for the dice in the pool.  That meant that the number range of the attributes had to match the number of sides for some die.  So, each conflicted attribute is a dice pool, a threshold, and a resource.  In order to keep the dice pool size to a manageable level, I chose a d6 for the die.  (In hindsight, this worked out remarkably well.  Maximum attribute values of 6,6,6 ended up being very thematic for the game.)

That pretty much sums up my thought process for those three attributes.

The Contest Tree
The Rosary Beads that keep track of who's winning are a fairly recent addition to the game.  The whole Contest Tree was added specifically to create a sense of rising tension.  This is an effort to fix a problem that I perceived in playtesting the game about a year and a half ago with some friends I saw over Christmas vacation.  At that point, the game was already fairly well developed and was to the point of having no Game Master.  The game worked, insofar as scenes would get framed and conflicts could be resolved.  But, the play just seemed kind of aimless.  People had interesting characters and the scenarios were reasonably good.  But, it kind of had the feel of Indiana Jones, Scully, and Neo milling about at a posh company cocktail party.  Something was definately missing.  I finally figured out that it lacked any kind of tension, despite all the dice that were being rolled.

So, I started looking hard at different games to see how they generate tension.  What I figured out was that many games just rely on a Game Master to generate it through experience and skill.  Traditional games, like D&D and LQ, generate tension through the threat of character death in combat (through what I now call the "Last Man Standing" pattern).  I was beginning to think that a game lacking a Game Master might be doomed to a lackluster existence.  At about that time, I went to an Albuquerque Isotopes baseball game.  As you might expect, the crowd started out calm, barely paying attention to the game.  As time progressed, though, the cheers and howls grew more frequent until, near the end, the crowd was noisy and rivetted to the action.  The game was close and the tension was palpable.  While I was observing this quite ordinary phenomenon, it occurred to me that the baseball game obviously didn't have a Game Master.  So, where was the tension really coming from?  The players were the same as at the start of the game, and yet the mood was completely different.  The same can be said for other sports as well.  What was the connection?  All of a sudden, the idea of a Contest Tree popped into my mind and I knew I had to add one to Gnostigmata.  Of course, I hadn't worked out the particulars at that point (which are fairly irrelevant), but I knew the basic pattern I needed to implement.  I needed to have two (or more) competing sides that were scoring points against each other to win "games", and game wins would accumulate to win an overall "season"[sup]3[/sup].  Replace "inning" with "scene", "game" with "act", and "season" with "climax", and you've got the Gnostigmata Contest Tree.  At this point, I still don't know if the Gnostigmata Contest Tree will satisfy its design goals adequately, since I haven't played it yet, but I'm very hopeful.  (I'm getting together this Friday with some friends to try it out.)

I hope that answers your question adequately, Paul.  If not, let me know what I need to clarify.

Footnotes
1) I hadn't yet written the "Game Master" design pattern.  In fact, designing Gnostigmata actually showed me what that Design Pattern needed to include - with a great deal of help from Mike Holmes.

2) I even toyed with the idea of coming up with a "density" value for various games (# gauges/# relationships between gauges).  I finally decided against it, though.  While a denser game is generally more compact, it is not necessarily a better game and I didn't want to encourage designers to throw in needless relationships just to attain a high density rating.

3) In a baseball game, one team is also doing its best to score "outs".  When they get three, they "win" the right to start accumulating more points.  So, innings are, themselves, mini-games whose outcomes help build tension.