The Designer's Notebook: Educational Games Don't Have to Stink!

Way back in 1982, I took a university course in formal logic presented entirely by computer. In those days it was done via a text-only terminal attached to a mainframe somewhere else. Also - quite innovatively for its time - it used automated speech generation to speak its text as well as showing it on the screen. The program demonstrated the principles of logic, then offered me problems to which I had to type the correct answer.

I found it slow going. Although the machine allowed me to proceed at my own pace, the material was dry and presented without any reference to the real world. There was no equivalent of the "story problems" that we used to get in math textbooks, which gave practical applications for the concepts we were learning. In fact, I came within an ace of flunking the course because I didn't get through enough lessons in time.

The logic class at Stanford was one in a long line of efforts to teach people things using computers, stretching back to 1960 and possibly even earlier. Formal logic was an obvious subject for computerized education. The system's designer, legendary philosophy professor Patrick Suppes, crafted a robust and efficient means to teach it. What he couldn't do is make it inspiring or personally meaningful.

Later on I took another class with Dr. Suppes, at the very opposite end of the curriculum: the political philosophy of liberty. It was the first time I met him, because he had never appeared in person during the logic course. We read the works of John Stuart Mill, Mary Wollstonecraft and Friedrich Hayek, among others. There were only three people in the class, so we all just sat around a table and talked about the things that we had read. Dr. Suppes did not lecture or make pronouncements. He treated his students as equals, fellow-seekers of truth, so long as they were intellectually honest. His eyes were black and hard, and when he peered at you from under his bristling white eyebrows, you knew that you had his full attention… and that you had better say something that was worthy of it. I felt as if I were back in ancient Athens, sitting under the tree with Socrates. It was scary and exhilarating, one of the best classes I ever took.

I had had two courses, both ostensibly from the same man, and the contrast between the two modes of teaching could not have been greater. The former went in one ear and out the other, and I learned the material only for so long as it was necessary to solve the problem sets. The latter introduced me to ideas that I still think about today. It wasn't just a question of the nature of the content, but how I learned it and what I could do with it.

My feeling as if I were studying with Socrates isn't just exaggeration. Suppes himself has written in his "Intellectual Autobiography" (1978):

Over twenty years later, we're still a long way from meeting the Socrates Standard. "Teaching machines," as they were once called, have mostly failed us. They're OK for typing, or for drill-and-practice lessons, only just tolerable for things like chemistry or history, and hopeless at debating the political philosophy of liberty. They generally teach in a linear, inflexible way. They cannot think up new analogies to help convey an idea to a student. A good teacher can adapt his approach to the strengths and weaknesses of his audience on the fly. It's like the difference between a computerized dungeon master and a human dungeon master in a role-playing game. The human can modify the quest to take into account the particular composition of the party of adventurers.

A lot of bad educational software was designed beginning with the assumption that human interaction is unnecessary, and teachers are superfluous. This is wrong. Good teaching still requires a teacher. A teacher's two greatest tools are charisma and attention, both things that computers cannot offer. A teacher uses his charisma to create interest and excitement in the student, and uses his attention to reward, punish, and compel attention back from the student. A student knows that when a computer program says "Well done!" it's just a programmed response, and if she does badly or ignores the computer, the computer doesn't really care. Computers don't pay attention; all they do is sit and wait for input.

When you start talking about computer games, as opposed to other instructional software, the situation gets even more complicated. Now you're not only trying to teach, but to do so in an entertaining way. Lately there has been growing interest in using computer games to teach, both in schools and in the home. As a longtime game designer, and as a more newly-minted teacher, I have a somewhat heretical view of this.

My heretical view is simply this: computer games don't teach. I think the idea that you can teach using computer games is based on a flawed analogy between gameplay and learning. Here's how the analogy goes. Players of games have to overcome obstacles in order to achieve victory. They do this by learning the weaknesses, or limitations, of the opponents they face. Similarly, students learn knowledge in order to pass tests. So learning a fact is equivalent to defeating an enemy, and passing a test is equivalent to achieving victory. And a great many educational games are created this way.

This is a terrible way of learning! Why? Because in playing a game, the instant an enemy is dead, we forget him. We are only concerned with him for as long as it takes to beat him. This was, in effect, what happened to me with the computerized logic course. I passed each lesson, and remembered its message only insofar as it was necessary to pass another lesson. When they were all done, I forgot the lot.

(That "forgetting" is a positive benefit to us as game designers - it makes games replayable! If you didn't have to re-learn a bit every time you played, to re-experience some of the challenges, games would have no replay value.)

The analogy is flawed because computer games are not good at imparting knowledge or explaining principles. That's not what they're designed for. They're disorganized and chaotic - intentionally so, that's part of the fun. Games throw a whole collection of challenges at the player, usually all mixed in together, to create an exciting, varied experience. Even a simple first-person shooter usually combines explore-the-space, avoid-the-traps, find-the-keys, shoot-the-monsters, jump-the-crevasse, conserve-your-ammo, spot-the-secret-doors, and don't-get-killed, all at the same time! In Sim City the player has to look after money, power, water, roads, crime, pollution, tax rates, and so on, again all at the same time - and that's before actually doing any city planning or dealing with disasters. If you fire up Sim City and you don't already know what you're doing, you'll probably fail and have to try again. You have to discover its principles by trial-and-error. That's unsystematic and grossly inefficient. Good gameplay, perhaps; bad pedagogy for sure.

In short, it's my belief that games don't teach, they illustrate. That's an important distinction. Games are not useless in the educational process, but they're not good at teaching per se. Games are good at creating understanding of knowledge the student already has. And they're excellent at transforming abstract ideas into concrete experience. Games don't teach, but they can help people learn.

Sim City came with a big manual that explained all the ideas upon which the game was based. If you wanted to play the game well, you had to read the manual first, and then when you played the game you could see the ideas in action. The manual taught; the game illustrated. Big manuals are out of fashion nowadays, so instead we use tutorial levels. But the tutorial levels are not the real game. They're a stripped-down version of the game that explain a few principles at a time. Unfortunately - unlike a manual - they're also expensive to create and take up a lot of disk space. And they certainly don't come anywhere near the Socrates Standard.

So, having said all this, I have a number of concrete suggestions for using games as part of an educational process.

Admit that games don't teach, they illustrate. If you're going to create an educational game, make a game that shows rather than tells, that turns intellectual knowledge into visceral understanding.

Don't make games that are too much fun. It would be a mistake to try to demonstrate the principles of flight using a combat flight simulator. A fighter jet is so powerful that it is much less affected by gravity or the winds than a single-engine Cessna is. Furthermore, a combat simulator has too many distractions: radar, missiles, enemies, missions, and so on. The students will spend all their time fighting and ignore the basic concepts they're supposed to be learning. It's simply too much fun, and the game rewards things that have nothing to do with flight itself: enemy kills rather than coordinated turns. Instead, create a simple game that directly illustrates the principles and ties victory to understanding them. Avoid irrelevant details that are lots of fun but have nothing to do with the subject.

Games that are too much fun are usually made by professional game designers, who treat learning as a by-product, not an essential element of the gameplay.

Don't make games that aren't fun enough. These games are usually designed by teachers who don't know enough about entertainment. They're often poorly-disguised drills, or are insulting to a child's intelligence ("Quick! Mr. Spock needs to know the sum of 2 and 2!"). Such games fail to engage the student's imagination, and there's little connection between the material to be studied and the (often rather feeble) game world in which it is supposedly being used. You must find a way to meaningfully and above all coherently incorporate the educational content into the gameplay.

Don't make games that take too long. Commercial games often have huge setup times - creating characters, learning the user interface, building a base, and so on. Commercial games are designed to last from 20-40 hours or more, which they do by dumping the player into a minefield of simultaneous challenges or introducing their ideas very slowly, with tons of repetition. This is called providing value for money, but you can't afford it an educational environment. In a school, the bell rings every 50 minutes. An educational game needs to get straight to the point and move along steadily.

Don't make games that obscure the principles you want to illustrate. Games like Sim City are driven by interrelated systems of equations, and as I said above, require the player to manage a whole series of problems at once. Rather than illustrating a single idea clearly, they illustrate many ideas complicatedly. This is OK if your main point is to show just how difficult a city planner's life is; but if you want to study a specific relationship, then the student must be able to hold all other variables constant and observe the effect of changing just one. (Sim City is actually better than most in this regard; Sim Earth was nearly incomprehensible.)

Include advisors. An advisor is a computerized character that pops up from time to time to highlight problems and suggest courses of action to the player. In some games it isn't a character, just a scrolling text bar or window that displays the same kind of information. As a general principle of game design, all games need a feedback mechanism to let the player know how he's doing, but advisors also give hints or make recommendations. These help to reinforce in the player's mind how a particular issue is to be managed. In Theme Park, for example, the advisor said things like, "The roller coaster has broken down. Send a mechanic."

Don't forget the value of creative play. Up until now I have been talking about concepts, challenges, and consequences -- classic competitive gameplay. But creative play has educational value too. You can learn about the principles of mechanical engineering by designing and testing bridges, as in Bridge Construction Set (formerly Pontifex II) from Chronic Logic, which won the Independent Game Festival's Audience Award. You can learn about human perception by mixing colors in additive and subtractive modes. You can learn about genetics by breeding new creatures in an artificial life game. A game does not have to feel like a thinly-disguised exam. Look for ways to let your students experiment and create rather than just answering questions.

Don't try to serve chocolate-covered broccoli. You can't make a kid like broccoli by covering it in chocolate. A computer game can't make someone take an interest in a subject purely by dressing it up with fancy graphics and audio. Furthermore, educational software cannot ever compete with multimillion-dollar commercial games, any more than wildlife documentaries can compete with Hollywood blockbusters. It is an expensive, wasteful mistake to try. Strive to be the best at what you are, not what you wish you were. Choose a level of visual and audio content that fits within your budget, then execute that content as beautifully as you can within those constraints. It's quality, not quantity, that counts.

There are a lot of cheap, cruddy educational games out there, and the problem is often both poor design and poor production values. But a great artist or a great writer can work wonders with nothing but a pencil if they have the talent for it, and the same is true of a game designer or a teacher. Educational games don't have to stink, and as a learning "modality" (to use a buzzword currently popular in academic circles), they don't deserve the bad reputation that they currently have. The idea of using games to learn is a good one even if some of the implementations have been poor. Let's keep working towards the Socrates Standard.

______________________________________________________