The Forge The Internet Home for Independent Role-Playing Games
About the Forge | Articles | Reviews | Forums

The Crunchy Bits #2: "Hell, there are no rules here - we're trying to accomplish something."
by Emily K. Dresner-Thornber

Edison's oft quoted remark, "Genius is one percent inspiration and ninety-nine percent perspiration," holds true for any creative endeavor. As the greatest inventor of the 20th century, he holds more patents than any other single human being - over one thousand of them, including the electric light bulb. In theory, he knew his stuff.

Like the light bulb, games are inventions. A single spark of inspiration lies at the heart of every one. Yet, building great games is work. Sometimes, it's an insurmountable task. Many great ideas end up on the cutting room floor because their designer didn't want to see them through - not because they are lazy, but because there are always a million more interesting things to do then write yet another paragraph.

There's a trick - cut the project into pieces, and those pieces into sub-pieces, and so on and so forth. But the trick doesn't work without forward planning. The following presents the beginning of one possible approach to dealing with the basic project management behind a roleplaying game. These are not rules, but guidelines.

These are the first three steps: the concept, the synopsis, and the basic outline.

Step #1: The Concept
"I know! Let's write a game where everyone plays household furniture! We can write rules for when someone sits on us, and take damage when we're spilled on!"

"Nah, not enough combat. We should be trees, and throw spores at each other. Crab Apple Attack!"

"But we can't go anywhere. Maybe we should play household pets. You can be the small yellow canary, and I'll be the large Maine Coon. I bet I could convert that to GURPS!"

99% of all new games never get out of the concept stage. Most are simply unworkable - they're too silly or too narrow to work as a game. Others tie themselves to a particular game or genre, and are unworkable as commercial product, such as tailored Cthulhu scenarios or Spelljammer quests.

The concept is a simple sentence or two that sums up the basis of the game. It provides the designer with a handle on their bit of inspiration and to decide if it is a workable idea or not. Most games go through several iterations of the concept before one solidifies.

Concepts are very simple. For example, the concept for Vampire is the following:

Players are undead beings adhering to Victorian-style Vampire mythos. They belong to "clans" (classes) who fight with one another and specialize in different "powers." Vampires retain a certain amount of their humanity, and tend to feel badly about eating regular humans as nighttime snacks.

Similarly, the concept for Deadlands is equally simple:

Players are gunslingers out of the Old West. Except, all the old tales of the Old West - the ghosts, the mad scientists, the crazy clockwork - it's all real.

Write down the concept. Look at it. Think about it. Let it stew for a few days. Solicit feedback. The designer must ask several questions:
  • Is this setting limited to a single player, or can multiple players cooperate?
  • Does the setting make sense without a convoluted explanation?
  • Does the game stand alone, or does it require other, commercially published game systems to flesh out the setting and the system?
  • Does the game concept feel too narrow? If characters wander off the beaten path of the basic campaign concept, does the game fall apart?
If any of these fail, the game designer should rework his or her concept until it passes. If the designer cannot reword the concept, it goes into the bit bucket. He or she tries again with something else - usually after sitting around throwing out more ideas, or dreaming up more concepts while standing in the shower.

A few hints to figure out what is good and what is bad quickly:
  • Games that feel limited to a single player are best left as short stories. Roleplaying games encourage cooperative play.
  • Games that put players in an adversarial role against one another may or may not be thrown out, but it is important to remember adversarial games do not promote cooperative play, and appeal to a very small range of people.
  • Games that feel overly complex to the designer are not workable. A good rule of thumb: if the designer feels confused explaining the system to a third party, the system is too complicated. Rework the concept until it feels simpler.
  • Is the game fun? If the designer wouldn't want to play the game, the game concept does not work.
Now is the time to either throw it into the circular file or to keep it and hammer it into shape at the beginning. Never be afraid to throw out a game concept that starts to feel unworkable after a few days. That was one idea out of a million - more will come.

The basic concept for "Robotz" is:

Example 1: The players are A.I.s inhabiting robotic bodies and infiltrating mankind. They live a secret life of networks and silicon. Some robots want to assimilate man, and others want to destroy it.

Step #2: Synopsis
"Do you want to hear about my game? Huh? Huh? It's really cool and it's all about how players go around killing dragons, but they do it with laser guns instead of swords, and it's all in outer space in an alternative universe. And everyone wears spandex! And there's this bad guy, and he's in collusion with the dragons."

Of the 1% of the games who make it out of the concept stage, most of them end up in unformed rambles. Many prospective game designers have good ideas, but not all of them can communicate them effectively. Clear, concise communication is the secret to all game writing, and the synopsis is the first crack at it.

The idea of the synopsis is to start fleshing out the concept and putting in details. It is not a gaming session or a multi-page description of the setting; rather, it is a paragraph of text describing your game. It should go into the hands of another and they should "get" it. It's an effective tool for soliciting feedback.

At this point, the game is now a pitch. Theoretically, the designer can send this to someone to get his or her attention, and try to start the gears of publication. For the purposes of the self-publisher or the Independent game, it is a baseline to work from, a way to explain yourself, and a good blurb to put on a website. When soliciting editing assistance, layout assistance, or artwork, it's the starting point for negotiations. Do not be afraid to rewrite it several times until it gets the message across. A clear synopsis will help at many steps later in the process.

An option for very mechanically heavy games, or games whose play resides almost entirely in the system, is to form the pitch into a paragraph describing the mechanics of play. For example, Once Upon A Time from Atlas Games is a nearly pure mechanical game, and a description for that game would describe the cards and the mechanics for passing the thread of story around the table.

Again, Robotz is the victim of an example. A typical synopsis for the game reads like the following:

Example 2: It is 2038. Super A.I.s called "Overminds" exist in secret. They plot to manipulate humans and each other for their own ends: the assimilation, the destruction, or the harmonious existence with Man, or the destruction of each other. Through the net and their illegally tapped resources, the Overminds build intelligent, autonomous robotic agents to carry out their orders to gain the upper hand in a coming A.I. Revolution. Characters are these robotic agents, and they work together to carry out their master's secret conspiracies.

It sounds corny, but there it is.

Step #3: Basic Outline
"Who designed this game? I can't find anything in this book!"

Take any gaming book off the shelf and look at the table of contents. Take another one down and compare the two. There should be very basic similarities, even if the games are radically different in nature.

A roleplaying game is made of three basic "atomic" components: setting, rules, and game master information. The game may vary in the density of the three. For example, Over the Edge has very little in the way of actual mechanics, but it has a great deal in the way of setting and game master information. Big Eyes Small Mouth 2 has only a little setting - an explanation of anime and the genres - a large amount of game mechanics for the characters and for the game, and a sizable GMing section detailing anime in better detail, and an example adventure.

Every roleplaying game has all three sections to some degree. This does not mean that "undesired" sections have to be more than a few pages. This does not mean that every game must have so many rules they fill up a single book. It is up to the game designer to find the balance for his or her book.

Settings include histories, backgrounds on classes and races, descriptions of conflict, motivations, locations, and anything else the designed feels a player needs to immerse themselves in the game. The setting may or may not include equipment lists. If the game is of a conspiratorial nature, like Call of Cthulhu, there might be regular equipment and "secret equipment." The same with fantasy games, where the magic equipment may not be available to the characters at the start.

Mechanics splits into two categories: character creation and actual play. Character creation encompasses skills, statistics, magic, and any kind of merits/flaws system. Play, again, splits into two categories: skill use and task resolution. (Advancement falls under "GM Instruction.")

The Game Master section includes adventures, secret backgrounds, important NPCs, research materials, further setting details, and "secret" equipment lists.

After writing the synopsis, the game begins to fall into these three buckets. The first step into making an outline is to write out brainstorming lists.

Example #3: Brainstorming Robotz

Setting: History of the A.I.s, the computers of the future, the network of the future, the Overminds and their motivations, "Hives" of agents inside an Overmind, being a "child" agent of an Overmind, some future hand-wavings about law and the net, some fun things about fighting in MMORPGs.

Mechanics: Different robot bodies, different robot types, "Programs" (spells), lists of possible merits, cool new weapons, attachments, mechanics for fighting in the net, mechanics for fighting out of the net, skills.

GM Information: Human groups out to get the A.I.s, secret human plots dealing with robot bodies, expanded equipment lists, adventures, real history of AI and the Turing Test, some real information about hacking and networks.

This is suitable information to put together in a first pass at an outline. This is not the final outline. There will be many revisions of this sucker before I write a single word of the game. This is merely the first swipe at the beast.

In Your Favorite Word Processor, take advantage of various heading and outline features to keep track of the outline as it grows. The Word Processor is the game designer's friend. Use it, love it, and it will love back - until it crashes, so back up often. Emacs, too, has an outline plug-in, for those of you who prefer to do your writing on Linux.

Here is a very early swipe at the Robotz outline. Note: almost all of this is going to change, but for now, it's a good idea of what the big chunky sections will look like. The first attempt at an outline always looks a bit on the plain and dull side.

Example #4: "Robotz" Outline v. 0.1a
  1. Introduction
  2. Setting
    1. History of the Overminds
    2. Inside the Hives
    3. Children of the Overminds
      1. Different types of Robots
      2. Different types of Agents
    4. SNORT
    5. The Coming A.I. Revolution
  3. Mechanics
    1. Character Creation
      1. Stats/"Races"
      2. Merits/Flaws
      3. "Programs" (Magic)
    2. Task Resolution
      1. Skill Resolution
      2. Combat - Normal
      3. Combat -- Net
  4. GM Information
    1. Various and sundry secret Anti-AI Human Groups
      1. NSA
      2. Secret Microsoft Task Force
      3. People Against Robots
      4. Several more "Secret Societies."
    2. The (Real) Background of A.I.
      1. A.M. Turing and the Turing Test
      2. Stalling in the 70's and 80's
      3. Learning Algorithms and games
    3. Hacking
      1. Some very basic networking
      2. Viruses and Parasitic Computing
      3. Crypto
      4. References and Goodies
From this, you can get a feel for what the game may eventually look like. It's filled with some "gritty" real science (hacking, A.I.) with a veneer of science fiction on top of it. For the system, it's leaning toward a bit of conventionality with some gaming stock standards - not too terribly creative, but not difficult to understand, either. The end of the book is chock full of goodies and background to help flesh out the world. The book isn't very exciting, but who knows what will happen in later iterations of the outline.

There's no real sense of balance, yet. While it appears that the third section will eat up most of the book, in fact the Mechanics are likely to take up most of it.

That's the beginning of the book. Slowly, it is starting to come together. In the next installment, I'll present the actual design of an RPG through the Outline, fleshing out a basic one into something that looks considerably more like a book.

So, stay tuned...

The Forge moderated by Ron Edwards and administrated by Vincent Baker.
All articles, reviews, and posts on this site are copyright their designated author.