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:
It should be enjoyable and attractive both for a child and an adult.
It should allow plenty of opportunity for the child and the adult to interact with each other. On the other hand, the child should be able to figure out how to have fun without any adult supervision. (This is what really takes brains.)
It should be versatile and deep enough to be fun to a wide age-group of children.
It should have qualities that grandparents will consider educational. (You and I know that if it's good software, it's educational. But it might be hard convincing Grandma and Grandpa of that.)
It mustn't have anything that could make adults uneasy about recommending it for small children. In other words, avoid violence.
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.
The Print Shop (Broderbund)
Obstructs many children younger than 10 from thinking creatively or working independently by providing mind-boggling abstractions and procedures.
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.
Kid Pix (Broderbund)
Long-time king of the child software market--allows kids to do the wacky and ridiculous. It was created by Craig Hickman with his 3 year old on his lap. When Broderbund handed it over to an outside contractor for version 2, they wrecked havoc.
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!"
1. MAKE IT OBVIOUS.
This is the ideal, but most difficult method of providing instruction - the sign of a masterpiece. Create an environment where the child will determine intuitively what is to be done in each situation. Borrowing familiar objects and dynamics from the child's world will help a lot.
2. CHARACTERS THAT TALK TO THEMSELVES.
Instead of telling the child, "Now do this," have one of the characters (or objects) talk to itself about what needs to be done.
3. TEACH BY EXAMPLE
This is a common strategy in 2D scrollers. Have some other character - even the enemy - do what you would like the child to do. Repeat it until the child picks it up. Children like to imitate.
4. ENCOURAGE EXPLORATION.
Make your environment free and comfortable enough that children will be willing to try things out until hitting on what you want them to do. While they're figuring it out, they'll still be having fun.
Four Subtle Ways to
Provide Instructions Without Text
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").