Power To The Kids!

The mind of the child lies at the vortex of software design. The major breakthroughs in user interface, such as icons and multiple application windows, originate in work done for children. So does the concept of the laptop. But alas, the educators have grabbed the market of childhood software and perverted it into the polar opposite of everything for which the personal computer stands. Rather than empowering the children and liberating their inner creative selves, they intimidate and enslave the child to the machine. Rather than teaching the very first lesson every child of the modern techno-world must learn, that Man controls the Machine, they subliminally inculcate the child with the notion that Man must obey the Machine or fail.

But there is hope: Game developers, with their unbridled, insane imagination and nonconforming nature, are the ones who can crawl into the child's world and liberate those latent inner powers that have remained dormant. Here are some game design strategies for children up to seven years old.

Know Your Market

Somewhere between 32 and 36 months, a child can learn to manage a mouse. A four year old can easily be a master of the machine.

However, the higher end, seven year olds don't yet get along with sophisticated game-controllers. This is one of the reasons none of the console makers have had any success to date with this age group. Another reason is that this age still identifies with childhood and, frankly, thinks very differently than older children (see "The Case for Inappropriateness"). Around seven or eight, a major reorganization of grey matter takes place,. By nine, you have everything it takes to make a full-blown Ultra-64 junkie. These kids no longer want "kid's stuff" - they want the real thing. So let's try to understand what goes on when children age one to seven hit silicon.

The Case for Inappropriateness

A major concern I have in leaving my child alone with educational software is a lack of inappropriateness. This becomes of special concern when dealing with the very young (under seven years of age). Inappropriateness is a very vital element at that age. The fact is inappropriateness is the small child's most powerful learning tool. It allows a child to pick up any object and try anything with it. Mud can be cake. A block of wood can be a doll. Underpants can be a hat.

Then, around the age of seven or eight, something very dramatic - and tragic - occurs. It occurs almost universally, in every country and in every culture where such things are observed. Mud becomes mud. Blocks of wood become blocks of wood. Underpants come to have but one use. Anything else is inappropriate.

Show a six year old a rock and ask him what he thinks it is. You could be in for anything. Wait a few years to ask him again, and it's a rock. And only a rock.

It seems something innate to the human species. Only a smattering of individuals manage to escape this syndrome, preserving their sense of inappropriateness into adulthood. I don't know how fortunate it is for those individuals - or for the people that have to live with them - but for humanity the dividends are bountiful.

I doubt we would have mathematics, for example, if it weren't for these recalcitrants. Mathematics is all about inappropriateness. You apply the same set of digits and formulas to entirely diverse sets of realities. And how about original art and social reform and... well, just about anything else requiring nonlinear thought? Whether Newton or Einstein, Beethoven or Picasso, Spinoza or the Lubavitcher Rebbe, Karl Marx or Groucho Marx, it was the child alive within them that made those quantum leaps in human thought.

What we want to do, then, is to parachute the child gently into adulthood, holding on tight to that willingness to try the improbable, the preposterous, and the patently absurd. We must always leave open the option to try out the ridiculous, and even encourage it.

Software just doesn't lend itself to this sort of thing. Programmers don't like users who muck about. We like to design controlled environments, where the user becomes just another fairly predictable object. When you stop to think about it, little kids are a real pain for all of us in this industry.

That's why we write for "good" kids. Kids who will press the right button and only the right button. Kids who like to be rewarded and don't like to get things wrong. Kids who are fairly predictable - just not quite as bright as us big people. But also not as promising as the nudnik trouble makers.

Nobody's going to make a killer app for early learning this way. What we need is not nice software for good kids. We need great software for rotten brats. We need products where kids can discover that by doing completely unexpected and inappropriate things, they can get really nifty things to happen. We need software where the best solution to a problem is the craziest one.

After all, isn't that just what good ol' Albert did when he decided that everything is relative except for the speed of light, that mass and energy are really the same thing, and time is just another dimension? Sounds pretty crazy to me. No wonder he did so lousy in school. He'd do even worse on Reader Rabbit.

An adult will purchase and share the product. A child typically doesn't even choose the software. It's usually picked by a parent or grandparent according to what they think the child will enjoy. They almost always mitigate the guilt of spending so much for a kid's toy by justifying it as "educational."

All this means that your software must have the following qualities:

Know the child. Not just you, but the artist, the animator, the programmer, the sound and music people - everyone creatively involved in the project must have a real, first-hand, in-depth feel for the child.

The problem is that everyone feels that they're already an expert on children. After all, no one has managed to escape the first-hand experience of being one. Still, few of us have maintained a faithful recollection of what childhood is really all about.

I recommend watching a child who's at a computer. There's no more lucid window into the child's mind. They talk to themselves, to others, and to the machine more articulately than at any other activity.

Try talking with a child as he or she sits at the machine to get even more feedback. Be careful not to influence their decisions or processes. You want the raw child - not one tainted by your external influence.

A vital connection to the game you're producing is essential. Children's software isn't the sort of thing you contract to out-of-house generic programmers. People that make children's software don't "do that also" - they are people that specialize in children's software.

Know what the child needs. Children do a good job of looking as if they're wasting time, but secretly they are in the business of educating themselves about how the world works. That's how they have fun. They just need you to facilitate their discovery by providing them with the right tools and environment in which to explore.

In other words, they need you to empower them. Just as you empower the adult, the teen, or the older child to build cities, blow up monsters, or fly jet aircraft, so you empower the younger child to explore and discover a world to which they can lend some sense.

The tools the child needs to have to do this have two primary qualities: versatility and comfort. Versatility allows the child the freedom and power to explore. Comfort allows the child the confidence to go for it. When you think about it, these are the same two qualities that we look for in a good car, home, computer, or any other adult tool. It's just that for the child, these two elements have somewhat different meaning.

Need #1: Versatility

Versatility means that I can do with it whatever my mind imagines I can do with it. Sand, mud, water, and sticks are eminently versatile. They are also the favorite toys of any child. There are some basic ways to provide that same versatility in your game.

Provide tools, situations, and environments that have multiple uses. When you design an object, a tool, or an environment, don't just think about what you intend the child to do, think about what the child may attempt to do. And then make that possible.

If you provide a hammer for building, make sure that hammer can smash things as well. If you provide water for putting out a fire, let that water create mud when it mixes with dirt. This ensures that objects have integrity and that their relationships are well integrated.

Another advantage to making your software flexible is that it loosens the age restrictions. Different-aged children can use objects for different purposes in different ways. Also, a child can grow with the game. They can come back to it a year later and find fascinating new facets to the game that didn't seem to be there before.

Realize that a child is an extreme functionalist. Everything must have a use. If the child doesn't find an immediate use, that child will have no qualms about breaking the object so that it fits into some use. Call it egocentric, call it narrow-minded, call it reckless vandalism - the child's functional orientation is something that you can take prime advantage of in your game.

Encourage exploration and banish the fear of failure. Remember, the child's way of learning is by trying everything out. The greatest obstruction we can put in the path of that learning process is to feed children the notion that if they try something interesting, they're going to fail.

Let's say you have an aerial view of a world with continents, islands, and bodies of water. You show the child the starting location and allow him or her to move around elsewhere. What makes sense is to move only a short distance from the starting location. The child may try this at first, but eventually will try flying off to a distance. That doesn't fit into your game, so you just don't allow the child to enter that area. You've just discouraged exploration.

Or let's say you've provided a vacuum cleaner. Those are for vacuuming the floor, right? It just so happens, I created one in a game and let the kids test it. I should have known: They tried vacuuming the alphabet blocks on the shelf with it. Nothing happened, and I felt badly. In the next iteration, I designed the vacuum cleaner to suck the paint off the letters on the blocks. Adults didn't try doing that, but the kids love it.

Rather than restrict the child to linear game flow, reward exploration and novelty. If the child tries to enter an area of the map that is not yet accessible, don't just block entry. Provide some feedback in terms of vital information to the game. If you provide the child with a pen, allow the child to stab holes in the paper as well as write on it. If your background is made of clay, allow the child to smudge parts of it. All these things are vital methods to the child's learning strategy. They also make things infinitely more fun.

Avoid arresting control from the child. This very common failure is found in the best of kids' software. In the early days of procedural code, it was excusable. Today it's not.

We all know how we feel when a process takes over our machine and doesn't allow us to do other work. We're reminded that, "Oh yes, there is a machine here. And right now it's getting in my way." It doesn't feel like fun and it doesn't feel empowered.

When an animation or any process begins - no matter how entertaining it is - the child shouldn't have to wait until the process is over to try out something else. Conversely, trying out something else shouldn' mean aborting whatever is already happening. That's sending a strong message that "You're not really in control here" to the child. Sure, that means a lot better management of your code and a lot more quality control, but the playfulness it adds to your game is well worth it.

Knowing that, here are two caveats: Don't make it too easy for the child to abort a process inadvertently. Remember that children will often click the mouse for no apparent reason. But don't throw in some obtrusive interface, either. Come up with something elegant. Also note that there are situations in which allowing a child to abort a process could severely complicate matters and is simply not worth it (this occurs in adult software, too). But it's a situation to be avoided.

Watch out for "the clickies". This is a typical syndrome suffered by many kids new to computers. In its most extreme form, it involves an almost continuous clicking of the mouse on anything that looks clickable. More commonly, it means that no button survives without at least a double-click - if not a triple or quadruple.

In many cases, this can prevent the child from mastering your game. For example, if the first click of a button initiates an action and the second cancels it, you can imagine how much fun we're having. Similar problems occur when a button leads to a new scene where another button appears in the same place.

Give the kid a break: Test all clickable objects by double-clicking them. You may simply want to clear the event queue of mouseclicks after processing any click.

Don't build in "wrong" responses. This is where so much "edutainment" beats its way to the grave. The last thing any child wants to hear is a machine telling her she's wrong. Up until that point, you had a chance of convincing the child that she controls this mega-power monster.

Let's return to the vacuum cleaner that I made. After the children were empowered to suck the paint off the alphabet blocks, they were concerned about how to get the color back. So I made a holding area where the letters reappeared when vacuumed away. When passing the mouse over these displaced letters, they screamed, "Help! Put me back!" If you dragged them back to their original spot, where they fit in perfectly, they would snap into place. But if not, they would just fall back to the holding area.

This feature provided a great opportunity for kids to learn the shapes of the alphabet characters. Then came the acid test - which turned out to be one of my sweetest moments of success. It was one of the most lucid and revealing windows I've ever had on a child's mind.

I sat a three year old at the machine who didn't know the letter "A" from an ink spill. He vacuumed the letters. He expressed concern. He found the lost letters and dragged them back - without error. Then it happened: He was dragging the capital letter "O" back to its place when he passed over the letter "Q" block. Then he turned back. He lined up the "O" over the "Q" block without releasing the mouse button and said, "Hmmmm. What if...?" And then he let the mouse go. The letter fell back to where it came from. His reaction? "That's funny!" And then he dragged the letter straight to the "O" block where he knew it was supposed to go in the first place.

What exactly the child learned from this exercise is a matter of conjecture. But suppose the machine had been inane enough to tell him, "That's wrong, try again!" I know exactly what he would have learned: Experiments are wrong.

Don't let the machine boss the kid around. Let's get this straight: Machines are tools. Like hammers, screwdrivers, automobiles, and telephones. Tools are things people use. A good tool is one that feels transparent in its master's hand. Now, imagine a hammer that looks up at you and smirks, "Hey, look who thinks he knows how to hold a hammer!"

The greatest, and perhaps most seductive error that we can make with children's games is to make the machine into an entity. No cutesy "I don't understand that" or "Now do this" or "That was wrong, try again." The greatest experience that we can provide for a child is the sense that nothing is as important as the imagination and this game is an opportunity to explore it.

Occasionally, there is a need to instruct the child how to use the game. There are plenty of ways to do this without commands (see figure "Four Subtle Ways to Provide Instructions Without Text").

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.

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 nocomparison 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.

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.

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].