A Comprehensive Game Design Methodology
From First Ideas to Spectacular Pitches and Proposals

The content of this website is licensed under a Creative Commons CC BY-NC-SA 4.0 Attribution–NonCommercial– ShareAlike 4.0 International License. You can freely use and share everything non-commercially and under the same license as long as you attribute it to and link to:

J. Martin | |

However, you can also buy the Ludotronics PDF edition
for an unreasonably moderate price at DriveThruRPG.
Learn here about the five excellent reasons to do so!

Why DriveThruRPG? It’s the largest tabletop RPG download store and you’ll probably end up buying much more than just your copy of Ludotronics. Which would benefit all game designers!

Why not Amazon? Ludotronics isn’t well-suited for the Kindle format. And at €14.99, Amazon’s cut amounts to €9.75. Well, no.

More to read: My papers at Research Gate, my blogs at between drafts and just drafts.

Level Two: Interactivity

Process Phase Level Two

Beat 1. Rules

From Rules to Game Loops

Your first challenge in the Interactivity territory, and a formidable one, will be to create the best possible game loop, or set of game loops, for your game.

First off, let’s clear up a terminological confusion. What is a game loop or core loop?

It’s either of two things. For game developers, it’s a piece of code that keeps the game running from game state to game state with or without user input, and neatly clocked. For game designers, it’s what the player will do over and over again during play.

Let’s take Pong, the most basic example possible. From a game developer’s perspective, Pong has a continuously running “while” loop with a number of update functions that listens for events, notably player input, and drives and draws everything that’s supposed to be going on in accordance with the underlying rules. What’s going on, in turn, is based on math, fresh player input, if any, and the state its previous iteration left it in, and it sees to it that each event gets the processing power it needs and when it needs it to execute on time.

From a game designer’s perspective, the loop consists of the player moving either the left-screen paddle against the AI or the left-screen or right-screen paddle against another player up or down, hitting the ball, and waiting for the ball to return. That’s what the player does again and again, faster and faster, until either the AI or a player misses the ball and one of the counters goes up.

Naturally, we will be concerned with the game designer’s perspective, not the developer’s perspective. But as a game designer, you should know the difference.

With that out of the way, let’s start out on this journey. Not only will you have to sketch a game loop, you will also have to sketch a matching set of game mechanics. Which is not as easy as it sounds. The meaning of “game mechanics” is greatly disputed—with attempts at definitions ranging from the pedestrian to the esoteric. Yet, we know that game mechanics are connected in some way to rules, so we will build a model around game loops and game mechanics based on the nature of rules. Thus, we first have to answer the question of what constitutes a rule in video games.

With board games or card games, or with about any kind of non-digital games, the meaning of a “rule” seems obvious to us. This obviousness is reinforced by the fact that these games usually include a set of printed rules.

But what are these rules, what do they do? Let’s probe the game of chess, the game of Go, and the card game Skat.

In the game of chess, the king’s bishop’s placement (f1, f8) in the initial game state is a rule. Its movement limitation (diagonal movement only) is a rule. One of its distance limitations (another game piece in its path) is a rule, and one of its movement terminations is also a rule (anywhere on its allowed path within its distance limitations). Beyond the rules that determine the King’s Bishop’s positional values, there are rules that determine the consequences of these positional values, like check or stalemate (or, for other game pieces, promotion, castling, or en passant).

Now, the bishop can also terminate its movement on a square occupied by a game piece of the opposite color and “take” that piece, and its movement is also limited by the edge of the board. These are rules too, but for reasons that will become clear later, let’s put them aside for the time being.

In the game of Go, the free placement of a stone on any vacant intersection is a rule. The exceptions to that (self-capture, infinite repetition) are rules. The capture of a stone of the opposite color is a rule. Rules determine a stone’s positional value in conjunction with other stones, and they determine territorial values scored by stones of the same color.

In the admirably complex game of Skat, the procedure to determine the game value (also called hand value) is a rule. That a player has to follow suit, if possible, is a rule. That the set of trump cards constitute a suit is a rule.

Along these examples, we can spot the following pattern. Rules can define game states (e.g., the initial chess setup). Rules can define value states (for, e.g., positional values, territorial values, face values, trump values, or game values as in Skat). Rules can define any action that leads to a different game state (moving the bishop in a game of chess, placing a stone in a game of Go, playing a card in a game of Skat). Rules can define any change in values brought about by moving to a different game state (check positions; shifting territories in a game of Go; game value change through overbidding in a game of Skat; game scores in general).

At this point, we need to go on a brief tangent about manuals to collect some insights that will then lead us back to our question. For the types of games we looked at so far, manuals exist that scrupulously list every single rule of their respective game. For pen & paper RPGs or tabletop war games, it’s similar, but also a bit different. Their rules and manuals are amended and superseded all the time; the tide of specialized rule books and expansions never ebbs; and the number of rules can grow so large with time that they overlap and contradict each other—necessitating even more rules. Nevertheless, in a perfect world, manuals for these game types would also list every single existing rule for their respective games, just like the manuals for chess, the game of Go, and Skat.

Video games, in contrast, have no printed rules. And, with very rare exceptions and video game adaptations of board games, card games, and so on, video games also don’t come with on-line manuals that list all the rules. That’s because it’s the video game itself that enforces its rules—in such a way that, for the player, playing the game equals following the rules. The player need not be told that they can’t run faster or jump higher than the allowed values—they simply can’t run faster or jump higher than that, and even exploits are not a matter of breaking the rules but these rules’ intentions. Manuals, if there are any, do explain some rules, but for completely different reasons. They do not explain rules in order to get players to follow them, but to tell players how to get started and better achieve their goals.

But what about the rules themselves? Are board or card game rules and video games rules inherently different from each other?

Judging by our examples, they aren’t. Just as in board games or card games, rules in video games define the initial game state and the final game state. They define which interactions are allowed to move the game from one game state to another. They define value states, and how and when they change for each element as it moves through successive game states.

There are a number of differences, but on another level. As an example, video game rules not only govern the allowed behavior of human agents, i.e., players, but the allowed behavior of non-human agents as well. And while human agents—barring cheats—can only break meta-rules like communication etiquette with other human agents, non-human agents can break the rules, or be above them, any time. Regardless of whether they’re really above the rules or only appear that way, for the player it amounts to the same thing. After all, you can’t look up the rules in a manual and check! What about headshots served by NPCs from two miles away with a creaky 1888 commission rifle? Intermittent enemy invulnerability? Bosses warding off attacks with impossible actions that feel as ad-lib as any rule of Jewish poker? Are all these bound by the same rules the player must follow, or is it simply sloppy game design? Generally, this cannot be answered, so players often perceive it as a violation of rules the players themselves cannot but obey.

But apart from these and a few other characteristics not directly involved in the nature of rules, video game rules are not different from board or card game rules with respect to function and purpose.

Let’s condense what we have collected so far:

  • Rules define the initial game state and the final game state.
  • Rules define how and when game elements can interact and can be interacted with.
  • Rules define the value states of a game element and how these change from one game state to another.

Regardless of how simple, complex, or exotic the rules of a game might be, this covers what rules do for all practical purposes. Importantly, game states, interactions, and value states can be left undefined or defined in more than one way as they can adopt zero as well as multiple states, options, or values. The rules can define two or more possible initial or final game states, for example, or define that there isn’t an initial or a final game state at all. The rules can define how to interact with game elements but not when (at which point in time), or only when but not how. Time limits in chess games are “when” rules. A very simple arena shooter might have “how” rules but no “when” rules, so players are restricted in what they can do, but allowed to do what they’re allowed to do at any given point in time between the game’s initial and final game state. An arena shooter with spawn protection, in contrast, also has a “when” rule. Finally, a game can leave game elements’ value states undefined, or define more than one value state for an element toward different conditions.

Fig.4.11 Rules (Definition)
Fig.4.11 Rules (Definition)

What’s not easily discerned from this is the tendency of video game rules to proliferate profusely during development. Just pick a purportedly easy game that seems to have “just a few rules” and write these rules down for someone who’s never seen that game before, but whose life depends on playing it without violating the rules even once! Somewhere something will escalate quickly.

As an example and an exercise, let’s pretend we were given this task for the game of Go. The initial game state is certainly manageable (the board with its number of grids and its initial condition, the stones, their colors, and the number of players). The final game state isn’t too complicated either (both players pass consecutively with the white player last, or one player resigns). When game elements can be interacted with is also easy (black moves first, players take turns). How game elements can be interacted with is more demanding but still manageable (players place one stone on an empty intersection or pass; stones on the board can’t be moved; surrounded stones are captured and removed; self-capture is not allowed; moves that repeat a previous board position are not allowed). But explaining the rules that assign territorial values to any given game state from the stones’ positional values, that’s where our list erupts. The farther a match goes, the more difficult it becomes even for professional Go players to reliably estimate this value, and the value of the final game state—the score—has to be determined by a complicated process. (Which provides such a huge potential for disagreement that it can only be determined at times by resuming play, or letting a tribunal decide.) And that’s the game of Go, which is said to have a relatively simple set of rules! The value of the final game state in a game of chess, in contrast, is easily determined—but in return, this game’s how department is densely packed.

All this holds true for video games as well, only more so. Video games can have enormous numbers of rules, and when it comes to coding, every single seemingly “indivisible” rule has to be broken down even further. This, in turn, has consequences. Trying to design a video game bottom-up from these rules would be a grueling task for a game designer. Equally, trying to develop a video game top-down from abstractly defined player activities would be a backbreaking task for a game developer. Therefore, we need to build a model that provides and manages reasonable layers of abstraction with structures that are both hierarchical and flexible, from which designers and developers can work their way down or work their way up, whatever the case may be.

This model, our rule management model, will have four constituents or hierarchy levels: rules, rule sets, game mechanics, and game loop elements. Let’s build this model one step at a time.

Whenever we have a large number of rules, the most sensible response is to collect closely related rules into rule sets that can be addressed through a table of content. A “king’s bishop” rule set, e.g., would contain its rules for initial game state, movement limitation, distance limitation, and movement termination. Then we have the two rules that we put on the back burner a while ago: that the king’s bishop can occupy the square of a game piece of the opposite color and “take” this game piece, and that the king’s bishop can’t move beyond the boundaries of the chessboard. Neither rule is exclusive to the king’s bishop, so it’s more efficient to put them in different rule sets— one that deals with taking opponent’s pieces and one that deals with universal properties.

For a video game, for example, we might collect the rules we need for walk, run, or jump to create “walk,” “run,” and “jump” rule sets, respectively. But this is flexible! If movement exists in your game but is only of minor importance, it might be more reasonable to bundle the rules for walk and run together into a single “horizontal movement” rule set, or even create just one “movement” rule set that also contains basic jump rules. If you’re designing a game that focuses on movement, in contrast, it might make more sense to collect the rules for vertical jump and horizontal jump into separate rule sets, or create even more specialized rule sets for running jumps or double jumps, and so on.

Thus, we can codify the first two definitions for our model:

  • Rule. A rule defines a single, indivisible property of a game element, of a class of game elements, or of a game.
  • Rule Set. A rule set contains all the rules that are required to define a specific agent interaction.

Now let’s shoot for the next layer and define a game mechanic:

  • Game Mechanic. A game mechanic is a categorized collection of rule sets that define a specific player activity.

This needs some unpacking.

As a first step, we need to clarify the difference between an “agent” and a “player” as they appear in our definitions. An agent is defined as everything that interacts with, and thereby changes, a given game state; this can be a simple process, a complex in-game AI, or a player. Players are mostly human, but not necessarily so.

As a second step, we need to clarify the difference between a player activity and an agent interaction. This difference depends on game type and many other factors, but first and foremost it’s a matter not of definition, but of design.

To gain an understanding of why this is a matter of design, we first need to take the detour of looking at a number of practical examples.

In games where movement is needed but subordinated to more expansive activities like combat or exploration or puzzle solving, “jump” should be classified as an agent interaction, which makes it a rule set. Then we can take this rule set and organize it together with related rule sets for, e.g., walk, run, and dodge into a collection that we call “movement.” This, then, would qualify as a player activity, which makes it a game mechanic.

But then, if you design a platformer that is all about movement, “jump” is a much more significant activity, probably with particular modes of attack and a number of combos. In this case, it should be classified as a player activity, which makes it a game mechanic in its own right.

Here’s another example. “Pulling a trigger” would be an agent interaction in most cases, governed by a rule set that might include rules for chamber status, recoil, muzzle climb, loss of aim, and similar. “Shooting” would be a player activity in most cases that includes rule sets for different weapon types, actions, reload procedures, sights, pulling a trigger, and similar. “Projectile” or “hitscan,” in turn, could also be player activities, but more granular ones than “shooting,” for certain types of games that center around shooting.

As a final example to demonstrate the flexibility of this concept both horizontally and vertically, consider “cover.” Originally, back when taking cover meant nothing more than moving behind an obstacle, it was part of the “movement” game mechanic and didn’t have a life on its own because the obstacle’s rule set took over. Later, when taking cover expanded to “leaning out” or “peeking” around corners or obstacles as in early Metal Gear or Medal of Honor or Thief games and similar games that followed, it became either part of the “shooting” or the “stealth” game mechanic as a rule set. Finally, the concept of “cover” expanded even more, and it became a game mechanic in its own right, introduced by games like Kill.Switch or Gears of War.

To answer our initial question, it’s this conceptual flexibility that makes the difference between an agent interaction and a player activity, between a rule set and a game mechanic, a matter of design.

Our model does not assume, prescribe, or predefine rule sets or game mechanics in any way. You, as a game designer, can make them all up, make them more granular, more sweeping, more numerous, or more uncommon, even thoroughly unconventional. It will give you infinite options to try out something unusual, remix old and worn-out rule sets into a new game mechanic that surprises and delights, adapt any game mechanic and fine-tune it to the character of your game. For the latter, consider the rules that govern reloading a weapon. These would normally be a rule set, not a game mechanic. But if you want to introduce more realism for your game, more suspense, or maybe just more opportunities for exasperation, “reloading” could become a game mechanic in and of itself, with different procedures and ammunition types for different weapons, the potential for misfeeds and jams, and procedures to clear these and other malfunctions under fire.

By and large, your design decisions which rules should constitute a rule set and which rule sets should constitute a game mechanic need to be based on factors like scale, common sense, the principal character of your game, its value set, and its theme. And, of course, your intended playing experience!

Which brings us to our model’s final and most important constituent:

  • Game Loop Element. A game loop element is an integral part of a cyclically recurring sequence of player activities that defines the gameplay.

A game loop element is supported by one or more game mechanics, just like a game mechanic is supported by one or more rule sets.

Fig.4.12 Rule Management Model
Fig.4.12 Rule Management Model

With this set of definitions under our belts, let’s turn our attention to the design process. For three major reasons, the most important factor for creating a great game loop is to start with your game loop, not with your game mechanics.

The first reason is again a matter of perspective. Think of game mechanics as “features” and game loops as “benefits.” The former is the design perspective, the latter the player perspective. From the design perspective, your game mechanics can objectively consist of great rules and rule sets which, from the player perspective, amount to a game loop that subjectively sucks. Alternatively, you can design a gripping game loop that is supported by well-known, even humdrum game mechanics.

A second reason is that game loops and game mechanics operate in different domains. How rules, rule sets, and game mechanics interact with each other needs to be tuned and balanced in terms of complexity, whereas the game loop, as it is executed by the player, needs to be tuned and balanced in terms of playability. And playability should always have the right of way. (We will come back to implications of complexity in Beat 2. Reactions.)

Finally, game mechanics as such, with all their rule sets and rules and everything, do nothing. It’s game loops where these rules are instantiated into interactions, activities, and a progression of game states that evolve over time in accordance with the rules.

Nevertheless, it will spare you long and miserable stretches of agony later, from prototyping onward, if you keep your set of game mechanics and your set of game loop elements properly aligned from start to finish. To accomplish that, your game mechanics and your loop elements must always be affiliated in consistent and robust ways.

This doesn’t mean one-to-one relations. A single game loop element can be supported by more than one game mechanic, and one and the same game mechanic can support several game loop elements.

Rather, the trick is to keep everything tidy, all the time. What if you want to tweak a rule set from a game mechanic that supports, say, three different loop elements? That’s no problem at all. But what if that tweak should only apply to one of these loop elements and not the other two? Well, that is a problem! Different interaction rules for different contexts under the same name or label will become messy quickly, and it will certainly not endear you to your game developers. If you want to tweak a rule or rule set for a different game context, maybe for a higher degree of realism, then you need to create a new game mechanic around that rule or rule set. Instead of just one “movement” game mechanic, for example, you will then have a “movement onroad” and a “movement offroad” game mechanic. That’s what you should always do, without exception. Regardless whether the difference applies to a whole bunch of rule sets or just one single rule.

The rule management model is intended to support a rigorous and consistent design process throughout. It is also intended to be accessible and productive for everyone involved, and to facilitate communication.

  • The game developer can take a game mechanic’s rule sets, take these rule sets’ individual rules, and break these individual rules down into codeable components, all without losing the bigger picture.
  • The game designer can design a game mechanic for one or more game loop elements with the playing experience and the game’s overall vision in mind, sketch its rule sets, and then sketch the rules for each rule set, all without losing their way among its myriad of details.
  • The playtester will naturally chunk related sets of interactions into player activities and experiences, which will reflect the design process based on this model in analyzable ways.

Conversations about game mechanics that are informed by this model are mutually intelligible for game developers, game designers, and playtesters alike. Design, development, and testing processes will benefit accordingly.

Let’s make up an example, a classic first-person shooter. We will call it Shroom! because we want it to be really colorful, and we want it to teach us a lot.

What we want the player to do, over and over again, might be something like this:

Fig.4.13 Shroom! Game Loop
Fig.4.13 Shroom! Game Loop

These are the activities the player will go through again and again. They will explore (look for enemies, secrets, resources), fight (overcome enemies), solve (overcome obstacles, unlock secrets), and manage (pick up and manage resources like health, ammo, and power-ups).

First, let’s check this setup against the player activity cocktail from our motivational building, as discussed in Level One: Integral Perspectives I. Not every game loop needs to have its full seven-ingredients cocktail, but it pays off to have as many ingredients as possible. To recall, the ingredients are Jane McGonigal’s seven types of activity from Reality Is Broken: high-stakes work, busywork, mental work, physical work, discovery work, team work, and creative work. For Shroom!, we have high-stakes work (survive in firefights), busywork (picking up ammo and health packs), mental work (cognitive challenges like obstacles and secrets), physical work (handling input devices for heavy loads of combat and some puzzles), and discovery work (exploration). That’s quite a lot for such a simple loop! (Perhaps that’s one more reason why this general game type is so enduringly successful.) And adding a multiplayer mode and a player community would upgrade the cocktail to all seven ingredients with team work (CTF, Team DM, and other cooperative modes) and creative work (user-generated maps, mods, and conversions), respectively. If in doubt what to pack into your game loop, pick from these ingredients and compose an interesting blend!

Each loop element, in turn, will be supported by a set of game mechanics. Let’s have a look at how loop elements and game mechanics work together, first from the perspective of the latter.

  • Movement. The first and most sensible thing to do is to create a game mechanic for “movement,” which will hold the rule sets for walk, run, jump and running jump with height and width values, dodge, strafe, and whatever rules and values will be needed in that department.

This “movement” game mechanic isn’t dedicated to any particular loop element. Instead, it will support several loop elements together with other game mechanics. This mechanic will also hold the rule sets for very basic combination moves, like the aforementioned double jump. Other game types like jump’n’runs, platformers, or beat ’em ups will have a much more sophisticated system of combination moves, which will greatly affect the number of rule sets and the number of dedicated mechanics that are created around these rule sets.

  • Navigation. Next, we will create a “navigation” mechanic for the first loop element “explore,” with rule sets for player orientation like a map, compass, player position, waypoints, and so on. That way, the “explore” loop element will be supported by two game mechanics, “movement” and “navigation.”

Which, quite obviously, wouldn’t suffice to make “explore” an enjoyable playing experience, so let’s take a brief time-out to go off on a necessary tangent again. Every single game loop element must be interesting and that wouldn’t be the case if it merely provided the rule sets for walking, running, or jumping around, and knowing where you do it. Right here, you can already cash in on the advantage of working from game loop elements toward game mechanics, not vice versa. You can see immediately that these two mechanics alone would put playtesters to sleep quickly.

You could resort to pelting them with “enemies” and “puzzles” at every corner, but you might not want to do that. Or, you could make the “explore” element more interesting by making it more challenging. Rule sets could be added for movement combinations to overcome increasingly difficult terrain, and similar. But for a game like Shroom!, that might not be a good idea. Because, in all likelihood, it will compare poorly to mechanics from games dedicated to such stuff, fail to match the game’s overall design patterns, and not serve the theme. (In Level Three: Plurimediality, these requirements are discussed in-depth as skill, style, and subject matter.) But there is a more promising course of action to make this loop element more interesting. Instead of adding more elements from the Interactivity territory in terms of rule sets and game mechanics, you can call in artillery from the Plurimediality, Narrativity, or Architectonics territories. In other words, you can make the “explore” loop element interesting through design elements introduced in Level Three: Plurimediality, Level Four: Narrativity, or Level Five: Architectonics.

After that it gets a little more complex, so we’ll switch our perspective from game mechanics to loop elements.

  • Fight. There are many different options to arrange rule sets and game mechanics for combat, depending on your intended level of realism, or hair-splitting. Shroom! is a very simple game, but it’s also a combat-focused game. Thus, the “fight” loop element should be supported by a substantial number of game-mechanics that differentiate between distinct combat activities, but not approach titanic levels of granularity like Phoenix Command or Operation Flashpoint.

A good solution would be to break combat down into three game mechanics, namely “projectile,” “hitscan,” and “melee,” and add two additional game mechanics for “cover” and “stealth.” Together with “movement,” our combat loop element would then be supported by six different game mechanics, which are neither too many nor too few for this particular game type.

  • Solve. To keep things simple, this loop element will only be supported by the “movement” mechanic and a “use” mechanic with various rule sets (a “use key” to press buttons, open doors, switch levers, etc.).

That will suffice to give the player some tough nuts to crack without turning Shroom! into a puzzle game. Again, if we supported this loop element with a whole range of game mechanics, allowing us to create tougher and more complex cognitive tasks, we would run the risk of designing a different game, or of implementing “features” that would compare poorly to games that are cut out for this challenge type.

  • Manage. Besides “movement” to walk up to stuff and pick it up, it will be supported by a “resourcing” game mechanic that comprises three rule sets for health, ammunition, and power-up management.

The underlying rule sets of this game mechanic would be comparatively simple, but it’s all we need. If Shroom! were a survival shooter with aspects of constant scarcity, more differentiated game mechanics for “manage” would be called for. But in our case, basic management rules suffice.

Together with these game mechanics to support each loop element, Shroom!’s game loop looks like this:

Fig.4.14 Shroom! Game Mechanics
Fig.4.14 Shroom! Game Mechanics

To sum it up, our game loop sketch consists of the four game loop elements explore, fight, solve, and manage, each supported by two or more player activities in the form of game mechanics: two for exploration, six for combat, two for solving cognitive challenges, two for managing resources. For a simple, combat-focused game, this looks reasonably balanced. Other games will have more loop elements, a more complex loop, or even a set of loops that form a metaloop. There, a game loop like ours could be just one loop among others. There could be an additional loop that revolves around dialogic interactions for communicating with NPCs, negotiations, gaining knowledge, and driving the plot forward, and maybe another loop for a crafting system and upgrades, and yet another loop that handles upleveling the player character—all embedded within one or two metaloops and maybe even one superloop. In modern video games, game loop/game mechanic systems can become complex indeed.

Again, let’s take a walk along the design process, in the order in which it would actually occur.

The first step is to sketch your game loop, or set of game loops. What will your player do again and again and again throughout the game? That’s the most important thing. For each design iteration, ask yourself: would that game loop appeal to your player personas? does it vibe with your USP? will it support your theme? Should the answer be “no” to any of these questions, you might have a great loop on your hand, but it’s a great loop for a different game, maybe one you want to design in the future. But it’s not the right game loop for this game. Asking yourself these three questions constantly will also prevent you from missing essential design factors in conjunction with your player personas. Consult them! One such factor, for example, might be “loop duration.” If you’re designing a casual game that people will play while commuting or during short breaks from work, you should design your loop accordingly. Shroom! most certainly doesn’t fit that market. But if it did, you would want to design your two “explore–fight–manage” and “explore–solve–manage” routes in such a way that the player can decide which route to take, and that one of these routes can be completed in under two minutes. Should the answer to all questions asked above be “yes,” proceed to sketch and refine.

The second step is to sketch a set of game mechanics that will support your game loop elements. Your mechanics should be interesting with some innovative flavor along the lines discussed above, but easy to catch on to overall. Always remember Jean Piaget’s Moderate Novelty principle and Raymond Loewy’s MAYA principle for Most Advanced Yet Acceptable. There should be a good deal of familiar mechanics for each unfamiliar one.

The third step is to sketch the basic rules and rule sets that control your game mechanics. Crack open each game mechanic and sketch the rules and values that you need in order to script a prototype and group them into rule sets. For “movement,” you would have to sketch a full set of spatial values, time values, and control values (walking and running speed, jump height and width, jump duration, strafing angles, double jump click-timing, how slopes effect speed, and so on). For “explore,” you would have to sketch what the player can see when and how on their map and a working compass. “Combat” demands quite a lot, from weapon ranges to damage values according to distance to how aiming and sights are handled, and much, much more. For “solve,” that would be a preliminary list of move, use, and combined move & use sequences to overcome obstacles and find secrets. “Manage,” finally, as basic as it will be, also needs a considerable number of rules and values. You need health values and how they relate to damage values from the “fight” mechanics, rules for the number of available health packs relating to parameters like map size, enemy numbers, and difficulty settings. For ammunition, you need values for magazine size and how much can be stored in the player inventory, rules about how damage affects gameplay and the player, and how much and what kind of ammunition is dropped by what kind of enemies when they’re killed. For power-ups, you have to design different classes of power-ups that make the gameplay more interesting, how power-ups that affect health or damage interact with health or damage values, the number of power-ups that should be issued, and how hard it should be to obtain them.

All this might sound like a lot. But, as has been pointed out before, don’t forget that even the most basic rules and the most basic values you sketched are basic only for you as a game designer! Game developers will have to break each of these rules and values down into codeable components. They have to cope with a number of elements one order of magnitude higher than you.

At this point in time, you should give all these rules and values your best shot, based on experience and instinct. They will be far from perfect, or complete. Later, during your preparations in the Proposition phase’s Level One: Prototyping, many of these rules and values will take shape and begin to shine. But, basically, this will never stop. You will have to add rules and values, scrap rules and values, and revise and tweak rules and values throughout the development process. And, for all your efforts, you won’t be done with it after shipping either, for a substantial amount of time!