作者: xeophin

由于我现在的本职工作和参加的地方服务，让我有机会见识到各种用于儿童神经康复的治疗游戏。大多数游戏都配有专门的输入设备。

准确地说，应该是输入设备有配套游戏。因为制造商通常是在设备造好后才考虑游戏。另外，那些游戏的设计意图虽然好，但往往没能表现出来。

我决定根据自己的观察列一个表，提出一些改进意见。以下观点并非诋毁其他设计编程治疗游戏人员的工作，只是探讨了设计新游戏时可能会遇到且应该解决的问题。当然，主要是提醒我自己不陷入这些误区。

therapy game design(from xeophin.net)

普遍误区和解决办法

首先，不得不说如果你要为儿童开发一款治疗游戏，那么你确实遇上重大挑战了。儿童是最苛刻的受众之一，如果他们喜欢你的游戏，他们毫不费力就能挑出游戏中的任何一点点瑕疵。如果你的游戏恰好又露出蛛丝马迹，那他们就更可能这么做了。例如你创造了一个不符合逻辑的游戏世界：让一只奔跑的狗必须一边跳起来躲避爆炸的蘑菇，一边提防弹出来的巨手打到自己的肚皮，一边收集漂浮在半空中的钻石？

我没有瞎说。孩子们肯定会问为什么。如果这只狗饿了，它为啥不吃蘑菇？为啥蘑菇会爆炸？狗要钻石干嘛？钻石为啥挂在空中？地上的巨手是做嘛的？当治疗专家必须专注于实际治疗时，他们无法想出现成的解释？孩子会不停地问为什么。只有当游戏中的所有东西都符合逻辑且彼此相关时，孩子们才会停止怀疑。所以，设计原则第1条：游戏世界必须符合逻辑且有意义。

据我观察，许多游戏的失败结果远比成功更壮观。想象一下，在一款游戏中，鸡蛋和西红柿必须浮着，不可以落地，最后安全地放进篮子里。当这些东西成功地放进采集篮子里时，玩家就能听到一声单调的“咔-戚”。如果玩家把东西掉到地上了，西红柿就会飞溅成漂亮的花，鸡蛋里就会蹦出一只小鸡仔，咯咯叫着跑开。我见过的例子不止这一个。失败的结果是东西碎裂、飞溅、爆炸，有声有色；而成功的回应呢，甚至只有Windows系统内置的提醒声！这下玩家纠结了：如果这游戏我玩得太好了，那么我就得不到什么乐趣了，因为一切有趣的事只有在我玩得烂时才发生。这真的是游戏的目标吗？我想不是吧。所以，设计原则第2条：要让成功的反馈比失败的反馈更令人满足。

我将为了降低成本，利用重复训练某个动作来制作游戏这种邪恶的想法称为“西西弗斯主义”。例如玩家必须重复地做某件事，如摘苹果放进篮子里。这种简单的任务一完成，游戏就重新开始。然后，玩家又开始再摘苹果。游戏又重新开始。再然后，玩家再开始摘苹果……这也太无聊了吧！虽然重新装载游戏和计数器程序应该不难编写，但对玩家来说，这太令人郁闷了。无论刚做完什么，之后又得重来再重来。苹果不断地消失在篮子里又不断地从树上长出来。除了抽象的计数器，玩家感觉不到任何进步，更别说“哇，看我摘了这么多了！”因为篮子里空空如也。无论玩家做什么，也是无用功。这像不像西西弗斯（游戏邦注：在希腊神话中，西西弗斯被诸神处罚，不停地把一块巨石推上山顶，而石头由于自身的重量又滚下山去，诸神认为再也没有比进行这种无效无望的劳动更为严厉的惩罚了）不断地做同一件事，却看不到任何进展？解决办法非常简单，就是让苹果填满篮子。最后，玩家看到满满的一堆苹果就心满意足了，感到自己劳动真勤快。所以，设计原则第3条：用视觉反馈让玩家感到进步。

游戏活动的大量重复，除了让玩家看不到进展，还产生另一个问题：厌倦。这算不得什么新问题，因为在即使是主流游戏也存在。不妨称其为“采矿”，本质上还是叫玩家不断地重复相同的事。无论是《魔兽》、《暗黑2》、《天堂》还是《无尽的任务》，大多数MMORPG的玩家都是在“采矿”。为什么？因为这些游戏中的“采矿”就像玩老虎机：大多数时候，玩家能得到一点点回服（矿石），但一个不小心，你挖到宝发大财了。抱着这种再挖到宝的念头，玩家于是不停地采矿。在治疗游戏中增加“有价值”的道具可能不完全是这样的，因为这类游戏没有或不必有经济模式，但随机事件会有效地减少例行公事的感觉。时不时地（在治疗过程中至多一两次）苹果变成梨？或者突然飞出一只虫？总之，时不时有出乎意料的事发生，总有新鲜事可等。这就是“采矿”的回报。设计原则第4条：在惯例中加入意外的事物。

当然，重复不是治疗游戏在短时间内就变乏味的唯一原因。另一个是，普遍内容不足。玩了某款游戏五分钟后，玩家就看透整个游戏了。从那五分钟后，什么也不会改变了。难度不再提升，玩家也不再进步。如果没什么可以探索了，那么作为玩家的我还花时间玩那游戏干嘛——除非还有其他始终变化的元素吸引我。对于那些每天都会玩一阵子的游戏，我看到的大多数治疗游戏都没有重玩的价值。设计原则第5条：提高重玩价值。

另一个问题与玩游戏的人和开发游戏的人没有太明显的关系。特别当以儿童作为目标受众时，开发者必须明确这些孩子的游戏识记经验可能比他们本人还丰富。这是个难题，因为治疗游戏会被孩子拿来与索尼、EA或任天堂出品的主流游戏作对比。作为开发者，没理由模仿这些游戏的视觉风格。尽管如此，开发者还是利用这些主流游戏的视觉模板、词汇和某些更好更合适的游戏机制，快速设置场景和实现游戏目标，以贴近孩子们的游戏经验。然而，必须明智地使用这些视觉模板：如果角色行为“不得体”，孩子们马上就会觉察。治疗游戏未必就是孩子玩的第一款游戏。而且往往不是。如果游戏能让孩子投入的时间超过五分钟，那么设计时就必须考虑到孩子脑子里的游戏生态系统。设计原则第6条：注意目标受众的游戏识记经验——如果有必要，尽量接近。

我充分意识到，倒三条原则意味着生产更多内容和代码，成本也会随之提高。但如果这能增加游戏的效力，为什么不遵循呢？

我想开发者们跳过这三条的原因是：他们可能认为那些只是给小孩子玩的治疗游戏，可以敷衍了事，反正孩子们永远不知道。问题是，你记不记你当小孩子时怎么处理手上的东西？什么都要大胆尝试？孩子们也是这样对待游戏的。为了搞明白怎么回事，他们会拨开所有东西。与此类似，孩子们会找到一切可能办法去探索游戏中的东西并加以利用。更严重的情况是：这可能会完全破坏真正的治疗进程。是的，作为开发者，你不必说服玩家继续玩你的游戏，因为玩家通常也是被迫的。但如果你认识到要改进游戏，创造一个玩家乐意玩时间享受的世界，那就好了。设计原则第7条：好好修饰和改进治疗游戏，就像要把它放布在Xbox Live Arcade、Playstation Network、Steam或苹果App Store上。

我知道其实这些原则都不新鲜了。对于从事游戏开发已有一段时间的人来说，都应该是常识。

但说到治疗游戏，开发者往往不再是游戏设计师而是工程师，输入设备才是其关注重心，而配套游戏不过次要考虑的东西，其作用只是展示设备的性能。我仍旧希望这种状况会得到改善。但在此之前，开发治疗游戏的态度真的得改一改了。

端正态度

从研究文献就能看出开发者对待治疗游戏的态度。鲜有文献描述游戏如何运作、如何刺激、奖励或惩罚玩家。甚至是基本的游戏机制都没有提及。相反地，硬件设置倒是说了很多。但安装在戴尔电脑、显示在21寸LCD显示器上的游戏呢？大多数治疗游戏的系统都有一定的系统要求，这跟专门的硬件很不相干——毕竟，《孤岛危机》和《FarmVille》都能运行在相同的硬件设备上，但我不认为有人真的觉得，因为这一点，那些游戏的玩法就大同小异。

是时候制定一种合理而规范的方式来描述那些游戏，那样才能进行对比，最好还能评估品质。要提到主要游戏机制是什么？游戏循环如何运作？如何保持玩家游戏？玩家失败的结果是什么？是否存在获胜条件？如果有，是什么，如何达到？如何奖励获胜的玩家？失败的玩家是否受到惩罚？如果是，如何惩罚？玩家还能得到其他的什么反馈？玩家如何融入游戏世界——以第三人称角色还是第一人称视角，以操控角色还是简单地移动鼠标光标？游戏尺寸有多大？游戏的画面、视觉效果、主题、场景？环境的精细程度？与主流游戏是否相似，相似程度？

研究文献应当能回答其中某些问题，这样才能深刻理解治疗游戏——除了高分辨率的画面（颜色也很少在今天的研究文献中提及），当然，还有展示游戏和玩家对游戏反应的视频。

开发者有必要通过大规模的调查问卷了解如何设计这类游戏；制作好游戏一般都很费时（自然也费钱），但治疗游戏不止只新设备的演示工具，其本身应该得到与设备相当的关注度。

毕竟，病人的注意力最终是放在屏幕和游戏上的，全然不会注意是什么设备在运行游戏。如果游戏有趣而有吸引力，玩家自然会再使用那种设备。否则，无论设备本身有多好，玩家都不会再使用了。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

7 game design rules that apply to therapy games (as well)

by xeophin

My current job/civilian service has given me the unique opportunity to have a look at a variety of therapy games that have been designed for children’s neurorehabilitation. Most of those games come with specialised input devices.

As a matter of fact, it’s usually the input devices that come with games. Too often, the games seem to have been created as an afterthought of the device, and too often, those games have good intentions, but fail to deliver.

In order to be aware of those problems myself, I decided to make a list of my observations and how they could be mitigated.

The following points do not intend to discredit the work of all the people that designed and programmed the therapy games mentioned, it should merely discuss some problems that can occur and should be addressed when designing new games. Of course, that mostly means me, so I don’t fall into those pitfalls myself.

Common Pitfalls and their Resolutions

First of all, it has to be said that if you’re tasked with creating a therapy game for children, you have quite a challenge to overcome. Children are one of the most demanding audiences, and they will have no problems picking your game apart at the seams when they feel like it. They will feel most inclined to do so when you give them reasons. Like creating incoherent game worlds. A running dog that has to avoid exploding mushrooms by jumping whenever boing poked in the belly with a huge hand and meanwhile collecting diamonds that hang suspended in thin air?

I’m not making this up. Children have all right to ask what is going on in these cases. If the dog is hungry, why isn’t he just eating the mushrooms? Why are the mushrooms exploding? What is a dog supposed to do with diamonds? Why are the diamonds hanging in the air? What is that huge hand doing below ground? Therapists are forced to come up with on-the-fly explanations when they should be allowed to concentrate on the actual therapy. Children will always ask about the why. Suspension of disbelief is one thing, but it only works when all the elements within a game world make sense and are related to each other. Therefore, Design Rule No. 1: Create game worlds that are coherent and meaningful.

In many of the observed games, failure leads to more spectacular outcomes than success. Consider a game where you have to juggle eggs and tomatoes, keeping them afloat and safely depositing them in a basket, without letting them drop to the floor. When successfully placing these objects into a basket for collecting, a simple “ka-ching” sound is heard. When dropping these objects on the floor, however, the tomato splatters with a satisfying “splotch” and the egg cracks and a chicken emerges, running away clucking. This is by far not the only example available. Upon failure, things break, shatter, explode; loud and visceral. Success is merely acknowledged, often just by some Windows built-in warning (!) sound. As a player, the ramifications are clear: if I play the game as perfect as possible, I will rob myself of all the fun, since all the funny stuff only happens whenever I fail. Is that really the goal of those games? I don’t think so. So, Design Rule No. 2: Make feedback upon success more desirable than upon failing.

The desire to create games that train certain movements repeatedly in combination with minimal budgets to produce these games results in a rather toxic combination – what I’d like to call Sisyphusication. The player has to do something – like taking an apple and putting it in a shopping basket. When this simple task has been done, the game is reset. Then, the player has to take an apple and put it into a shopping basket. The game is reset. Then, the player has to take an apple … ad nauseam. While just reseting the game and bumping a counter might be easy to program, it is utterly frustrating for the players. Whatever they just did, they have to do all over again. And again. The apple instantly vanishes out of the shopping basket and reappears on the fruit display again. Apart from an abstract counter, there is nothing visual that would give the player a sense of progress, a feeling of “Whoa, look how much I’ve done so far”. The basket is always empty. Whatever the player does, it is futile. Wouldn’t you feel like Sisyphus, having to do the same thing all over again, without getting the feeling that you’re getting somewhere? It would be so easy. Just let apples fill up the shopping basket. In the end, the players would see a heap of apples and have the satisfying feeling of having worked really hard. Therefore, Design Rule No. 3: Give the player visual feedback to provide a sense of progress.

With a lot of repetition comes, independently from any sense of progress, another problem: boredom. It’s not like that’s something very new, even in mainstream games. There it’s just called mining. But it still means you have to do the same things over and over again. Players still do it in World of Warcraft, in Diablo 2, in Lineage or Everquest or most of the other MMORPGs. They keep on mining. Why? Because mining in those games is more like playing a slot machine: most of the time, you will get small earnings (like ore), but once in a while, you hit the jackpot and receive a valuable item. The hope of getting more of those items drives the player to keep on mining. Adding “valuable” items in therapy games might not work out directly, since none of them have or need an economic model, but random events might lessen the routine considerably. What if from time to time (once or twice during a therapy session, at most) an apple turns out to be a pear? Or a bug that skitters away? Something unexpected that happens from time to time, something to wait for. Something that repays the efforts of mining. Design Rule No. 4: Embed something unexpected in the routine.

Of course, this is not the only reason why therapy games can seem boring after a very short time. Another is the general lack of content in most cases. After one play-through of 5 minutes, the player has seen the whole of the game. From here, nothing will change anymore. Not when the difficulty changes, not when the player gets better. But if there is nothing more to explore, why should I, as a player, spend more time with the game – unless it has some other, ever-changing element that makes it interesting for me? For games that are supposed to be played more or less daily for an extended period of time, most of the therapy games I have seen are rarely designed with replay value in mind. Design Rule No. 5: Add replay value.

Another problem is the obvious large disconnect between the people that play the games and the people that produce them. Especially when it comes to children as a target audience, the creators should be well aware of the fact that those kids likely have a higher game literacy than the creators themselves. This is a challenge, as the therapy games will be measured against the production values of mainstream games made by Sony, EA or Nintendo. As a creator, there is no point in trying to emulate their visual style. Still, it is possible to tap into the gaming knowledge of kids, by re-using the visual templates, the vocabulary and some of the better and appropriate game mechanics, allowing you to set scenes quickly and visualise the goals of a game. It is required, however, that these visual templates are used wisely: the kids will know immediately when a character is not behaving “correctly”. Therapy games will not be the first game a kid has played. Far from it. If they’re supposed to engage a child longer than 5 minutes, they need to be designed with the knowledge of the ecosystem of games in mind. Design Rule No. 6: Be aware of the target’s audience game literacy – and tap into it, if necessary.

I’m perfectly well aware that these last three rules mean producing more content and leads to more code, driving up costs. But if it could increase the game’s efficacy, then why skimp on it?

Oh, and regarding skimping on things: It might be tempting to program these games in a rather quick and dirty way – they’re just kids playing therapy games, right? They will never know. Problem is – do you remember how you approached almost all things as kid? Fearlessly trying out everything? This is what kids will do to the game. They will poke at everything, trying to figure out how it works. As easy as that, they will find every possible exploit a game has to offer – and use it to their advantage. In the worst case: completely circumventing the actual therapeutic procedure. Yes, you, as a developer, won’t have to convince the player of a therapy game to keep on playing, because this player is usually forced to play your game. But it would be nice if you acknowledged this fact by polishing and debugging your game to create an environment the player likes to spend time in: Design Rule No. 7: Polish and debug a therapy game as you would a game that’s being published on Xbox Live Arcade, Playstation Network, Steam or the iTunes App Store.

I’m aware of the fact that most of those rules are nothing new. They should be common knowledge to anyone that dealt with game design for an extended period of time.

When it comes to therapy games, however, the creators too often are not game designers but engineers, where the robot or newly developed input device is the centre of attention, and the games that come with it an afterthought, merely a demonstration of the gadget’s capabilities. I’m still hoping that this will change in the future. But for that, the attitude towards the creation of therapy games has to change.

Necessary Changes in Attitude

This attitude is most visible in the way therapy games usually are treated in research papers. In the fewest cases you get a description of how they work, how they motivate, reward or punish players. The basic game mechanics go unanswered. Instead, you get descriptions of the hardware setup. But what good is the information that the game ran on a Dell desktop computer and has been shown on a 21″ LCD monitor? Most of those therapeutic games have modest system requirements, making the specific hardware quite irrelevant – after all, both Crysis and FarmVille will run on the same hardware, but I don’t think there is anyone seriously suggesting that because of that, those games are similar in how they are played.

It is time to create a proper, formalised way to describe those games so they can be compared and, in the best case, their quality can be evaluated. What is the main game mechanic? How does the game loop work, what keeps the player acting? What happens if the player fails to act? Is there a winning condition, and if yes, what is it, how can it be reached? How is the player being rewarded upon success, is the player punished for failure, and if yes, how so? What other feedback is the player given? How is the player integrated into the world – as an avatar in a third-person-view, from a first-person-perspective, as a puppeteer, as a simple mouse cursor? In how many dimensions does the game play? What does the game look like, what is its visual style, its theme, its setting? How detailed is the environment? Is it similar to available mainstream games, and to what degree?

These are some of the questions that should be answered by research papers and which would give an actual insight into the therapy game used – apart from the high-resolution screenshots (in colour, which, too, is a scarcity in today’s research papers on the topic) as well as videos that show both the game and the player’s interactions with it, of course.

Maybe the existence of such an extensive questionnaire could provide the necessary awareness when it comes to creating therapy games: Yes, asking game design professionals is helpful in such an endeavour. Yes, good games take time (and therefore money) to create. No, therapy games are not just demo applications for an awesome new device, but require just as much attention as the device itself.

After all, when all is said and done, the patient’s attention will be on the screen and the game, while the input device will disappear from the player’s mind. If the game is engaging and interesting, the player will use your device again. If not, they won’t want to use the device again, no matter how well-constructed it may be.(source: xeophin)