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:
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
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.
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:
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.
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.
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.
This phase’s reading order is fixed for the Introduction, Level One and Level Six.
Level Two through Five are non-linear: you can tackle them in any order you like.