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.