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.

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.

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").

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.

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.

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 TzviF@aol.com.