[Designing games is about critical thinking and why you are doing things, rather than learning the rules for a particular outcome and repeating them automatically without thinking, argues lecturer Dr. Lewis Pulsipher.]
As I was thinking about a time when my department head came to my game design class unannounced to evaluate my teaching, I had a "eureka" moment.
When she visited, 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 often don’t know what they did and haven’t learned much.
Like the monkeys who, if they randomly type long enough, will 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, designer of hundreds of published tabletop games and some video games, on Twitter recently said, "To summarize my experience: Design is a way of thinking!")
Video game production (not design) 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. Possibly 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".
This is why so many hardcore video game players despise randomness in their games, they want to be able to find a solution that always works, and some of them (after becoming familiar with the game) then do their "speed runs" where they apply a solution very rapidly. They have "beaten the game" and probably stop playing it soon after.
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 players over time. Frequently this is the difference between, on the 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 by rote how to win at Civilization or Warcraft III (when played against other people), Britannia, or Dragon Rage, Diplomacy or even Risk, they have to understand how it all works and then think as they actually play.
Where is this especially relevant? In social networking games. Run-of-the-mill social network games are so easy to play by rote that few people need to be taught -- or the game tells them what to do. (I'm thinking of games like Farmville, Cityville, Empires and Allies, Yoville, and so forth.)
More importantly, the people who play them are happy to play by rote, they don't want to have to understand, to think about what to do. It is the "mass market", the same kind of terrain occupied by Monopoly, Sorry, and Game of Life. Even many of the most popular "hard core" software entertainments can be played more or less by rote, if you have the hand-eye skills and perception skills. Some of the best require a strong understanding, but they're not the ones that sell best.
[Dr. Lewis Pulsipher is the designer of half a dozen commercially published boardgames, and has over 17,000 classroom hours of teaching experience. His book "Game Design: How to Create Video and Tabletop Games, Start to Finish" will be published later this year by McFarland and Company.]
This article seems to be meandering a bit. You start talking about students in game design not learning by rote, but then move over to game players playing by rote, which sounds like a completely different topic to me. Are you saying that developers who create games by rote training only create games that have training-like mechanics? I'm not sure I follow.
You also mention that a lot of hardcore players hate randomness in their games, and yet a lot of hardcore players also clamor for multiplayer, which introduces the random human element (a concept that you champion in your article).
Sorry, I don't mean to be too critical, I'm just wondering what the real point of the article is.
Agreed. I was loving the first half, but around the time he started talking about hardcore players I didn't know where he was going- and then it just ended.
The conclusion seems to be about social games- no idea how that ties in to the title "Don't Train Students on Game Design- Educate Them."
"A game does not have these kinds of solutions, and cannot be "beaten.""
The ever-shrinking definition of "game" on Gamasutra now excludes Super Mario Bros. and checkers, as well as anything outside the bubble of "puzzle contest."
Keep going guys, at this rate you'll get it down to *just your favorite game* by the end of the year!
Yea, this article is lost trying defend a case for not teaching by rote. The reality is everyone is at a different level learning wise. Many need rote many don't but all need close training to pick up their craft, especially the first few years. Creativity will not be stifled by this rather strengthed through the vigorous self discipline.
You can branch as many and as often times as you like, after that.
My own theory crafting ~ From personal experience at several jobs.
The first year you realize you know nothing.
the second year you think you know everything.
Every subsequent year after you realize how much more you do not know at all.
I think also the best teachers are the ones who realize not everyone learns the same way, or the same speed, but push each student as they are capable ..in whatever means they are capable no matter what classes they are expected to be "done" with.
We see in society that everyone has a role to play, no matter what they bring to the table, personality or intellingence-wise. But the best teacher I ever had taught a class I was absolutely enamoured with, and it was done in an "exercise fashion" ~ build muscles push / then rest.
the biggest crossroads isn't probably as much how good of a teacher you are, but how much sleep the student gets and what they are interested in getting out of the course.
So funny story...I'm a game design teacher whose dean JUST came in to do a class observation and I had the same experience described in the beginning of this article. I cannot agree more that there is an element of "finding your own way" that is better for learning game design. Even in my software classes I tend to be much more hands off, and have been thanked by students for it, by showing them what they need to know to complete projects during short lectures but letting them explore to find what other tools will aid their workflows while being available to help them. Not only does this encourage exploration of features, but it also helps them remember where important buttons, checkboxes, or bubbles are because they have to problem solve their way through issues.
The so called "monkey books" (nice term btw) are absolutely useful for learning the software needed to make modern games. However, they're simply a means to an end rather than the end itself. Even then, there are monkey books that give you a lot of the "whys" of things and what the product of the book will mean to a game's design. This is something I tried to do with the monkey book (it is...I absolutely admit that) I just put out and I really look for when searching for ones I want to buy/suggest.
Knowing a lot about, to use the article's example, 3DS Max doesn't make you a game artist, designer, or developer, it makes you a person who knows a lot about 3DS Max. I would rather work with a Blender user with the soft skills for working out abstract game designs than someone who can only press the buttons on an "industry/curriculum" standard program. Overall the software/methodologies are just another means to an end. A player won't care if the developer used Maya or Cheetah 3D, Photoshop or GIMP, C#, Javascript, C++, or Python - they just want cool/fun/interesting gameplay.
For game schools to create people who will meaningfully enhance the industry, they have to focus on teaching more than just the standard software, they need to shape people who can think through design problems.
Chinook plays checkers the same way any chess program plays chess (selective brute-force alpha-beta search). It makes the early moves of the game "by rote" according to instructions from its opening book, and it has large endgame databases covering all positions with 8 or fewer pieces left on the board, which it uses to play perfectly in the latter part of the game. In between, it uses alpha-beta search with many optimizations and improvements, and a heuristic evaluation function to evaluate leaf nodes in the search tree. Because of the narrow branching factor of checkers, when it exits the opening book Chinook is often in a position where its search can reach all the way into the databases along some lines of play. I guess its also true that for some lines, opening book plus databases will allow it to play every move of the game "by rote", but thats just a technicality... Chinook is basically like every other modern game-playing program that uses alpha-beta.
One interesting thing: When they were building Chinook, their goal was to defeat Dr. Marion Tinsley, who was then the human world checkers champion and who had lost only 5 games in over 40 years of his career. Because checkers is so drawish, the only way to beat him was to use Chinook off-line to exhaustively verify the base of human knowledge about checkers openings, trying to find specific lines of play that decades of human study had reached the wrong conclusions, and program these "cooks" into their opening book so that if Chinook ever found itself in those positions it would pretend to think for the normal length of time, but then choose the "cook" move that the human knowledge was wrong about. Chinook actually managed to win 2 games against Tinsley using this technique, although he beat the program 4 times in the same 39-game match.
Dr. Schaeffer wrote an interesting book about it:
http://www.amazon.ca/One-Jump-Ahead-Challenging-Supremacy/dp/0387949305
This was written not to defend a particular form of teaching, but to make a connection between rote learning, training, and puzzles, and also between understanding, education, and games. (My title was "Training, Education, Puzzles, and Games".)
For something more specifically written about the problems of teaching, see http://gamasutra.com/blogs/LewisPulsipher/20111201/90722/Teaching_Game_Design_Th e_Problems.php
There's an interesting -- and I would say fair -- analogy being made here between game players and (future) game makers.
In the same way that there are gamers whose idea of fun is relaxing with simple, rote games with clear goals where playing long enough generally equals winning, and gamers whose preferred kind of fun is in having inductive insights into solving puzzles, there are people with the practical "builder mind" and people with the conceptual "designer mind." Usually these aren't the same person. So trying to teach them the same way is likely to be ineffective for some of them.
Incidentally, I think of the primary problem-solving approaches used by these two styles as "persistence" and "perception," respectively... and those descriptions apply to how different people make games (building vs. designing) as well as how people play games. "What to do" and "how it works" both matter. ("Why do it" matters, too, but that's yet another style. ;)
I was confused as well. I followed along at the beginning, but started to lose interest. The article contradicts itself. And, I wonder if he isn't leaving out important words sometimes.
He said, 'A game does not have these kinds of solutions, and cannot be "beaten."' ... Is there a word missing? It just said, 'They have "beaten the game" and probably stop playing it soon after'...
And, why all the hating on hardcore gamers? He makes them sound like little miscreants scurrying around with sinister intent... 'Beat the game, BEAT the Game, ... BEAT THE GAME!'
I have to agree with everyone here. The article seems a bit unclear as to the point it wants to make.
I do understand the first part of the article saying we shouldn't train our students but educate. Rote learning is a dangerous but necessary step in students education. It is up to the students to push pass rote style learning. The reason I say that is cause each students learn at their own pace. To force a student to push past rote learning when they are not ready, ends up destroying their confidence in the long run.
But with that said, it is the instructors job to educate the students as to why they make the decisions they have made. For instance, making a game. A student might think that his combat system is awesome and well balanced. But if he has no feedback loop, he fails in teaching the player what is being done. This is where the teacher comes in. He sits down, plays the game, and points out exactly why the students feedback loop is broken and suggest ideas on how to fix it. He's not forcing the student to take one specific action, he leaves it open for the student to learn on his own.
All in all, the reason rote learning doesn't work in the field of games. Is because there is no right way to make a game. You could sit there and spend hours telling a designer why they need a health bar. They can agree. But a health bar can be anything other than a health bar. From hearts that disappear as you're hit, to an invisible health bar that regenerates when the player is "safe". There is no right way to do it.
You also mention that a lot of hardcore players hate randomness in their games, and yet a lot of hardcore players also clamor for multiplayer, which introduces the random human element (a concept that you champion in your article).
Sorry, I don't mean to be too critical, I'm just wondering what the real point of the article is.
The conclusion seems to be about social games- no idea how that ties in to the title "Don't Train Students on Game Design- Educate Them."
The ever-shrinking definition of "game" on Gamasutra now excludes Super Mario Bros. and checkers, as well as anything outside the bubble of "puzzle contest."
Keep going guys, at this rate you'll get it down to *just your favorite game* by the end of the year!
You can branch as many and as often times as you like, after that.
My own theory crafting ~ From personal experience at several jobs.
The first year you realize you know nothing.
the second year you think you know everything.
Every subsequent year after you realize how much more you do not know at all.
I think also the best teachers are the ones who realize not everyone learns the same way, or the same speed, but push each student as they are capable ..in whatever means they are capable no matter what classes they are expected to be "done" with.
We see in society that everyone has a role to play, no matter what they bring to the table, personality or intellingence-wise. But the best teacher I ever had taught a class I was absolutely enamoured with, and it was done in an "exercise fashion" ~ build muscles push / then rest.
the biggest crossroads isn't probably as much how good of a teacher you are, but how much sleep the student gets and what they are interested in getting out of the course.
The so called "monkey books" (nice term btw) are absolutely useful for learning the software needed to make modern games. However, they're simply a means to an end rather than the end itself. Even then, there are monkey books that give you a lot of the "whys" of things and what the product of the book will mean to a game's design. This is something I tried to do with the monkey book (it is...I absolutely admit that) I just put out and I really look for when searching for ones I want to buy/suggest.
Knowing a lot about, to use the article's example, 3DS Max doesn't make you a game artist, designer, or developer, it makes you a person who knows a lot about 3DS Max. I would rather work with a Blender user with the soft skills for working out abstract game designs than someone who can only press the buttons on an "industry/curriculum" standard program. Overall the software/methodologies are just another means to an end. A player won't care if the developer used Maya or Cheetah 3D, Photoshop or GIMP, C#, Javascript, C++, or Python - they just want cool/fun/interesting gameplay.
For game schools to create people who will meaningfully enhance the industry, they have to focus on teaching more than just the standard software, they need to shape people who can think through design problems.
One interesting thing: When they were building Chinook, their goal was to defeat Dr. Marion Tinsley, who was then the human world checkers champion and who had lost only 5 games in over 40 years of his career. Because checkers is so drawish, the only way to beat him was to use Chinook off-line to exhaustively verify the base of human knowledge about checkers openings, trying to find specific lines of play that decades of human study had reached the wrong conclusions, and program these "cooks" into their opening book so that if Chinook ever found itself in those positions it would pretend to think for the normal length of time, but then choose the "cook" move that the human knowledge was wrong about. Chinook actually managed to win 2 games against Tinsley using this technique, although he beat the program 4 times in the same 39-game match.
Dr. Schaeffer wrote an interesting book about it:
http://www.amazon.ca/One-Jump-Ahead-Challenging-Supremacy/dp/0387949305
For something more specifically written about the problems of teaching, see http://gamasutra.com/blogs/LewisPulsipher/20111201/90722/Teaching_Game_Design_Th
e_Problems.php
In the same way that there are gamers whose idea of fun is relaxing with simple, rote games with clear goals where playing long enough generally equals winning, and gamers whose preferred kind of fun is in having inductive insights into solving puzzles, there are people with the practical "builder mind" and people with the conceptual "designer mind." Usually these aren't the same person. So trying to teach them the same way is likely to be ineffective for some of them.
Incidentally, I think of the primary problem-solving approaches used by these two styles as "persistence" and "perception," respectively... and those descriptions apply to how different people make games (building vs. designing) as well as how people play games. "What to do" and "how it works" both matter. ("Why do it" matters, too, but that's yet another style. ;)
He said, 'A game does not have these kinds of solutions, and cannot be "beaten."' ... Is there a word missing? It just said, 'They have "beaten the game" and probably stop playing it soon after'...
And, why all the hating on hardcore gamers? He makes them sound like little miscreants scurrying around with sinister intent... 'Beat the game, BEAT the Game, ... BEAT THE GAME!'
/scratches head (like the monkey I am)
Gigi.
I do understand the first part of the article saying we shouldn't train our students but educate. Rote learning is a dangerous but necessary step in students education. It is up to the students to push pass rote style learning. The reason I say that is cause each students learn at their own pace. To force a student to push past rote learning when they are not ready, ends up destroying their confidence in the long run.
But with that said, it is the instructors job to educate the students as to why they make the decisions they have made. For instance, making a game. A student might think that his combat system is awesome and well balanced. But if he has no feedback loop, he fails in teaching the player what is being done. This is where the teacher comes in. He sits down, plays the game, and points out exactly why the students feedback loop is broken and suggest ideas on how to fix it. He's not forcing the student to take one specific action, he leaves it open for the student to learn on his own.
All in all, the reason rote learning doesn't work in the field of games. Is because there is no right way to make a game. You could sit there and spend hours telling a designer why they need a health bar. They can agree. But a health bar can be anything other than a health bar. From hearts that disappear as you're hit, to an invisible health bar that regenerates when the player is "safe". There is no right way to do it.