Game Balance Concepts

So, for those of you who recall, I ran a free online class last summer. (If you missed it, all of the content is still there, and you can feel free to look through it at your own pace.)

Well, I'm doing it again this summer. Game Balance Concepts is a ten-week course that will go in depth in the topic of game balance.

Why do this again? Because I'm clearly insane. Also, I'm hoping to actually get paid for my time. But mostly, it's because game balance has always been an interest of mine, and it's the kind of niche class that I would never be able to teach (or even propose as a Special Topics course) as an adjunct. So, this is the best method I have of creating an experimental course with original content, just to see what happens.

At any rate, the class starts on July 5, so come and join me.

Takeaways from GECS

I'm just getting caught up from attending GECS last week and meeting a bunch of other really awesome people. The focus of this workshop was using games to teach STEM courses; usually the crowd I hang around with is game developers who get into teaching, but here I saw more educators who were taking steps into games, so it was a bit of a different perspective. Here are the lessons I learned:

There is interest in games beyond "game development" schools and departments. Some traditional educators see games as a means to an end, a way to make their content more accessible. From their perspective, they couldn't care less whether it's games, or inquiry-based learning, or circus clowns, as long as it gets their critical course content to stick in their students' brains. This is certainly not always the case -- there are plenty of professors who delve into games because they are gamers -- but there are others who are unfamiliar with games but are still trying to use them because they want to be effective teachers. The game industry (especially those of us who teach) need to reach out more to other departments, rather than staying in our own comfort zones.

Games are not the only way to teach. While some "serious games" people like to tout games as some kind of panacea that makes all learning activities more fun and engaging, the best examples of so-called "games" that I saw were not taking advantage of the interactivity so much as non-game elements that are engaging. One example, by engineering professor Brianno Coller, illustrates this. He opens a course in Control Systems by presenting this racing-car game, where the car is controlled by some very simple source code. It starts out not doing anything; he tells it to move forward, and the car drives straight into the first wall. He then tries to get it to take a corner, by steering towards the center of the road (with the tightness of the turning proportional to how off-center the car is -- if you're at the side of the road, you swerve wildly, while a slight displacement only requires a slight correction). This seems intuitively like it would work... but when you run it in the simulation, something strange happens. The car takes the first turn, but then starts veering wildly out of control, vastly overcorrecting for its position, until it eventually gets so far out of line with the road that it crashes into a side. This leads into a discussion and exploration of why that happened, how to correct it through a phase shift, and all of the calculus and other heavy math that you need to derive it. He has found that this method of teaching is far superior to simply diving into the equations with no context.

Is Brianno's course superior because it uses games to teach? I don't think so. Instead, what he's doing is opening his lecture with a real-world mystery, something the students can see that is interesting and counterintuitive, and then he goes through the course material to solve it. Once he's got that "hook" the students are much more interested in learning the material, because it's not just a bunch of random facts and equations anymore... the learning has a purpose. And while that mystery may be presented within a game world, I don't think it's the game that gets student interest as much as the mystery itself.

A storm is coming, and it is going to suck. One concern I'm seeing from a number of people is that game industry growth is not keeping pace with the number of graduating students from game-related programs, and yet the number of academic programs is still increasing. As a result, I think the industry is going to get more and more competitive over time, and things are going to be pretty rough for students for awhile (until we find some kind of equilibrium). Corollary: it's likely that we will see more industry "abuse" of fresh students, in terms of expecting long hours and lower pay, since there is more labor supply than demand. Reputable schools should warn their current and prospective students about this trend. (Don't worry about dropping your enrollment numbers; in practice, you're not going to be able to talk most students out of choosing a game development major, anyway.)

Another storm is coming, and it is also going to suck. One by-product of the many industry layoffs this last year, is that a lot of ex-developers are considering teaching as a career, which is a great thing. However, to save costs, a lot of schools have been taking advantage of this by hiring more adjuncts and reducing their full-time staff. This is exceedingly dangerous on the part of the schools that do this, and here's why: the game industry is cyclical in nature. When the next upswing hits and the industry goes on a hiring binge again, schools can expect at least half of their adjuncts to leave. If a department that used to be 50/50 between full-timers and adjuncts goes down to 20/80, and then half of the adjuncts leave, the result would be devastating.

We think there are more academic standards than there actually are. How many schools has the average faculty taught at? I don't know, but the answer seems to be pretty low. And yet, a lot of people I talked to just assumed that their experience would extrapolate to every school in the country. One example is the assumption that adjuncts always get paid less than full-time faculty; I've run into some schools that pay them about the same per course (it's the same course, after all), and other schools that actually pay adjuncts more, on the theory that (a) they need to partly make up in cash what they don't pay in full-timer benefits, and (b) a lot of adjuncts have day jobs, so teaching is effectively "overtime" work for them, and they need the extra pay as incentive to put in the extra hours. Another assumption is that full-time faculty always teach a certain number of courses each term; I've seen requirements of anywhere from 5 courses per term down to one course per year, depending on the school, the department, and how much research the faculty is doing outside of their classes. Another assumption: everyone complains about how hard it is to work across departments because they are "silos" and yet I've seen some rare schools where inter-departmental collaboration is the norm. It seems to me that each school is different, and there are few if any standard practices that really apply everywhere. I was just a bit surprised at how many career faculty seemed unaware of this.

Upcoming Events

Looking for something game-related for your students (or you) to get involved in? Here's what my calendar looks like for the next few months:

Health Games Challenge: this weekend (May 21-23)! A 48-hour game jam (i.e. build a game from scratch in a weekend) based on the Apps for Healthy Kids competition. We have seven sites: Boston MA, Seattle WA, Albany NY, Athens GA, Fairfax VA, Orlando FL, and Pittsburgh PA - site info is available on the event website. If you're not near a site, you can still participate from home; send an email to info@healthgameschallenge.org stating your intentions. I like game jams to begin with, as they provide a great experience in a short time; this one in particular is interesting because the end result might actually do some good in the world. (Full disclosure: I'm one of the organizers for this event.)

Games in Education and Computer Science: June 3-4. Registration is closed for this workshop, but if any of you happen to be going, I'll see you there. Participants will work together to identify problems and solutions in the space of using games in engineering / computer science education. Work groups will producer reports (similar to Project Horseshoe), so expect a post here, after the fact.

Game Education Summit: June 15-16. I attended this last year in Pittsburgh, and there is no better place to meet people who are interested in the intersection of games and education. This year it takes place in Los Angeles (a bit far for me to drive, so unfortunately I can't attend this time), but highly recommended if you're in the area and/or have a travel budget.

Origins: June 23-27. This consumer-focused game convention takes place in Columbus, Ohio and is the third largest such event in the world (after Gen Con and Essen Spiel). Teachers get in free as usual (you need to show some kind of academic credentials). While there are some education-focused sessions, mostly it's about immersing yourself in playing all manner of non-digital games. This makes it more useful for game designers than, say, programmers or game audio folks.

Protospiel: July 9-11. I went to this last year and it was the most amazing experience I've ever had as a game designer. It is essentially a small gathering of non-digital game designers who spend a weekend playtesting each other's games. These are people who understand games, design, and playtesting, so it is about the best kind of feedback you can possibly get. Potentially instructive for students who want to see what real playtesting is like. The down side is that it's in Ann Arbor, Michigan, so it may not be in your area. If you are in the Austin, Texas area, there's also the inaugural Protospiel South coming up soon (May 28-30).

Overall, it's looking to be a busy and eventful Summer!

Adjunct versus Full-time

In the game industry, there is a big difference between working for a single company full-time and being a freelancer. In education, we use the term "adjunct" instead of "freelance" but they are essentially the same thing. There are benefits and drawbacks to each.

Benefits of Freelancing/Adjuncting

• You can make your schedule as light or heavy as you want, with a proportional increase or decrease in pay. Since you're paid by the hour (or by the project, or by the class), "unpaid overtime" is not in your vocabulary. And if you've got the extra cash to hold you over and you feel like taking a month-long vacation between projects, no one's going to complain.
  
• For industry freelancing, you typically make more money per hour than you would if you were salaried. Stupidly, the reverse seems to be true for adjuncts at many schools, but this will vary from school to school.
• You are, essentially, your own boss.

Drawbacks

• Everything listed above has a flip side.
• You only get to "set your own schedule" if you successfully drum up business. Sometimes your services just don't seem to be needed by anyone, and if you don't have a nice fat cash reserve, you starve. Other times it seems like everyone wants you to do something, and you have to turn down work because you just don't have the time. Freelancing is a feast-or-famine world.
• You'll also find that psychologically, it is really hard to turn down work when someone is offering you cash. Even if it puts you in "crunch" mode to get everything done. Even if the project is a boring, soul-sucking grind. Saying "no" is a skill that most of us need to learn, and we learn the hard way.
• You know about that "make more money per hour as a freelancer" thing? There's a reason for that. First, it's to compensate for the times when you don't have any work. Second, you don't get benefits -- no 401(k), no health or dental plan, no free games and snacks in the break room -- unless you pay for them yourself. So even though you get more money per hour of your time, overall you usually end up making less money per year than you would at a full-time job. (Naturally, this is even worse as an adjunct at schools where you get paid less per class than full-timers.)
• You basically must have a fair amount of experience working full-time at a game company. For industry freelancing, you need a proven track record, but more importantly you need the personal contacts that come with the territory -- who do you think is going to hire you? For adjunct teaching, the whole reason to hire you instead of having a full-timer teach the class is that you've got field experience. So, freelancing is not an option that's open to you fresh out of college; it's a door that opens up slowly as you gain experience, and the more experience you have the easier it is. (If you've got 10 years experience like me, you get most of your business through a few key contacts. If you've got 30 years experience like some people, all you need is to Tweet saying "I'm looking for contract work, any takers?" and you get a dozen offers in five minutes.)
• There are a lot of little hassles that are fairly trivial on their own, but collectively make your life a little more annoying. You have to bill clients and wait for them to pay you, rather than just having ADP send you a direct deposit automatically. Your taxes are more complicated because you receive a dozen 1099s instead of a single W-2. You have to keep separate folders for the multiple projects you're working on, and double-check every email to make sure you're not sending proprietary Company A information to the guy at Company B by mistake. You have to do some research on health insurance, rather than just checking a box next to Self, Spouse or Family on the HR booklet.
  
• Yes, you're your own boss. As your own boss, you're a slave driver.

You can, of course, get the best of both worlds by having a day job and then moonlighting. Assuming your day job doesn't have you working so many hours that you wouldn't have the time.

The Good and Evil of Internships

Internships are typically short-term jobs targeted at students. In theory, the company gets the benefit of a "try-before-you-buy" way to evaluate potential junior-level hires before they graduate: that is, hiring a new person is much less risky if you've already worked with them before (assuming you actually liked their work, of course). In exchange, the student gets that all-important industry experience that gives an edge when they seek full-time jobs after graduation. Oh, and the company gets cheap labor. And the student gets to work on an awesome project like a game they'd like to play, which is like the bestest summer job ever.

In theory.

In practice, there are pitfalls on both sides.

From a company's perspective, interns aren't as cheap as you'd think. What you aren't paying them in wages, you're paying for in time: your average intern needs a bit more hand-holding (or as we call it, "management") than your average full-time employee, which means they are sucking time away from your more productive full-timers. If a $7/hour intern takes up an hour a day of your $80/hour programmer's time... well, you can do the math, but it's a bit more than it looks like on paper. And what do you get in exchange? Game companies don't typically want cheap employees, they want productive employees, and someone who (by definition) has no practical experience is not necessarily going to be that productive. Yet.

From a student's perspective, it's not all sunshine and roses either. Yes, you're working "at a game company" but what are you actually doing there? You are probably not working on anything mission-critical. Maybe you're doing QA, where you at least can't do any real damage if you suck at your job, but if your end goal is to be (say) a level designer then you're not really learning much about how to, you know, design levels. Maybe you're given menial tasks like taking notes in meetings, making copies, and picking up food deliveries. Or maybe you're given a real, honest-to-goodness game development task in your preferred field, and at that point you should be wondering why the company is getting away with paying you so much less than the other people who are doing the same work in the cubicles next to you.

This subject has come up a bit lately because of the somewhat common game industry practice of unpaid internships. There are some problems here:

• In some cases, they are actually illegal. The criteria vary from place to place, so companies doing this would do well to consult a lawyer.
• Even if it is technically legal in one particular case, there is the potential for others to see the practice as exploitative.

Is it actually exploitative? In my experience, no. The studios I've seen that offer them tend to be very up front about the fact to any potential interns. For exceptional interns, the companies do usually pay them (as long as they don't go parading it about the other interns). Because they are getting free/cheap labor, they're willing to work around the intern's schedule -- it's not a 40-hour work week so much as "show up whenever you want, choose your own hours". It's hard for me to call this exploitative, certainly not on the order of third-world child labor sweatshops or anything.

This is particularly relevant for schools that have game dev programs, as most of them encourage their students to get internships, some schools actually require that students have a documented internship for graduation, and others offer course credit for internships (paid or not). In particular, this means schools need to:

• Do some due diligence. Be aware of the labor laws in your area. I don't know if a school could get in legal trouble for deliberately steering its students towards illegal work, but I wouldn't want to chance it.
  
• Keep up with local companies. Know which ones offer internships. If any of them offer internships that are technically illegal, it would be a great opportunity to gently notify them of this fact (for their benefit, so they can protect themselves -- it's probably just a matter of the studio not being aware).
• Educate your Career Center, professors and students. For students especially, make sure they understand the issues at stake as they choose a place to work at.

Educators can certainly be part of the process of making sure this all happens.

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.

Project Horseshoe

So, I went to Project Horseshoe this year, not knowing exactly what to expect, but hearing from survivors of earlier years that it was awesome. I was not disappointed, and now I understand what it is all about.

The format is highly similar to a game jam. The first night, we collect in one place and have introductions and casual conversation. Bright and early the next morning, we brainstorm a bunch of potential projects to work on, and then aggregate around a few that are of passionate interest. Then we spend the rest of that day and most of the next day working on our projects. At the end of the second day, we present our results to the entire group. I've praised game jams before, so if you like that kind of "get lots of amazing stuff done in a very short period of time" you'll understand the appeal of an event like this.

There are two key differences between PH and a game jam. The most obvious is that in PH we are not making video games from scratch, but rather brainstorming the solutions to difficult problems facing the game industry (for example, my group worked on how to build ethical decision-making into games, in a way that is more sophisticated than a choice between pure-good and pure-evil). So it is more of a "game design jam" than a "game jam."

The second difference is the quality of people. PH is invite-only. This is similar to the difference between the Global Game Jam (open to all) and the Indie Game Jam (invite-only among a small circle of professional game devs). Both methods can work well, either a focus on quantity or quality... as long as the "quantity" method includes some way for the great stuff to bubble up to the top. PH is in the latter camp.

All reports (from this year and previous years) can be found here.

Relevance to teaching:

• Some reports may be directly relevant to student projects. For example, in one class this quarter, I see one student proposing a game with ethical decision-making and three students writing proposals for Facebook games, both of which are topics covered this year.
• In a course on the game industry, game design, or game criticism/analysis, one possible assignment could be to read a report of the student's choosing and present it to the class -- the same way other courses might do the same with reading and presenting a current research paper or foundational article from the field.
  

Escapist article

My debut as an Escapist columnist was just posted. It amazes me that I'm at a point where I can just send emails to some well-known game developers asking interview questions, and they actually respond. I'm still not sure how this happened.

For students, I'd also recommend reading the editor's note to this issue. It describes a little of the culture of game development, and is a reminder that this is not just an industry of gamers, but of human beings. Sometimes as a rabid game fan it is easy to lose sight of that.

One interesting thing I just realized is that you might or might not be able to ask the same question ("what games do you keep playing obsessively?") of teachers. Yes, many game development teachers are rabid gamers... but I've run into more than a few that have no personal interest in games. But I don't think I've ever met a game designer who didn't love games. It's strange, the differences between the two worlds.

Now, I just have to decide whether The Escapist counts as a peer-reviewed publication for purposes of my CV... probably not.

Culture Shock: the role of policy

In academia, there is less of a team spirit than there is in the game industry. Probably this is because there is less of a threat of, say, an entire department getting laid off because their collective product didn't sell enough units at retail. This difference has many manifestations.

One difference is in how closely people follow written policies.

In industry, while most workplaces do have some kind of Employee Manual with a list of policies, these are usually seen more as guidelines (except in the obvious cases where there would be legal repercussions if the policies are ignored). Getting an exception to, say, a sick leave policy is a matter of talking to your boss about it and having a good reason, especially if that reason ultimately benefits the team and the game.

In the academic world, policy seems a lot stricter. Asking for an exception is essentially asking your boss to go through some kind of appeals or justification process on your behalf. It is asking for more work, in a world where everyone already has quite enough work on their plate, thank you. So it is far more likely to meet a stone wall in this case. You are more likely to see bosses and administrators hiding behind official policy rather than explaining it or working around it, because following the rules is the path of least resistance, and there isn't much personal reward to putting in the extra effort.

For my peers in industry considering academia, this is one of those annoying things you can expect to run into. Ultimately, it means you have to choose your battles carefully, because you won't have enough time to fight over every silly little thing (at least, not if you expect to get all your work done).

Obviously, not all schools are this bureaucratic, and not all game companies are this relaxed. I'm talking general trends here, based on my experience. As usual.

Textbook Review: The Art of Game Design

It's been awhile since I did one of these, mostly because I've been busy with other things aside from reading. I'm glad to be looking at textbooks again, because quite a few interesting ones have surfaced in the past year or two. And so today I examine:

"The Art of Game Design: A Book of Lenses" (Jesse Schell)

Now, this book came out about the same time that mine did, and it managed to steal the spotlight, so I really wanted to hate it. But it really is a solid book, and fully deserves the praise it has been receiving.

The information is solid, as I would expect it to be. Game design is a broad field, and Jesse has an even broader skill set, allowing him to effectively write about game design... but also about a variety of other fields that game design can (and should) draw from. This on its own makes the book stand out; many books that are supposedly on game design do not teach the first thing of it, so it is nice to read from someone who actually knows what he's talking about.

The writing is very conversational and even intimate in tone. Only Jesse could have written this, and his voice is very clear in the writing to anyone who has met him. There are no practice problems or quizzes, making it feel more like a guided tour than a stuffy textbook. I found it easy to start reading, easy to keep reading, and very accessible throughout.

Perhaps the best part, the part that I am likely to steal for my own classes, is the organization of the book. Each chapter introduces one aspect of game design, such as story, game worlds, game mechanics, game balance, or the iterative process. The topic is explored in depth, and connected to other topics. Throughout the book, a concept map is built piece by piece, chapter by chapter.

The book is comprehensive, covering not just the core concepts of game design but also everything immediately surrounding it: interfacing with the rest of the development team, dealing with companies and funding and profit-making, player communities, and so on. While a "pure" game design course might eschew these kinds of peripheral topics, I find their inclusion necessary as a way to prepare students for the realities of the industry: you are not going to be creating your own games from whole cloth, you will be designing other people's games according to their own constraints, so get used to dealing with that on multiple levels.

Embedded within each chapter are a series of "lenses" as alluded to by the subtitle. Each lens is one way to evaluate a game-in-progress, and includes one or more direct questions to ask of the current iteration. Many of the lenses directly reference one another (or sets of lenses are grouped together in the text), making something of a concept map between them as well.

If the book has any weakness as a course textbook, it is that it does not give exercises or other tasks that could be assigned as homework, so the teacher will need to provide that on their own. Additionally, the book seems to naturally assume that the reader is already working on their own game idea; it therefore does not provide any direct call to action for readers (particularly students) who may not know where to begin if they have not already started. In this, it actually makes a great companion to my book (which is practically nothing but a series of constraints that can be used to start a game project).

Students: If this textbook is not required reading in your game design courses (or especially if you do not have any game design courses), take some initiative and go read it yourself. Its combined breadth and depth make it an ideal starting point to show you all practical areas of game design and (most importantly) to get you thinking like a designer. Think of it as a foundation, upon which everything else can be built.

Instructors: This book is perfect for an intro game design course. You could cover a selection of topics that are of interest to you (or that best fit your curriculum), or try to cover all of the topics briefly just to give some exposure (as you might in a survey course). Consider having students hang onto this text so that some parts can be referenced in higher-level design courses.

Also, if you are just planning out your first game design course, you could do worse than following this book (addressing each chapter in the order it's presented) as a rough syllabus.

Professionals: A lot of the information here might seem basic if you are an experienced designer. That said, we all have our weaknesses -- a technical designer might not be great at building worlds, while not all story writers are proficient at game balance -- and this provides an accessible way to get at least a minimum baseline of understanding of those other parts of design that are so mysterious to you. The most useful part will probably be the lenses themselves (of which you can purchase a separate deck of cards, one lens per card, as a quick-reference) as they provide an easy way to objectively examine the game you are currently working on.

Lessons from SIEGE

For those of you waiting patiently, I am now back, and can hopefully get back to a quasi-regular posting schedule. This summer's online course took pretty much all my attention, and I am now getting caught up.

(For those of you working at game companies or academic institutions, I'm going to teach another free class next year, and am looking for sponsors. If you want to broadcast your message worldwide to people interested in learning game design, email me: my address is ai864, and it's a yahoo.com account.)

I returned just last week from SIEGE 2009, a small conference in Atlanta. Even though it is largely focused on game development in Georgia and the surrounding region, for some reason they like to bring me down there. I spoke on a panel about experimental games (short version: find them, play them, make them) and ran two game design workshops. Here are my takeaways from the conference:

Game Writing

Story/dialogue/creative writing is one of my weak points as a designer, so when people who know about this stuff are speaking, I pay attention. This session was given by Bill Bridges, Nathan Knaack, and Joe Carriker.

• Create a backstory document for internal use only. The idea, I assume, is that you should know enough about your world that (especially if you use multiple writers) you can avoid contradictions and continuity problems. This was referred to as the "writing equivalent of concept art."
• The hardest part of game writing is making it succinct, because game writers instinctively want to write long walls of text (which leads to the "TLDR effect").
• Separate the gameplay-relevant text from the flavor text (flavor text is, by definition, that text which is not useful for gameplay and is purely for the enjoyment of players who want to know more about the story world). A good example of this was given in World of Warcraft, where the text for a quest includes a short gameplay synopsis ("kill 5 rats") alongside a large block of flavor text (telling you why you're supposed to care about killing 5 rats).
• Someone asked, why not include some gameplay text inside the flavor text, as a way of giving a gameplay bonus to those players who read the story? Great answer: if you do this, you are giving a gameplay advantage to precisely those players who don't want it! The players who care about getting more plusses on their equipment are the ones that ignore your story because it slows down their power-leveling, and if you force them to read your elaborate story just for an extra +1 they will resent you for it. (The roleplayers who just want to immerse themselves in the story, meanwhile, are more concerned with reading the story then optimizing their stats.)
• Corollary: one positive trend in game writing these days is to try to embed the story in such a way that it is optional -- players who care about it can spend all the time they want reading it, but it should not get in the way of players who just want your story writers to shut up and get on with the game already. (Ideal example: the audio tapes in Bioshock.)
• When writing dialogue for characters, give each character a unique voice. By giving different accents and verbal mannerisms, it's an easy way to give them more personality, while also making it easier for the player to tell the NPCs apart.
• Writing for MMOs is a huge challenge, above writing for most other kinds of games. Why? Because story is about change, and in MMOs there is not a great deal of change. Any game writing in MMOs has to work around this somehow.

Player-Centric Design

The actual name of this talk was "Getting the Human in the Game" and it was about never forgetting that you're designing your game for actual players, not robots. What followed was a blast of quick game design tidbits from designers Andrew Greenberg, Danny Miller, Michelle Menard, and Harrison Pink.

• Many games follow the classic Hero's Journey quite well, until you get to the end, where the hero is supposed to return with the Prize and then share it with the rest of society to make a better world. This last bit is an important part of the classic story structure, and most games leave it out entirely. One major exception: MMO Raids, where a group of heroes follow this journey and return with epic loot that they can all share.
• One other challenge to the classic Hero's Journey: most hero stories center around a single heroic figure, but in games we are moving towards a collaborative set of heroes rather than a single central hero (think Team Fortress 2 or Left 4 Dead). This is not unheard of in classic hero stories either (Jason and the Argonauts has an all-star cast of heroes, it's not just about Jason) but this is something that contemporary game writers should be aware of when crafting their stories.
• Interesting potential for exploration in game design: there are six primal emotions (fear, disgust, joy, sadness, surprise, anger). Instead of saying "I'm going to create a game that causes a particular emotional response in the player," start the other way around: find existing game moments that produce your desired emotions, then extrapolate to figure out what mechanics can cause those emotions.
• When trying to force an emotional response in the player (especially towards an NPC or other object in the game world), do not assume players will inherently know that, say, dogs are scary or that they should love butterflies or whatever. Show them through NPC dialogue or behavior modeling that this is how things are in your world. For example, if you want the player to find a certain flower beautiful, have an NPC remark on how pretty that flower is. (I think a great example of this is the Weighted Companion Cube in Portal, where players can become emotionally attached to a crate, simply because this psychotic disembodied voice tells them to.)
• Numerical score is meaningless nowadays. You scored 10,500 points -- is that good or bad? How would you know? An alternative is low-dimensional scoring (say, a score of 1 to 10). There is a temptation to make scoring complicated for the purposes of game balance, and feel free to do this, but it is important to make the final score less granular so that the player can have some idea of how good they really did. Examples: ranks or letter grades; achievements and badges; or giving some kind of context ("your score is better than 80% of other players").
• We think little kids are dumb, but they are actually smarter than we are much of the time. When designing for kids, we tend to lead by the hand to make sure they don't lose... but the end result is that they don't feel a sense of accomplishment. Alternative: create safe spaces for kids to fail.

Better Business Models

Jason Della Rocca gave a wonderful keynote entitled "10 things that don't suck about the industry." There were a number of points he made, but the most relevant takeaways I saw were from finding new business models beyond the current AAA publisher / third-party developer model.

• Current typical business model: spend lots of money (in the millions), then stop development and release your game, then make money (hopefully more than you spent). This sucks -- you get no feedback during development, so the best you can do is cross your fingers and hope. Failures are expensive and cannot be undone, leading to the excessive risk-aversion that we all love to whine about.
• Here's a better alternative, which we are already seeing with many social network games: spend a small amount of money, then do a "soft" beta launch and start making money much earlier. At this point you can then manage your income against your development expenses in realtime. Ideally, have several games in development at once, and you can shift dev resources from the worst-performing to best-performing games.
• Even better: we are moving towards a better understanding of how to collect and make use of metrics in games. Combine that with fast releases, and we can use metrics to figure out what games are and aren't making money, and why. This can greatly reduce the risk of development, allowing developers to take greater creative risks while still reducing the cost of failure.
  

Soundbytes from Protospiel and SIGGRAPH

Protospiel is an annual gathering of non-digital game designers who come together to playtest their current works in progress. This is not a typical conference -- there are no sessions, lectures, or keynote speakers. It is all playtesting and analysis from start to end.

That said, I picked up a few things. In no particular order:

• Resource: http://www.eaieducation.com/ - a website where you can order colored stackables, plastic cubes, and other useful game prototyping bits for relatively cheap.
• Ever since the success of the Pandemic board game, a lot of people have been experimenting with pure cooperative games (I saw a number of co-op games at Protospiel, in addition to the ones coming out on the market already). One problem with the entire genre is when you have a situation with one expert player working with a group of novices. In this case, the expert dominates the game: they can either sit down and shut up and let everyone else flounder about (and now the expert is bored), or they can take charge and direct everything (and now everyone else is bored). They can offer hints while still letting everyone else retain their autonomy, but overall the game relies on the expert player to keep things fun (rather than the gameplay itself being inherently fun). This is a problem that arises from games that are purely cooperative and also offer complete information sharing between players. One possible solution is to build "information walls" between players so that a single player doesn't have the info to direct everyone else... but then this pushes players towards playing individually rather than as a coordinated team, and the whole point of being "cooperative" is lost. One interesting solution I'm seeing is to make the play real-time, so that the expert player just doesn't have the time to coordinate everything; this is how co-op video games work (one player can't simultaneously work four keyboards and mice), and there's no reason it can't work with board games... in theory.
• Games for girls: an important aspect here is the social dynamics between players. One designer did research on this by actually going to a mall, sitting on a bench outside a trendy store, and observing groups of shoppers. I thought this was a rather clever way to do research on a target audience, and could probably have applications with other audiences.
• Resource: A lot of designers have a game from Amigo called Rage. This is not because Rage is all that great a game. It is because it is a card game with seven suits, numbered 1 to 15 in each suit, along with several Joker-like suitless cards... meaning that you can use some subset of a Rage deck to prototype just about any card game you can imagine.
  

From a purely cultural standpoint, I noticed some interesting things about board game designers when they get in large enough groups for culture to emerge:

• You can tell which hotel rooms are populated by board game designers, because they all have the "do not disturb" sign hanging on the door at all times, even when they're not there. Why? Because they have learned through experience that hotel cleaning staff will often mistake their prototype game bits (torn pieces of paper, index cards and cardboard, etc.) for trash, and throw them away... or, almost as bad, to "helpfully" organize them so that you can't find anything. One game company employee reported that they no longer outsource the cleaning of their office, after one time when a janitor threw away a bag with prototype bits and a playtest notebook (this would be the non-digital equivalent of having your IT guy accidentally delete your entire code base on the server, along with all backups.)
• There are some differences in jargon between board game and video game designers. "Analysis paralysis" (where a player spends too long thinking about their turn, stalling the game) happens frequently enough in board games that it is simply referred to by its initials, as in "this game is really prone to AP, you should add a sand timer." In video games, AP means Associate Producer, which is a bit different.
• Meanwhile, a lot of board game designers have not been exposed to video game development at all. In a relatively large group discussion, someone was afraid of making too many differently-shaped custom pieces, and I suggested using "palette-swapping" -- that is, use a small number of shapes, and color them differently. No one had ever heard of the term before. This would not happen in a gathering of video game devs.

SIGGRAPH (I'm not sure why, but I always see people capitalize it like they're shouting it) is a conference on computer graphics, blending both the artistic and technical. At first I felt a bit out of place as a game designer (we don't normally work with graphics directly), but I found a lot of kindred spirits that are either teachers or game designers, and I wrote down a bunch of notes... again, in no particular order.

• Nowadays, some game design students are hired in large companies as Associate Producers and are given some basic production and design tasks to see what they can do. If they're really good at one or the other, they can transition into a role that fits their skills. If they suck at both, they can just get fired without too much pain.
• For educational games, align the learning goal with the core game activity / mechanics; use the peer network as a learning environment; make sure that increasing relevant skills outside of the game translates to better performance within the game. (In this case, "gaming the system" or using a "walkthrough" or "FAQ" -- normally considered cheating -- is actually a good thing... as long as doing so allows the student to meet learning outcomes.)
• There is natural tension between wanting to give the player complete agency, and wanting to give a controlled, focused (if "on rails") experience. Interesting compromise: use psychological principles (such as reciprocity, scarcity, appeal to authority, etc.) to manipulate the player towards the game's goals. The player maintains their sense of agency, while still doing what the designer wants them to.
• Consumer psychology research is useful when making persuasive games, since marketing to consumers is essentially persuasion.
• In cooperative games, think of communication as the core mechanic. If passing information to your fellow players has an in-game cost, that makes things interesting (and also solves the "expert player" problem identified earlier).
• I used to assume that a game with intentionally incomplete mechanics -- that is, games where the rules MUST be interpreted or invented by players and cannot be 100% standardized -- could not be faithfully represented as video games. After all, video games require programming code, and programs can only follow instructions, not make value judgments or rules interpretations. But I missed something. You can do this in a limited sense, by putting certain parts of the game under manual player control. As an example, there used to be a client called Apprentice that let you play Magic: the Gathering online with your friends. This program didn't implement any of the rules of the game at all; it just let you click and drag cards and tokens around a virtual game board, and displayed your cards to your opponent. It was up to the players themselves to actually play the game by the rules, without using the computer as a rules mediator. A similar thing could be done for other games, such as tabletop RPGs (or games where one of the rules is essentially "the players decide on a rule").
• Girl Scouts and Boy Scouts have offered "Merit Badges" as a reward system since, like, forever. It only took the video game industry about 35 years to figure out how compelling this was. What else can we learn from the systemic psychological indoctrination of kids, in terms of how to use that to make better games? :-)
• Resource: Future Pinball is a free-to-download pinball simulator that allows players to construct their own tables out of parts, with mostly click-and-drag functionality and minimal scripting (no hardcore programming). This offers some great opportunities for game design students. For one thing, very few 18-year-olds today are intimately familiar with Pinball, so it is a level playing field. Pinball table layout is highly constrained (by both space and availability of parts), preventing projects from having scope that grows out of control. Pinball table design uses the same skills as any other level design. By tying a "create a pinball table" assignment to an intellectual property (such as a recent popular movie or TV show), students can be challenged to take an existing narrative and translate it across media... a good skill to have, and a challenging one in the case of Pinball where the player actions are highly non-linear and unscripted (and unlike video games, it's hard to put the player "on rails" in Pinball).
• One difficulty with making games with sexual content is that sex is extremely personal and different for everyone. Interestingly, I think the same is true of spirituality; if someone discovers how to make a compelling game that can bring a player closer to God, the same techniques could probably be used to make a serious game about sex. Is that ironic?
• Will Wright was quoted as not liking the term "non-digital" to describe board games and card games and the like. He prefers "matter-based" games. I am amused.
• As a teacher, convincing students to attend local industry functions (such as IGDA meetings) can be a challenge. Some students do not see the value, and approach this as "more gross-icky-disgusting-learning outside of school, and not even for a grade, so why spend my free time with that". Others see the value but are intimidated, and don't want to do anything embarrassing in front of the very people who may want to hire them later, so they just don't show out of fear. Professors may want to think of ways to work around this. Or, we could take the approach that the students that don't show are the ones that wouldn't make it in industry anyway, so it provides a useful selection/filtering process.
• When analyzing games as an art form, where is the art? It can be found in many places: the visuals (obviously)... although there may be a distinction between "game art" and "art-games"; the game mechanics to the extent that they lead to play that expresses meaning; player activity which can be artistic, but raises the problem (expressed by Roger Ebert) of authorship -- if art requires an artist, is the artist the game designer or the player? ; the game environments, as an analogy to designing the stage as opposed to writing a play; the game code itself, to the extend that it enables everything else, and also that it can push the boundaries of the technology (consider the parallel between coding on a very constrained platform like Atari 2600, versus writing a constrained poem like a Haiku).
• Currently, a lot of traditional museums are confused with how to frame interactive exhibits. Actually letting visitors touch the art is new to them and makes many of them nervous. As more artists are creating interactive works, and as more museum curators are considering ways to make the entire museum-going experience more interactive (even "game-like"), this problem is being attacked from both ends and will probably become a non-issue within our lifetimes.
• Aristotle's three-Act structure doesn't translate well to games, because Acts 1 and 3 essentially map to non-interactive cut-scenes. Almost the entire game is Act 2. (However, if you use the three-Act structure on a micro level to design quests, NPC plot arcs, individual levels, and so on, it can lead to a more robust larger story.)
• Game writing tips: don't write about what the main character does, but what they will experience (remember, the player is in control of what the main character does). Think of game fiction as told through objectives and rewards. Don't tell the story through the main character; instead, write the story through the NPCs and their own points of view.
  
• Use the game space to create memorable moments.
  

Twitter as Education Platform

Yesterday afternoon, something magical happened. A game design discussion spontaneously broke out on Twitter. The original topic of discussion was the role of narrative in games, but eventually it extended to several other topics. Some really top-tier designers were taking part in the discussions, including David Jaffe, Clint Hocking, Damion Schubert, John Romero, Harvey Smith, Brenda Brathwaite, and about a dozen others whose names you should know if you are at all interested in this industry.

The main conversation continued until past midnight. Pearls of game design brilliance dropped constantly, each in 140 characters or less. It was amazing to see. As of right now, there is still some discussion happening. There was talk of formalizing this and turning it into a regular thing, but I think the fact that it just randomly happened is part of what made it special.

Search for the tag #gamedesign on Twitter to see the whole thing, unreadable though it may be in linear format.

Why is this relevant to teaching game design? Because most practicing designers do not have the time to write a textbook, yet we teach from textbooks. Some designers have blogs, but the best we can do is reference specific entries from the past, and even then it is usually a single designer's opinion (if we're lucky, a few other designers will have a discussion in the comments on the blog). There are GDC roundtables, which are usually not audio or video recorded. There are closed-to-the-public email discussion groups, which do filter out slowly but cannot be followed in real time. But this Twitter thing -- it happened in a very public place, and just kind of emerged as an ongoing conversation. That is how developers spread information, by talking to one another and letting their experience and wisdom spread virally among the community.

I don't know if we'll see this happen again, but those rare times when it does are worth reading.

Report from Game Education Summit

I'm just catching up from the excellent Game Education Summit earlier this week. Here are my notes:

Donald Marinelli, keynote:

• Much of today's educational system is obsolete. Summer vacation exists to let young people go home and help their families with farm chores. How many K-12 students do you know that are planting wheat right now?
• If you are building a game for a class, build it for someone. Give it a purpose.
• ETC's "secret sauce" is that they let students teach each other.

Terrence Masson, on building Northeastern University's curriculum:

• Interesting way to structure a Capstone course with 10 people: first day people give their project pitches (most students pitch several alternative projects). Second day, students narrow the pitch list down to the two projects that the class will work on; students choose their teams (split into two teams of 5); each team assigns roles and chooses their project lead. Essentially, the students drive everything.
• Another interesting thing about this program is the requirement of two non-adjacent semesters in internships/co-ops. The benefit is that students keep the faculty honest: "What do you mean we don't have Zbrush on campus? That's what everyone is using now!"
• Note to prospective students: at this particular institution, the program is called "game design" but it is actually "game development". This points to the importance of schools and industry using a unified set of terminology.

Jessica Hammer, on how to teach creativity:

• First, you have to define what "creativity" is, because it is an overloaded term, and there are different kinds of creativity. She defined it as "appropriate novelty" -- something that is new, but within a given context/domain. (If you ask students to design a game and they write an essay instead, and try to define an essay as an innovative new type of linear-narrative game, this is not what we are looking for.)
• Creativity happens within a context or domain (i.e. within a set of constraints). There is a virtuous cycle within a field, where the domain influences individuals; the individuals produce creative work within the domain; and the gatekeepers who see this work then influence and redefine the boundaries of the domain to compensate. In the case of teachers, the classroom is the domain.
• One problem in practice is that we often measure creativity after the fact: we look at the final product and decide if it is creative. Unfortunately, this tells us nothing about the process used to create it... and if we want to teach creativity, we want to teach the process!
  There are three aspects to the creative process that students need to understand: the generation of novel ideas, the ability to decide what ideas to pursue (since ideas are a dime a dozen, once you learn how to generate them), and the motivation to follow through on your chosen idea and do the work to turn it into a final product. The class should focus on these.

Jessica's hints for course design:

• Begin with outcomes. "The goal of a course is not to deliver content, but to transform your students."
• Consider the length and pacing of the class. If there is not enough time to generate ideas, fail many times, and still finish, students will take fewer creative risks.
• "Personal attention is valuable currency." Keep class sizes small when possible. Group work can enable larger class sizes by having you deal with a small number of groups rather than a large number of individuals.
• Recruitment is rarely thought about, but is important. The more diverse your class (or, um, game studio), the more creative the ideas you're likely to see. When approached by a female and/or minority student, be supportive and ask if they have friends who would also be interested in taking your class. Also, consider the accessibility of your classes: if students can choose between written or verbal assignments, you will see higher enrollment among those for whom English is a second language.
• Use a lot of class time on playtesting and peer review. Professor should model appropriate feedback, to show what it looks like.
• Encourage uncertainty, in projects, classes and life. "Your game design education does not end when you leave this class. It has just started."
• Don't just have students solve problems that are handed to them, because this is not how real life works. Have them create and seek out their own problems to solve.
• There is a negative relationship between the time and emotional investment in a project, and willingness to take risks. In the middle of larger projects, consider giving smaller-scale "lightning round" design challenges that encourage creative risk-taking -- for example, email students with constraints of a challenge at noon one day, and they have 24 hours to post a short concept in an online discussion group. These are not a major component of the course grade; they are a chance for students to show off. Examples: "Design a game to be played in the waiting room of an ICU while you're waiting to see if a loved one lives or dies." / "Design a game for NASA that can keep astronauts alert and interested on a 3-year mission to Mars." / "Design a game for Obama's cabinet to help improve their effectiveness as a team."
• How do you assess creativity? Note that you get what you measure; students will game any system. If you want to reward risk, you have to give grading opportunities for it. Jessica splits the final project grade into three equal parts: the game itself (the final result of the process), the theory (students write a companion paper that shows the connections between the theory learned in class and its expression in their game), and the process (students submit a "process paper" that includes everything that was part of the project but not visible in the final form: raw data, early playtest results, early versions of the game, mechanics that were tried and abandoned... whatever the student wants the instructor to see).
• Divide larger projects into many feedback cycles / milestones. Iteration is part of the creative process, and class projects should reflect that.
• The nature of instructor feedback is important. If you just give a grade, that carries very little information. Extensive written feedback is much better, but can take a lot of time; to manage this, favor group projects or smaller numbers of submitted projects per-person.
• As the instructor, you are a strong influence on the culture of the classroom. You want students to feel comfortable taking risks, both in their projects and by raising their hand to make suggestions/comments in class. How you react when students say something "stupid" has a huge impact. Suggestion: draw from the "Yes, and..." technique of improvisational theater -- accept everything in class, refuse to shut down an idea or say that it's wrong, and instead challenge yourself to find the nugget of truth in there.
• Give students a sense of mission. People are more creative under stress when they believe in the importance of the final project. Because of this, fewer projects (reduction of workload) can paradoxically lead to students spending more time and doing more work... as long as the projects they have are the right ones.
• Self-efficacy is important: students must believe they can perform well in the class. Corollary: we as teachers must believe in our students. Research has shown that a teacher's belief in a student's ability to perform is often self-fulfilling.
• Praise students not only for their projects, but also for exhibiting personal qualities that we want them to continue: hard work, persistence, etc.

Walter Rotenberry (Wake Tech), on the challenges faced by Community Colleges:

• The ideal case for a Community College is that you are based in a "hub" of the game industry, so that your graduates have immediate local employment and internship opportunities. What if there are no game companies in a 100-mile radius?
• An alternative: focus on entrepreneurship. Require your students to take classes in business, enough that they would be comfortable building their own startups. Give students the tools to start their own local studios.
• Wake Tech's approach to a two-year program is interesting: cover a little bit of everything (at least one or two courses from programming, design, art, production, audio, business, game studies, etc.) to give a well-rounded background. This provides a foundation for transfer to any four-year school. I thought this was an interesting approach -- in my experience, usually with only two years to work with, Community Colleges focus on art or programming. I'm not sure that one approach is "better" than the other, but I can see the use of both.
• Encourage students to take courses in other relevant areas and departments: theater/drama, history, storytelling, etc. - the bonus is that in many cases there is no need to add specialized "game" classes, you can work with what is already there.
• Wake Tech got an $800K grant from NSF to develop their curriculum. This money is not allowed to go to new hires, but can be spent on curriculum development and new equipment. Other schools may be able to get similar money, so it is worth looking into.

G. Michael Youngblood on Computer Science-focused game research:

• Students can get involved through an NSF program called REU (Research Experience for Undergrads).
• It's easy to get academics involved; this is what many of us do. Biggest challenge is collaboration across departments, since games are so interdisciplinary.
• If you're working in industry and want to get involved, the easiest way is to visit. Invite some local researchers to lunch. Look at their stuff, read their papers, ask questions on what you don't understand.
• You can support students for your own benefit! If you have an idea you'd like to test out, $1100 per month for a grad stipend x 5 months = $5500 for a prototype and white paper. This is a pretty good deal if you're a large studio with an R&D budget! Note that some schools and some researchers will ask to charge overhead (to cover costs of building maintenance, utilities, etc.) that is as much as 50% of your grant. You do not have to put up with this; operations costs are not required for non-governmental grants, and you can offer the funding on a take-it-or-leave-it basis. Most universities would rather accept money than turn it down.
• Be on a university's Industry Advisory Board. Suggest that they research difficult, interesting problems.

Michael's list of things that the industry should keep in mind when dealing with academic researchers (particularly in Computer Science):

• Academics are extremely "paper-focused". If there's not a publication in it, then it doesn't matter.
• Academics are always behind and have too much to do.
• Like any programmer, academic researchers will overstate their ability to deliver for nearly everything.
• If a study involves humans in any way (such as, say, using college students in a playtest of your game), learn about the IRB process.
• The field of games research has matured quickly. Two years ago, "I'm working on a game" was good enough to get published. Today, you must also be able to show why your game research is cool or useful in some way.

Random tidbits from side conversations:

• Games and learning are both negative feedback loops: once you have learned something, you don't want to learn it again. This drives students to learn something and then stop. We need to find a way to counteract this by including a positive feedback loop, so that great students will want to keep learning and to learn more.
• I wonder if a school has ever hired an entire small development studio. Granted, not everyone has teaching skills, but you would get complete coverage of all subject areas and you'd be hiring people who already know how to work together as a team.
• Giving students a general literacy of classic games is important. One approach: have students write "reviews" of classic games. How do you get them to play older arcade or console games in the first place, when the original hardware is hard to come by? Several alternatives: first, many companies are repackaging their classic games for sale on modern systems (Atari Flashback, Midway Classic Hits, original NES games downloadable on Wii, etc.); second, with questionable legality, you can download emulators such as MAME; and third, particularly useful in class, you can find short gameplay videos of just about everything on YouTube to show what some of these games looked and played like.

Topic for Discussion: Beating a Course

Recently, someone wrote me about my book, claiming they had finished all of the challenges. I'm not sure if the person was serious (there are over 300 of them, after all), but it got me thinking about books and games, and the difference at the end of each.

It struck me that when most students finish a class, there is a sense of relief. "Finally, it's over. Now I can sell my textbook, throw away my notes, and forget all the stuff I just spend three months cramming into my brain." We approach games very differently. Maybe you just beat God of War 2 or Bioshock or Fallout 3 or whatever, and there is a sense of closure there... but there are also a bunch of locked Achievements, secret levels, more intense difficulty modes, different character classes or progressions, all kinds of other things that give the player incentive to keep going after it is "over".

What would classes be like if they had this kind of incentive system? Where students voluntarily chose to go back and read the chapters that weren't covered during the main course (the way they would explore optional levels after completing the main storyline of a game), do all of the end-of-chapter exercises that weren't assigned (like optional sidequests), write their own material summary to help other students (like writing a FAQ or Walkthrough of a game), or discuss the class and some of their ideas about the material with their friends?

"I just beat the final boss in Vector Calculus yesterday. But I was thinking of going back and collecting all the secret bonuses in each chapter, building up my Trig skill, and maybe going through the book again on Hard Mode and unlocking the bonus chapters on Differential Equations at the end. And I'm totally pre-ordering the sequel class, I hear they're releasing it in the Fall." It sounds ridiculous, but really, why not?

Student Post-Mortems

In a class I taught that just finished, I had the students make a complete, full-featured, production-quality board game from scratch over the course of a month (this was the major project in the middle of the course). At the end, I asked everyone to do a personal "post-mortem" by listing the things that they felt went right and wrong in development.

The list of things I see are astonishingly similar to the professional post-mortems that you see on Gamasutra when people make video games, and I feel echoes of previous classes I've taught where students made video games. So, I think a lot of these lessons are generally applicable, and worth sharing.

Rather than breaking it down into things that went "right" or "wrong" in this particular class, I'll list these as general points of advice that were repeated themes throughout the class. Some students listed these as things they did well and were thankful for; other students listed the same things as weaknesses that they wished they had paid more attention to. For our purposes it doesn't matter; this is the advice that my class would give you and your students.

• Playtest your game regularly, several times a week. Start as early as you possibly can. The earlier you start, the more time you have to make radical adjustments. You can never playtest too early or too much.
• Playtest with a variety of people, not just the same group of friends. Test with family, classmates, complete strangers, anyone you can think of. New playtesters offer new insights. The wider variety of testers you have, the broader the appeal of your final game.
• Start with a simple, strong core concept. If you don't know the purpose of your game or where the fun is supposed to come from, you'll have a hard time getting there. On the other hand, if you have some basic gameplay constraints that you create for yourself, a lot of gameplay will come naturally from that and it will feel like the game is making itself.
• Be wary of oversimplification. In general, it is harder to simplify a game than to make it more complex, and you should strive to make your game as simple as possible. There is a flip side to this: if you are overzealous about streamlining the rules, it is possible to accidentally remove player interaction, interesting decisions, and strategic options. When you remove rules from your game to simplify, pay attention to the play to make sure you are not removing a critical element.
• Observe people playing your game, without interfering. The learning curve of a game is critical, and the only way to gauge this is to have new players sit down and try to play without your assistance. Watch them struggle and see where they fail. This is one of the only ways to identify critical holes in your game in the end stages; as the designer, you are too close to your own creation to see the obvious flaws yourself.
• Don't neglect theme. In an effort to build the best gameplay possible, don't forget that a strong theme that fits the mechanics can make the game easier to learn, and a fun theme can generate player interest from the start. Include something that players can personally identify with in the game, to make it easier for them to feel like they're "in the game."
• Some mechanics are higher risk than others. If you are doing something that has never been done before (or has only been done rarely), the final project will take a bit more time, and you should be prepared for that. There is probably a reason why it hasn't been done before, and the reason is probably that it is hard to get it to work! If you are heading into uncharted design territory, expect to spend at least double the time on the project that you would have otherwise.
• Pay attention to readability. Some color combinations make your game difficult to read (I've seen black text on a dark blue background which was nearly impossible to read, and also yellow text on a violet background which was just painful to look at). If you haven't studied color theory, at least look at all of the text and icons in your game and make sure you and your playtesters can read them without eye strain. Test in both bright light (e.g. outside in the sun) and low light conditions.
• Leave time for "polish" at the end. When you have a month or two to make a game, it feels like you have forever. Realize that you would ideally like to have everything "done" earlier than the final deadline, so that you have plenty of time to make the game look more professional. Little details matter in the final presentation, but you will only have time for them if you don't procrastinate and if you build this expectation into your schedule. (Even then, it is often hard to do.)

There were also a couple of hints that are specific to board games:

• If you are making any custom components, do "proofs" before paying to print the whole thing. For example, if you're printing many sheets of cards, print a single sheet to make sure everything lines up right and that the colors don't bleed.
• Avoid printing double-sided if you can, because it's hard to get everything lined up. If you must, add a thick border which will help mask any cutting errors.
• Allot plenty of time for creating final game components. Even if your rules are finalized and you know exactly what you need, the process of actually building everything (which might involve painting wooden pieces, printing at a local copy shop, cutting pieces, and any number of other things) takes a lot longer than you think it will, so don't leave it for the last minute.

Design versus Marketing

Students who are hardcore gamers (i.e. most of them, if you're teaching game design) are used to seeing the marketing-speak on the back of a game box (we call this "box copy"). You've seen it before: "Over 30 levels! 300 weapons! Epic, engaging storyline! Intuitive combat system!"

Most of these students have never seen an actual game design document before. This would be the document that actually describes the details. Exactly what are the contents of each level? What are the names, damage, speed, accuracy and other effects of each weapon? What happens in the story, when exactly is each bit of story revealed to the player, how much is text and how much is voice acting, what is every last line of dialogue? How, exactly, does the combat system work and what are the controls? And so on.

It is, apparently, easy to get these mixed up. Box copy is useless if you're giving it to a programmer to implement. How does a programmer write code for "intuitive combat system" exactly? The answer is that they don't -- they kick it back to the designer until they get the details.

I'm seeing this more and more with students lately, and I'll be taking additional steps in the future to warn them of the difference between design and marketing. I wonder if other teachers see this as frequently as I am... and what, if anything, they do about it.