Tuesday, August 29, 2006

When is a Concept Ready to be a Draft?

Heya,

As I get ready to make an official announcement about how I’m going to sell my games, I’ve been wanting to stockpile a lot of different game concepts. Of all the steps in RPG Design, this is BY FAR the easiest. So let me preface this article by saying that having a game concept doesn’t really mean all that much. Practically everyone who plays RPGs has a game concept of some kind.

Okay, so what is the article really about then? Well it’s about knowing when your concept is fleshed out enough to move on to actually writing down a coherent version your game. Everyone is a little different, but for me I have a checklist. I call it my “Systems Design Checklist.” What I do is break my game concept up into seven distinct parts (or systems). Think of it like the systems checks that NASA does before they clear a space shuttle for liftoff. If I don’t have each of these systems in place, the concept stays in my notebook. If I do, it’s off to my keyboard. So what are these ‘systems’ I’m talking about? I have a checklist provided below if you’d like to copy and paste that, but for now I would like to describe each individual system in some detail.

System #1- The Play System: This system basically answers the question “What do the players do?” It covers items like scene framing, narration rights, procedures for entering ideas and actions to the shared imagined space where in-game events take place, stakes setting, and stuff like that. In essence, it’s the rules for talking. The play system spells out who gets to say what about what things, when they get to say it, and how far that power goes. This tends to be fairly free form in a lot of games, and that’s totally fine. However, some games ritualize this a great deal (e.g. Polaris).

System #2- The Character System: The character system covers two aspects of character. That is both the creation of characters and their components. This system answers the questions, “What does it take to make a character?” “What resources does the character provide its main player?” and “What resources does it provide all the other players/GM?” Character is one half of the components that go into Situation. So the character system should include arenas of conflict (since conflict is what drives the Situation). Usually arenas of conflict will be tied to a characters stats, personal history, or abilities. When designing my character systems, I make sure I have plenty of built-in arenas of conflict for the player to explore. However, it’s not just the character’s primary player that matters. All the other players, especially the GM if there is one, will be interacting with that character. So the arenas of conflict need to be made available to them as well in order to facilitate collaborative storytelling. When creating your character system, think about what parts of the character can other players (including the GM) use to springboard action? If you want to break it down, I believe the character system consists of three main parts:
1. Process of Creation
2. Main/Primary Player Resources
3. Other Player/GM Resources

System #3- The Resolution System: There are two main types of resolution: Task and Conflict. Each one of those can be broken down into styles: Drama, Fortune, and Karma. I’m not going into any sort of detail about those right now. Check the Provisional Glossary if you’d like to learn more about them. What I am going to talk about is what a resolution system accomplishes for a game. Mainly, it answers the questions, “Where is the element of chance?” “How can disputes between characters be mediated?” and “How are the outcomes of task or conflicts decided?” This can bleed over a little bit into the Play System. But that’s fine! All parts of a game should be related to each other in some form or fashion. When should a Resolution system be engaged? Answer: any time there is a dispute or conflict of interests between characters and/or players in the game that cannot be resolved by talking it out. Vincent’s, “Say yes or roll dice” seems a very appropriate answer to that question.

System #4- The Endgame System: An endgame system is very optional in an RPG design. A majority of games don’t have them, but some do. It answers the questions, “What is the final objective of the game?” “How does the character’s story end?” or “When does play stop?” Not every game needs and endgame. I happen to like designing with them because it helps me conceive of what a session or campaign (for lack of a better word) should look like, what I want the players to do, and the product I want the game to produce. For me, it is a device that helps drive the action to a climax. You may find that you don’t need one, but I encourage anyone working on an RPG to consider just how the game will end and if there is a way to mechanically support that ending that would enhance the experience.

System #5- The Reward System: Or really, the “Reinforcement System.” This system answers the questions, “How do I encourage the kind of actions and behaviors I want and discourage the kinds of actions and behaviors I believe are detrimental to play?” “What mechanical rewards do the characters receive?” and/or “What mechanical rewards do the players receive?” The best way, IMO, to break up rewards is to split them into two- Character Rewards and Player Rewards. It’s very important to understand the difference between the two. Heh, that’s probably a whole ‘nother article in and of itself. But anyway, examples of player rewards would be things like narration rights, plot tokens, or spotlight time. Examples of character rewards include experience points, relationships, and improved proficiencies. Not every RPG will have both kinds, but it is important to consider whether or not your game should. Remember the reinforcement system is the main tool you, the designer, have at your disposal to help the people playing the game to get as much out of it as possible. A weak rewards system will likely result in a weak play experience.

System #6- The Setting System: Setting is the second component of Situation. Where the action takes place has a great bearing on what sorts of conflicts (and by extension Situations) you can have. Creating your game’s setting is therefore, critical. The setting system answers “Where & when does the action take place.” “What is the geographical context and and/or social context for the game?” or “What parts of the fictional world do the players *not* have to worry about?” My games tend to be setting lite, but that’s not necessarily the way to go. Each game will be different. You’ll have to decide. In any case, the “setting system” can be represented in several ways. First, the setting can be predetermined. For instance, White Wolf has World of Darkness. Second, a setting can be hinted at in the text and then left up to the players to fill in as they go. Example: InSpectres. Finally, a game’s setting can be generated on the spot through play and discussion among the players like in Prime Time Adventures or Unversalis. It is important to know how your Setting System influences the Situation of your game. Providing a context for the conflict and action of the game is the main job of setting.

System #7- The Responsibility System: This system is the one you’d probably think about the least. It is the system that decides who does what in the game. For instance, it doles out whose job it is to decide when the Resolution System kicks in or when the Reward System kicks in. It decides which and how many characters each player will be in charge of. The Responsibility system is basically the job list of your game and procedures for deciding who is going to be in charge of what. Does your game have a GM? Does your game allow anyone to introduce conflicts? Does your game force each participant to portray a character? Basically, the responsibility system answers the questions, “What is everyone’s job?” or “What is each participant in charge of?” Sometimes various responsibilities will overlap. Sometimes they wont. Sometimes this will overlap with the Play System. Sometimes it won't. But whatever you decide, your game concept needs to make it clear who is going to be doing what during the game and what tools/mechanics/game pieces they will be able to use to accomplish their charge.

It doesn’t matter in what order you tackle these systems. I just sketch them out as the inspiration arrives. I put them in this order for this article as I found them in my notebook. So don’t feel like I’m prescribing a certain order of conceptualizing. I’m not. All I am doing is suggesting something to you that might be helpful since I have found it helpful to me.

So in conclusion, basically this is the method I use to determine whether or not a concept is worth taking to the next level: the drafting level. Drafting is probably another article for the future, but I feel that if I can have something - some idea - to drop into each of these seven slots, then I feel I have a game worth transferring from the scribbles in my notebook to a coherent document on my computer. You may have more systems or you may have fewer. But I would say that having some kind of method that determines when a concept is worth pursuing and when a concept is wasting your time is a valuable and time saving device.

::System Design Checklist::

O The Play System
O The Character System
O The Resolution System
O The Endgame System
O The Reward System
O The Setting System
O The Responsibility System

Peace,

-Troy

5 comments:

Troy_Costisick said...

Heya,

Hmm. That's an interesting idea. I try to do that sort of thing with the Socratic Design anthologies. However, creating a big pdf with all this stuff on is not a bad idea. I'll probably do one of my own some time down the road when I get a critical mass of articles under my belt. But in the mean time, if you'd like to do that for your own purposes, then by all means feel free! You have my full blessing to take my articles and turn them into pdfs and distribute them as you see fit. But the important thing is that this stuff helps you design. That means more to me than anything :)

Peace,

-Troy

thor said...

Troy - a little editing and it would be Lulu ready. But illustrations would help enormously.
Maybe even a workbook style design series.

Cheers

Thor

Unknown said...

Hi Troy,

jim pinto here.

Good article.

This actually is a worthy endeavor. While I'm "aware" of these steps as a designer, I'm not sure I'm aware of these steps as you've put them.

It certainly was interesting to see that my game has all these things taken into account, but it also encouraged me to look at other avenues.

Keep up the good work.

- jim

Troy_Costisick said...

Heya,

Maybe even a workbook style design series.

Hmm. That is a very interesting idea, Thor. I have a few more important posts I plan to make in the comming months, so something like that would have to wait. I mean, heh, Socratic Design isn't even a year old yet :) But you guys have given me some very good food for thought. I am humbled. But honestly, my only real hope is something I write here will be very helpful to you in getting your game written, tested, and published.

Peace,

-Troy

Micah said...

I know this post is nearly 5 years old, but it's still pertinent. I'm struggling on a game that I've been working on and someone pointed me here and it has been extremely helpful.

I'm subscribed to your feed, but I'm missing out on a lot by not having read through all of your past entries. You have some great advice on here.

So I just wanted to say thanks... thanks.