Bloom's Taxonomy

In the past, I've said that there's a direct link between education and game design. Mostly, I think about things that teachers can learn from the field of game design (because in my experience, a lot of teachers have trouble with something that games do really well: actively engaging the players/students). But this is my bias, because I have a lot more experience designing games than I do teaching. I'm just now realizing that game designers should be paying more attention to the field of education as well.

Case in point: Bloom's Taxonomy. Most game designers have never heard of this. I've heard it referenced often when teachers are talking to other teachers about their field, so presumably it is to education what the MDA Framework is to game design.

What is Bloom's Taxonomy? Long story short, it's a model for how we learn. First, we memorize a bunch of facts without really understanding them; then we start to understand what these things all mean, and we begin to actually use them to solve known problems; eventually, we learn to analyze new problems and solve them too, and if we stick around in a field long enough we learn to put existing tools, models and techniques together in new ways so that we can solve some problems that couldn't be solved before; finally, we get to the point where we can not only solve our own problems, but also evaluate other people's work in a competent way (which is something that, ideally, all teachers are capable of... but I digress).

Bloom's Taxonomy is important in teaching because it helps you to think of appropriate ways to design your courses based on learning goals. If you want your students to emerge from your course with the ability to analyze problems in your field, you're not gonna get there if all of your assignments and tests simply require rote memorization. On the flip side, if your goal is for your students to be able to apply knowledge to solve specific types of problems, then asking them to make abstract value judgments on other people's work is probably too advanced for the level you're teaching.

But enough about teaching -- think about this in terms of game design. Bloom's Taxonomy describes any kind of mastery... such as the act of a player mastering a game:

• Knowledge = learning the basic controls and mechanics of the game
• Comprehension = learning to use the controls without looking at the manual every 5 seconds; understanding the challenges that the game is throwing at you, and the general nature of what you must do to overcome them (whether you're capable of doing so or not)
• Application = advancing in the game, using your skills to "beat" an enemy, boss, level, etc.
• Analysis = optimizing your gameplay, e.g. choosing the best combination of skills, items and equipment for your party in an RPG. In other words, powergaming.
• Synthesis = finding new methods to optimize your gameplay with. The player innovation in MMORPGs of calculating "damage per second" as the ultimate measure of strength is an example of this. Anyone can use damage-per-second, but to come up with the idea in the first place required a pretty deep understanding of the game.
• Evaluation = at this point, I think we see a solid division between your average gamer and someone who has crossed the line to being either a game reviewer, critic, or designer. This would be the ability to look at several similar games and decide which one is "better" in some way (more fun, more balanced), while being able to back it up with solid reasons.

As a game designer, this has clear applications. Most games do not make use of all of these steps; a simple retro-arcade twitch game never goes beyond application, while only the most open-ended experiences lend themselves to any synthesis tasks. And this is fine, but it helps to explain why, say, a retro-arcade twitch game with an inventory/equipment system, multiple character classes, multi-level tech trees and such would probably not work.

This also explains what you need to do if you want to create an open-ended game where you expect players to find their own unique solutions to your puzzles (as in Thief or Portal). You have to work up to it, first taking your players through the knowledge, comprehension and application steps and making sure they're comfortable with those (perhaps by forcing them to: making it so that they cannot progress until they have mastered the basics). Only then can your players impress themselves with their own ingenuity at putting two mechanics together in creative and unexpected ways. Just giving the players all the tools up front and letting them play won't work, any more than giving your players a stack of equations on the first day of Physics 101 and then expecting them to "put it all together" and build a working rocket.