A Eureka Moment about Training, Education, Puzzles, and Games

I was thinking about a time when my department head came to my game design class unannounced to evaluate my teaching, and I wasn’t “lecturing” to the students.  They were working on game projects.  (This was not an introductory class.)  She seemed surprised that I wasn’t lecturing, but that may be because she typically taught introductory computer literacy style classes such as how to use Microsoft Office.  Classes that teach use of specific office software can be taught more or less by rote: if you want to make something bold you highlight it and press control-B or click the Bold button.  If you change margins you do thus and so.  And so forth.

These intro software classes don’t have to be taught entirely by rote but commonly they are, complete with what I call “monkey books”.  These books have students follow steps to accomplish something, but students tend to focus on getting through as rapidly as possible, and when they’re done they don’t know what they did and haven’t learned much.  Like the monkeys who, if they type long enough, type Shakespeare’s works . . .  You can learn from monkey books, but only if you want to learn and make the effort to learn.

Designing games is not and can never be taught by rote.  Teaching by rote is training, not education.  Education is about why you do things, why some things work and others don’t, about understanding what you’re doing.  Training is about exactly how you get a particular thing done.  I recognize that not everyone follows those definitions but I find it very useful to make this distinction, and other people with other purposes when defining education and training may make different distinctions.

Designing games is about education, not training.  Designing games is about critical thinking, and much of it is thinking, which is the antithesis of training.  You’re trained to do things automatically, without thinking.  (Reiner Knizia on twitter recently said, "To summarise my experience: Design is a way of thinking!")

Video game production at the outset can be taught by rote because people are learning how to use particular software, for example Maya or 3DS Max, or they’re learning how to program.  In the long run there is a process of education there, especially for programming, but in the short run for introductory classes a lot of it is simple straightforward “this is how you do it”.  There just isn’t much of that in game design.

But where the Eureka moment occurred was when I realized that an analogy can be made from this to games and puzzles.  A puzzle is something that has a solution, or perhaps several solutions, with the defining characteristic that once you figure it out the solution(s) always works.  So you can teach someone by rote how to beat the puzzle by teaching them the steps required.  It’s possible that those steps require certain skills such as hand-eye coordination levels that the person may not have attained, but once they attain those skill levels they can follow the solution and complete the puzzle every time, or as it is said in video games, “beat the game”.

A game does not have these kinds of solutions, and cannot be “beaten.”  To be good at the game requires something much more akin to education than training.  You have to understand why you’re doing what you’re doing, and when that isn’t the best thing to do, when something else is the best thing to do.  There is certainly problem-solving in games, but there aren’t solutions to the game as a whole that will always work.  Frequently this is the difference between having human opponents and having no opponent or a computer opponent, though computer opponents continue to become better over time.  Frequently this is the difference between, on th one hand, perfect information or uncertainty that can become predictable, typical in puzzles, and on the other hand uncertainty that cannot be predicted or accounted for by simple mathematical processes–the kind of uncertainty that comes from having several human opponents.

You can teach someone, by rote, how to win at Tic-Tac-Toe, or even Tetris, and you could for chess if anyone had completely solved the extremely complicated puzzle.  The checker program Chinook, as I understand it, plays by rote, playing what it knows to be the move most likely to lead to a win from whatever the current position is–no reasoning required.  You cannot teach someone how to win at Britannia or Dragon Rage, Diplomacy or even Risk, by rote, they have to understand how it all works and then think as they actually play.