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 One: Prototyping

Proposition Phase Level One


First, let’s break the whole process of prototyping down into a small number of simple steps, employing a slightly modified version of the design philosophy Donald R. Lebeau once posted on the AtariAge forums. According to Lebeau, you can break down everything you do into four simple steps:

  1. Make it.
  2. Make it work.
  3. Make it work reliably.
  4. Make it work reliably and X.

Lebeau’s original fourth step is “Make it work reliably and fast.” But for our purposes, that needs to be more flexible, so you can adapt it to your game treatment. The basic compass for that, in turn, is your work from the Preparation phase, applied to the four dimensions of the Ludotronics map. Depending on the dimension where your USP resides, the fourth step for your game treatment might look similar to this:

  • Game-Mechanical USP: Make it work reliably and smoothly.
  • Ludological USP: Make it work reliably and intuitive.
  • Cinematological USP: Make it work reliably and pretty.
  • Narratological USP: Make it work reliably and polished.

These are just serving suggestions—you have to find your own “X” that seamlessly integrates with your game treatment. But whatever it is, following these four steps will make your life easier and your work more focused.

Beat 1. Assemble

Will you need a proof of concept–prototype to go with your pitch? It depends. But having invested time and effort into putting your game treatment to the test goes a long way toward building trust. However, you’re in the concept phase, not in pre-production, and you most certainly lack the resources to deliver a pre-production prototype that could, and some say should, absorb up to 20% or even 25% of the entire development cycle. Nor does anyone expect you to. So if you want to create a prototype to test your game treatment and later present the prototype and the test results together with your proposition, it’s all about scale. And for prototypes, scale translates into focus.

Before we get into this in more detail, let’s review a general aspect that is very important. A prototype is supposed to be disposable. Disposable means that you shouldn’t fall in love with it. If you sink too much time into it, and care, by creating temporary assets that are too polished and code that is too optimized, you will be tempted to transfer prototype material into your actual game. Now, by design, prototypes are full of brutal shortcuts and snap decisions and trade-offs and stand-ins, each of which will return to haunt your team with exquisite nightmares during production.

There are two decisions you have to make before you can start building your prototype. One decision concerns creating a vertical prototype or a horizontal prototype, also known as vertical slice and horizontal slice (or layer). The other decision concerns creating an analog prototype or a digital prototype. The former warrants a brief explanation. A vertical prototype contains representative bits and pieces from almost everything that your game will contain. A horizontal prototype showcases one major aspect of your game more in-depth. Translated into Ludotronics parlance, a vertical prototype showcases bits and pieces from all four dimensions, while a horizontal prototype focuses on one particular dimension.

For each decision, there is a criteria set that you can use. For vertical vs. horizontal, the set consists of your game loop, your USP, and your core idea, the three most important elements from the Procedure phase. For digital vs. analog, the set consists of the four dimensions of the Ludotronics map.

Let’s begin with the three elements from the Procedure phase for your vertical vs. horizontal decision.

  • Game Loop. If your prototype can’t demonstrate what the player will be doing again and again, for hours and days and weeks, then it’s worthless. Your game loop should be the first thing on your mind when you start planning your prototype. In general, it is probably more difficult to integrate a game loop into a horizontal prototype that focuses on one dimension only than into a vertical prototype. But if it is possible, and other criteria support this, go for it. Whatever you do, though, your prototype must demonstrate the game loop. That’s a prerogative.
  • USP. If your prototype can’t communicate what differentiates your game from similar games directed at your primary target audience, that’s also a huge problem, but not as huge as a missing game loop. As discussed in the Preparation phase, your USP is your game’s most important value characteristic, and it will fall into one of the four dimensions of the Ludotronics map—Game Mechanics, Ludology, Cinematology, or Narratology. So if you want to highlight your USP, that could be a good reason for a horizontal prototype that presents this one dimension in greater detail. Provided, of course, you can also integrate your game loop!
  • Core Idea. If your prototype can’t demonstrate your core idea, that’s a bummer too. But it’s not as vital as demonstrating your game loop or your USP. Should your core idea fall into the same dimension as your USP, and your game loop can also be represented within this dimension, that might give a decision for a horizontal prototype additional weight. Because then your prototype would focus on the most compelling and most innovative aspects of your game treatment without surrounding it, and possibly diluting it, with a host of pedestrian elements from the other dimensions.

Next, let’s go through the Ludotronics map’s four dimensions for your digital vs. analog decision.

  • Game Mechanics. If your USP resides in the game-mechanical dimension, that leaves your options open for either a digital or an analog prototype. In case of the former, that would be a wondrous video game mechanic that couldn’t be demonstrated with a digital prototype! In case of the latter, mechanics and rule sets and rules can often be meaningfully mapped to the typical materials and actions of analog prototypes, be that paper, cardboard, sticky notes, coins, dice, playing cards, index cards, game pieces, counters, whiteboards and magnets, building blocks, or physical player actions and player decisions, all of which can be supported by pen & paper–like probability distributions as discussed at length in the Process phase. Even pace can be simulated! In Players Making Decisions, Zack Hiwiller relates the example of an analog version of Tetris where players had to scramble to catch or pick up “tetromino cards” that were thrown at them, and process them racing against time.
  • Ludology. If your USP resides in the ludological dimension, that will almost always call for a digital prototype. The ludological dimension is all about the interactions between player and game or between player and player, which usually involves the game’s controls and interfaces, kinesthetic learning, input-dependent cognitive tasks (a.k.a. puzzles), control scheme–specific coop or multiplayer action, and so on. It is highly unlikely that any of these can be simulated with the analog materials and actions enumerated above. None of these materials or actions would convey how actual controller input would feel, and how the game would react to that input. There might be cases where an analog prototype can communicate ludological elements, possibly around certain player-versus-player interactions. But that would certainly be an exception, not the rule.
  • Cinematology. If your USP resides in the cinematological dimension, which involves graphical style, music, sound, camera movement, and so on, to convey aesthetics, atmosphere, and emotions through its environment, that again will in most cases call for a digital prototype. Short of converting a whole conference room into a game level, firing up a playlist and showing a collection of pictures won’t cut it.
  • Narratology. If your USP resides in the narratological dimension, that leaves your options open once more for either a digital or an analog prototype. For the analog option, you can, e.g., create a short pen & paper adventure, or combine your interactive narrative with a map or some kind of terrain, game pieces, counters, cards, etc. But be sure to create your prototype around a meaningful chunk of narrative with its own stand-alone plot structure, maybe introduced by a three paragraph–roll-up, as discussed in the Process phase, so that it’s gripping and emotionally satisfying. Explanations and expositions are invariably clumsy and boring and will torpedo your setup.

To sum it up, if your USP falls into the game-mechanical or the narratological dimension of the Ludotronics map, the decision to create a digital or an analog prototype is up to you. If your USP falls into the ludological or the cinematological dimension of the Ludotronics map, it is strongly recommended that your prototype be digital, barring very distinguished circumstances.

After you made your decision, either toward an analog prototype or a digital prototype, you have to decide what to work with. For an analog prototype, all the materials and actions mentioned so far could be suited, plus anything your imagination comes up with, depending on your game treatment. For a digital prototype, you have three basic options.

If you don’t have any coding experience, you can use authoring tools that yield good results but do not force you to invest large amounts of time to wrap your head around scripting or programming. For interactive fiction, e.g., you can use a number of narrative authoring tools. These can be powerful design tools, with the cyberpunk game A(s)century as a case in point. For everything else, you can use any tool with a visual editor and drag-&-drop functionality. If you have scripting experience, you can use a scripting language to build your prototype. If you’re a seasoned programmer, you can use whatever development kit you like. All three solutions are fine. Just remember, especially for the third solution, that the prototype code is supposed to be disposable and should not find its way into the production cycle.

Then there’s the small matter of how to prepare your prototype.

The first thing your preparations have to take into account is that your prototype serves two different purposes, and it must serve both purposes equally well:

  • To test and assess your game treatment.
  • To present and show off your game treatment.

Then you have to decide what to include on a more granular level. Figuring this out is not altogether different from deciding what artwork to include in a portfolio or which sample to send out from an 80,000-words manuscript. The following three principles should always be your guide:

  • The prototype should be representative.
  • The prototype should be engaging and exciting.
  • The prototype should be accessible.

The beginning and the ending of your game, as you imagine it at this point, are not well suited. They’re almost by definition not representative to what the player will experience over the course of the game. Also, they’re not that exciting either. Endings have accumulated too much context and invested practice and emotion to serve as an involving stand-alone example. Beginnings are rarely exciting because you need exposition to get things going. On the other hand, everything that’s not in the close vicinity of the beginning of your game might not be accessible enough in terms of game mechanics and your game’s control scheme. If any of that is the case, your prototype will neither help you test and assess, nor help you present and show off your treatment.

The solution to this conundrum, in most cases, is to compose a prototype that uses everything you’ve collected in your Ludotronics inventory at the end of the Process phase in Level Six: Integral Perspectives II, but ignores concurrences. To do that, take your maps, graphs, tables, or charts for your rough sketches toward the distribution of learning curves, style dynamics, dramatic intensity, story arc and character arc, and the tasks, objectives, and subgoals that lead to the game-driven goal. Then, pick from each distribution something that fits your purpose. For example, you can take something from the very beginning of the learning curve and some very early tasks, combine them with something a bit more advanced in terms of story and style dynamics, and top everything off with a peak from your intensity curve. What you have to do, basically, is mixing a great cocktail that is representative, engaging, and accessible.

Don’t take these decisions lightly. As in scientific research, you will learn nothing from an ill-chosen sample. And as with portfolios or excerpts, a well-chosen or ill-chosen sample can make the difference between acceptance and failure.

Finally, before you start, don’t forget to nail down all the rules and values that you need for your digital prototype, from avatar speed to jump parameters to terrain effects, and so on. The same rules that apply to building a level, as touched upon in the Process phase’s rules section, apply to building a digital prototype. For an introduction to prototyping that is far more in-depth than what fits into this treatise, Jeremy Gibson Bond’s Introduction to Game Design, Prototyping, and Development is highly recommended, both for paper prototyping and for digital prototypes.

Fig.5.1 Prototype Setup
Fig.5.1 Prototype Setup

Now, build your prototype!

In the following two beats, you will learn how to test your prototype and how to prepare both your prototype and your test results for your pitch presentation.