Game Design Tech Tree, version 0.1 (beta)

I put this together today and thought I'd share. I've attempted to list every major skill or task that falls under the broad field of "game design." I then tried to create a kind of progression, based on which skills are desired prerequisites before learning or performing others.

This is very much a work in progress (I haven't even added any icons yet), so your comments are welcome. Click on the image for a large version.

Since this is mostly a graphical version of notes to myself, some explanations might be required. I'm not sure how much is obvious to the casual observer, however, so rather than write a lengthy essay explaining every last detail, I'll simply answer any questions you have in the comments here. Enjoy!

Stop saying "They Don't Teach You This In School"!

Twice in the past week I've run into a person that said as part of their presentation, something like "this is the stuff they don't teach you in school." In both cases, this was part of a presentation given at a school. Does anyone else see the irony here?

Okay, in some cases a person is saying this and they're not at a school. But you know what? If that person is saying anything that's really useful, before too long educators are going to notice, and we'll incorporate it into our curricula, and now it will be something taught in school. The very pronouncement that something "isn't taught in school" is self-defeating.

If it were just a matter of technical details, I'd leave it at that, but there is something more insidious going on here. When someone makes this kind of statement, the implication is that there are important things you don't learn in a traditional classroom setting. This may be true, but why? The primary reason is that you get out of your education what you put in, and that some things only come with experience, so students should stop waiting for their professors to spoon-feed them everything they need, and go out there and make learning a passion, and learn this stuff on their own.

However, all too often I think students take away an entirely different message: school is useless, your teachers are lying to you, the only real thing that matters is getting a "piece of paper," feel free to ignore all of your course content, what it takes to succeed is not hard work but rather knowing a few key "secrets" that take no effort. This attitude is incredibly damaging, especially to professors like me who are bringing their own real-world experience into the classroom setting and actually teaching the things that students aren't supposed to learn "in school."

Game Jams in the Classroom

Just talked at GDC yesterday for a whole five minutes, on applying Global Game Jam in the classroom in five non-obvious ways (you know, other than "get students to participate"). I think I was talking too fast for anyone to actually take notes, so here is the gist:

1. Have students read post-mortems and do a cumulative analysis.

The "post-mortem" is a tradition in the game industry: after a project is released, a reflection on what went right and what went wrong in the process (or as I put it: "figuring out why your game sucked as badly as it did"). You can find these on Gamasutra and in Game Developer magazine, and you can even see student post-mortems on Game Career Guide. And to start with, reading these is valuable for students so that they can see the patterns and get a feel for the most common pitfalls and dangers of game development.

Beyond this, though, it's instructive to have students search for Game Jam post-mortems (these are unofficial and tend to be on individual participants' blogs, so you have to do some digging to find them). The interesting thing is that a lot of themes in industry post-mortems on 5-year AAA projects also appear in Game Jam post-mortems (scope control, pipeline problems, engine difficulties, team communication, etc.). So a lot of the same lessons apply on how to develop a game, whether the game takes 2 days or 10 years.

2. Game Analysis

I teach a class called "Game Criticism and Analysis" (sort of like art criticism or film criticism, but with games). The goal is to be able to play games and analyze them in a way that's a little more sophisticated than "it's good" or "it sucks."

Normally, analyzing a full game is really hard in a class, because many games are very long to play ("80+ hours of gameplay!" is a common marketing tactic), and even shorter games are still 8 to 10 hours, which is hard to justify if you want students to analyze a new game each week.

Game jam games offer a solution. Because they are made in a short period of time, they tend to play quickly and have relatively simple systems, lending them to play in class or as homework without taking too much time.

3. Minimum bar for student projects

For "capstone" and other project-based courses where students work individually or on teams to make complete games over an academic term (or several), game jam games provide a realistic, achievable yardstick to measure project quality. I mean, these games were made in 2 days, so your students should be able to do at least as well with 15 weeks.

The best, most clever Game Jam games can be used as a source of inspiration for students, that they should be able to do better with so much more time. They can be used as a grading rubric, letting students know the quality level you expect (and informing the teacher about this as well).

4. Achievements

We tried some new things at Global Game Jam this year, among them Xbox-Live style "Achievements": totally optional extra challenges to allow experienced developers to really push their boundaries. It allowed people to seek their own level of challenge and comfort.

I see no reason similar things can't be implemented in most class assignments. (We already offer "extra credit" but "Achievement Unlocked" sounds so much more fun.) You can offer extra points, or you can simply make it available for the purpose of bragging rights.

5. Fix a broken game

As you might imagine, with only 48 hours, some games don't actually work. Maybe the team overscoped and had to make drastic cuts at the end. Or maybe the programmer stayed up a little too late and wrote some terribly insane code at 3am and now the entire thing is a mess. The whole project team would like nothing better than to sweep the whole thing under the rug and pretend it never happened (and hopefully take away some life lessons about how to not make games).

Additionally, there is often a disconnect between classes (where students typically start with a blank slate and write a complete, simple program from scratch) and industry (where you are almost always working with someone else's pre-written code, not even counting the use of game engines).

Luckily, one of the rules for Global Game Jam is that everyone (in theory at least) has to submit their complete game (including source code)... working or not. This suggests an interesting assignment: find a game that has the source code posted that doesn't actually run, and assign a programming team to fix it, while staying as close as possible to the original design intent.

Your students will hate you. They will complain that the people writing this code were horrible programmers. They will complain that the code is a mess, and that they just want to rewrite it all from scratch. They will probably use a lot more profanity than you are used to hearing from them. In other words... they will start to sound a lot more like professional game programmers :-)

Games at Conferences

As I'm going to GDC next week, it occurs to me that one of the things I'm known for in my small circle of colleagues is that I'm the guy who brings the board games. Video game developers generally like to play board games, and I happen to have a sizeable collection, so this is a win-win.

Playing games at conferences is different from playing them at, say, a local game club. The social dynamics, physical setting, and time availability are constraints on the kinds of games that people are most likely to enjoy. Let us take GDC as an example. Here are some considerations:

• I'm flying in, so I have limited space in my baggage (especially if I want to leave any room to take back some swag). This favors games that are small and portable -- card games, but even some board games that come in big boxes if I can remove the bits from the box, put them in plastic bags, and have them take up a lot less space.
• Most venues are noisy, so it's better if games are either well-known (I don't have to explain the rules) or simple (I can explain the rules quickly without blowing out my voice). This also unfortunately reduces the value of games where players have to speak a lot (e.g. those games that focus on trading, diplomacy, or negotiation mechanics).
• GDC is crowded, and every ten seconds one of the people at the table is going to turn around, see an old friend, and have to go off and say 'hi'. Games that are short (like, five minutes or less) are good here, as are those rare games that allow free entry and exit of players without screwing up everyone else. Ironically, games that have lots of player downtime can work well here: it lets players socialize with non-players when it's not their turn.
• Table space is plentiful at the conference, but not so much at parties. Some board games that use a lot of space are fine at breakfast, but I also need to bring a few games that are a little more compact for the nightlife. (Also, most nighttime activities involve drinks... so waterproof games are a plus, as are games that can be played competently while drunk!)
• Number of players is a consideration. Games that only support 2 or 4 players, or those that work best with a specific number, are not as good as those with wide ranges (2 to 8 players). You never know exactly how many people you'll have.
  
• Avoid games with play times more than 30 or 45 minutes. Someone will inevitably have to go to a session, or get called away on business.
• Games that have some kind of visual "wow" factor are nice, because they act as an attention-grabber for anyone walking past. This gives everyone at the table the opportunity to network, if only by answering the question "oh, what is that game?" over and over (hey, any excuse to get a business card). Note that board games with all the bits crammed into a plastic bag aren't so appealing at the table; this year I'll experiment with printing out a sheet with the game box artwork to stick in the bag, to make it look nicer.
  
• Know the audience. Three games in particular seem to be loved by a disproportionate number of game developers I know: Family Business (which I never have to bring because someone else inevitably does), Pandemic (everyone seems to love it but no one owns it, making it an obvious choice for me to cart along), and Dominion (sadly disqualified because it doesn't travel well, though I may attempt to stuff the basic set into an old box I used to use for Magic cards).
• Game developers (particularly designers) have discriminating tastes, so I try to bring games that showcase some kind of unique mechanic. If I can introduce other designers to new mechanics, this buys me street cred :-)
  

Given all of this, what games will I bring this year? I won't know for sure until I pack, but here are some likely candidates:

• Incan Gold. Supports 3-8 players, has a small game box, the rules are ridiculously simple but still engaging. Plays in five rounds, with each round taking only a couple minutes, and players can theoretically leave in between rounds without screwing up the other players.
• Pandemic. With the expansion, supports 2-5 players. Plays in about 45 minutes, pushing the upper limit for a game at breakfast, but this game sets the gold standard for pure-coop play in a board game... something that is notoriously hard to do.
• Hey! That's My Fish!. Serves 2-4. Small box. The rules can be explained in less than a minute, and play lasts for about five minutes. Delightful experience in such a short time, and it has these ridiculously cute penguin pieces.
• Notre Dame. For 3-5 players, takes about 45 minutes, and is about as complex and strategic as I dare to bring. That said, it has some absolutely brilliant mechanics, and is obscure enough that a lot of people still haven't played it yet. The box it comes in is large, but it's mostly empty space, so it collapses nicely.
  
• Brawl. This real-time card game takes about a minute to explain and another minute to play. Theoretically supports multiplayer, but works best with 2. That said, the games are so fast that this makes a good filler if you happen to only have one other person and you're both waiting for some other people to show up. Comes as a set of small decks of cards, so it's very portable.
  
• Rock!. Another real-time card game, also works with 2 (although I learned a nifty 3-player and 4-player variant from the publisher last summer). In an elegant way, demonstrates an important design principle: time pressure makes you stupid. It's just a single deck of cards, and even comes in a metal tin to protect the cards.
  

Other conferences have different criteria. GDX, for example, is a more relaxed atmosphere where you can actually congregate for a few hours at a time. So the games I bring there is different.