I was just asked an interesting question by a Ph.D. candidate: "how would I, as an academic researcher, contribute to the field of video game design?"

This is interesting because it seems so straightforward and obvious, but really thinking about it led me to a series of conclusions that really show both the similarities and differences between academia and industry.

Here's the "obvious" answer (well, obvious to anyone in industry): you don't. Industry largely ignores academic research. This isn't because game designers are a bunch of haters, it's for purely pragmatic reasons:

• Academic papers tend to be "rigorous" which is a nice way of saying that they take forever to read before you get to the useful parts;
• Even if we did have time, there's a dearth of peer-reviewed academic journals that specifically address game design, so we would have to hunt through all kinds of unrelated journals just to find something that's even relevant to the field;
  
• A lot of academics have no understanding or experience of industry, and therefore publish research that is useless to practitioners, so you have to read through multiple game design papers just to get one that you can use at all.

All of these things mean that finding useful academic research takes an awful lot of time, and time is the one thing game developers never have. We're working on a game, for Pete's sake, and it has to ship yesterday. Who has time to read through journals? We'll read Game Developer Magazine and maybe some articles on Gamasutra, but that's the most we can hope for. And publishing there won't get an academic researcher promotions or tenure, so forget it. Hence, researchers shouldn't bother, the majority of the time.

But wait -- does that mean that the field of game design is stagnating, if there is no way to push cutting-edge research to the field? Quite the contrary; we see innovative and iterative designs all the time. So how does the field build on itself, if there's no research? Thinking about this uncovers a flaw in the original question: it is built on some assumptions about the function and form of academic research.

In the sciences, at least, here's how it works. Suppose you're a research faculty. You do some research. You publish your results in a peer-reviewed refereed journal. Professional R&D folks in industry follow at least the top-tier journals to stay current on cutting-edge techniques and technology. The academic journal represents a primary source of knowledge that builds on itself over time. The original question assumes that game design works like this too. It doesn't.

Here is how professional game designers do research: they play games. Unlike other parts of a video game, the design is laid bare whenever you play. By playing you can explore the mechanics that were designed. Any mechanics that are hidden from you, such as combat formulas or enemy stats, can be found in a published hint guide (which is the closest thing we have to a public design document, most of the time). This allows us to analyze and study games directly. We ask questions like "how do these mechanics create a positive or negative player experience?" and "why did the designer choose to implement that feature in this particular way?" and "what are the weak points of this game, and how would we fix it?"

It is really a wonderful form of "publication"; imagine if scientists did not merely publish the results of their experiments, but also made their petri dishes and cell lines and laboratory equipment and whatnot available, and these were included in each journal so that the reader could precisely replicate their experiments at home! This is what published games are for game designers. Play is the game design equivalent of reading an academic journal. (Oh, how I love this field.)

So, this brings us to the non-obvious answer to the original question: to contribute to the field of knowledge that is game design, make a game and release it. If your game does something interesting, game designers will play it, analyze it, pick it apart, learn from it, and incorporate its lessons into their future designs.

It also means that all game designers, whether in academia or industry, are doing cutting-edge research, and every published game is peer-reviewed.

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.

The other day, I met some people who are thinking of hiring a game designer, I mention that I'm available for contract work.

One of my students who was present stepped in front of me and mentioned that he's also available, and cheaper to hire than me.

I know that I always say to pay attention, be observant, be ready to pounce on an opportunity... and apparently some of them actually listen. I'm thinking that, in the long run, this is probably a good thing.

Just a quick tip today from one of my earlier game design classes (we actually came up with this as a group in the middle of class while critiquing a student project):

If you're designing a paper prototype for a digital game and one of the core mechanics involves accurate positioning (examples include aiming in an FPS, positioning a paddle in a ball-and-paddle game, or maneuvering an avatar through an obstacle course), flicking a coin on a flat surface towards a target gives a reasonable approximation.

In our particular case, the student was designing a ball-and-paddle game. We discovered that if the coin was the paddle and a single flick was your allotted movement (then you repositioned the ball), it had the realistic property that it was much easier to hit a ball coming right at you than one that was landing halfway across the screen.

For an excellent example of this mechanic in action, see the non-digital game Pitch Car. Okay, so it's not Gran Turismo... but it could easily be the basis for a non-digital version of Mario Kart.

Having encountered a few former students recently, I was reminded of something that I think every student should know:

This is a hard industry to find your first job. There's a reason it's called "breaking in."

This usually hits home about 3 to 6 months after graduation. The student (well, no longer a student) applies to a bunch of game companies, only to either get rejections or dead silence. And then comes the self-doubt: am I not finding a job because there's something wrong with me? Am I not as qualified as I thought I was? If I'll make such a great game developer, why won't anyone hire me? Maybe I should've listened to Uncle Roy and gone into insurance.

Making it through that period is important. Once you're through, there comes a redoubling of effort: I just have to try harder. I'll apply to more places, and start looking for new opportunities that I might have missed. I'll call back those places I haven't heard from, just to check on things. I'll go back to the websites of the companies I was interested in and see if any new positions opened up since a few months ago.

And then on some idle Thursday, you get that call. And maybe it's your dream position that you thought was lost, and maybe it's QA at some local no-name casual games company, but at that point you've got what you were after: your first industry job.

Granted, it doesn't happen like this for everyone. Some students are lucky enough to line up employment before they even graduate. But I've seen the scenario above more often than not (and not just with my students, either), and it's worth a reminder that this is not a poor reflection on the student... it's part of the process.

So...

If you're a student about to graduate (or recently graduated): bookmark this post, and return to it when you're looking for that first job and everything seems so elusive. Remind yourself that it's not you, it's the industry. So buckle down and try harder, and keep trying until you get a job.

If you're a student who won't graduate for awhile: remember that this can happen, and plan accordingly. Make sure you've got some way to support yourself for awhile after you graduate, if you have trouble finding a job making games. Take care of food/water/shelter first, and realize that finding game-related work can sometimes take awhile.

If you're a teacher: remind your students of this every now and then. It's easy to forget, but it's important to remember.

I coordinated the second Ohio Game Jam this past weekend. I didn't make a game myself, although I did assist all the teams in very minor ways, so I got to see a little bit of everything. As such, I probably learned as much as any participant.

Lessons learned about running a Game Jam:

• Event planning is a lot harder than I thought it was. Last year, everything just fell into place, and there was a minimum of hassle. This year, it seemed like everything was an uphill battle, from finding a venue (which had to be changed last-minute due to a large-scale power outage) to recruiting participants (since I don't have reliable web hosting for the Ohio Game Jam website right now). For anyone else thinking about hosting a game jam, start planning at least a few months in advance and come up with contingency plans for everything. Hopefully the up-front work will be wasted and things will run smoothly for you, but if they don't then you'll be more prepared than I was.
• Things to take care of (either through soliciting donations/sponsors, providing yourself, or asking participants to bring their own): physical space; computers; open work space (for designing on paper); physical prototyping materials (blank paper, lined paper, graph paper, pens and pencils, and anything else you have on hand); food and drink; sleeping space (preferably with no light); and a large area where all participants can gather (for introductions at the beginning, and presentation of work at the end).

Lessons learned about game development:

• It's impossible to understate the importance of rapid prototyping. All three teams knew about this already, and yet they all made the mistake of trying to implement the complete game mechanics in one go, leaving them all with only 4 to 6 hours of time after "first playable." It's very easy to say that it's important to have something up and running really quickly, and quite another to actually do it; defining the minimum functionality set for playability is a skill, and one that not all designers are strong at.
• Corollary: trade off everything for speed when doing a rapid prototype. For artists, no need to have polished art when a stick figure works just as well for playtesting, and can be done in five seconds. For programmers, all that stuff about proper code structure and good commenting and re-use and maintainability that was drilled into you in every CS class you ever took... all of that goes out the window, because it takes extra time to make your code readable, and time is the one thing you don't have.
• Save early and often and back up. Sounds obvious, but one team had a computer crash that caused them to lose about an hour of work... when there was only 45 minutes to go before development ended.
• If you have a programmer shortage on your team, don't design a game that requires complicated game logic or AI. If you have more than one programmer, choose a development tool that allows you to work on code concurrently (two teams used Game Maker, which is hideously bad at merging two projects, for all of its other benefits).
• Game development experience helps in a game jam... but not much. Looking at the output of the teams, you wouldn't be able to tell which ones had industry professionals and which did not. (When I participated in a Game Jam, I noticed the same thing; I don't feel like my own project was any better for all of my experience, which is humbling.) I'm not sure why this is; perhaps, for all the benefits of field experience, lack of sleep ends up being the ultimate equalizer.

For those who are curious, here's the rundown of what happened at the event:
We had 13 people working in 3 teams, with a total of one game per team created (3 games total).
I gave teams a dual constraint: first, choose a social issue and create a game to spread awareness of that issue; second, design the game to be propagated through a social network like Facebook. As long as we're making games, we may as well try to save the world, right?

One team tackled the issue of financial responsibility and personal spending habits. The core concept was that people have two stats, Money and Happiness, and that there is a tradeoff where spending too much money on luxury goods causes you to run out of money (which makes your happiness go way down), but of course spending no money at all on luxuries also causes happiness to decrease, so the trick is to find a reasonable middle ground where there's plenty of money left over but also enough nice stuff to be happy. The game itself was a top-down scrolling game where the player's avatar wanders through a store looking for the cheapest necessity items, and maybe picking up a luxury item or two on the way. There were other AIs running around: other shoppers which were minor obstacles to work around, salesmen who would convince you to buy a luxury item against your will (while giving you minimal happiness in exchange), and thieves who would just steal money from you. The game created was incomplete, but could make use of social networking by allowing players to buy things for their friends (which increases both of their happiness) and competing with others on your friends list for achievements (most money, most happiness, fastest purchase of necessity items, etc.).

A second team examined the environment, specifically choices that governments make with regard to energy policy, in a turn-based resource-management strategy game. You control a small city with access to randomized natural resources, and choose what land to develop in what way (building hydroelectric dams over rivers, wind turbines in windy areas, solar panels, nuclear plants, etc. -- or of course you could develop the land as a commercial/housing area to attract more people to your city). You have a carbon footprint based on your population and the type of economy you have (fossil fuel-based, hybrid or pure electric), and a cap that's based on your population; if you go over your emission limit, you receive heavy fines. If you don't produce enough power for your population, you suffer blackouts and eventually you'll start losing population. You also have to balance all of this building against your available funds, of course. In Facebook, this game would also allow you to trade carbon emission credits and power with your friends, and also have leaderboards for largest city.

The third team took on the issue of child labor sweatshops. In their overhead-view action game, you played a child trying to escape from a shoe factory. You could pick up various shoes lying around each level (with tradeoffs for each: boots were powerful but slow, while flip-flops could be thrown quickly and accurately but did minimal damage). Your goal in each level was to pick up shoes and use them to knock out the adult supervisors, then talk to the kids to get information (which helped you progress in the game, and also gave you real-world information about sweatshop conditions). The game could propagate socially simply by having a high-score list, but did not include ways for different players to interact with one another otherwise.

I recently had a conversation with Alex, a former student of mine who made it in the industry (and totally deserves it, and I mean that in a good way). He's just finishing up his first project, so I took the time to get in touch with him and -- without having him break any NDAs -- did something of a post-mortem on his college education.

It occurred to me afterwards how useful our conversation was. As a teacher, I get some feedback during the education process but I get precious little after the students leave campus, so how am I to evaluate if my teaching is useful? An hour on the phone was worth a hundred end-of-course evaluations.


The biggest takeaways I wanted from the conversation:

• Did he enjoy the job? What were the best and worst parts? (This gives me additional content for my classes, either with a real-life horror story or success story, and some people might actually know him so the stories are more credible.)
• What was it like working on the project? (This tells me how obsolete I am. For now, at least, his experiences were similar to mine... so my descriptions of what it's like out there as a newbie are still valid for now. Whew!)
• What were some challenges they ran into in the project? (This is also an obsolescence gauge, and it tells me if I'm teaching the right skills based on whether I have course assignments that mimic real-world challenges.)
• What were some things that he encountered in the industry that I just totally failed to prepare him for? (The scariest question to ask but the most important.)

Anyway, I would encourage other professors and recently-graduated students to do something like this, especially at the time when the ex-students are just finishing their first project and have some time to reflect. Professors: initiate the conversation, as some students may be too busy or intimidated to just open up and start criticizing you after they're gone. Students: initiate the conversation, as professors tend to keep busy and have lots of things going on at once, and it'll be much easier for them to have this feedback if you open the door.

For what it's worth, my two big takeaways from this for myself:

• What went right: the importance of learning a new genre. Alex had never even heard of the genre they were creating before (tower defense games) and he had to learn really fast! This is a common thing in the industry for new designers, and being able to research a type of game they've never played before is a great skill to have. I had my students create a user interface for a modern football game, given the (correct) assumption that most of them weren't that familiar with sports games... or sports, for that matter. There's even an entire chapter in my book on how to work with an unfamiliar genre (Chapter 12).
• What went wrong: I didn't place enough emphasis on Excel in my classes. Sure, I said plenty of times that Excel is to game designers what Microsoft Visual Studio is to programmers and that students should do everything from keeping game stats to their checkbook and grocery list in Excel just to get familiarity with it... but how often did I actually give a game design assignment that required the use of Excel? Almost never. And I never gave any lectures on advanced features of Excel that are useful for game designers (like the use of RAND, RANK and VLOOKUP to create a randomly-shuffled deck of cards). I could probably offer an entire course in "Excel for Game Designers" but failing that I should at least have a few homework assignments that require it.

It's the little things like this that I'd never anywhere else, that remind me why I like teaching so much. Paraphrasing a couple of students:

A: "So, from your definition of the word 'game,' real life would be a game."
B: "Yes, I think life is a game."
A: "Then, is death Game Over or just a checkpoint?"

Had an interesting discussion awhile ago with a student where we came up with a theory that has probably been discussed elsewhere, though I'm not immediately aware if it has (the subject came up recently in another class I'm taking, and it reminded me of this):

The sum total of the freedom of a game designer to create the world, plus the freedom of the player to alter that world, is a constant.

An RPG like Final Fantasy that has more or less a linear, established plot gives the player relatively few choices in terms of affecting the game world; the player may have different strategies for beating monsters over the head with sticks as efficiently as possible, but at the end of the day they're going to save the world, rescue the princess and kill the evil wizard all the same.

Compare to Fallout or the Elder Scrolls games where the player has more control over the game world, but now the game designer is constrained: it's easier to create a world, but harder to tell a compelling story within that world.

I think this is, by and large, the difference between Eastern and Western RPGs.

If you're a designer, you haven't truly lived until a classroom full of students brings you paper prototypes of their video game proposals to evaluate. This was the most fun I've had grading. Ever.

Pretty much every student had at least one thing in their prototype that the rest of us (including me) can learn from, even if it was "don't do this". Failures of prototypes usually teach more than successes. Some students (correctly) failed on their own several times, threw away their own work and brought in something that worked much better -- allowing them to discuss failures AND successes.

I did have some assignments like this back in the Fall, but the students were leaping right into prototypes without first writing up a formal treatment (and also without having a solid foundation of game design theory to build on), so I think for best results this really should be a three-step process (theory, then treatment, then prototype).

The only part I had difficulty with was when a student brought in something that served as a negative example. Having your prototype harshly critiqued in front of an entire class would be mortifying, so part of me wanted to just move on without too much discussion... but on the other hand, part of me wanted to call this out as a great learning opportunity for the entire class. I think I managed to split the difference, embarassing a few students without providing the education for everyone else. Some day with more practice I'll find a way to do that better.

In the industry, you're often focused on a specific genre of game, not thinking about the broad spectrum of games as a whole. So perhaps it takes a student's eye to spot larger industry trends.

Such it was today in class, when my Game Design students came to the conclusion that you could make a "kart racing" game for any IP, any license at all... while still respecting the original story. We were unable to find an exception. It would seem to be an entirely generic genre.

My Capstone course (where a group of students create a complete game) is fortunate to have a Sound Designer as one of the eight students on the development team. On a professional development team this might seem like overkill -- the ratio of Game Audio to Everyone Else is usually closer to 1 in 40, not 1 in 8. There are exceptions, but our game isn't one of them.

Anyway, our sound designer comes in on one of the first days of class with a short looping sound for background music. It consisted of two tracks: a light, airy guitar melody and some deep bass drums. They're part of the same rhythm, so it's really just one sound loop divided into two tracks.

Here's the interesting part. By changing the relative volume of these tracks on the fly, the nature of the sound changes. If your avatar is flying through the air, play 90% guitar / 10% drums. If you're deep underground, change to 10% guitar / 90% drums. Walking on the ground, it's 50/50. Same song, but the nature of it changes dynamically based on character location (or health, or proximity of enemies, or what have you). It really sounds like three different songs depending on how you mix it. The programming to support this is absolutely trivial.

I can't think of a single game I've played that does this. Even games with dynamic sound like Shadow of the Colossus and God of War swap in one track for another at specific points in the sound loop, not really blending them. I suspect it took them far more effort from their Programming and Audio departments to achieve the same result that my student was able to do in about twenty minutes.

Has anyone else seen this technique before? Because once you've seen it, it seems like a really obvious thing to do...

A few days ago one of my students brought in a prototype for a game concept on a magnetic whiteboard. This has got to be one of the best prototyping tools I've ever seen. It has moveable parts -- custom magnets. Draw a stick figure, there's your avatar. Draw a straight line, now you've got a moveable platform for the avatar to stand on. Parts of the game that are static can be drawn in whiteboard marker, and erased / redrawn as needed. Parts that move are drawn on magnets, and you slide them around.

The particular model my student brought in also had cork board on the opposite side -- ideal for a pause screen or subscreen :-)

Yes, you can do this with post-it notes or index cards. But a magnetic whiteboard combines all of the best aspects of these in one prototyping tool.

And yet, I never had one of these when working for a game company, nor did anyone else who I worked with. It didn't even occur to us to go out and get one. So, to my game designer friends in the industry, I'd suggest going out and investing in one before your next project enters the concept phase.

Thank goodness for students with no industry experience; I don't know how we'd advance the field without them.

Emergent gameplay is when complex (and often unexpected) behavior arises from the interaction between simple rules.

In class yesterday, I witnessed emergent game design: some students in the class managed to create some very interesting mechanics even though I had not planned that as part of the lesson.

We were talking about the Prisoner's Dilemma, one of the few things from the field of game theory that's actually relevant to making games. Prisoner's Dilemma isn't all that compelling as a game itself, but it often finds itself incorporated as a byproduct into larger social games.

A student offered this modification to make the basic game multiplayer:

• Each player has the same two choices: Cooperate or Defect. However, if you Defect, you also choose a target -- one of the other players.
• If you Cooperate, you get 2 months in jail.
• If you Defect, you only get 1 month in jail, but the target gets an extra 2 months. Cumulative.

Very simple, but I like it as a designer because it has some interesting properties. If you play selfishly, there's no reason to Cooperate; Defecting is better for you, personally, no matter what. However, the total number of months spent in jail among all players increases if you Defect, so in the big picture Defecting hurts everyone.

In practice, players found that opening with Cooperation (assuming multiple trials) was a good strategy; anyone who Defected on the first round made themselves a target for retribution on subsequent rounds. If you were the only Defector at the table on round one, you were pretty much going to get killed for the rest of the game.

An unexpected meta-strategy occurred: once you do start Defecting, it's better to keep your focus on the same person rather than spreading it around. You make fewer enemies that way, and increase the chances that you won't be in Last Place.

I didn't learn much about teaching from this exercise (except to respect my students' game design skills, which I already knew) but the game designer in me was fascinated.