This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Need #2: Comfort
Every game designer is familiar with the principle of balancing challenge with ability. What many designers don't realize is that there is a third factor in the formula that allows you to widen the distance between ability and challenge: the player's sense of security. Simply put, if the player feels insecure in any given situation, that player will be less likely to take on challenges. With greater security, confidence increases and more challenges can be faced. More challenges means more time and enjoyment of your game. Comfort and security can sometimes be difficult to provide for little people.
Here's an example: Say you're a little kid. You've watched your parents break down in tears over something that you innocently retooled, redecorated, or otherwise abused. You haven't yet got it figured out, but it's becoming apparent that at a certain point things break, and some (apparently random set) of those breaking incidents cause big people to get really angry, which can imply significantly negative consequences for defenseless innocents such as yourself. Now you view your father's very nifty machine as one of those anger-triggering-when-busted things. You might not feel so secure.
As if that's not enough, when you get into this game, your head starts spinning. Things keep changing. Each screen is different from the screen before. Tools work differently according to when you use them. Characters change their roles and behaviors. It seems that at any moment, the whole thing could just blow up.
Sure, there are kids who aren't intimidated easily. But all children work better when they feel more secure. A game can provide security by following a few simple guidelines.
Provide a guide. Humongous Entertainment does a great job of providing warm, nonthreatening guides with whom every child can identify. Every child who plays PUTT-PUTT JOINS THE PARADE leaves the game believing that he or she is Putt-Putt, which provides a lot of security. There are a number of ways Humongous achieves this. First of all, Putt-Putt always seems to knows what's happening. Putt-Putt never looks too frightened or overly perturbed by events, so neither does the child. Putt-Putt responds to situations just as the child would. Putt-Putt never tells the child what to do or passes judgment on the child's actions. He never behaves in a totally unexpected manner or does anything without the child first approving. He never gets hurt or dangerously lost. If anything negative did happen to Putt-Putt, the child's sense of security and willingness to continue the game could be adversely affected.
(Putt-Putt was Humongous's first - and very successful - attempt at an adventure game for kids. Their second title involved a teddy bear wandering around a house at night in the dark and encountering some exasperating situations. It was the first child's game I ever saw that could make a child break down in tears.)
A lot of consideration, discussion, and testing goes into creating a guide like Putt-Putt. After all, the guide becomes a central feature of the child's experience. Many developers try to make their guides asexual, androgynous, or totally ambiguous. My sense is that as long as the character is clearly defined early on in the design process, it will integrate well and work. Also, keep in mind (I need my bodyguards present while I make this statement, but it's true) that many boys will have difficulty identifying with a girl character, whereas most girls will have no difficulty identifying with a boy. If it comes down to using one or the other, use a boy.
Another strategy is to provide a choice of guides. This considerably increases your workload, not just in terms of code, but in ensuring that every scene works appropriately with either character as the guide. Beware that it also detracts from the game's focus and feel.
The Humongous line provides heroes that kids can easily identify with and also serve as guides. The age-appropriate problems are cleverly presented. The user-interface is simple, intuitive and consistent.
Be Consistent. Just as your guide must be consistent, your artistic style, sound effects, backgrounds, and object behaviors must be, too. Think through everything and define styles and behaviors clearly in your design document.
Children approaching seven years old are just learning to believe that there is consistency out there; that there are laws of nature that you can trust to be the same today as they were yesterday. Half of their play is all about discovering this wonderful, secure consistency of nature. Don't be the one to undermine that.
One place consistency tends to break down is when the operating system's user interface raises its hoary head. Adults are expected to recognize and deal with Open File dialogs and such, but not children. Make sure to provide your own substitutes to these things if necessary.
Make It Intuitive. Once you've learned how to use something, if it looks like it should be used differently you continue feeling insecure about using it. For example, I move my kids about in a beat-up '86 Toyota van. To lock all the doors in this brilliantly designed vehicle, you pull up a switch by the driver's seat. That makes all the locks go down. Brilliant, eh? After all these years, I still get it wrong one time in every five. If that's so with adults, it's all the more so with children.
Of course, what's intuitive to adults may be counter-intuitive to children. To an adult, it makes perfect sense that if you look up, the shampoo won't go in your eyes, or that you place the right arm in the sleeve on the left side of the jacket facing you. To children, these are things to be taken on blind faith out of the awe that they have for these big people who seem to know what they are talking about.
Which means that there's no substitute for testing your interface ideas on real, live children. Show them objects and ask, "What do you think this does?" Then listen carefully as they give their own ideas of what things should look like.
Avoid Shifting Modalities. Shifting modalities means making things work under one set of rules in one instance, but under another set of rules in another. Engineers just love designing things that way. End users are completely confounded by it.
One of the hardest objects I've had to design is a telephone for children. After the typewriter, the telephone is the most poorly designed device of the modern era. It behaves one way when "on the hook," another way when "off the hook," and yet another way while "on line." No wonder teaching young children to operate a telephone can be so frustrating. Ever had a child answer a long-awaited call and hang up while he goes to look for you? Or had a child start dialing the phone while you're still on the line? Every tool that you give the child should have only one way of working, regardless of what happened just beforehand. Every object should have a well-defined, internally consistent set of behaviors that never shifts about.
Usually, when I make a tool for a child, the initial iteration has more than one modality. It takes some thought to find a way to provide everything you want in one simple mode, but you end up with a far easier-to-use tool.
No Reading. Yes, it sounds obvious, but developers keep on doing it. I've even seen software that purports to teach basic reading, but can't be understood unless you know how to read (and even then...).
Know that if a child cannot read, that means the child can't read. You're going to have to find other ways to communicate. Even if the child can read, he or she may not comfortable doing it.
Use Kid's Voices. The only excuse for using adult voices in software is that it is much easier than using children's voices. Children can be a real pain to record. If they don't get it right the first time, you've usually lost it for the day. Very often you'll have to blend two or three recordings together to get what you want.
But if you do it right, the rewards are phenomenal. There's just no comparison to hearing the fresh, vital, and expressive voices of young children speaking out of your machine. You'll capture the heart not just of the child who's playing, but of the adult who's machine is being hijacked as well.
Don't Increase Difficulty Without the Child's Approval. Edmark is notorious for this. Some educator applied half-baked notions of Mastery Learning mixed with poor arcade-game design and arranged gameplay so that as soon as a child gets too comfortable, things become more difficult.
Edmark's Thinking Things allows kids to explore, but oozes goodyness and expectations. This "Tooney Loon," for example, can get really bossy and obnoxious when you fail to imitate it correctly.
Now, that's often fine in the real world, where there are plenty of signs to tell kids when they're improving and that things are going to get more difficult; generally, an intelligent adult or friend is giving real feedback and reading stress levels loud and clear.
But when progress is blindly automated, it's bad. The child thought he was doing well, and now he's failing. And he can't tell why. The least you can do is explicitly let the child know that difficulty is increasing, as in a typical shooter, where you can see the opponents are becoming bigger and more threatening. You know you're on a higher level.
Personally, I'm a proponent of letting the children decide when to take on bigger and more difficult tasks. This way, they retain their sense of control and develop a sense of their own capacities as well. That may be too much to expect at a very early age, but as they come closer to "metacognition" (awareness of what they are thinking) it makes more sense.
Provide Immediate Response to any Action. Adults begin to feel uneasy if they've clicked a button and nothing's happened within 0.2 seconds. With kids, results are magnified. I previously mentioned the "clickies" syndrome. This is often brought on in otherwise perfectly balanced kids by repeatedly unresponsive buttons. Aggressive behavior has also been noted. They may just plain give up. (Just be thankful you're not programming for primates. In a project creating buttons with icons recognizable by a gorilla, the beast was noted to trash machines that did not respond immediately. Literally.)
Remember that small children have just understood the notion that there is such a thing as cause and effect in our world. They're still quite suspicious of the phenomenon and ready to attribute anything to magic. We want them to know that machines aren't magical. Kids are.
The Living Book Series (the oldest CD ROM series for kids, originally from Living Books, now at cheaper quality from Big Tuna's Productions) provides small children a simple, comfortable environment. It flunks out, however, in versatility. You can't even abort an animation, and some of them are very long.
Make the Click Areas Big Enough. Kids are not as detail oriented as adults; for children, close is good enough. Make sure your buttons are big. If the child is supposed to drag things to specific places, expand the "hot" area invisibly beyond the graphic.
It's also a good idea to provide plenty of feedback when the cursor is over a hot spot. Changing cursors, animating the area, cueing audio, and showing eyeballs that follow the mouse are all effective means of helping children follow the action. These tactics also help them keep track of the cursor's location; losing the cursor is another common phenomena with small children.
Build It And They Will Come
Kids have been getting the short end of the technology stick for too long. Adults - and big kids - are handed more and more power every day, but small folk just get pushed around more and more. Game developers have the tools to empower and liberate children.
Nevertheless, you have to know them very well. Don't ever assume that you've got children down pat and can predict their every turn and click. Keep studying them closely and they'll never cease to amaze you.
Tzvi Freeman teaches Game Design and Documentation at Digipen School of Computer Gaming in Vancouver, British Columbia, Canada. He has designed several commercial games and has acted as a consultant on many others. He can be reached at [email protected].