One of the things that I was thinking about recently is how the design process goes in games and how to really work with turning designs into rules, and I'm also running a horrible delay on actually completing that process, so I figured that I'd write about it instead of starting down the rabbit hole of finding yet another thing to change and postponing my deadline further.

The process of going from a design to a finished rule is probably the most fundamental element of game design, and it's one that doesn't always seem to require a whole lot of thought or effort. After all, isn't a rule basically a game's design?

Design versus Implementation

It would seem so at first, but the idea that rules are automatically taken from a game's design can be something of a simplification, and that can pose dangers to your finished product.

A design is the abstract breakdown of the game into its constituent elements. You have each mechanic and probably many if not all of the variables and other factors already set up in the design before you even get into plotting rules, though this isn't exactly a first-second process; designs and rules will change over the course of time.

One of the things that people forget, however, is that the rules are merely an implementation of the design.

I've discovered as a game designer that the actual finished rules can vary a good deal for an identical design outcome. This may sound somewhat weird, but keep in mind that the rules are simply a concrete formation of the design. Let's look at an example: "Players can choose to heal their allies using five Mana and an action that takes their turn."

This is a very simple rules, and a very simple design. You could also say: "With a turn action, a character may heal an ally at the cost of five Mana."

This would imply two different implementations of the same idea. You've got a turn-based system, actions that can take a whole turn, a mana resource, healing, and multiple characters, at least two of whom are friends.

An Example from Magic: The Gathering

However, the way that you complete this will be very different. If you look at a card in Magic: The Gathering, you may find that it has the same effect in play as a different card with different rules text. This is primarily due to evolution over the years (as Wizards of the Coast is very good at keeping consistent rules text), but it highlights this well.

Saying that a creature may attack on the turn it is played is the same thing as saying that it has Haste, but these are not fundamentally the same rule.

As a result, you have a lot of variability in changing your rules into designs.

Where Do the Differences Come In?

A good designer balances a cognitive workload for players with mechanical systems that are satisfying. Typically this is done by pursuing a particular narrative (and I can get into the psychological reasons why having a narrative is important, but basically telling a story is easier than creating a satisfying challenge without context), so the design needs to be able to balance the narrative and cognitive workload for players.

A good example of this are the old-school point-and-click adventures that I am personally not a huge fan of but which reflect an important cornerstone in video game design. The sort of "crowning achievement" of these adventure games was to tell a story to the players that could be humorous, insightful, or just plain cool, but to do so in a way that let the player feel smart.

Be too cruel to the players with narrative wrong-turns or character death, and you wind up making them feel stupid (or, more likely, think that you're either stupid or cruel), but if you just let them walk to the finish you don't give them a feeling of having accomplished anything.

Most of these adventure games had a simple inventory mechanic in which you'd just compare items that you had with your environment to see if you could fix whatever problem presented itself.

While this isn't a mechanic that lends itself to emergent play–that is, gameplay that is derived from mechanics rather than writing–it is one that highlights this golden window of hitting the right difficulty and telling a story in such a way that you create a coherent play experience.

As a tabletop game designer, one of the things that I have to worry about is the mental limits of players.

This isn't to say that the average player is an idiot. I haven't done any significant research, but I would guess that people who are attracted to play, particularly roleplaying, trend toward being at least of average intelligence.

However, the game is not going to take up someone's whole mental acumen for a sustained period of time. They will be willing to devote their full attention to it for a relatively short amount of time (measured in hours, but probably not more than a few dozen), and they need to be able to get the rules into memory well enough to follow them with minimal disruptions for reference.

Three Priorities for Rules

The requirements of having satisfying play without unreasonable demands creates three primary requirements for rules:

1. The rules must be consistent and coherent so that players have a reasonable expectation of what will happen.
2. The rules must be simple enough to remember or quickly reference, and must also be easily communicated.
3. The rules must be able to accomplish the goal of actually facilitating play.

On tabletop, the rules are interpreted by people. For a designer, this makes things interesting.

Basically, you can have some issues that are going to self-resolve, and work with some leaps of faith. I don't have to define every challenge ahead of time, for instance, because a GM will do that for me during the execution stage.

On the other hand, I need to provide enough information for a GM to do that, and I also need to make sure that the system's robust enough to handle a little bit of a beating from misinterpretation and the consequences of people filling in those gaps.

The idea here is that a roleplaying game offers near total independence, but that's something of a design hell. You will find yourself quickly overwhelmed if you try to do everything. I made a game once with over 150 unique weapons, or, as I now like to call it, a tremendous waste of pages. This was on top of conversion rules for real-world weapons, and other features that were intended to allow an incredible diversity of combat options.

Not only was it too much for people to parse, it failed on all three of the priorities for rules; it was too eclectic, too clunky, and not at all furthering the play or narrative.

Now, that's not to say that games can't have a lot of content. Content's great. I love Shadowrun, and half of my experience with it is shopping for stuff in the massive lists of gear it provides. But that content has to feed into a convincing game experience, and a designer's best-spent time is on working on the core experience, not content.

Content can be made during testing and after the design and rules are finished, and you only need as much as players demand, so be smart about what you put work into. Prioritize the core mechanics, and they'll treat you well. Prioritize the content and you could wind up with a game that's unplayable but which you've invested a lot of time and effort into fruitlessly.

1. Consistent and Coherent Rules

The first thing you really want to pursue is having rules that will do the same thing every time they come up. This is just a requirement in general to have any rules that can be considered a mechanic.

Mechanics are important because they are reusable and can lead players into an understanding of the rules and systems of a game.

Having no consistency in rules creates a frustrating experience as players feel left behind by the action, and it'll lead you to major issues with the second priority because each rule will be an entirely different scope.

Dungeons and Dragons does this incredibly well by making almost every action in the game dependent on the result of a twenty-sided die. This means that every attack, skill check, and non-magical action in the game is going to either happen automatically (if this fits the narrative) or with the same core mechanic.

It's also worth noting that you then want to extend this to almost everything in your game.

To take the example of Hammercalled, the game I've been spending the past year and a half or so working on, everything is based on the same hundred-sided die (actually two tens-place dice) roll, and there are a lot of assumptions about everything being player-focused.

When the players want to roll, they find a characteristic that best fits their objective, add any other benefits, and then try to have a result that's lower than their target number. It's got a "blackjack" style system going on, where you get benefits based on how high your result is, so long as it isn't too high.

This creates a consistent core mechanic (you always roll the same dice in the same way), and also a coherent one (you don't have to remember different rules for different situations, and we even handle our magnitude of results on the same core dice).

This isn't to say that you don't have potentially many different rules in your game, but this consistency gives us two really important features:

First, we can always have an easy fall-back for if a particular rule isn't remembered. Roll d100 and if the result's good you probably succeed. This is true for everything in the game, except automatic actions that don't need rolls.

Second, we have a firm foundation from which to build out into other rules. In combat, for instance, there is a highly defined manner in which a good result increases the damage you deal. In future product lines, we might add more clearly defined magic, or cyberspace hacking, or stuff like that, and we'll always be able to branch out from our core.

2. Memorable or Easily Referenced Rules

You want players to be able to play your game, and every moment spent reviewing rules while they're trying to play is going to be a huge problem.

An example of this is the game of Chess. Chess is relatively difficult, but is not terribly complicated. You have about a half-dozen different types of pieces, and they always follow certain rules that are both metatypical (e.g. all pieces are taken if another piece moves into their square) and individually typical (knights always move in an L shape, two tiles straight away from them and then veering off one tile to either the left or right).

Of course, Chess is a very symmetrical game, and it's not necessary to have symmetrical rules for all players (for instance, a player can specialize in having a character that heals, while another can specialize in having a character that moves quickly and forces others to move), but you can fit all the rules for it on a piece of paper.

Generally, you want to have just a few rules that give you a broad base for interactions. Think of Minecraft; you can punch blocks to remove them (or harvest them, if you have the right tool), and then craft together in a table. You have an arbitrary number of elements, but they behave as expected because they represent, as a general rule, concrete (rather than abstract) elements of reality, and any references you need can be found quickly through in-game or out-of-game tools (e.g. for crafting).

Into the Breach is another game that does this terrifically; it's a super-simple turn based strategy with giant robots versus giant monsters, and the core mechanic is basically just moving, attacking, and pushing. However, you see two or three inflections on each of those commonalities and it can be quite complicated when you actually get into it without ever becoming confusing.

Using the same key terms and limiting the number of them to a short list is important; if you have more than fifteen core concepts for players to remember you've almost certainly gone too far.

You can also cheat with reference materials. Character sheets in tabletop RPGs are lifesavers, but you can include useful information on them. It is expected that people bring these, so you can sneak a lot of reference material in here if you're clever. However, there's still no substitute for just having simple, logical interactions.

The game that has most frustrated me in my roleplaying career is the Warhammer 40:000 RPGs published originally by Fantasy Flight Games. I love them and I've had some great experiences with them, but they're a perfect example of a game that expects you to reference materials during play, with fifteen pages worth of explanations of what happens when characters or vehicles suffer particular sorts of damage and rules for dealing with all sorts of stuff that you can ignore without consequence 90% of the time. I've played them for years and I still have to keep my nose in a book while playing them, which is somewhat frustrating and a constant reminder to keep things simple.

3. Play-Focused Rules

The biggest and final element of creating a game is to have rules that are focused on play.

I'm not a big believer in "balance", in part because the games I make are not designed to be competitive. However, there is one thing to be said for it: every player must have a way to change the game-state, and by extension the narrative universe that the game takes place in (if there is one).

One of the games that I think does this best (that I playtested and contributed a couple minuscule elements to) is Open Legend.

Open Legend is all about high power-level characters, and you get things that are just absolutely fantastic within that in terms of how it handles the balance and storytelling. It has almost no resource management, but it manages to feel really balanced despite the fact that everyone can pull off their most powerful abilities all the time. How?

To quote myself:

A character who lives in their world works best when they, and their companions, have access to the things that make them unique at all times. Giving a character some resources to expend turns roleplaying into an exercise of mathematics and futile attempts to balance–there is a place for strong mechanics in games, but they should not come at the expense of characters having access to distinct abilities.

The thing that you need to be able to do with your rules is say that they work in a way that is productive. These productive rules need to foster the ability to make choices; play in its most essential form is making decisions and seeing their consequences. This is what gives it value; it is both exploration-based learning and amusement.

This would be a good subject for a whole talk in and of itself, but the general idea is this: you want to be able to give players the ability to make meaningful decisions all the time. Whether this occurs on a very deep level or a relatively shallow level is entirely up to you; Mario Party is an example of strategic play (moving around the board and collecting stars) blending with more frenetic play (random multiplayer minigames) to blend multiple types of skill together, and this is common in a lot of competitive games.

In roleplaying, I've described the play as being broken into three levels: metastrategic character development that allows players to shape the rules by which they will play, strategic long-term play and resource management, and tactical rules interactions.

Wrapping Up

The process of turning a design into rules is one that's more than just a simple exercise of word choice, but goes deeper into how your rules bring your design to fruition.

Games can facilitate play only when their rules provide an environment that permits it, so it is necessary to have consistency without too much complexity, and a focus on what the play objectives are going to be in terms of the overall schema of the game.