Opinion: Game Thinking

[In this reprinted #altdevblogaday-opinion piece, Broken Rules' (And Yet It Moves) Martin Pichlmair looks at "wicked problems" in the game design process, and the challenges in gamifying services.] 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"[1], 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."[2], 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. Wicked Problems 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:

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.[4] The reasons why wicked problems are so prevalent in the game development process are many, but the most obvious are:

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. [1] Lawson, B. (1980): How Designers Think. Third and revised Edition, Architectural Press, Oxford, 1997. [2] Gedenryd, H. (1998): How designers work. Ph.D. dissertation, Cognitive Studies Department, Lund University, Sweden. [3] 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. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]