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 6. Reveals

From Types to Tasks

In this level’s final beat, we will discuss tasks. After typology as learning outcomes and taxonomy as learning organization, tasks as learning opportunities through challenge are your skill spectrum’s third and final constituent.

Every task thrown at the player must be solvable in principle by the player—that’s the basic nature of gameplay. But solvability isn’t the only requirement for good task design, as will be seen. Also, while every challenge is a task, not every task needs to be a challenge. You can task the player with non-challenging busywork, for example, as touched upon in Level One: Integral Perspectives I and Level Six: Integral Perspectives II. Or you can employ participatory play as taskless play, a major topic in Level Five: Architectonics. In this beat, though, we will only talk about tasks that involve challenges and compel the player to learn.

Not all tasks are created equal. Once more, for the purpose of designing games, we will simplify shamelessly and differentiate between three basic kinds of tasks: physical tasks, cognitive tasks, and empathic tasks. Before we look at them in more detail, let’s map them to our learning typologies, as discussed in the previous beat.

  • Physical tasks are primarily connected to skills and knowledge and require control, coordination, and endurance. A physical task can be to defeat an enemy in combat; jump from one moving platform to another; or steer a vehicle through an obstacle course.
  • Cognitive tasks are primarily connected to knowledge and understanding and require memory, analysis, and evaluation. A cognitive task can be to find a way to open a locked door without brute force; line up a row of symbols in the right way to open a crypt; or figure out how to move one’s troops to outflank an opponent.
  • Empathic tasks are primarily connected to understanding and attitude and require cognitive, emotional, and compassionate empathy. (Their respective differences in a nutshell: grasping someone’s emotional state; feeling with that person; doing something about it.) An empathic task can be, over and above purely strategic reasoning, to grasp a character’s motives or intentions or disposition in general and act accordingly; decide which party to join in a conflict; or weigh the consequences of one course of action against its alternatives.
Fig.4.25 Task Model
Fig.4.25 Task Model

This model is not altogether different from the triad of physical, mental, and social tasks that the rational level/game design approach works with, as mentioned in the previous beat. But the methodology is different. While rational level/game design focuses on skills, the Ludotronics task model focuses on tasks. As discussed in Beat 5. Readiness, our focus on tasks allows us to break skills down into its components skill, knowledge, understanding, and attitude. Then, while we can treat physical tasks and physical skills as compatible for all practical purposes and cognitive tasks and mental skills as comparable, the ideas behind empathic tasks and social skills are quite different. Beyond how we use them in this beat, moreover, the special nature of empathic tasks also informs an important design approach for dramatically complete games in Level Five: Architectonics. Nevertheless, don’t let that keep you! Rational level/game design is an excellent methodology that you can and should work with if you want to, especially during actual development.

Which leads us back to the concept of flow and the general principle that the motivation to play equals the motivation to learn. The moment you take learning out of the equation, physical tasks become player interactions, cognitive tasks become puzzles, and empathic tasks become interactive storytelling. While these labels certainly have their place in general discourse, they don’t provide you with a meaningful paradigm to guide design decisions. “Player interaction” is too broad, “puzzle” too narrow, and “interactive storytelling” has by and large outlived its productivity, as discussed in Level Five: Architectonics.

Regardless of type, all well-designed tasks have three mandatory characteristics and one optional characteristic:

  • Solvable means that a task’s difficulty matches the player’s present location on the associated learning curve.
  • Consistent means that the nature of the task is constrained by its immediate context and by the game’s theme.
  • Recognizable means that the nature of the task is not itself a challenge, but is either known to the player or unambiguously communicated.
  • Elastic means that the task can either be solved at adaptable difficulty levels or in different ways, not just one.

Let’s look at these four conditions in more detail.

To ensure solvability, task design should always be guided by reasonable and justifiable expectations that the player has sufficiently progressed—in skill, knowledge, understanding, or attitude—to be able to solve that task’s specific challenge. This equally applies to physical, cognitive, and empathic tasks. There’s an additional aspect involved that is intimately connected to autonomy/agency from our player motivation model: solving a task should always be indistinguishable from making a difference. In other words, solving physical, cognitive, and empathic tasks should always have consequences that matter.

To ensure consistency, any task should naturally arise from its context and be related to the theme. You can’t prevent tasks from being solved through sheer guesswork, but no task should only be solvable through guesswork. Physical tasks or empathic tasks rarely have a problem with following context and theme. Cognitive tasks, in contrast, often run rampant. A frequent problem with clever puzzles, for example, is that it’s hugely enjoyable to design them, whereas the prerogative should be that it’s hugely enjoyable to solve them.

To ensure recognizability, you should always convey to the player what a task expects them to do. Players should be able to tell what kind of task they face. That shouldn’t be a challenge by itself! Not knowing what the task exactly is leads to trial & error approaches and frustration. To prevent that, every task needs an operational frame. This frame allows the player to form a mental picture and identify the principal tools and strategies that are a match for this task. Never forget to establish such a frame! It’s easy to forget, alas, because you know exactly what the task is about. Outside of video games, puzzle collections meticulously establish the frame for each puzzle and leave no doubts as to what set of tools and strategies are needed to solve them. This should be considered good practice for video game design as well. For physical tasks, an operational frame enables the player to tell whether it’s about dexterity, accuracy, timing, about perfecting a certain interaction or combining different interactions, and so on. For cognitive tasks, an operational frame tells the player what to look for, like a missing piece of information, a certain piece of equipment, an unconventional use of a conventional object, the interpretation of a message, or the initiating action of a Rube Goldberg–like chain of events that solves the problem in deliberately complicated ways. And so on. For empathic tasks, an operational frame tells the player what exactly is at stake in terms of consequences and repercussions and scale, which often isn’t altogether clear. Without that, it’s nearly impossible for the player to run meaningful thought processes that lead to meaningful decisions.

Finally, you can add elasticity, which is entirely optional. Tasks that are designed with elasticity in mind are solvable in different ways, at adaptable difficulty levels, or both. It can mean that an opponent can be defeated with more than one strategy or that hints lower the task’s difficulty. Here’s a great example. Many history museums have a terrarium for insects that use camouflage and mimicry. It’s also packed with plants and brushwood, and visitors are challenged to spot as many of these insects as possible. Then, if these visitors get stuck or want to verify their discoveries or both, they can press a button to flood the terrarium with light of a wavelength that neither the visitors nor the insects can detect, but every camouflaged insect is marked with a tiny spot that reflects some of that light in the visible spectrum. As you can guess, this is hugely entertaining for every age group. The beauty of this solution is that these markers are so tiny that the task isn’t automatically solved by pressing the button. You still have to spot them, and you still have to identify which parts around these spots belong to an animal and which parts are brushwood! That way, the task’s difficulty “degrades gracefully” to manageable dimensions for less experienced visitors. As a game designer, you can create similar or equivalent ways to make tasks elastic instead of frustrating, by gracefully degrading their difficulty. All that without giving the solution away wholesale on the one hand, or encouraging players to fire up their second or third screen and check for solutions online on the other. But don’t rush it! Give the player enough time or even a button before you flood them with hints through NPCs or otherwise, which is one of the more annoying aspects of the hugely enjoyable games from the Uncharted series. Even better, you can give the player the choice to activate or deactivate cues, like Shadow of the Tomb Raider does.

Fig.4.26 Task Properties
Fig.4.26 Task Properties

There’s one more basic rule for task design that hasn’t been mentioned yet. It’s a negative rule, and it says that you shouldn’t design tasks with “binary” solutions that solely depend on one specific piece of knowledge or one specific insight that the player either happens to have or not. Probably the most famous binary type are riddles, and many writers on game design mention them explicitly as one of the things that you should avoid, among them Bob Bates in Game Design or Zack Hiwiller in Players Making Decisions. But, as a thought experiment, could the riddle be salvaged if it naturally arose from its context and were related to the theme, e.g., if the riddle of the Sphinx were given to the player at a multi-generational family dinner on Thanksgiving, and the game’s theme had to do with aging? Yes and no. Under such circumstances, when the solution can be found through observation and reasoning, it might be salvageable indeed—but only because it has ceased, under these circumstances, to be a riddle. In all other cases, use riddles only if you want to see all your players except one strangled and devoured by the Sphinx.

up | down


In the Interactivity territory, you learned what rules are and do, how they interact with each other and with the player, and how they can or should relate to reality and realism; the meaning and use of values and how they relate to each other and to gameplay; the demands of skill and difficulty design; and the range and nature of tasks and the challenges they represent. It’s far from exhaustive, but it should give you enough ideas to get started and sketch this territory’s game-mechanical and ludological elements.

You have to ask yourself the following questions. Do you have a good idea about your game loop and its associated game mechanics, how the rules and values will work together in your game and process abstracted player input within the game world, how the game progresses based on that input, and what your players have to learn, and how, and through what kinds of tasks? Do these tasks deliver to your player the just-right amount of challenge, the interactive playing experience model’s element directly associated with this territory? Do they also support autonomy/agency and mastery/performance from the player motivation model, also associated with this territory?

If the answer to these questions is yes, congratulations! You just beat a tough level.