I recently attended a talk by a gamification proponent who presented a fragmented and ill structured theory on what gamification can bring to a product. He arrived at the right conclusions, but due to the long and winded road he took there. the audience was generally unwilling to accept the fine finale of his talk. In the end, he dismissed gamification as the surface-scratching marketing tool that it currently is, proposing a focus on “game thinking” instead. Because he failed to come up with a convincing definition of that phrase, I thought I should step in and deliver one. Mine is based on “design thinking”, a term popular in design theory. I’m quite familiar with design theory because it was the foundation of all our research at the university department I researched, taught and worked at before entering the exciting world of the games industry.
Design as a Process
It is an engineer’s dream to structure the design process of a product into discreet steps leading from idea to finished product. Many disciplines of engineering, be it software engineering, bridge building, or product engineering, shared this dream. Take a problem and solve it by dividing it into sub-problems that can be tackled in succession. The steps are: generate an idea, make a plan, follow the plan, ship. At worst, the product is mistaken as the process, with “the plan being organized so as to make the structure of the design process reflect the structure of the sub-components of the resulting design product.”, which is then called the product-process symmetry.
Yes, the waterfall model is a famous result of this thinking. But there’s a reason why most game studios utilize agile methods instead of the waterfall model. Games do not lend themselves to this style of strict planning. This is especially true if they are innovative, but even games with a marginal degree of innovation might have development challenges that are difficult to take into account in advance. The same is true for product engineering. I’m not very familiar with bridge building, so I won’t talk about that. In design, iteration became the new paradigm, and with it came a plethora of new design and development methods – from rapid prototyping and pair programming to interaction sketching.
The core of games is interactivity. Games are rules systems that only flourish upon interaction. The dynamics and aesthetics of play is what we design them for. In design thinking, the notion of “wicked problems” was introduced to describe those mostly user-centric problems that are so hard to solve in a step-wise problem-solving manner. Rittel and Webber described wicked problems in 1973 as problems where the following list of conditions is met:
- There is no definitive formulation of a wicked problem.
- Wicked problems have no stopping rule.
- Solutions to wicked problems are not true-or-false but good-or-bad.
- There is no immediate and no ultimate test of a solution to a wicked problem.
- Every implemented solution to a wicked problem has consequences.
- Wicked problems do not have a well-described set of potential solutions.
- Every wicked problem is essentially unique.
- Every wicked problem can be considered a symptom of another problem.
- The causes of a wicked problem can be explained in numerous ways.
- The planner (designer) has no right to be wrong.
Think of a game mechanic and you can see how nicely it fits this description. I’ll give an example. We’re currently testing out different single-player mechanics in Chasing Aurora. One of the design challenges we’re facing is developing physics-based 2D flight for a bird-man. Since flight is your main means of traversing a level and the challenges are platformer-ish, the player has to have a lot of control over movement. On the other hand a lot of the challenges are built on wind-streams that affect your movement. We’re iterating the flight movement component again and again and again and again to strike the perfect balance between control and being at the mercy of the elements. Now let’s look at the above list. (1) The description of the problem is informal and incomplete. (2) We will not know it when we built the perfect control scheme just bounce against the fluffy invisible wall of diminishing returns because there is no absolutely (3) right solution to this problems. (4) There isn’t even a formal test we could apply to test if our solution is perfect. All we got is unreliably human game testers. (5) If we implement a different solution it affects the whole gameplay. (6) There is no point in describing all possible control schemes for character movement, we just need to make it (7) deep, feeling fresh and perfectly fitting to the game as a whole. (8) Reminder: The whole game can be regarded as a wicked problem. Point (9) is impossible to tackle without venturing into philosophy. I leave that as an exercise for the reader. And finally, (10) the game will simply not fulfill the player if we fail.
The reasons why wicked problems are so prevalent in the game development process are many, but the most obvious are:
- Game development is bound by countless constraints: Genre, technology, player expectation and physiological limits, to name a few. Constraints call for creative solutions.
- Interactivity is at the core of games: Nearly every aspect of a game manifests as a dynamic system bound to user interaction. Interactive components always need to be tested with players.
- All systems and parts of systems are connected: Health and health packs, health packs and lifting strength, lifting strength and inventory display, inventory display and button mapping, button mapping and device drivers, device drivers and graphics cards, graphics cards and shader versions, shader versions and post-processing FX, post-processing FX and particle systems, particle systems and healing magic, healing magic and health. Solutions to one problem affect a host of other problems and their solutions.
- Innovation needs experimental setups: Every innovation is a risk. Despite the ongoing cloning and the prevalence of straight genre works, there’s a huge amount of innovation in the field.
The standard game design and development problem solving toolkit consists of tools to overcome wicked problems: Scrum, prototyping, MDA, game testing from pre-alpha/internal to beta, interaction sketching, even patching and the rampant board game obsession. Tackling wicked problems is key in game design. And we’re doing it every day.
We’ve Already Solved These Problems, Let’s Tell The Others
Game development never fell into the product-process symmetry trap in the first place. We’ve solved a lot of design problems in this industry that other similarly structured areas are still having problems with. And if you look at the current trend of gamification and how horribly designed most of the applications of gamification are, it is clear that the challenge is not only bringing game mechanics to other areas but revising company structures in other industries so that they are able to tackle problems as game design tasks. Hand over the keys instead of opening the doors. To truly gamify a service, processes in the company that run the service have to be adapted. New processes, tools and methods have to be introduced. Just adding a points-based rank system does not do the trick. While restructuring the company, the whole process of user interaction has to be restructured, too. I am no friend of gamification, but if you do it, you better do it whole-heartedly. If you add achievements to a web service, make them as supporting to your design goals as possible (after all, achievements play an important support role in modern gaming), as a prize for risking something, as a tool to foster changing the style of play, rewarding exploration and experimentation, as a means of comparing your progress to other player’s progress. Awarding points for arbitrary interaction is not gamification and reduces the whole concept to a marketing trend. Structuring interaction dynamics via game mechanics can make products better.
If gamification was about introducing game/design thinking to new areas, it would not feel so much like a marketing stunt. I firmly believe that a lot of products – and their design processes – could profit from the agile design methods we use in game development*. And a lot of interactivity can be rendered more satisfying when it is game-designed.
 Lawson, B. (1980): How Designers Think. Third and revised Edition, Architectural Press, Oxford, 1997.
 Gedenryd, H. (1998): How designers work. Ph.D. dissertation, Cognitive Studies Department, Lund University, Sweden.
 Rittel, H. & Webber, M. (1973): Dilemmas in a General Theory of Planning. Policy Sciences, Vol. 4, Elsevier Scientific Publishing Company, Amsterdam.
* If you look at the most successful recent product launches, like the iPhone, and think about how many iterations they went through before being released you can see design thinking in action. Also, I think what sets Apple apart from other companies mostly the fact that they do not release every iteration of a product to the market. It’s not like they make better hardware than Samsung. Samsung just releases crap mobiles additionally to their great and well thought-out products.
** … and it will not sell, and not have a decent metascore, either.