作者：Martin Pichlmair

我近期参加了某个游戏化倡导者举办的演讲，他认为目前的游戏化行为只是一种肤浅的营销工具，提出我们应当转向专注于“游戏思维”。但他无法对这个词语给予令人信服的定义，所以我认为自己应当更进一步诠释我眼中的“游戏思维”概念。

我的定义以“设计思维”为基础，这是个设计理论中较为流行的术语。

gamification(from entrepreneur.com)

设计过程

从想法到最终产品，将整个产品设计过程分解成有序的各个步骤，这是每个工程师的梦想。包括软件工程、桥梁建造和产品工程等各类工程师都有这个梦想。也就是说，将问题分解成可以相继解决的小问题，最终实现解决整个问题的目标。

这些步骤就是：产生想法，制定计划，根据计划行动，完成。

当然，关于这种想法比较广为人知的结果就是瀑布模型。但是，多数游戏工作室利用敏捷开发模型而不是瀑布模型，这其中有一定的原因。这种严格的计划并不能够全面考虑到游戏开发过程中的所涉内容，尤其是当这些游戏属于创新型游戏时。即便是那些创新度较少的游戏，也可能会面临某些无法预先料想到的开发挑战。

产品工程也是如此。在设计中，迭代成了新的行业规范，从迅速构建原型和配对编程到互动构图，众多新的设计和开发方法也就随之而来。

棘手问题

游戏的核心是互动行为。游戏是只能通过互动来添砖加瓦的规则系统。我们设计的目标就是游戏过程中的动态和美学。在设计思维中，我们可以用“棘手问题”这个概念来描述那些难以用上述分解法来解决的问题，这些问题多数是以用户为中心。

Rittel和Webber在1973年通过《Dilemmas in a General Theory of Planning》这一著作，将棘手问题描述为满足下列条件的问题：

1、棘手问题没有明确的形式。

2、棘手问题没有停止规则。

3、棘手问题的解决方案不分对错，只分好坏。

4、棘手问题的解决方案不存在立即测试和最终测试。

5、棘手问题的每个可执行解决方案都必然会产生某种结果。

6、棘手问题不存在一套可以精确描述出来的潜在解决方案。

7、棘手问题从本质上来说都互不相同。

8、棘手问题可以被视为其他问题的征兆。

9、棘手问题的产生原因可以有许多种描述。

10、计划者（即设计师）在处理问题时不能犯错。

审视某项游戏机制，你可以看看它与这些描述的契合度如何。接下来我将会举个例子。我们目前正在测试《Chasing Aurora》中的各种单人机制。我们面临的设计挑战之一是，开发基于物理学的鸟人2D飞行模式。

因为飞行是通过关卡的主要方法，玩家必须对移动有良好的控制。同时，游戏中大量的挑战构建于影响玩家移动的空气流动上。我们不断地重复制作这个飞行移动成分，努力实现控制与挑战间的完美平衡。

现在我们根据以上列表来审视这个问题。问题的描述不正式而且不完整（第1点）。我们无法构建出完美控制方案（第2点），因为这个问题没有绝对正确的解决方案（第3点）。

我们甚至没有正式的方案用来测试解决方案是否完美。我们获得的只是不可靠的人类游戏测试（第4点）。如果我们执行另一种解决方案，可能会影响到整个游戏玩法（第5点）。在描述所有针对角色移动的可行控制方案时没有统一点（第6点），我们只是想让它看起来既深层次又新颖，而且完美地适合于整个游戏架构（第7点）。

这让我想起，整个游戏可以被视为一个巨大的棘手问题（第8点）。只能通过游戏哲学上多方面的探索才能够解决这个问题（第9点）。最后，如果我们的解决方案失败了，玩家肯定会对游戏感到不满意（第10点）。

棘手问题在游戏开发过程中如此盛行的原因很多，但是最为明显的原因有：

1、游戏开发受到各种限制，包括题材、技术、玩家期望和生理学限制等，正是这些限制了创造性解决方案的产生。

2、互动行为是游戏的核心。作为动态系统，游戏中几乎每个层面的上方都是用户互动。互动成分需要玩家来进行测试。

3、整个系统和系统各个部分间是相互联系的。生命值和生命包，生命包和力量提升，力量提升和仓库展示，仓库展示和按键布置，按键布置和设备驱动器，设备驱动器和显卡，显卡和阴影效果，阴影呈现和后处理FX，后处理FX和粒子系统，粒子系统和治疗魔法，治疗魔法和生命值，所有的这些都环环相扣。单个问题的解决方案可能会影响到其他的问题及其解决方案。

4、创新需要实验。每次创新都带有风险。尽管现在盛行克隆和题材借鉴，但这一领域仍有许多创新空间。

标准游戏设计和开发问题解决工具包含有解决棘手问题的工具，比如 Scrum、原型、MDA、从内测到公测的游戏测试、互动构图以及补丁等。解决棘手问题是游戏设计中的关键成分。我们每天都在做这件事情。

solving loop(from niallhore.wordpress.com)

其他领域中的运用

如果你看看当前的游戏化趋势以及多数游戏化应用产品的不良设计，就很容易发现我们不能只是将游戏机制带到其他领域中，而是需要修改其他行业中的公司结构，这样他们才会像游戏设计那样解决所面临的问题。

要真正将服务游戏化，公司运行服务的方式就应当有所改变。引进新的处理过程、工具和方法。仅仅添加某些基于点数的排名系统并不能实现游戏化的目标。在重新构建整个公司时，用户互动的整个过程也应当重新构建。

如果你在执行游戏化策略，那么就要全身贯注，把所有精力投入其中。如果你想要在网页服务中添加成就系统，尽量让其为你的设计目标提供支持（游戏邦注：成就系统在现代游戏中扮演着重要的支持角色）。将成就系统作为冒险做某些事情的奖励，奖励用户的探索性和实验性行为，或者作为玩家之间比较发展进程的方式。

为主观互动行为奖励分值并非游戏化过程，而且会使整个游戏化概念变成单薄的市场营销手段。通过游戏机制来构建互动动态才会让产品变得更好。

如果说游戏化是将游戏或设计想法引进新的领域中，那它就不应该只是一种营销手段。我坚信，许多产品及其设计过程都可以从我们在游戏开发中使用的敏捷设计方法中获利。如果是以游戏思维来设计互动过程，我想这样的产品才会让用户更满意。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Opinion: Game Thinking

Martin Pichlmair

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.

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:

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. (Source: Gamasutra)