Here's an all-too-common lament from teachers who aren't located in a game development hub like San Francisco:
"I'd love to have some guest speakers from industry in my class, but none of them live here. Occasionally I can snag one if they're in town to see family or something, but it's not anything I can count on. And I don't have the budget to fly people in regularly."

There's a better solution out there, and it's so simple that I'm amazed this doesn't happen routinely. It's called Skype. (Okay, technically any videoconferencing software will work. But an awful lot of professional game developers use Skype already. For those who don't, it's shockingly easy to download, install and use.)

The setup is incredibly cheap. At minimum, you need:

• A computer in your classroom and a computer at the guest lecturer's desk. You can pretty much count on any game developer to have a computer, and it's honestly been awhile since I've stepped into a classroom at any school that didn't have at least a computer at the podium and overhead projector.
• Audio and video in the classroom. Again, most classrooms these days come wired for it. Absolute worst case, bring your own laptop. Most laptops these days have speakers, mic and webcam built-in; if not, you can get cheap-but-passable for 20ドル or less each.
  
• Some way for the guest lecturer to speak to you: speakers and mic (or headset) and webcam on their end. Many developers have this already. If not, spend 50ドル or so to order some basic equipment on Amazon and ship to them directly; it's a nice way to say thank-you if you're not paying an honorarium, it's a whole lot cheaper than covering travel expenses, and a gesture like this drastically increases the chance they'll do it again next year.
• A willing guest lecturer. Often the easiest part, since there are so many to choose from. Just make sure your social network is up to date.

Then you just have to set up a time, videoconference them in, have them give their lecture and take some questions, thank them for their time, and you're done. (Strictly speaking, you don't even need video; you could get away with just having a normal phone call, connected to a loudspeaker in your room. But I've found that being able to actually see the other person adds a quality that's worth taking the extra steps.)

Hints and tips to make things easier:

• Sometimes I find that a speakers + microphone combo leads to echoing, when the microphone picks up the sound from the speakers. To avoid this in your classroom, keep the mic turned off except when speaking. To avoid this from the guest's side, suggest a headset instead.
• Run a test call beforehand to do a sound/video check, maybe a few days in advance, just to get the bugs worked out of the system. If possible, do your test using the exact same setup/location where the actual call will take place.
  
• Have the guest's phone number, in case the internet picks a bad time to go down, just so you have some way to get in touch with them in an emergency.
• Make sure the guest knows how to use whatever videoconferencing software you're using, and walk them through it if not. If they have slides, make sure they know how to share their screen.
• Set this up in advance. Check in a few days in advance, and a few hours on the same day, just to make sure you're still on. Sometimes developer schedules can suddenly shift last-minute, so if you have the occasional cancellation, better to find that out before your class starts.
• When looking for guest speakers, don't limit yourself to your home country. In fact, it may be more convenient for people who are at a time zone that's a few hours apart from you; spending an hour doing a guest lecture from home is sometimes easier and less disruptive than doing so from the office in the middle of a work day. (That said, if you can set up a virtual "studio tour" with the developer walking a wireless webcam through their office, it can be all kinds of awesome.)
• If the speaker is in a different time zone than you, make sure you know the difference, and specify time zone in every email and other contact you have to make sure there's no confusion. To make it the most error-proof, give both times, yours and theirs ("So, we're still on for tonight, 3pm ET / 8pm GMT?").
• Lastly and perhaps most obviously, be respectful. While many developers are happy to get involved with education and share their knowledge with your class, remember that they are still volunteering their time for your benefit. You need them more than they need you. So be sure to treat your guests well, whether they are connecting to you virtually or in person. Do this right and they may even recommend other speakers for your class. Treat a speaker poorly, and maybe they'll tell their friends to avoid you in the future, and suddenly you'll have a much harder time with this. It's a small industry, after all...
• Conferences like GDC are a great place to meet potential guest speakers. Bring up the subject gently, then follow up a week or two later to those who expressed interest.
  

If you've done this a lot, feel free to post any additional tips (or traps to avoid) in the comments.

This blog post is indicative of the kind being thrown around by so-called "gamification" aficionados. I've seen a number of others along the same lines, but this one is fairly succinct and direct, and I think it can act as a proxy for other similar statements. If you're in too much of a hurry to read it, the practical upshot can be summed up in three points:

1. The education system in the US is broken.
   
2. Grades are an outdated game mechanic. This is part of the problem.
   
3. Replacing grades with other extrinsic motivations such as virtual currency is superior and will give students the motivation they need to learn.

Okay, so I have no problem with saying education is broken. It's hard to find anyone who thinks otherwise these days. What about the other two points?

Grades may be part of the problem, but they are not an "outdated game mechanic" because they are not a game mechanic at all. Very often I see rewards classified as "game mechanics" but they are not. The term "game mechanic" has a specific meaning to game designers; roughly speaking, a mechanic is a description of a systemic reaction to an event (such as a player input or a given kind of game state). A reward system that describes the conditions on which a reward will be handed out, and the exact rewards tied to what actions, would be a game mechanic. A grading rubric is a game mechanic. A grade or other reward itself is, in game design terms, a resource or a reward (but not a mechanic). Anyone who is going to speak of something as a game, needs to learn their terminology.

Second, and this is where a lot of "gamification" things fail: extrinsic rewards destroy intrinsic motivation. This has been documented so many times, I'm amazed I even have to say it. You could make a valid argument that by their nature as an extrinsic motivator, grades reduce a student's intrinsic love of learning. But to say that replacing one form of extrinsic motivation (grades) with another (virtual currency) seems flawed in the extreme. They have the same problem! Here's a recent example, where the introduction of 'badges' made students concentrate on earning badges to the detriment of their learning. Well, duh!

You might be thinking: Okay, Ian, if you're so smart, then what is the fix to grades? I would say that we need to do a better job separating the grade (assessment) from the actual learning. Let the reward for learning be the fact that you're learning something awesome and it's giving you new skills and abilities, and you are "leveling up" merely by learning it. I understand we can't do away with assessments entirely, but how about we be clear that they are assessments, not rewards? Young kids start out looking at the world around them with a sense of wonder; in theory, it should not be that hard to simply not get in their way as they enjoy learning stuff.

Look at any expert that is passionate about their field... say, a physicist. Do you think they were motivated to learn physics because they got good grades, or because they thought it was inherently awesome to learn about how the world around them actually works? For that person, this fascination with How Stuff Works is their reward, and as teachers we would do well to find out what makes it so fun for that person to do physics all day, and how we can show our students how awesome that is for them, too. And this is something that the external reward systems propagated by "gamification" systems simply doesn't seem to account for.

Let me be clear. As far as using best practices from the field of game design and applying that to make other tasks more fun and enjoyable, I'm a huge fan of doing this, especially when it comes to teaching. At its best, this is what "gamification" is, and I'm all for it. But all too often I see the term "gamification" used synonymously with "external rewards such as points or virtual goods" and that is something we must all be very careful with, because that may solve some problems in the short term but is probably ineffective or even detrimental to learning in the long term.

I realize I haven't posted here in awhile, mostly because I've been kind of busy. But something that's occurred to me recently is how social media is becoming a really great thing for games education.

To be clear, most of my students are on Facebook so they can share drunken pictures of themselves with their friends (and then get chewed out by me for it when I point out that this is what their future employers are going to see). My students are generally not on Twitter, and don't see the point. In both cases, I think my students often miss the point, and lately I've taken to being more aggressive about promoting the upsides.

The teachers I talk to are split more evenly. Some are totally into social media, others have dabbled but haven't really taken the next step, and others haven't drunk the kool-aid yet.

Why Students Should Care About Facebook

• Pretty much the entire game industry is on Facebook. If you want to get into the industry, you had better have a Facebook account. This is a great way to keep in touch with people you met at GDC or your local IGDA meeting or whatever. Guess what those industry people post on their Facebook status? If you said "job postings" give yourself a virtual ribbon. (You should probably have a LinkedIn account too, because everyone in the game industry has one of those too, but you can't play games on LinkedIn.)
  
• Like it or not, Facebook is now a non-trivial part of the game industry. Zynga's annual revenue from FarmVille alone is greater than that of most AAA retail games. Social games are a new breed of game (at least on this scale), and students - especially those about to graduate - had better pay attention, because right now there's an increasingly good chance their first job will be working on one of those.
• There's a lot to learn (good and bad) from the play patterns of social games, that can be applied to other kinds of game designs. In particular, the use of metrics to inform design and the ways that games use social cred as a game mechanic are things that can easily carry over into other multiplayer games, from board games to console or online PC games.

Why Students Should Care About Twitter

• The entire game industry is also on Twitter. Unlike Facebook, you don't have to be a personal friend of David Jaffe to follow him.
• Yes, a lot of tweets are things like what your favorite developer is having for lunch that day. Guess what: this is a great way to see game developer culture from the outside. Want to have some idea of what it's like to work with these people? Follow them and see what they sound like.
• Every now and then you get to see some amazing back-and-forth conversations happening in real-time between some of the most brilliant minds in the industry.
• Yes, people tweet job postings, too. Perhaps more frequently than they do in their Facebook status, even.
• If you can't afford to go to a conference like GDC but you're interested in what's happening, follow the Twitter stream. Each individual tweet doesn't say that much, but in aggregate you can extract a lot of meaning and get all the major high points - it's the next best thing to being there.
• Perhaps most importantly - and this is true for both Twitter and Facebook - their value is multiplied once you're actually in the industry. Right now with the social network I have, I don't use social media to swap drunken stories; I use it to swap valuable information. Just the other day, I asked about who had done research into the psychology of how people's estimates of odds/probability go horribly wrong (I wanted this info for a class I'm teaching) and got a bunch of great references. Later, someone I follow asked if there was such a thing as a game design notation, and I was able to point them to two examples. It's like trading money! (And anyone lucky enough to be following either conversation got the benefit of seeing all of the questions and responses in real time.)

Why Teachers Should Care About Facebook

• It matters to students (see above). If your students are trying to break into the industry and this helps them, it should be relevant to you.
• It's an interesting way to connect to your students outside of class, in a more casual/social setting.
• It's a great way to keep your own connections with industry and other educators you know. (And former students who join the industry, who make some of the best connections of all.)
• Facebook games provide great fodder for classroom analysis and discussion about game design. And if you happen to play these games on your own for fun, you'll never be lacking for neighbor requests / item gifts if you ask your students for them ;-)
  
• You can create groups on Facebook, for free, and use these to supplement your classroom learning. Yes, a lot of schools have their own courseware like Blackboard, but that has the disadvantage that it's a separate, isolated place where students have to go. They go to Facebook anyway, so it's a lower barrier to entry if they can post pictures and status updates and then check on their classes as long as they're there.

Why Teachers Should Care About Twitter

• As with Facebook, it's relevant to your students so it should be relevant to you.
  
• If class happens to be scheduled during a big industry conference, keeping a live Twitter feed on the overhead projector is an interesting way to generate some spontaneous discussion (though it can be distracting).
• It's a very immediate way to connect with your class. If you have a random thought from home at 10pm that you think would be relevant for your class, tweet about it and use a specific tag (like your course number) so your students can follow. You can also issue challenges to your students outside of class and have them retweet their responses... like, "change a rule of Tic-Tac-Toe to make it better, in 140 characters or less" and see what they make of it.
  

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.

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 800ドルK 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.

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?

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.

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.

There is something that has taken me many years to learn, after observing a number of other game designers and the systems that affect their careers. It boils down to something like this:


If you have to tell everyone how great you are, then you're not.



The best designers do not have to "self-promote" within the industry, because they have worked with other people who respect them enough to be their willing evangelists. As soon as you spend too much effort trying to build yourself up, that is precisely when the rest of the industry will gleefully tear you down. If you feel unappreciated, like you're just not getting a fair shake and you're not getting the attention and appreciation you deserve, it is because there are so many talented people out there competing for that same attention. Best move is to be patient and not overreach; yes, you will feel underappreciated for awhile, but in time your good work will come back to you.


If, by contrast, you spend a lot of time and effort convincing people that you're God's gift to game design, the worst possible outcome is that you succeed in your efforts. And then you're given a project that is beyond what you can handle. But you won't realize it, and you'll take the entire project down with you, and your co-workers will not thank you for their pink slips when the studio closes.

The same rule applies to teachers, but in a different way.

There is a temptation as a teacher to drum up attention for your classes. You want students to know that you're teaching all these cool classes about video games. You want enough students taking your classes that it proves to the higher-ups that there is demand and that they need to throw more resources at your program. You (and probably your boss and boss's boss) want "butts in the seats" under the assumption that if only enough people take these classes, they'll see how awesome they are and spread the word.

This leads to a similar problem as with the industry. If you promote your classes, you will get some students who either feel compelled to take them by your high-pressure tactics, or you will get students who are largely unmotivated and assume that "game class" equals an easy A. Neither of these students really wants to be in your class, nor will they try particularly hard.

In the long term, I'm thinking that the best way to promote your classes is to spend all your time making your classes a great experience. If the classes are that awesome, your students will evangelize for you, and they'll do it better than you can. Your initial class population might be lower, but it will also be more motivated and energetic because those students had to do some work just to take the class -- they had to find out that it was there, and they had to read the course description and probably talk to their advisor to see if this was for real, and they had to sign up on a leap of faith without encouragement from you. These are the students you want in your class.

In both industry and academia, this is the advice I would give:

Spend your time doing great things. Don't spend as much time showing or telling about your work. Let others discover it for themselves.

There are many kinds of project that help someone to learn design. Some are more or less appropriate in the different stages of a student's educational experience.

Non-digital games (i.e. Eurogames). Design a complete non-digital game (such as a board game, card game, or tile-laying game) from scratch.

Advantages of Eurogames:

• These kinds of games represent game design in its purest form. The design is laid bare, and cannot be concealed by high-poly-count art or impressive technology.
• These games can be built very quickly and cheaply. To make a "first playable" version takes only a few minutes, typically using only simple components like index cards and notebook paper.
• They tend to play quickly, which gives a lot of opportunity for playtesting, iteration, and polish if extended to a longer project (1 or 2 month time frame).

Disadvantages of Eurogames:

• Does not often meet student expectations. Students starting out in a video game development curriculum may be confused or frustrated that they are not working on video games. Extra care must be taken to justify the concept.
• In America, board games have a poor reputation from our culturally-accepted "family game" fare of Monopoly, Chutes & Ladders, the Game of Life, and other children's games. Initial exposure to Settlers of Catan, Carcassonne, Puerto Rico, Bohnanza, and the like requires a massive paradigm shift on the part of most people.
• Because students have little experience with board games, many "original" ideas are actually things that have been done before, but the student is not aware. In my classes there's always at least one student who sponteneously and unintentionally re-invents some classic game that they've never heard of. These projects require a lot of guidance and game-literacy on the part of the teacher.
• Some aspects of Eurogame design do not directly apply to video games. For example, it's hard to simulate the satisfying feel of pressing a button to make Mario jump in a board game.

Recommended for:

• A student's first experience to the world of game design.

Tabletop RPGs. Design the system for an RPG, playable by one mediator ("GM") and a small group of players. I would also include LARPs and, to a lesser extent, ARGs in this category.

Advantages of RPGs:

• Most students are at least familiar with Dungeons & Dragons, so prior experience is not a problem. A fair number are enthusiasts of the form, so this will generate a fair amount of excitement.
• Most RPGs require a strong integration between gameplay and story, making them ideal for the study of both game-based storytelling and core systems design.
• As with Eurogames, the system is laid bare in the rules, making RPGs a very pure form of design (even moreso than Eurogames, as most RPGs only have a handbook and not even any board or game bits).

Disadvantages of RPGs:

• RPGs are a very specialized form of design that may not immediately carry over into some other game media or genres.
• The enjoyment of an RPG relies largely on having a good GM and a good set of players. Good play can salvage bad design (and poor play can wreck a great design), making it difficult to evaluate a game purely on its own merits.
• RPGs take a long time to play. Typical play sessions last several hours, played regularly over the course of months or years. This greatly slows the number of playtests and iterations allowed in the space of a single course.
• Take a look at a professionally-printed RPG rulebook some time. Many are in the hundreds of pages, and are too large in scope for a student project. Even if you remove a lot of the fluff and filler, something as "small" as a 15-page rule set will still seem large to a typical undergrad student.
• Since RPGs integrate story and gameplay, it's important to have a solid understanding of both before taking on this kind of project. Learning how to tell good stories is hard. Learning how to design a solid and balanced rule set is also hard. Doing both together at the same time is too hard.

Recommended for:

• A mid-level elective course, with an intro game design course and an intro storytelling course as prerequisites.

Video games. Of course, when most students are thinking of "making games" they are thinking of video games. Generally, at the student level, I would subdivide this into two types of video game projects: very small and short individual projects, and mid-sized group projects. Most students would prefer to make large AAA video games, the kind that take several years with a team of hundreds of professionals, but of course the scope is too large for a college course.

Advantages of individual video games:

• Students really get to take ownership of their project, and it is usually very exciting for them to be making their own original video game.
• A truly outstanding student project has the possibility of winning an IGF award, which is a big deal.
• This is the most practical form of experience for students who want to make video games as a career.

Disadvantages of individual video games:

• Most individuals do not have art, sound, programming, and game design expertise, so some students will be disappointed and frustrated at their inability to do certain things in their project.
• Scope control is a problem with inexperienced students, who tend to design more than they can reasonably implement in a length of time. It requires a sharp eye and quick response from the professor to get students to keep their projects manageable.
• Because it is not going to be a AAA game, some students will take a small project less seriously than they should.
• At the very least, an individual game requires both programming and game design skill (art and sound can be fudged more easily). Learning programming is hard. Learning game design is also hard. Trying to learn both at the same time is too hard, and is the reason why so many people fail when they start out trying to program their own game from scratch as their first hobby project.

Recommended for:

• High-level class with a lot of prerequisites. Concentrates on showing students how to assemble all these various component parts in order to make a complete video game.
• High-level class with several game design and programming prerequisites. Concentrates on rapid prototyping, and making games that are ugly but functional as a way to test out certain mechanics or ideas. (A lot of prototyping can be done on paper, but some things like User Interface are best done digitally.)
• Intermediate programming class, with a game design class as prerequisite. Students learn programming while applying what they already know about game design.
• Introductory programming class, where the game design is done by the professor ahead of time and students can concentrate solely on implementation.

Advantages of group video games:

• Most directly simulates the interdisciplinary team environment found in the industry.
• Students can specialize; each individual does not have to be good at everything, as long as they are very good with at least one thing.
• Allows for larger scope than individual projects (although still not as large as AAA games).
• Like individual projects, an outstanding group project is potentially IGF material.

Disadvantages of group video games:

• Most students do not have a lot of experience working in teams. Lots of things can go wrong: an individual unmotivated student that drags down the team, communication lapses between students that make integration difficult, the design team overscoping the project, personal conflicts between team members, and all of the other general chaos that happens when people try to work together.
• Since this requires students from several disciplines, you usually have to recruit from multiple departments. Setting up a cross-listed class and getting the go-ahead from outside your home department is a bureaucratic nightmare. Getting a good mix of students with varied abilities is likewise difficult.
• Students will tend to bite off more than they can chew, especially once they realize that they have so many people working on a project. Getting them to start small and add (rather than starting big and cutting) is always a challenge.

Recommended for:

• A senior-level "capstone" course, after students have already taken all of the core courses in their respective majors.

For those of you who I met at GDC and found their way here, welcome!

One thing I talked to a lot of people about is an experiment I'm doing this Summer, called "Game Design Concepts."

This is a free online class that I'm going to teach. It is not affiliated with any college or university, and not for credit. It will be taught through a combination of blog, email and wiki. It contains all of the information (and then some) in one of the game design classes that I normally teach in a classroom in exchange for tuition money. But I'm releasing it for free this Summer.

The subject of the course is, as you might expect, game design. The intended audience is:

• Students who are interested in game design, and either are at a school that doesn't teach it well or doesn't teach it at all (or maybe you just want a second opinion).


• Teachers, especially those who teach game design. You can compare my material with that of your own class. Maybe you'll find some useful resources that you didn't know about, and maybe you'll be able to offer me some hints in return.


• Game developers who aren't designers. In a lot of companies, game design is still considered something of a "dark art" and those who aren't designers are often curious about how game design is done. In a few hours a week, this whole other field can (hopefully) be demystified.


• Game designers. Do you have an interest in contributing to education? Do you want to know what it is that the next generation of designers -- the ones who are likely to report to you in 4 to 6 years -- are being taught in the classroom? This is a way to find out, and contribute your own experience in the process.


• Anyone else with an interest in learning more about game design. For example, parents or grandparents of game designers who are curious about what these kids are doing; or hardcore gamers who want greater insight into the design decisions that make their favorite games so great.

If I've got your attention and interest, the blog is at gamedesignconcepts.wordpress.com and all updates (including instructions to register) will be posted there.

Autism. Aspberger. OCD. ADD. ADHD. Tourette's. Bipolar. You name it, someone in the game industry has it. Probably several someones, and probably at least one someone who is incredibly successful.

For this reason, it's hard for me to even call these "disabilities" -- given that the word "disabled" literally means that the person is not able to do something, and clearly it is possible to make games regardless of what psychological label might be applied to someone. But then, I'm not a psychologist.

For the most part, people in the game industry don't care if you've been diagnosed with anything, as long as you can help them make great games. You could be criminally psychotic for all we care, as long as it doesn't impact the development schedule. (Okay, I exaggerate. But only slightly.)

So, it took me by surprise the first time a student gave me this little slip of paper from the campus office of disabilities, several years ago (I've since gotten used to this ritual; it seems there's always at least one per class, and usually more).

For those of you who have not taught before, here's how it works: the student brings you this paper that gives you (as the teacher) no practical information, except to tell you that the student requires some special privilege (commonly, extra time and privacy when taking exams). You have to sign it -- in all the places I've taught, I've never been allowed to keep a copy -- and then the student takes it back. Presumably it gets filed somewhere, I don't know.

And then, naturally, you forget about it, because you're not allowed to keep a copy. Until exam time comes, and you remember that two of your students have special requirements, but you can't remember which students (many students with so-called "disabilities" are quite high-functioning), and one of them might have dropped your class a few weeks back anyway. Oops. I've been doing this for a few years and I still manage to screw this up most of the time.

The most frustrating thing, though, is that you're given no information about how to teach more effectively. I understand and accept that we're dealing with confidential information on a need-to-know basis, and I will often be getting the bare minimum of relevant information. But this conflicts with a desire to teach properly, and if I know that (for example) talking more slowly or repeating myself will help or hurt the situation, or if making my lecture notes available is useful, or if I should avoid calling on a student in class because it would embarass them... well, it'd be good to know, but there's no way for me to find out without a confidentiality breach.

The obvious thing to do in these situations is to talk to the student directly, and simply ask if there's anything you can do... but often the student doesn't know, because they aren't a professional educator.

Best solution, I suppose, is to take matters into my own hands. Read books on as many of these disabilities as I can find, particularly any that might give clues on how to teach better, and hope for the best.

Brenda pointed me at this article about creating a "21st century classroom experience." This has nothing to do with game design per se, except that just about all of these tips are restatements of basic game design principles, suggesting once again that game design is applied education (or maybe it's the other way around).

Summary of the tips and their context as a game design teacher (several points in the article are restatements of one another, so I collapsed them):

• Don't just push information. Encourage students to think critically by creating an environment where the students can (and want to) ask questions. Translation: let the player actually play in your game world. How fun would a game be if it just told the player to enter a certain code and then asked them to play it back?
• Make it relevant. Don't just explain arbitrary facts, put it in the context of how they're actually used so the students can see a connection between theory and practice. I've already written about that a couple of times.
• Soft skills are important. What will really make the difference is your students' abilities in leadership, empathy, communication, teamwork, and other things that are hard to measure on multiple choice exams. This is why games like The Sims and World of Warcraft are popular, despite them not having distinct measurable goals.
• Allow for variation. Education isn't one-size-fits-all; different students have different levels of ability and prior experience. Translation: include multiple difficulty levels in your game.
• Give practical experience, not just theory. The article goes so far as to say that teachers are "designers" so apparently I'm not the only one saying this. Translation: if it's nothing more than a series of cut scenes, it isn't a very fun game. Or, as Sid Meier has famously said, "if the designer is having more fun than the player, you have made a terrible mistake."

There is an inherent conflict between the nature of classes and course objectives, when it comes to designing a game as a class project.

The best way to learn to design games is to make a rapid prototype, fail miserably, figure out what you did wrong, and try again. Repeat until you get it right. In order to do this, the student has to feel like it is okay to take risks, that it is perfectly acceptable (even expected) to try crazy stuff that may simply not work out.

But of course, this is for a grade. Enter the fear of failure. Or, it's not for a grade at all. No threat of failure, but likely no effort put in by students on an "optional" project. Is there a way around this paradox?

Here's the method I'm currently using:

• My non-digital game design project has four milestones. The first is just a high concept, target audience, basic information (number of players, etc.) and some core mechanics. The second is a rough but playable prototype. The third is a playtested prototype, with the mechanics finalized or close to it. The final milestone is a polished product.
• All milestones are graded. Early milestones are easy points -- just turn in something, anything, as long as it works. Later milestones are graded based on the quality of the design -- you'd better have done some iterations.
• For the future, I'm thinking that early milestones should be worth fewer points than later milestones. This puts less importance on early work and more focus on the final product.
• On the days where milestones are due, students bring their works-in-progress to class and present the work for peer review. This also gives me a chance to see how the projects are progressing. In the future, I should probably just give a grade right then and there for the early milestones.
• Make it clear to students from the beginning that the more they iterate on their project, the more they playtest, the more they fail and then change, the better their final project will be. Unfortunately, this is one of those things they might just have to find out the hard way for themselves. I'll try bringing in a student work from an earlier course (with permission) in its various stages of completion, to show just how much difference playtesting can make.

It seems to me that every school that offers online courses does things a bit differently. For the classes that I teach online, I try to have as much interactivity as I have time for. I'll post on discussion boards, I host virtual "office hours" through an online chat program, and I send out regular emails with my own personal spin on the topic. I also offer feedback through grading papers, even if it takes me longer.

I realized today that in theory, the entire thing could be automated:

• The course content is all online, so there's no reason why I need to add anything to it. Let the students read it on their own without the professor offering any extra commentary.
• The discussion boards are for students to interact with each other, not the professor. When "participation" is one of the grades of the course, there are tools where you can get post counts, average length of post, and all kinds of usage stats without ever having to actually, you know, read what one of those student people is actually saying.
• Papers can't be automated easily, but if you design the course you could go light on those assignments and heavy on multiple-choice and fill-in-the-blank quizzes which can be graded by a computer system.
• Instead of holding regular "office hours", simply post your phone number and let students call if they need help with anything. You know they never will, whether it be from feelings of politeness or intimidation.

Not that I would ever teach this way, mind you. I don't think it's really teaching if I'm not involved, it's more like a long, drawn-out certification process.

On the other hand, it's easy to "teach" a class this way, so I'm sure there are people out there who do it like that. Some might just be overwhelmed with other things in life so they fall back on something easy. Others might be greedy and want extra pay for next to no effort. Still others might think this is what online classes are supposed to be, that once you get a computer involved it somehow means humans should be removed from the equation.

I suppose the lesson here for students is: buyer beware. Make sure that you're getting your money's worth when signing up for an online class, and make sure you know what kind of instruction and personalized attention you can expect. If all you're looking for is a few quick credit hours without having to leave your dorm room that's one thing, but if you're actually looking for an education then do your due diligence. (Put at least as much effort into shopping for a class as you might into getting a high-end stereo system for your dorm, since that's probably about what you're paying.)

Interestingly, I think there's a parallel here with outsourcing in the game industry, in that many companies that think "outsourcing" really want the thing they're outsourcing to be automated (and they find out to their chagrin that game development is not so easy a process to automate).

Yesterday, I was in Savannah giving a presentation with Brenda at SCAD to other educators about the use of games as a teaching tool. It was intended as a combination of my earlier Origins presentations and our Game Design Improv event.

I learned something interesting here: when talking about games in education, I take for granted that most of the time I'm talking to educators who already play games heavily (or teach game development), so the use of games in the classroom is not a hard sell. In this case I was speaking with professors from art history, photography, audio, film, media studies, and several other fields that are not directly related to games. We spent a lot of time discussing whether games were worthwhile for classroom use at all, and if so in what situations. It was a wonderful discussion that really challenged us all, and it's a discussion I'm not used to having. I was also impressed by the high degree of game literacy from these professors who were not gamers; participants referenced a number of game industry personalities and important games. Apparently it's not just game designers who study other media; they're paying attention to us, also.

Coming up, I've got a few speaking engagements. I'm speaking at GDC, both times during the Education Summit. I speak twice: I'm doing the next iteration of Game Design Improv with Brenda, and also speaking with Susan Gold and Gorm Lai about the results of the Global Game Jam.

The month after that, I'll be at GDX (here's last year's site, the new one isn't up yet), speaking about the relationships between art history and game design -- basically, why game designers should take at least one art history class, and why they should pay attention. (Short answer: because we may feel like games are a new medium and we're blazing new trails, but an awful lot of what we're doing with games-as-art is stuff that the art world already addressed hundreds of years ago, and we need to understand this so we don't keep reinventing the wheel.)

A short collection of social awkwardness as experienced by a game-designer-turned-educator, in no particular order:

• Having several students admit that they played a game you worked on, when you know the game in question wasn't particularly good. (Additional awkwardness: when the game in question is M-rated, and you know that the students were underage when they played it.)


• Giving a game design constraint for an in-class exercise, and repeatedly being asked questions about the exact boundaries of the constraint... and realizing simultaneously that my students are trying to weasel out of the constraint (and that I should be annoyed), and also that my students are trying to precisely define the constraint (which is an important skill for game designers, and something I should be proud of).


• Witnessing a student fall asleep in class, and hoping that it's because the student got no sleep and not because I've really become that boring. (Additional awkwardness: waking the student up, and hoping that I done it in a way that I haven't cruelly humiliated them.)


• Assigning a homework that's not only easy but actually fun, and seeing that half the class didn't bother to complete it. And then wondering if my definition of "fun" has changed.


• Writing something out (an assignment, a syllabus, an email, etc.) that I thought was clear as could be, and having students not understand it. This either means I'm not as good a writer as I thought, or that my students aren't functionally literate, or that my students are lazy... and no matter which it is, there's nothing I can be happy about.

Because we're both game developers, Brenda and I conducted a post-mortem of the book we wrote. Because many professors write their own textbook eventually, I thought it might be nice to share what we learned with you. (After securing the go-ahead from Brenda, of course.)

To protect the innocent, I won't say what we got "right" or "wrong"... but this is what we learned, for better or worse.

• Write with a co-author that you already know you work well with. I really can't stress this enough. Aside from halving the amount of work you have to do, it's great to have someone to bounce ideas off of, and it's kind of like having an extra technical editor for free. It's also a lot harder for the project to stall when you know that someone else is counting on you (a friend and colleague, not just some monolithic book publisher).
• Use some kind of version control system. It doesn't have to be as elaborate as Visual SourceSafe or CVS, but you will be making many changes and revisions to documents, and you will want to have a history in case you need to reference that paragraph that you deleted three months ago and now you want to use it in a different chapter. We found that simply numbering the documents (Chapter01_v1.doc) was sufficient.
• Use the Track Changes functionality in Word. It's great. It's like a version history built-in. Use the comments to communicate with your editor and other authors.
• If you're working with another author, use Google Docs for preliminary work. It's a free, convenient way to share chapters, and if you're on an instant messaging program (or on the phone) you can even edit the same document at the same time. You can always add any special formatting later, after importing into Word.
• Keep track of the current status of each chapter (not started, rough draft complete, final draft complete, submitted to publisher, accepted by publisher) in an Excel document. Update it whenever you finish anything. This is especially important if working with another author, so you know who is currently editing what (you run into a lot of "did you finish this chapter and it's waiting for me to review, or were you still working on it?" questions).
• Choose your book topic carefully, and whenever possible write about what you already know. Everything that you have to research takes extra time, and a book where you have to research everything will take a lot of time.
• When you're working with the publisher on the initial schedule, build time in the schedule for iteration. There are a lot of tasks that affect the entire book (consistent formatting, terminology, overall structure and other things) that you'll want to change several times as you write, and the easiest way to do this is just to make one final pass over everything at the end... rather than making these changes several times over the course of the project. But you only get to do this if there's time, and if you're rushing to meet the deadline then the whole thing can look a bit sloppy.
• As a corollary, keep a list of open issues for the book, so that nothing falls through the cracks. Keep it updated whenever you run into a problem that you want to defer until later, and reference it when you're doing revisions.
• Find people to review different parts of your book (friends, colleagues, grad students... anyone who you think would give you good feedback for any particular chapter) and start that process early. If you're writing a textbook intended for classroom use, teach a class from an early version to see how it will actually function (think of it as a "beta test").
• Get constraints from your publisher early on regarding number of chapters and pages, and find out the approximate ratio of pages in Word to printed pages in the book (a ten-page Word document might be twice as many pages in the book because of extra whitespace added to sections so the paragraphs aren't split between multiple pages, or to allow extra space around figures and photo images). This prevents you from finding at the end of the project that you suddenly have to add or cut a bunch of content.
• While I'm on the subject of images, get your images early. Securing the rights to photos of people, screenshots of games, company logos, and so on takes a lot of time.
• Develop a system for references to other parts of the book (for example, "See Chapter X, Page Y" when you don't know what the final chapter and page numbers will be). If you use actual numbers, you'll just have to end up changing them later... and woe to you if you accidentally miss one.
• Create a core statement for the book up front. Do you want to write in a professional or casual tone? Do you want to focus more on content or concepts? What is the underlying theme, the one thing you really want the reader to understand when they're done -- the common thread that ties everything together? Revisit your core statement when you're reviewing or revising your chapters.
• Clear your schedule if at all possible. Writing a book takes a lot of time, and if you're trying to balance that with teaching classes, doing freelance work and remodeling your kitchen, you are just not going to have the energy. If you minimize your downtime and interruptions, things will go more smoothly.
• Do your due diligence with publishers. If you've got a great idea for a book, then it should be a great idea no matter who the publisher is. Seek publishers who have a line of successful books in your field, so that you can get some decent cross-pollination with readers of other books in the same series. Look for publishers with wide distribution networks. Think of whether your publisher has the means and understanding to promote your book (or, whether they're willing to let you do some self-promotion). Find out who your editor(s) will be, and how much experience they have (if any) in your field; if you've written a book before, you may be able to request a specific editor for your book. At any rate, there's no reason why you should just take the first offer that comes along and accept all terms without negotiation... any more than you would with a job offer.
• Keep backups of everything. If all of your work is on your home computer hard drive and that hard drive crashes five days before the next scheduled milestone submission to the publisher... well, I'm sure you can imagine.
• And lastly, don't expect to get rich as a book author, any more than you would as a game developer. The advance you can expect as an author is not very much when you compare to the amount of time you're going to spend on the project. Yes, you can make a lot of money if your book sells well enough to earn you royalties, but that is the exception and not the rule. This doesn't mean you shouldn't write a book... but if you write one, do it for reasons other than money.

If there are any other textbook authors in the audience, please comment and share your own tips.

I've said before that classes are more interesting to students if you can make them more game-like, i.e. to give the students some interactivity (if not actual decision-making) rather than just lecturing at them.

If you're a teacher who is used to just speaking at your students and want to break yourself of the habit, here's an easy experiment for you to try in your next class:

1) Look over your lesson plan, and pick out one thing that is ambiguous, unknown, open to interpretation, or otherwise has no "right" side or answer. (Example in a biology class: the definition of the term "life".)
2) Design an open-ended question about the thing you chose. (Continuing the above example: "How would you define the term life?")
3) At some point in your lecture, ask the question to your class, and wait for the students to try to answer. If it takes a few seconds before you see any raised hands, that means they're actually thinking about your question, which is a good sign (or it means they're asleep, which is a sign that you've been lecturing for too long). Sometimes students will raise their hand to elaborate on (or even disagree with) a previous student's answer; encourage this, as you're creating an interactive dialogue among your students. If one student gives an answer and no one else feels like adding to it, challenge it yourself; play devil's advocate. But if at all possible, confine yourself to a role as moderator; if you chose a good question, your students will do your work for you.

You might notice a few things about this method:

• It gives your own voice a much-needed rest in the middle of a long lecture :-)
• Your students will actually be paying close attention.
• Your students will actually be thinking. In class, no less.
• As often as not, one of your students will say something particularly insightful that makes you think.

If you try it and like the results, increase the number of questions. Personally, my classes are usually about two hours, and I shoot for a goal of at least three discussion-questions per class. But if you're not used to it, you can work up to this one question at a time.

I was confronted with the opinion the other day that teachers are overpaid because they only have to work 9 months out of the year but get paid for a full year. I'm pretty sure the person who expressed this opinion has never actually met a teacher before, but it seemed like a thought that a lot of people might have. So, I thought I'd set the record straight.

First, a teacher in any field typically gets paid a bit less than a working professional in that field, even though they have to know just as much (if not more). This is why a lot of teachers feel underpaid for their work -- because with their qualifications, they could make more if they weren't teaching.

As for being underworked, I know of very few teachers who sit idle on summer/winter break. In my own experience, the time fills up fast:

• There's a lot of prep work to do for classes before they start: revising syllabi and course content, evaluating new textbooks, and keeping current with industry trends all take time.
• If you're teaching any brand new courses, you have to develop everything from scratch, which typically takes about as much time as teaching the course itself (i.e. one new course = two old courses, in terms of time commitment).
• Keeping professional skills sharp is important. Over breaks I usually end up doing some kind of freelance contract work.
• Ever heard of summer and winter classes? A lot of teachers hold classes over these supposed "break" periods.
• And of course, during the academic year teaching is a lot more than just a 9-to-5 job. In theory you're supposed to have a 40-hour work week, which is 4 or 5 classes if you're full time (that includes face time in lecture or lab, and also out-of-class time spent grading). But in addition to that, you have other duties: academic advising, office hours, faculty meetings, and (if you're really unlucky) being on a committee.

In reality, teaching is more than a full-time job.

Does that mean that these thoughts of "lazy" teachers who only work "30 weeks out of the year" are completely inaccurate? Unfortunately, no. It is possible to reduce the workload. You can hold office hours for your classes simultaneously, and then use the time to get other work done if no students show up (although this means you'll end up treating students like they're interrupting you when they show up for scheduled office hours). You can just copy your course notes from earlier classes without updating them, which reduces prep time to almost zero (but then you cheat your students out of a modern education). You can set up your assignments so that they're easy to grade (but anything easy to grade is usually not that meaningful -- for example, you can tell a lot more about a student's understanding by reading an essay than you can get from a multiple-choice question, but multiple-choice is easier to grade).

So, it is possible to have lots of time off, work 40 (or fewer) hours per week for 30 weeks a year, and have the rest of the time free to... um... do whatever teachers do when they're not working. But so far, the only way I've found to do that is to cheat your students. If you want to be a good teacher, forget any thoughts you had of annual three-month vacations...