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 download store for role-playing stuff in existence and you’ll probably end up buying much more than just your copy of Ludotronics. Which would benefit game designers everywhere!

Why not Amazon? For one, illustrated non-fiction isn’t well-suited for the Kindle format. Also, at a €14.99 price point, Amazon’s cut amounts to €9.75. Well, no.

Level Two: Interactivity

Process Phase Level Two

Beat 5. Readiness

From Skills to Challenges

The second part from the preceding Beat 4. Representations revolved around the representation of player input in your game world. This input has to be learned somehow, no matter how realistic or abstracted it might be. Thus, your follow-up challenge in this beat is to tailor your game’s learning conditions to your target audience and to the challenges that your game will provide.

We can break learning conditions down to six essential elements:

  • What are the skills that your player must develop to beat your game or play it well?
  • How hard is it to start playing and enjoying your game?
  • Will getting better at some point become impossible or no longer make a difference?
  • How are your learning events distributed over the course of your game?
  • Can the player tailor your game’s difficulty conditions to their needs, and how?
  • Can the player tailor your game’s density conditions to their needs, and how?

We will call these six conditions the skill spectrum, skill threshold, skill maximum, skill progression, difficulty preferences, and density preferences, respectively.

We will discuss all six conditions in this beat, divided in three major parts. First, we will start with the first condition, the skill spectrum, and look at its constituents typology (learning outcome), taxonomy (learning organization), and, to a degree, task (learning opportunity). Then, we will examine the next three conditions together, the dynamic triad of skill threshold, skill maximum, and skill progression. Finally, we will discuss the remaining two conditions, difficulty preferences and density preferences. For the former, we will revisit our design pattern of the concurrent escalation of risk, relief, and reward; for the latter, we will introduce the design pattern of plot, prompt, and proximity.

Fig.4.22 Learning Conditions Model
Fig.4.22 Learning Conditions Model

Let’s begin with the skill spectrum. For every game, the player has to bring a range of skills to the table. Most of them go unnoticed. Among those that go unnoticed, for example, are being able to read, make deductions, recognize various patterns, use a mouse or a controller, differentiate colors, understand a language, and so on. Also, often particular to what’s misleadingly called “genre,” there are numerous conventions the player must have an idea about, from the concept of power-ups in first-person shooters to the pretzel logic of puzzles in classic adventure games. For your game, you should have a fairly good idea about its presuppositions in terms of skill requirements already because you should know your target audience.

These requirements, though, are not what a game’s skill spectrum is about. The skill spectrum is about the range of skills your player has to develop over the course of the game to beat your game, or play it well. Remember, your game is the learning experience that your player needs in order to play your game! Not counting general physical or intellectual fitness training and a few esoteric exceptions, players don’t train for a game outside of the game, and that includes practicing moves and combos or practicing against the game’s AI, like bots. The game is the training! (Which is one of several reasons behind humankind’s preoccupation with games in the first place.) And what the player will be practicing during the game and throughout the game in order to beat the game or play it well, that’s the skill spectrum. And this skill spectrum shouldn’t come about haphazardly according to what gameplay happens to demand at any given moment, no. It should be meticulously planned.

This comprises planning for three different areas:

  • Typology (learning outcome)
  • Taxonomy (learning organization)
  • Task (learning opportunity)

Typology and taxonomy will be discussed right away. The task element will follow in Beat 6. Reveals where we will convert learning opportunities into physical, cognitive, and empathic tasks (and also touch upon similar approaches like rational level/game design’s triad of physical, mental, and social skills). Our design progression from learning outcome to learning organization to learning opportunity might seem puzzling at first, but it’s the most systematic approach to designing interesting and relevant challenges for your players.

A more intuitive and probably more common approach, in contrast, might look like this. Imagine you have your setting, your characters, your principal story line and a handful of plot points, a rough ensemble of acts, sequences, and levels, and your game loop and its associated game mechanics. Now you start creating unnecessary obstacles, the challenges. (Challenges in games are unnecessary obstacles by design; following Bernard Suits in The Grasshopper, unnecessary obstacles are even a necessary condition for a game to be a game in the first place. We will come back to them in Level Six: Integral Perspectives II.) Let’s say that there’s a plot point in your story where the player character must acquire an item, and you begin to pile on obstacles in correspondence with your game loop elements and game mechanics. You put that item in a cave where it’s hard to find, a ferocious mountain torrent between the player character and the cave, and an acutely ill-tempered bear into the back of the cave. Is this how you should proceed?

You could, but there’s a better way. Let’s rewind and start from scratch. You have your provisional setting, characters, story line and a handful of plot points, a rough ensemble of acts, sequences, and levels, your game loop and its associated game mechanics. Then, you have your theme, which is “negotiation,” together with all its motifs, and you have your design-driven goal from the Procedure phase’s Level Three: Tracing the Goal with its growth, insight, and experience elements.

Your first task now is to sketch out everything that the player must learn over the course of the game to achieve your game’s design-driven goal. These are your game’s learning outcomes, and you should categorize them as either skill, knowledge, understanding, or attitude change (more on that in a minute). Then you take each outcome and break it down into manageable learning objectives, with or without the help of a learning taxonomy (also discussed below). Next, you take these learning objectives, which is in effect everything the player has to learn while playing your game, and distribute them piece by piece—skills, knowledge, insights, attitude changes—across your rough draft of acts, sequences, and levels. Finally, you turn these pieces into challenging tasks so that each is a perfect fit for its respective learning opportunity, and assign them to specific beats.

Let’s go back to our example and imagine the following setup. The boss enemy at the end of your level is an earthquake. To survive that earthquake, the player/player character must be able to negotiate treacherous, collapsing pathways across and between buildings (cognitive/physical task), climb a steep precipice while dodging boulders and nasty showers of pebbles (physical task), and persuade an irascible harpy at the top of the cliff to pick them up and take them to safety (empathic task). Now that you know what your player must be capable of by the end of that level, you can distribute your tasks as learning opportunities toward these exact capabilities. For the plot point from our example, let’s keep the torrents, the cave, and the bear for simplicity’s sake, but design their actual challenges with these learning opportunities in mind. The player might have to negotiate a collapsed bridge construction to overcome the torrents (cognitive/physical task), cool down the bear (empathic task), and climb to the top of the cave to retrieve the item from a barely accessible niche (physical task).

If you use your learning outcomes and follow these patterns instead of pulling obstacles and challenges out of thin air, you can always make informed design decisions about what to put in the player’s path and why. What’s more, you can use these learning outcomes and these design pattern to create a killer level for your prototype, and later rework and refine everything during development, together with your level design team.

Now let’s take that detailed look, as announced above, at our typology and taxonomy structures. Everything that the player has to learn over the course of the game are this game’s learning outcomes, and you should structure these learning outcomes in useful and practical ways. To do that, you should classify your outcomes according to a qualification typology. You can make up your own typology, but the typology the Ludotronics paradigm works with distinguishes between skill, knowledge, understanding, and attitude.

  • Skill as a repeatable, observable performance.
  • Knowledge as being able to recognize and recall facts and procedures.
  • Understanding as grasping complex processes and being able to apply knowledge in new and different contexts.
  • Attitude as changed or adapted behavior based on increased skill, knowledge, or understanding.

This set is loosely based on a variety of qualification typologies including so-called “KSA” models (knowledge, skill, attitudes or, more often: abilities), but reworked and broadened to dispel the rather limiting clouds of immediate workplace utility. Skills comprise proficiency, expertise, competence, and similar. It is not the same as knowledge. You can have knowledge about something without being able to apply it, and you can be skilled at something without knowing how it works. You can be skilled at something and know how it works, but you don’t understand the underlying principles that would enable you to apply your skill and knowledge in different contexts and circumstances. You can be skilled at something and know a lot about it and understand the underlying principles, but you do not act on it or adapt to it by changing your attitude—your approach, mindset, perspective, or character if need be.

Here’s an example. You’re a good long-distance runner, that’s skill. You learn how to train, do exercises and workouts, all in the right order, and prepare for races so you can run faster and farther, that’s knowledge. You acquire insights into the mechanics of running and the complex physiological processes of your body so that you can avoid burnout and injuries, tackle shorter distances, or pick up other sports related to running, that’s understanding. You resolve to train hard and eat well every day, and you keep that up, that’s attitude.

Importantly, though, don’t try to slice everything your player has to learn into all four types. Not every skill needs knowledge, not every skill or knowledge needs understanding, not every attitude change has a skill attached to it, and so on. You can be great at repairing warp engines without changing your attitude, and you can resolve to eat well without understanding the intricacies of nutrition.

Concerning the nature of knowledge and understanding, there are two possible sources of confusion: the difference between recall and recognition on the one hand, and the difference between procedures—which belong to knowledge—and processes—which belong to understanding—on the other.

If you can come up with a certain actor’s name at a party or remember someone’s street address, that’s recall. If you can’t remember that actor’s name or your friend’s street address, but you immediately know it’s the correct one when you see it or hear it, that’s recognition. In general, you can recognize far more things than you can recall. If your exam preparations are focused on recognition, and that’s more often the case than you think it is, you will have a rude awakening during the test when you try to come up with answers that necessitate recall. Except when it’s a multiple-choice test. Then, recognition will serve you well, provided it’s sufficiently granular. If you design cognitive challenges of any kind, popularly known as puzzles, mind the difference! Should the player be able to recall a vital piece of information, perhaps nudged by a subtle clue? Or does it suffice if they recognize a piece of information that is dangling before their nose? Both recognition and recall have their place. Always be aware of their difference!

Similarly, you should always be aware of the difference between procedures and processes. In its most basic form, a procedure defines a sequence of steps, nothing more, nothing less. If you follow a cooking recipe, that’s a procedure. Your knockdown furniture’s assembly instruction sheet is a procedure. A military chain of command is a procedure. You don’t let the chicken simmer for two hours after you removed its skin and bones, you don’t tighten the screws before you insert the dowels, and you don’t report the latrine malfunction to the Chairman of the Joint Chiefs of Staff even if you think it will prove decisive for the outcome of the war. (Unless perhaps you’re at least a major general or rear admiral yourself.) Procedures can be mind-numbingly mundane or mind-blowingly intricate—neither difficulty nor complicatedness are defining attributes.

While the nature of procedures is comparatively easy to explain, the nature of processes is a whole different beast. There’s a reason why it doesn’t belong to knowledge, but to understanding!

If you search for definitions, most of what you will find are variations on two themes. A process is either a set of interacting, interrelated activities to create a desired result, or a process uses, converts, or transforms inputs to create a desired output. None of them is particularly convincing, or helpful.

To start with, procedures have outputs too, because outputs are the very idea of procedures. That’s certainly not a differentiator. Then, by and large, processes outside standardized ISO definitions have no “teleological” superstructure; biological, chemical, social, psychological, mental, or evolutionary processes do not have a “goal” or a “desired output” in that sense. Finally, the primary “output” of many processes is the process itself, while all other outputs, ranging from waste heat to self-aware human beings, appear as collateral benefits or collateral damage, depending on how you look at it. And even these “collateral” outputs are not necessarily predictable in the sense that their output can be deduced from the input. Then, what about legal processes, economic processes, or the scientific process? Indeed, they have tangible outputs like court decisions, gross domestic products, and knowledge. But in contrast to procedures (legal procedures, customs procedures, clinical trials, and similar), these processes’ primary concern is to keep the process itself alive and running: the legal system, the economy, the scientific endeavor.

With that and a reasonable distance to procedures in mind, we can at least say this much:

  • Processes have a complexity threshold. A process will cease to be a process when it falls below a certain level of complexity.
  • Processes are continuous, time-sensitive, and timing-sensitive. They are vulnerable to, and need to be prepared for, disruptions and interruptions.
  • Processes are both inevitable and necessary for non-trivial systems. Systems evolve with and through processes and cannot exist without them.

If you know and understand the difference between procedures and processes, you can utilize it for all kinds of challenges.

The most popular cognitive challenge design is to create procedures that the player then has to crack. Actions have to be carried out in certain ways and in a certain sequence. Time sensitivity might be involved, like timing-sensitive cause-and-effect puzzles in Tomb Raider, but it’s still a procedure. (Having to cook, boil, and simmer ingredients at different stages for specified amounts of time doesn’t turn your cholent recipe into a process.)

But, for example, to make complex and often momentous decisions in games like Mass Effect and its sequels, the player must understand a whole lot of processes, not just procedures. (Often enough, following procedure isn’t Shepard’s strong suit anyhow.) The player must understand, for example, the vital processes of an alien civilization—its cultural, legal, and military organization, and each process’s strengths, vulnerabilities, sensitivities, and potential loopholes. Without an understanding of these processes, the player can’t make productive decisions. This is true for many games that are strong on player choice in this department, with The Witcher 3: Wild Hunt as another prominent example.

As an aside, what sets this Process phase of the Ludotronics paradigm apart from its preceding Procedure phase mirrors some of these distinctions. Sketching the game’s theme, its motifs, and its design- and desire-driven goals is a much more “procedural” activity than sketching the whole game across its four territories Interactivity, Plurimediality, Narrativity, and Architectonics with all their mutual dependencies and requirements. Also, the end product of the latter is a fairly complex system most of the time, whereas the end product of the former is not.

Now, your game can offer the player a balanced cocktail of learning outcomes with skill, knowledge, understanding, and attitude ingredients. But that’s not necessary. Indeed, it’s rarely the case! The reason is that learning outcome types hook into a game’s core dimension and contribute to its playing experience in different ways. Thus, depending on game type, some learning outcomes are better suited than others. Let’s parse our learning typology once more to see where outcomes fit best:

  • Skills as repeatable, observable performances are often at the center of games with a ludological core, from arcade games to first-person shooters to simulations to party games—most often consisting of dexterity, accuracy, quickness, speed, timing, or stamina outcomes and combinations thereof.
  • Knowledge s the ability to recognize and recall facts and procedures is especially relevant for games with a game-mechanical core, from chess to match 3 to strategy, 4X, or building/resource management games. The player has to recall many facts and facets from the game’s rule set; recall and recognize a sufficiently large set of procedures like openings or combinations.
  • Understanding as the ability to comprehend complex processes and apply skills or knowledge in new and different contexts is a great asset for games with a narratological or a cinematological core to follow a plot or artistic patterns—from adventure games of all kinds to role-playing games to exploration games and visual novels. But a deep understanding of processes is also an asset for games with a game-mechanical core that have emergent properties and allow complex player input, like multiplayer strategy games or the game of Go.
  • Attitude as a change in behavior based on skills, knowledge, or understanding is applicable to all four dimensional cores; a game can demand attitude changes toward patience, self-discipline, team play, fairness, decisiveness, diplomacy, steadfastness, and so on, but also toward negatively connotated attitudes like ruthlessness and deceptiveness.

None of this is set in stone, though. Don’t let it keep you from doing things differently! All four types work great with all four dimensions. Your design decisions should always depend on your game’s target audience, its value characteristics, and its theme. They should not be based on game type.

Now that you created your sets of desired learning outcomes, do you really need to organize them further into a taxonomy, as the Ludotronics learning conditions model suggests?

No, you don’t have to. But it can enrich your game’s skill spectrum in ways you wouldn’t have thought of without it. Or, you can even make your game taxonomically complete.

There are many excellent taxonomies available for the cognitive, affective, and sensory domains (check Level One: References in the Postmortem phase for Anderson, Bloom, Harrow, and Krathwohl entries). But these are generally better suited for designing school curricula than for designing games (except so-called serious games, where you will definitely need them). Instead, we will use Howard Gardner’s Frames of Mind taxonomy that is simpler and easier to apply. It’s a model embroiled in disputes about the meaning and definition of empirical evidence, but, like other, simpler models we have adopted elsewhere, it is well-suited for our purpose of designing games. (Also, Howard Gardner is a frequent collaborator with Csíkszentmihályi Mihály, and that should count for something.)

Compiled from several of Gardner’s publications and leaving out some stuff that he himself calls experimental, our model comprises the following “intelligence domains”: linguistic (verbal) intelligence; musical intelligence; logical-mathematical intelligence; spatial intelligence; bodily-kinesthetic intelligence; interpersonal (social) intelligence; intrapersonal intelligence (understanding of self); and naturalist intelligence (the capacity to make consequential distinctions).

These eight domains are more than enough to inspire ideas. They also cover enough terrain that we can call a game taxonomically complete that requires the player to learn something from each domain to win or beat that game or play it well.

As an example, let’s make high-level sketches for both steps, typology/outcome and taxonomy/organization, with the help of our third-person action-adventure game against the backdrop of the French Revolution from the Procedure phase’s Level Three: Tracing the Goal. Our high-level sketch of the game’s learning outcomes could include elements like this:

  • Dexterity-based skills for action elements and cognition-based skills for puzzle elements.
  • Knowledge about different forms of identity and their respective historical contexts and developments in the eighteenth century.
  • Understanding the nature of identity, the formation processes of identities, what identity means in different contexts at different times for different people, and its resilience or mutability.
  • Attitude changes toward the player character’s own identity and toward other forms of identity represented by non-player characters.

For the second step (which is by no means mandatory, as a reminder), the first thing you would do is consulting the taxonomy and check your typology against it.

What our typology sketch already covers are the spatial, bodily-kinesthetic, interpersonal, intrapersonal, and naturalist domains. Which, come to think of it, is a lot! What’s missing are the linguistic, musical, and logical-mathematical domains. Could the game become more interesting and enjoyable if we implemented some of those too?

A little research and brainstorming goes a long way. Rhetorical skills and speeches are important characteristics of the French Revolution. What if the player character needs to become a better, more convincing speaker or writer? After all, Thomas Paine is their friend! What about the composition of the Marseillaise? Maybe the player character must learn the melody by ear from Rouget de Lisle, as contraband, when they share a prison cell together in 1793. Also, what if the player character at one time has to assist Lazare Carnot—who had studied with Benjamin Franklin and could plausibly be introduced by Paine—to solve applied math problems for the Ministers of War?

To repeat, you can use any learning taxonomy you like as the foundation for a taxonomically complete or near-complete skill spectrum. Gardner’s Frames of Mind model is just a suggestion. But it is a model that’s neither too simple nor too complex, and it will get you off the ground in no time.

Now that you created both your learning outcomes and your learning organization—what the player actually and specifically has to learn in terms of skills, knowledge, understanding, and attitude to beat your game or play it well—you need to take each learning outcome and transform it into a string of increasingly difficult challenges that you can then distribute across your game. These challenges, which we will call physical, cognitive, and empathic tasks, will be the central topic in Beat 6. Reveals, this level’s next and final beat.

Let’s turn our attention now from the first condition, the skill spectrum, to the dynamic triad of the second, third, and fourth condition: your game’s skill threshold, skill maximum, and skill progression.

Their associated design parameters are how hard it is to start playing and enjoying your game; if there’s a point at which getting better becomes either impossible or no longer makes a difference; and how hard it is to get better at playing your game.

There’s a mantra that threads all three conditions together. It’s called “easy to learn, hard to master,” known as Bushnell’s Law or Bushnell’s Theorem. You’ve certainly heard of it. According to Blizzard’s co-founder Mike Morhaime, this mantra is part of Blizzard’s core values, for example (as expressed in Dean Takahashi’s VentureBeat anniversary interview). While it has the potential to provide excellent advice to design your difficulty conditions, we have to deconstruct it first. In other words, we need to take it apart and put it together again in a way that is applicable to the types of games we’re talking about, not the type of games that Nolan Bushnell was talking about.

“Easy to learn, hard to master” is attributed to Nolan Bushnell in or around 1971, but it can’t be traced back to an original source. The quote in its entirety has been handed down like this: “All the best games are easy to learn and difficult to master. They should reward the first quarter and the hundredth.” Quarter? Yes, we’re in arcade territory! A place and time when, from the design perspective, the goal of a game was to get the player to insert another coin, which should give us pause. It also gave Ian Bogost pause. In his Gamasutra feature article “Persuasive Games: Familiarity, Habituation, and Catchiness,” he argued that we should abandon this “easy to learn, hard to master” creed altogether. While his arguments are compelling, let’s try to steer Bushnell’s law in a different direction, to liberate it from its historical ballast and salvage it for our purpose of creating great games.

Arcade games are still around, but their true heir are free-to-play games with in-game purchases. Free-to-play is a business model that has become more and more sophisticated over time. There was a seismic shift in 2013 when Wargaming abandoned the pay-to-win model, and many others followed suit. Still, there’s a lot of arguing going on how one should define “to win” and how a game like League of Legends isn’t simply obscuring pay-to-win elements, but we can at least say that at this point in time, naked pay-to-win is dead for mainstream games. (Underneath that surface, though, billions of dollars are made by pay-to-win games that you might know only from fantastically implausible banner ads on those websites that you visit at your own risk; for particulars, read Robert Zak’s “Playing the Games Found Behind Clickbait Adverts.” By now, the perhaps most successful studio behind those games belongs to, yes, the world’s second-largest gambling machine manufacturer.)

This shift notwithstanding, F2P games are structurally related to arcade games. Both types of games are focused on one thing, and one thing only: retention. Retention is what keeps the stream of quarters running, retention is what positively affects the probability of in-game purchases over time. It is true that retention in arcade games affects the revenue stream directly, while retention in F2P games affects the revenue stream only indirectly. But retention is still the primary revenue engine in F2P. With incredibly high adoption rates triggered by marketing budgets that go berserk at launch, even the slightest increase in retention positively affects the revenue stream, thanks to the power of statistical modeling.

Now, if you want players to keep playing your game, provided it’s not an arcade or F2P game, you aim at making it as interesting and enjoyable as possible, and player success as rewarding as possible. But with arcade and F2P games, you want your players to always spend money, so that formula alone no longer works. To get the player to insert another coin or buy items or time as often as possible, forced failure must be part of your formula. And when your game works with forced failure, it needs different reward structures, among them types of behavioral modeling that keep your players grinding on with well-placed soul-crushing obstacles, intermittent rewards, improbable numbers of near-misses, and other potent mechanisms that can push your game over the line and lead your players from gaming as a sports or pastime activity into the realm of gambling and addiction. To create the math behind all this is challenging and beautiful, but its effects can become ethically dubious and corrosive.

Not counting infernal monetization rackets like loot boxes (which, owing to gambling law regulations, thankfully seem to have run into a wall shortly after inception), regular games that are neither arcade nor F2P do not need this kind of behavioral modeling to keep their players playing. It’s here where we can grant Bushnell’s “easy to learn, hard to master” a fresh lease on life. Instead of behavioral modeling that keeps the player playing from their first coin to their hundredths, we can make it to mean the following: that the player can enjoy the game from the very first moment, and that the challenges match player growth in just the right way to make it harder and harder, but also more and more rewarding, to win the game, beat the game, or achieve true levels of mastery.

Sometimes, there are people who think that all this isn’t benign either and just another form of addiction. In a way, that’s not so far off the mark. After all, it’s the same hormone system that gives you those reward shots that feel so great, regardless of how they’re triggered—as a reward for a learning experience or as a reward for successfully navigating behavioral design patterns. But then, children are relentless learning machines because of it; the internal rewards for learning experiences are so enjoyable that it’s impossible to keep children from learning. It’s just that most societies model advanced learning in such ways that shift these internal rewards toward external rewards like grades and report cards and recommendations for standardized learning outcomes, with deleterious consequences to the joys of learning. It’s no coincidence that playing, from sports to video games, counts among the very few areas where people are still able to perceive and relish the learning experience itself as a desirable reward. So yes, learning is addictive in principle. But we still have to encounter a civilization that collapsed because too many of its citizens enjoyed learning too much.

That should suffice for the historical and behavioral underpinnings of our skill threshold, skill maximum, and skill progression triad. Let’s have a look now at each of them in more detail, beginning with the skill threshold.

The skill threshold, also called skill floor, determines how hard or how easy it is to start playing and enjoying your game. “Hard” or “easy” means two things in that context: the game can be accessible/inaccessible in terms of difficulty and it can be accessible/inaccessible in terms of familiarity (adopting this term from Ian Bogost’s article referenced above).

Of familiarity, your game should take care by design. Based on what you know about your target audience, it should follow Jean Piaget’s Moderate Novelty principle and Raymond Loewy’s MAYA principle, Most Advanced Yet Acceptable, as discussed in the Preparation phase’s Level Six: Capture the USP. Later in the game, when your player needs to learn more and more stuff that’s unfamiliar, these principles should still be in effect.

Difficulty is another matter. To approach it, let’s view it not from a beginner’s perspective, but from a pro’s. If your target audience consists of experienced players, would it be okay to design the game with a skill threshold that makes it barely accessible, perhaps inaccessible, for less experienced players? With the right target audience, such a strategy might not sound unreasonable at first. After all, you don’t want your game’s early levels to be boring!

There is a well-developed niche for games with merciless skill thresholds, like Dark Souls or, more recently from the same developer, Sekiro: Shadows Die Twice. But outside of that niche, it’s almost always a mistake. First off, it won’t win over players who are curious and might become part of your target audience if your game gave them a chance. Then, the difficulty in most types of games cannot become arbitrarily high over the course of the game, so if you raise your game’s threshold difficulty, you will have to flatten difficulty and learning curves later. That way, you will lose less experienced players early and more experienced players later. (You can make your game shorter instead if it rhymes with expectations.) In multiplayer games where the difficulty can indeed become arbitrarily high, vast disparities in skill level will develop even between experienced players so that the original threshold problem can’t be solved by raising the difficulty in the first place.

At the end of the day, it’s always better to make your game’s initial difficulty accessible for beginners.

In multiplayer games, you can go about it in several ways. One way is to design your game with a handicap system that allows players from every level of expertise to enjoy playing against each other. Another way is to equip less experienced players with the means to earn a few achievements early on. In arena shooters, for example, you can implement one or more “spammy” weapons that cannot but score from time to time. (There will always be a number of more experienced players who clamor to have them nerfed, but don’t let that deter you.) Also, you can employ matchmaking, even if the process of running matchmaking protocols and servers will give you serious headaches in return. (Back when every player with a copy of the game and a broadband connection could host a multiplayer game over the web, it worked just fine without matchmaking because players naturally flocked to game servers that suited them, and they were well-versed in differentiating between offerings advertised as n00bserv or {{{1337}}}_SniperCity.) These are only the most obvious solutions, so use your imagination.

For all other games, you can solve the threshold problem with just one rule: you should make your opening levels not difficult, but interesting.

If you keep that rule in mind, together with the rules of familiarity discussed above, your game’s skill threshold should do just fine.

Next, there’s your game’s skill maximum, also called skill ceiling. It decides whether or not, at some point, getting better becomes impossible or no longer makes a difference. For that, we need to differentiate between four basic game types.

The first type are multiplayer games, from Go or chess to anything from shooters to strategy to simulation games. For these games, the allowed input complexity from players is very high and might even be arbitrarily high, as discussed in Beat 2. Reactions. Thus, these games do not have an inbuilt skill maximum. In old gunslinger tradition, sooner or later there will appear someone who’s even better than you.

The second type are also multiplayer games, but a certain kind of arena games where the player avatar or avatars are restricted in what they can do by design. Think League of Legends, Defense of the Ancients, or Overwatch. In such games, the skill maximum is defined in the long run by each avatar’s potential, not by the potential of the player or players.

The third type are retention games like arcade and free-to-play games, as discussed above. These are designed to become more difficult ad infinitum, but that will stop at some point for purely practical reasons. Games from this type do not have an in-built skill maximum, but they will sooner or later acquire one when they run out of new content.

The fourth type are single player games that have an inbuilt difficulty by design. These can be shooters, strategy games, action-adventures, simulations, jump ‘n’ runs, and almost anything you can think of. They all have a skill maximum above which no additional success or reward can be gained. The player cannot beat such a game better than flawlessly. (But as we know now thanks to Zero Master’s Doom II reveal, it can take twenty-four years for someone to accomplish that.)

These types cover games as designed. Not covered are ideas players come up with all the time to make games harder and more challenging in unexpected ways, like timed runs, self-imposed time limits, equipment restraints, and so on. The passion to break a game’s skill maximum in imaginative ways is strong in many players.

Your game’s skill maximum will often be defined by its type, but not necessarily. Either way, it needs some planning. What difficulty type should it be? How far can the difficulty be raised? In a game with a skill maximum, can you offer bonus content or mechanisms where players can find new challenges beyond beating the game? And so on.

Then, skill progression, the final element of our dynamic skill triad. If you think of the skill threshold as your opening and the skill maximum as your endgame, then the skill progression can be characterized as your long, long middle game. Its core question—how learning increases with playing over time—is essentially a question about learning curves. Your game must get its learning curves right in order to become a great game. For each learning outcome from your skill spectrum, you must develop a good idea about how long this will take your players to learn, and in how many increments. Without that, you won’t be able to coordinate and synchronize your game’s learning experience with its playing experience.

Learning curves have a scientific meaning and a popular interpretation. Scientifically, a steep curve means “rapid learning progress.” In popular interpretation, a steep curve means “learning is hard and brutal.” You should be aware of both meanings and, in a manner of speaking, work with both.

Fig.4.23 Learning Curves
Fig.4.23 Learning Curves

The questions you have to answer are these:

  • For each learning outcome: into how many increments can it be broken down?
  • For each learning increment: how long will it take the player to learn?
  • For each learning experience: what kind of playing experience is the best fit?

What each increment means depends on the nature of the learning outcome it belongs to (your typology) and, if you have one, its place in the learning organization (your taxonomy).

At its most basic, an increment can be any of the following: mastering a new mechanic; mastering a new combination of established mechanics; mastering a new puzzle type; mastering a new combination of established puzzle types; gaining and being able to recognize a certain piece of knowledge; gaining and being able to recall a certain piece of knowledge; gaining insight into a plot point or a story development; gaining a non-player character’s trust; understanding a non-player character’s motives; adopt or abandon a certain strategy; adopt or abandon a certain attitude; and many more.

For your proposal, you can sketch these increments by following your own experiences and making reasonable assumptions on that basis. Later during development, though, you should rework your map empirically and scientifically. For example, you can follow the aforementioned approach of rational level design or rational game design, whose origins are somewhat hard to pin down, but a lot of work seems to have been done by developers at Ubisoft. Following this approach, you “atomize” each learning outcome into its smallest constituents and create learning curves based on empirical data and math. Your go-to sources should be Luke McMillan’s Gamasutra feature article “The Rational Design Handbook: An Intro to RLD” and Chris McEntee’s “Rational Design: The Core of Rayman Origins,” also on Gamasutra (plus, for good measure, Raph Koster’s blog post on why “Tools Don’t Stifle Art!”).

But beware, not everything can be broken down into increments, and not every increment is easily digestible. (Rational level/game design accounts for that, so don’t worry.) For a variety of skills from art to math to programming, there exist “Every x Tutorial Ever” cartoons where each step but the last looks ridiculously easy, but the last one displays, out of the blue, a preposterously perfect professional result. It’s funny, it’s hyperbole, but there’s some truth to it. To reach professional levels, no matter for what, there will almost always appear obstacles out of the blue that can only be overcome by executing and mastering many different elements at once. Thus, not all increments should or can be alike. From time to time, there will be increments that pose formidable challenges to your players. These need more time to learn and provide a different playing experience. These should also, how could it be otherwise, correspond with your dramatic structure in ways that make sense! It doesn’t always have to come down to boss fights, by any means. But boss fights are always a good default place because the player is expecting a formidable challenge and is prepared.

In other words, your learning curves will never be perfectly smooth. Nor should they! If you remember the “spikes” from the extended flow model from this level’s Opening, your learning curves should not increase continuously, but display up-and-down patterns. That way, your player can experience phases of stress and fiero and phases of relief and control as well.

Eventually, only you can know how your game’s ideal learning curves should look like—dependent on your game type, your core idea, your skill spectrum, your target audience, the number of levels, and the game’s overall length, to name just a few parameters. For free-to-play games, for example, the occasional unbelievably steep mountain (which, in scientific terms, corresponds to an endless barren plateau) is a frequent design choice that makes perfect sense. In general, by distributing your challenges and sculpting your learning curves across levels, sequences, and acts, you should always follow the imperative of variatio delectat by delighting the player with variety.

Our final topic in this beat are the two preference types that provide your player with options to tweak your game’s learning curves to their individual needs: difficulty preferences and density preferences. Both are vital to enable the player to stay within their flow channel, as discussed in this level’s Opening. Here’s what they do:

  • Difficulty preferences make it easier or harder to start playing and enjoying your game; they raise or lower the skill levels necessary to enjoy your game and beat it or play it well; they lower or raise the game’s skill maximum; and they stretch out or compress learning experiences.
  • Density preferences control the frequency of challenges through shortening or lengthening the time between their occurrences; they control the number of challenges that occur simultaneously at any one time; and they stretch out or compress learning experiences.

Just like the playing experience, your game’s learning experience needs to be flexible. A player might love to put the pedal on the metal and encounter more and tougher enemies faster. But the same player might need to relax a bit between cognitive challenges, like puzzles, and need even more time between empathic challenges, e.g., interactions with NPCs that require decisions. In other words, your difficulty and density preferences should be able to accommodate different playing styles.

No two games are alike, so there are no master keys for the design of difficulty or density preferences. To get started, though, there’s no shame in letting the player simply choose from a well-designed and well-stocked set of difficulty settings. You can even let the player set the difficulty for different kinds of tasks, like physical tasks or cognitive tasks, as Shadow of the Tomb Raider does. These difficulty settings, in turn, don’t have to be static; some dynamic difficulty adjustment within each difficulty setting could be involved. But be careful with DDA. Players are a clever lot, DDA isn’t too hard to spot, and they will game the system whenever they can. Also, make sure there’s a mechanism in place that controls and recognizes DDA as a confounding variable. Only then can your game keep track of, and communicate, each player’s true achievements and keep bragging rights intact.

Still, overall difficulty settings and even clever DDA are very crude tools, each in its own way, and you should always try to design more sophisticated means with which, knowingly or not, players themselves can control difficulty and density during play. While you have to find your own creative solutions, there is a handful of general principles you can work with.

For difficulty preferences, a general design principle that puts players in control—especially in control of their flow channels—is to design the game’s challenge structure in such a way that it concurrently escalates risk, relief, and reward. This has already been discussed in this level’s Opening, but a refresher won’t hurt. Are you, the player, willing to jump down that suspiciously ladderless manhole for extra loot or a rare power-up, and risk falling into toxic sludge instead of hitting that laughable excuse of a maintenance catwalk? Greater risks that experienced players are willing to take are met by greater relief like health or ammo and greater rewards of any kind (rewards as such will be discussed in-depth in Level Six: Integral Perspectives II). This can be supported by offering the player a choice between different game mechanics to meet that challenge.

Fig.4.10 Concurrent Escalation Principle
Fig.4.10 Concurrent Escalation Principle

Again, think Mario and Mario-related games that make use of these principles all the time. Or think open world games where certain areas are more dangerous than others, cleverly communicated so that the player can make informed choices as to where to go, and when. Moreover, there could be secrets and secret areas that the player can only find and unlock above a certain skill level. And so on. Regardless of how you handle it, you should always aim at providing a joyful and satisfying playing experience not just to your ideal player, but to fast learners and slow learners and players with different levels of expertise alike.

Lastly, density. Before you can design your density preferences and give players a say in how often challenges occur and how many at once, you need to exorcise every incarnation of the abominable “x seconds” rule that has patrolled the marbled hallways of game design for far too long.

It’s a rule that makes about as much sense as its dreaded cousin in the realm of dropped food. Players should at least be given the option to contemplate and explore, to savor sights and digest plot points, to process emotions and stress-test controls. Similar to difficulty preferences, there is a design pattern that gives players some basic control over their density preferences: plot, prompt, and proximity.

Plot means that a challenge is triggered when the dramatic structure calls for it, which might or might not be caused by the player’s actions. Prompt means that an impending challenge is signaled by hints or cues, and the player can respond when they’re ready. Proximity means that a challenge is triggered when the player moves toward it.

The latter, famously employed in Half-Life and outlined in Ken Birdwell’s illuminating Gamasutra feature “The Cabal: Valve’s Design Process for Creating Half-Life,” lets players control density through self-confidence. If the player moves slowly and cautiously, challenges are triggered one at a time. If the player moves fast and aggressively, multiple events are triggered in rapid succession.

Fig.4.24 Density Preference Patterns
Fig.4.24 Density Preference Patterns

As always, you have to find your own creative solutions. But you don’t have to start from scratch: these patterns and principles will give you a head start.

If you have a lavishly designed skill spectrum with a great selection of learning outcomes, a skill threshold and a skill maximum that make sense, great learning curves, and a number of options to give your player some basic control over how and when challenges occur, then you have all you need to make your game interesting and engaging from the first beat to the hundredth.