Textbook Review: Basic Game Design and Creation for Fun and Learning

This is part of the series of book reviews.

"Basic Game Design and Creation for Fun and Learning" (Nanu and Naveena Swamy).

It is books like this that give the rest a bad name. For starters, in spite of the title, this book has absolutely nothing to do with game design. It should not be surprising that the authors have no published titles to their name and have apparently never worked in the game industry, which is a strong warning sign for any book.

In reality, this book covers the basics of implementation in Game Maker, a game authoring tool. Now, I'm a big fan of Game Maker itself. But the help files and example games included in the download and the forums on the website are far better at explaining how to use it, and go into greater depth than this book does. So, the book itself is entirely worthless; there is no need for it to exist in the first place.

To add insult to injury, the book attempts to explain some basic Object Oriented Programming methodology... and actually gets it wrong! If you're going to use the term "polymorphism" and apply it to Game Maker, be sure you know what it means first.

Students: Avoid this book. If you're interested in programming games but you're not comfortable with the more technical programming languages like C++ or Java, then you might consider starting out with something simple like Game Maker. But the documentation with GM is sufficient, and if you absolutely need a book to read there are better ones.

Instructors: If you're going to devote an entire class to teaching a single tool, you'd probably be better off teaching Flash than Game Maker; Flash is more versatile and powerful, and it's actually used in the industry from time to time. Even if you do want to teach Game Maker as part of a larger course, there is no need to use this book to do it.

Professionals: If you're a non-technical game designer who wants the ability to express your ideas in the form of a digital prototype, again, Flash is probably the best tool for the job if you have it available. Game Maker can be used to make certain kinds of prototypes really fast... but again, there's no need to use this book.

Origins Report (Part 3)

As the board game and video game industries are inextricably linked, it's sometimes useful to compare the trends in both. Here are the recurring themes I saw this year in eurogaming:

• Pirate and superhero themes. No doubt this is to capitalize on the popularity of these themes in the movies. We often talk of the link between Hollywood and video games, but the link is very much there for board games as well.
• Animals. I found a disproportionate number of board games that featured animals, including three games with camels, three games with sheep (not including the line of Catan games), two games with cheetahs, and then the occasional monkey, giraffe, elephant, kangaroo or penguin. I have no earthly idea why the fascination with animals, or why it's so much more pronounced in non-digital games.
• Gladiator combat. If conflict is an inherent element of games, then it's no surprise that games should be particularly good at modeling a straight-up fight. Still, there haven't been many gladiator games in past years, so I'm guessing this year's rash of them is just a statistical fluke.
• Educational games. There was a game that could be described as the Periodic Table of Pokemon. Another game that taught K-6 math skills, with a superhero theme. And another that featured many historical figures, with the History Channel brand. The thing I found shocking is that these games are actually touting their educational value as their main selling point. While this may get some extra sales with teachers and parents, it probably loses just as many (if not more) sales from gamers who would play these games except that we all know how much educational games suck. I have to wonder what would happen if a company released the same game under two different names -- one with an obvious educational slant ("Numbers League: Adventures in Addiplication") and another where the education is intentionally hidden ("Stupor Heroes"). Same game, different name and box copy, in an attempt to capture both the educational and gamer markets. No one is doing this, but I think it's an opportunity just waiting to be grabbed by any or all of them.
• Shorter play times. Due I suppose to today's ADHD society, games are getting shorter. I noticed a large number of very solid, deep strategy games that were playable in 45 minutes (a couple of years ago, these kinds of games mostly took two or three times that long). I think this is great; I can play more games to a satisfying conclusion in less time. There are even some tabletop wargames that are playable in under an hour nowadays; thirty years ago, these were the kinds of games that would take an entire weekend to play.
• Longer play times. Perhaps as a backlash of the shortening trend, I also saw a number of games that take 3 to 6 hours. You can always tell these games because they come in these gigantic boxes with tons of boards and tokens and figurines, and they cost $80 or so. Interestingly, the video game industry followed this same trend with budgets, starting about five years ago: you have to either be a "value" (very low-budget) or "AAA" (very big-budget) game, with it becoming increasingly difficult to find funding in the middle. That trend continues in video games to this day, although it may start reversing itself with third-party Wii games.
• Reiner Knizia. Seriously, the man seemed to have at least one new game with every major publisher. I don't know if he's just morally opposed to an exclusive contract, or what.

Origins Report (Part 2)

Lewis "Lou" Pulsipher is another game-designer-turned-teacher. I seem to find more and more of us each year. He gave a session this year on game design. I was less interested in the content, more in how that content was presented (since that's the real challenge, isn't it?).

Lou is a big believer in documentation and backups. If you have an idea and don't write it down, that idea may never come to you again and it will be lost forever, so always have something nearby to record your thoughts. Regularly transcribe your ideas from the paper you wrote it down on to a computer document, and back up your hard drive regularly. Even if the idea goes nowhere right now, having it preserved lets you go back and dig up old ideas later on; they can be a source of new ideas, and you might also (years later) finally figure out how to get that old game to work. Having lost my own share of ideas over the years to lost documentation, I'm not going to disagree, and I found it interesting that he hammered on this idea quite a bit -- most game design books don't say much about it at all. I suppose this is the difference between theory and practice.


Also on the subject of documentation, Lou points out that many people don't want to read the game manual, they much prefer to have a friend show them how to play because it's easier. This is no big surprise to anyone who plays a lot of video games (nowadays it's standard for them to have an on-board tutorial that teaches you everything, so that the manual is superfluous) but the board game industry still hasn't caught on. Lou suggests that it would be very easy to audio-record a gamer explaining the rules of a board game, as if to their friends, juxtaposed with photos, diagrams or video. This provides a pretty efficient rules "document" that could either be packaged on CD with the game, or at least put on the publisher's website. Lou also mentions that this would be particularly useful for educational games; many teachers who aren't hardcore gamers would still like to integrate some games into their class, but they don't want to take the time to learn the rules.


Lastly, Lou proposes that a game can be broken down into nine atomic parts. Not all games have all these parts, but the sum of them could be used to completely describe a game His parts are:

• Theme/history/story
• Objectives or victory conditions
• Game state (he called this "data storage and information management" -- a way to record the important variables in a game such as victory points, board position, cards in hand, etc.)
• Order of play (turn-based, realtime, etc.)
• Movement and/or placement
• Information availability (that is, what information is visible or hidden from each player; this includes immediate information hiding such as a closed hand of cards or fog-of-war mechanics, but also includes unknown future information such as the outcome of a die roll)
• Interaction of game entities, including conflict resolution
• Economy: resources, the means to acquire them, and the means to exchange them
• Rules of player-player interaction outside of the game state (this includes mechanics such as trading, negotiation, auctions, and metagaming)

I find it interesting to compare this to the list of formal elements from Game Design Workshop:

• Players
• Objectives/Goals
• Procedures (I found this confusing in the text, but it essentially means the UI -- the actions available to the player allowed by the rules)
• Rules
• Resources
• Conflict
• Boundaries (that is, where does the game end and the Real World begin; includes physical boundaries such as a proscribed area of play, and conceptual boundaries that let the players know who "is playing" and who is not in the absence of physical boundaries)
• Outcome
• Dramatic elements (this includes story and narrative, but also the aesthetics created by the dynamics of the game itself, such as rising tension in a well-paced game)

There are similar elements on both lists, so it may be useful to combine them the next time I teach a theory-of-game-design class.

Origins Report (Part 1)

Last year at Origins, most of the sessions I went to seemed a bit... sponsored. As in, "Hi, I'm a representative from a boardgame publisher, and I'd like to tell you why you should use our games in your classroom. By the way, I have no experience in education, and I have no lesson plans, but don't let that stop you from buying lots of stuff."

This year was much improved. Publishers who were pushing their own agenda at least brought a good assortment of lesson plans and were presented by someone who'd been teaching for twenty years. Others, even if presented by someone who worked at a publisher, concentrated on practical content. And then there were the independents like me, just out to spread the word about whatever we had experience in.

Mark O'Bannon gave a primer on good storytelling practice. Since this was at a game convention, the subject was approached mostly from the perspective of "how to become a better GM by understanding what makes a good story", although the basic principles are the same whether you're writing a book, a screenplay, the plot of a video game or a tabletop RPG adventure. It occurs to me that "write a two-hour game session and then run it with fellow students in a group" would be an interesting assignment for a creative writing class.

The session was pretty basic, so there weren't many surprises for me: most of the content was taken from the holy trinity of Aristotle, Campbell and McKee. Two other books were mentioned as being useful in the context of game writing: "Characters and Viewpoint" by Orson Scott Card, and "How to Write Science Fiction" (someone said at the session this was written by Ben Bova, but a search through Amazon suggests this was Card also). I'll evaluate these later this Summer if I have time.

There were a couple gems in the session I hadn't encountered before:

• When creating a setting, build what O'Bannon referred to as a "community of opposites": character rivalries, feuding factions, environmental hazards, etc. -- things that exist as sources of conflict in the setting itself.
• On the subject of showing character, a useful way to think of this is to have two emotions fighting against each other. When one emotion wins, that's when you see a person's true character. (Example: pride vs. fear. Put a proud character in a dangerous situation and see whether they fight or flee.)
• McKee especially talks a lot about how the main character should change during a story, but O'Bannon points out that this doesn't have to be the case; it's possible for the main character to be more of a catalyst, someone who causes change in all that he touches, without actually changing himself. An example would be Kwai Chang Caine.

This post is already getting pretty long, so I'll summarize the other sessions later.

Speaking at Origins: Final Details

As promised earlier, here are the details of my speaking engagement:

I'll be speaking twice, once on Thursday July 5 at 9am, and again on Friday July 6 at 3pm.


The title of the talk is "Why use games in a classroom?" but that's actually not the best title. Presumably everyone attending Origins already understands the positive effects of gaming, and anyone attending a session for teachers is already on board with the whole games-for-learning thing. I'll actually be talking about some basic game design theory (i.e. "What Makes Games Fun") and then applying that to education, to make the class time more engaging for students.


If you're in the area, drop by and say hi!

Textbook Review: A Theory of Fun for Game Design

This is the first in a series of book reviews. I'll start of with one of the few useful books I've read.

"A Theory of Fun for Game Design" (Raph Koster).

Everyone involved in game design -- students, teachers, and professionals -- should read this. It's very short, uses a large font, and every other page is a cartoon; you can read through it in an afternoon. It makes the case that learning is the source of fun in games, and that game designers are just a specialized type of educator.

This book is fairly light in content; it's not about how to design games, per se, but about what game design actually is. Probably the most important thing you can get from this book is a way to describe your field to friends and family who aren't gamers (particularly those with the attitude of "why are you wasting your life with those games, instead of studying something real?").

Students: Due to its brevity and tight focus, this is one of the few books that is easy for a student to just pick up and read on their own. If you're broke, you can always just read the thing in your local Borders some random afternoon.

Instructors: I think it would be tough to use as an actual textbook in class; it's too short. For classes where this book would be appropriate, just read it yourself and prepare a lecture that summarizes the key points. And then encourage students to read the entire book on their own time, if they find the topic interesting. Another option would be to require it as one of several short textbooks, and include assigned reading (with a summary report to be handed in) as part of a larger class -- either mandatory, or for extra credit.

Professionals: Pretty much every game designer I know personally has already read this book. If you haven't, you probably should, if only because it comes up in conversation from time to time. But if you work with other designers, they were probably bugging you about reading this long before I made this post.

Textbook Reviews

Last Summer, I posted a proposed college curriculum for game design. That project is complete, so I would be in need of a new Summer-long blogging series for this year.

Books on game design are tricky things. There's an awful lot of material out there, enough to be quite daunting to the student, teacher or professional looking for the right one. A disappointingly large percentage of the books out there are practically worthless, and telling them apart from the "good" books often requires enough experience that you wouldn't need the book anyway. Fear not; I shall wade through the mountains of manure to find the few shining gems, so that you don't have to.

Then there's the matter of breadth. Game design is a huge field, like Science; you could no more write a single unified textbook on "game design" any more than you could write a "science" textbook. Every book will necessarily have its own specialization, so even the books worth reading may or may not be useful to a specific designer.

I will comment on several things for each book: first, the focus of the book (because the books themselves rarely tell you), and whether the writing on that topic is worth a darn. Next, the intended audience; again, the books themselves will almost always say they're "for everyone" or "for all levels" because the publishers know better than to limit their audience, so I'll provide my own opinion of who the book really seems most useful for. Then I'll talk about each of the three groups that comprise most of the readers: is the book suitable for a student studying on their own; is it useful for a practicing game designer in the industry; and is it useful as a textbook for a class (and if so, which class).

I realize that some of this may involve biting the hand that feeds me, since many of these books were given to me for free by the publishers so I could evaluate them as potential textbooks for my own classes. In this case, I feel my allegiance should be more to the cause of education than the financial interests of book publishers; if anyone wants a good review from me, they'll have to write a book worthy of it, plain and simple. (I receive no kickbacks or other compensation whatsoever for anything that I post here, nor will I ever do so. I promise.)

I will also include links to all reviews from this post right here, same as last summer, so bookmark this one later if you want the complete list:

A Theory of Fun for Game Design, by Raph Koster
Basic Game Design and Creation for Fun and Learning, by Swamy & Swamy
Patterns in Game Design, by Bjork & Holopainen
21st Century Game Design, by Bateman & Boon
Game Design Workshop, by Fullerton, Swain & Hoffman
Rules of Play, by Salen & Zimmerman
Game Design: From Blue Sky to Green Light, by Todd
The Game Design Reader, by Salen & Zimmerman
Game Design, Theory and Practice (2nd Ed.), by Rouse
Fundamentals of Game Design, by Adams & Rollings
Introduction to Game Development, edited by Rabin
High Score!, by Wilson & Demaria
Introduction to the Game Industry, by Moore
Chris Crawford on Game Design, by (surprise!) Chris Crawford
Break into the Game Industry, by Ernest Adams
Teaching Videogames, by Oram & Newman
Challenges for Game Designers, by Brathwaite and (shameless plug) myself
The Art of Game Design, by Jesse Schell

If Game Design were Painting...

Here's another way of looking at what game design is, thanks to a recent conversation I had with Brenda.

Suppose I have this great idea for a painting, but I don't have the artistic or technical ability to pick up a brush. I could spend years learning anatomy, perspective drawing and the use of various tools, but that would take too long. I can picture this thing perfectly in my mind's eye, although once it's actually on physical canvas it might not look as cool as I'd originally thought. Or, maybe I have all the ability that I need, but I just don't want to put in the effort, because painting is hard work and takes a lot of time.

So, instead of doing it myself, I'll write down a detailed description of exactly what I want painted. I'll include all kinds of details, descriptions of characters and background scenery and color... although my vocabulary might be a little strange to a professional artist, if I never learned technical terms like "vanishing point". Then I'll give this description to a professional artist, and if my idea is cool enough maybe she'll make the painting for me.


Suppose I manage to find a willing artist. A first draft of the painting is made. I offer corrections, in some cases because the artist's work includes better ideas than what I'd originally envisioned, and in other cases because I was unclear in my "spec" and the artist misunderstood what I wanted. We go back and forth like this for awhile. Finally, the painting is done and we're both happy with it (or, I decide that it's "close enough" and I need the money). We sell the painting. I get all the credit, because it's my idea, and the painter was just my instrument. The painter gets more of the money from the sale, because of supply and demand (fewer people want to build someone else's idea, than to come up with the ideas themselves).


Of course, this would never actually happen for a purely creative work. And yet... that's more or less the relationship between game designers and game programmers. And part of me has to wonder how we game designers can possibly get away with it.

A Reusable Game Design Exercise, Iteration 2

Awhile ago, I posted a way to randomly pick a set of constraints for a Game Jam. I actually used it to generate one of my final exam questions for the Digital Game Design course ("write a one-paragraph game concept that fits the following constraints...").

Alert reader Nathan Ostgard pointed a few things out to me in email:

• Exercising your skill of "learn to work within a set of constraints" requires different materials than exercising your skill of "be creative and come up with something new". My original spreadsheet is very much geared towards the former, and is not all that suited to the latter (mostly because it forces you to work within existing, well-established genres).
• There is a difference between Theme and Setting. I lumped them both together without really thinking, but you could easily separate them.
• You can easily add additional categories of constraints; the five I originally listed are by no means the only ones available.

He built a spreadsheet with the following categories, and elements in each category:

• Setting: Fairy Tale, Fantasy, Futuristic, Medieval, Mythology, Modern, Steampunk. (I would add: Historical, Historical Fiction.)
• Theme: Action, Adventure, Comedy, Crime, Drama, Horror, Mystery, Romance.
• Objective: Align, Avoid, Build, Chase, Collect, Destroy, Escape, Explore, Find, Grow, Race, Solve, Timed.
• Perspective: 3D Chase, 3D Eye, 3D Roaming, 3D Static, 2D Side, 2D Top. (I would add 2D Isometric, and the so-called "2.5D" of games like Viewtiful Joe.)
• Bonus: Abstract, Cooperative, Emergence, Five Minutes, Fog of War, Luck, Physics, Rulebreaking, Self-Expression, Sensation, Social, Squads, Turns, Vector.

Thanks, Nathan!

Pieces of Paper

A little while ago, two students presented very different views of my classes.

One student said that he took his tuition and divided by number of credit hours, and figured that he was paying about $120 for each of my two-hour lectures. This perspective made him extremely hesitant to ever miss class -- every time he did, it was like buying two new games and throwing them away!

Another student cynically disagreed, saying that what he was really paying for wasn't class time, but the piece of paper you get when you graduate. To him, the real value of school was its ability to qualify you for a job where you can "do interesting stuff".

The true irony is that this second student was in my Capstone class, working on a team to develop a game!

I wonder how I can best put up a resistance to this second attitude. Other than just being the best teacher I can, of course.

Fun with multiple choice

I prefer my exams to contain essay questions, because they offer greater opportunity for expression; they're harder to copy without cheating being obvious; and they give me a better idea of just how much my students grasp the material. The down side is that they take forever to grade, so I can certainly understand the practical consideration of a multiple-choice exam -- especially since the professor is under time pressure to turn in final grades at the end of the course.


Brenda, another game-designer-turned-professor, says to me about multiple choice:

For a multiple choice exam, you can create the silliest answers, and people will select them. It's like a mini-game. My favorite silly answer is "Costikyans". I use it a lot. We talk about Greg's articles regularly in the quarter, and it still surprises me when someone selects his name as an answer. In this case, the correct answer should have been "Semiotics."


I'll have to try that some time, just for laughs.

And now that she mentions it, if I ever make an RPG, I'll be tempted to name the currency the Costikyan. It doesn't sound that much more odd than, say, Gil, Potch or Zenny. "A sword of flame? That'll be 300 Costikyans, please."

Correcting the Answer Key

During the process of grading a final exam, one student's answer to a particular question was very different from my own "correct" answer, but persuasive enough to make me question my own assumptions.

After looking a few things up, I think the student is right. I now have to change my own answer.

Naturally, this was the last exam I graded, so now I get to go back through every single other one and redo the grading on this question. (I won't take points away from students who made the same mistake I did.)

I have to wonder how common this is. I know that every teacher says they learn as much as their students, but I didn't expect to be learning things after the class was already over.

Extra Credit

On my take-home final exam, just for fun, I included an extra credit question: "What is the secret code?"

I gave out the code on the last day of class, as a bonus for anyone who was there. It turns out that every student was there.

Some students missed the question. I have no earthly idea how they managed this.

Some students not only missed it, but made up their own code. Predictably, most of these students guessed the Konami Code. Except that -- get this -- they got the code itself wrong. I seriously considered giving negative points for this question in such a case, as penalty for defiling the memories of my youth.

The down side of take-home finals

The day that my take-home final is due, it occurs to me there is one slight drawback, especially if the exam is sent to students online:

All of my students now have a permanent copy of the exam, so I can basically never use it again without making serious changes. (At least, not in the same school.)

I'll have to keep that in mind next time.

The Final of a Thousand Faces

I've discovered the joy of the take-home final exam. It's like telecommuting: my students don't have to show up at any scheduled time, and I don't have to make the trip to campus. I'll definitely have to do this more often.

In one of those "why-didn't-I-think-of-that" moments, I recently heard of an interesting compromise: a "take-home" final that is posted online at a specific time, and must be turned in within 2 hours. Essentially, this contains the time pressure of a standard exam, but without everyone having to be in one place. I suppose it makes it tougher to police cheating... except that I prefer essay questions anyway, which are really hard to copy without the cheating being obvious (especially if the test is timed).

Self-Censorship

Game designes often struggle with "edgy" content. Do we put in this extra thing because it's cool, or leave it out because it might push the game's rating to M when the publisher demands that it be T? Or, even if it's an M game, maybe this is just a little too offensive; we don't want the industry to have to go through Hot Coffee all over again. And then we criticize ourselves for being too hypersensitive, and doesn't the industry have to deal with enough censorship without us doing it to ourselves?

Well, I just had that same kind of feeling when teaching, for the first time (and probably not the last). I encountered a game that would make a great example for my Game Design class, for why the theme of a game can make a huge difference in player experience even if the underlying mechanics are the same. In particular, there's this game that is mechanically an uninspired clone of a street-fighting game... but the theme is either going to be hilarious or offensive depending on who you talk to, because the playable characters are from the Bible. So, I only brought it up after class, to a few select students who I knew would appreciate it. And now I'm chastising myself for putting political correctness before education.

Life Imitates Games

Within the space of one day, I have two student game concepts that are imitated by the real world.

One concept is an anime-inspired "bunny girl versus cat girl deathmatch" sort of game. This morning on the radio I hear about an endangered species of bunnies being attacked by feral cats.
Another student proposed a collection of carnival-midway-style minigames, sort of like the retro game Carnival only with more variety. Today I see an announcement about just such a game, to be released for the Wii.

The news was dated after the assignments turned in, so it's just a really odd coincidence. (Or, my students are just really good at predicting the future. Maybe I should ask them to consider a career in meteorology.)

Bonus coincidence: my Capstone class has been working on a game for the past 20 weeks with the theme of killing your avatar in the most entertaining way possible (as a reversal of the standard goal of saving/protecting your avatar). Then I find a game called Five Minutes to Kill (Yourself)... thankfully, with very different mechanics.

Emergent Design: Student Paper Prototypes

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.

Culture Shock: Doing the Work

As my class ran under time today and students left about half an hour early, it occurs to me that the decision to cut things short was met with enthusiasm -- not because my students hate taking my classes (I hope!), but they've just been conditioned through years of education to get out of class as soon as possible.

This sort of thing doesn't happen in industry. If I'm working as a game designer and spontaneously decide to take half of the afternoon off, the rest of the team isn't going to heave a sigh of relief that I'm leaving (nor is the publisher, or the client). But here, my "customers" are perfectly happy if I'm not doing the job I get paid to do, at least to a certain point. It's rather unsettling, really.

Culture Shock: Transparency

In every game company I've worked at, management was pretty transparent. It's not like you could always walk into the CEO's office and ask to see the financials, but in general any company-wide decision was justified to the employees and there was room for discussion. Often there was discussion before any decision was made.

Universities aren't like that. For one thing, they're much larger than your typical game dev studio, so there's a lot more things going on at once; if you were informed every little detail crossing the desk of your boss (and your boss's boss, and boss's boss's boss) you'd have so much information to sort through that you wouldn't have time to get any work done. Also, I think there's more of an overall attitude that people should be separated; professors should teach and do research, administrators should administrate, and no one needs to be aware of anyone else's job. Information is distributed on a just-in-time, need-to-know basis.

I understand that there are very practical reasons for this, but at the same time it's still unsettling to not really be aware of what's going on around me. I hear the results, but not the reasoning... so when I hear "such-and-such department now has a new vision" I have no way to place that information in the proper context. I also worry that such opaqueness at the management level, whether at a university, company or government, opens the door to abuse of power since there's less accountability. Not that this will absolutely happen, mind you, but the door is open.

I suspect this isn't an "industry vs. academia" thing, so much as a "small vs. large organization" thing. All of the game studios I've worked for have been small: dozens of people, not thousands. And it's not like I can find a 30-person university to compare.

Speaking at Origins

In the board game industry, there are two major public-facing events in the US (similar to what E3 used to be for video games). One of them, Origins, takes place pretty close to where I live... and as if that weren't enough incentive to attend, teachers get in free.

Part of this education track involves access to a set of lectures and workshops about using games in the classroom. Most attendees teach something non-game-related, and many teach at the K-12 level.

I'll be speaking there for an hour on Friday morning (with a repeat on Saturday afternoon) on some theory of game design -- specifically, what makes students prefer games over classes -- and then how to incorporate that into the classroom to make it more engaging.

I'll post more details as they become available.

A Reusable Game Design Exercise

One of the designers I worked with at Cyberlore, Jesse King, once came up with a wonderful design exercise. He made some lists of game elements (mechanics, themes and such), put them in Excel, and used the functions VLOOKUP and RAND to display a random element from each list. Your goal as a designer is to come up with a one-paragraph game concept that contains all the given elements. Then you hit F9 (in Windows, anyway) to reroll and get a new set of elements. Repeat until you realize you've been doing this all afternoon, and then sheepishly return to your day job.

It occurred to me that a "random game idea generator" such as this has two academic uses: in the classroom (as a fun brainstorming exercise or even on an exam), and as a way to randomly pick a theme for a Game Jam.

I went ahead and made one of these specific to a Game Jam environment (that is, it avoids game elements that would be difficult to implement in a short time, such as 3D worlds or online multiplayer). It has the following categories, and elements in each category:

• Theme: Medieval Fantasy, Modern Fantasy, Modern Sci-Fi, Futuristic Sci-Fi, Alternate History, Romance, Drama, Crime/Mystery, Survival Horror, Ancient Mythology.
• Genre: Turn-Based Strategy, Realtime Strategy, 2D Platformer, Overhead Shooter, Scrolling Shooter, Sim, Graphic Adventure, Puzzle, Time-Based/Racing, Dance/Rhythm.
• Core Aesthetic: Physical Sensation, Growth/Advancement, Social Experience, Fantasy/Escapism, Narrative/Drama, Challenge, Discovery/Exploration, Deliberate Rulebreaking, Control/Leadership, Probability/Chance.
• Objective: Chase, Race, Kill/Destroy, Build, Collect, Avoid, Spatially Align, Escape, Explore, Solve.
• Design Challenge: Squad-Based, Nonstandard Control Scheme, Diplomacy, Feedback Loops, In-Game Economy, Emergent Systems, Fine Art, Training/Education, Fog of War, Abstract Graphics.

If you have any suggestions to add to any category, feel free to suggest in the Comments below.

If you'd like a copy of the Excel spreadsheet, email me at ai864 at yahoo. If you don't like Excel, you can do this with index cards instead; write a game element on each card, sort the cards into categories, and draw one random card per category.

Additional variants:

• Allow the designer to ignore any one category, but the game must fit all the others. This relaxes the restriction, and might be ideal in a Game Jam if you want more variation between teams.
• Choose game elements chosen randomly from among all the categories, so that you may get some blank categories and some categories with several elements that must be satisfied simultaneously (e.g. you may have two "genre" elements, 2D Platformer and Turn-Based Strategy, and you'd have to find some way to combine the two).
• Make a game out of it with several designers present: the first designer generates a single random game element and proposes a game that contains that element. The second designer generates a new element and must propose a game that contains both elements. Continue until a designer can't think of a game; they're eliminated. Also, you can't re-use earlier game concepts; you must propose a new one each time.

Written Exams

This past Thursday marks the first day I've ever given a midterm, and the second time I've had anything resembling a standard written exam.

It's much harder to make a written exam "game-like" without having rules that are so confusing that they get in the way of evaluating students' mastery of the material; the best I could hope for was an exam where students found the questions interesting and thought-provoking. (This meant essay questions. Lots and lots of essay questions. 18 of them, to be precise.)

Mostly, students complained about a two-hour written exam due to hand cramps. They can play video games with an ergonomically-destructive N64 or GameCube controller for ten hours straight, yet two hours of writing and they've suddenly got carpal tunnel. I don't get it.

Having never made an exam like this, I was afraid that it would be too easy, or too hard, or too short, or too long. As it turns out, it looks like I had some serious beginner's luck; no one ran out of time but most students stayed nearly till the end, and so far it's looking like the grades will fall on a nice bell curve. If I've made a serious mistake, it's setting myself up to grade 18 essay questions for 23 students over a single weekend (which is, honestly, much more writing than two hours on a single exam). No hand cramps yet, even with playing Guitar Hero during breaks!

Culture Shock: Citations in Games?

When an Academic writes a research paper, the paper generally cites a large number of sources. This serves several purposes:

• The more sources a paper cites, the more legitimacy it appears to have at first glance, since it is building on established material. Especially if it cites sources that are already well-known and established in the field.
• The more papers that cite a specific source, the more weight is given to that source, and the more prestige to its author(s).
• It helps avoid claims of plagiarism, copyright infringement, etc.

Ultimately, it benefits the creators of the cited work and the new work.

Games don't really do this. In the industry, an obviously derivative game tends to not list the game it's derived from in the credits, even under "special thanks". Sadly, this is even the case in direct sequels, where the team that built the original engine may get no mention in the credits of the sequel. The closest we get is paying homage to an older game by including an easter egg as a direct reference.

It struck me the other day just how wrong this was, when a student of mine pointed me to a game called Bubble Tanks. This game is an extremely obvious ripoff of Jenova Chen's flOw: both take place in water, both have relaxing background music, both let you grow by defeating enemies and shrink by getting hurt, both send you back to easier areas if you get hurt too much. Bubble Tanks adds the ability to shoot, and that's about it. And yet, Bubble Tanks makes no mention of flOw, either in the main screen or in its credits. "Special thanks to Jenova Chen for inspiration" would have been appropriate, no?

The issue is even muddier in this particular case, since flOw was part of a graduate student project, as the practical application of a written thesis. If Bubble Tanks were also a thesis project, you can bet there'd be some serious allegations of academic dishonesty; and if flOw were simply a commercial project everyone would call one or the other a "clone" and be done with it. But when a game crosses boundaries from Academia to Industry, then what? (Not to mention that flOw was commercialized; you can play it if you have a PS3.)

What do you all think? Should commercial games be required (or at least encouraged) to list the games that inspired them in their credits somewhere? I think it'd be useful, in that it would make it easier for Game Studies folks to trace the history of games and game mechanics... but at the same time, I don't see it happening any time soon. Which brings up another question: why the difference between academic projects and commercial ones?

The Many Faces of the Game Designer

If you're a student taking my Digital Game Design class, consider this a spoiler warning: we'll be covering the topic in this post later, so turn back now if you don't want to ruin the surprise.

Now, for the rest of you...

Explaining what "Game Design" is to people outside the industry has always been difficult, because it's such a broad field with such a wide variety of tasks, and because it's intangible (i.e. generally, you can't point to any part of the screen of a video game and say "that thing there is game design"). Yet, it is vital for us to be able to explain what we do to the rest of society -- or at least to our friends and families who want to know more about our lives. And for ourselves, so we can constantly remind ourselves of why we shouldn't just give it all up and become accountants.

So far I've found the following analogies useful:

• Game Designer as Architect. We don't build the game (or skyscraper) ourselves, we just outline the plans (game design documents / blueprints) to let the programmers (construction workers) know what to build and what it will look like when it's done. As far as I know, this analogy is original, and I was the first to state it this way.
• Game Designer as Party Host. We invite the players to play our game (visit our party), and do our best to make it an enjoyable experience for them. I first saw this analogy in the first few pages of the recent textbook Game Design Workshop.
• Game Designer as Artist. Much of game creation is just like the creation of any art form. This is self-evident to most game designers I know, but was proven ever so succinctly by Scott McCloud's Understanding Comics (which is as much about Game Design as it is about Comics, as any game designer who's read it can tell you). This was also touched on by Raph Koster in his book, A Theory of Fun. And of course there's been the question of "whether games are art" that has been argued on both sides since the birth of the medium... and if games are art, then it's not much of a stretch to say that designers are artists.
• Game Designer as Educator. Raph Koster's book argues this as well. In brief, the theory goes that games are fun because they keep us in the "flow", i.e. giving us tasks at the upper end of our abilities; our brains find this an enjoyable state to be in because they are improving by learning; thus, games teach... which means game designers are teachers. Raph makes the argument far more persuasively than I do.
• Game Designer as the Judicial Branch of the Government. Donald Norman, in his book Design of Everyday Things, famously states that "design is the successive application of constraints." Then designers are the ones who place constraints on the player -- you must do this, you can't do that -- similar to lawmakers in the rest of the world.
• Game Designer as God. No idea who I can attribute this to, and of course everyone who's passionate about any field thinks that God is one of their kind. But I mean this in the literal sense; we create a world, its inhabitants, and all of the rules that govern it... and yet, we also create free will (as exerted by the players). Generally, our games are much less complicated than the physical Universe, but the basic principles of creation are the same.

Do you have any other analogies you'd like to share? Post them in the comments.

Virginia Tech

I heard about the shootings yesterday morning on NPR. While driving to school. This gives a perspective that you don't really have when you're working for some software company. (Especially a game company. For all the talk of video games causing violence, I don't think there's ever been a single case of a workplace shooting in the game industry.)

It was appropriate for me to say a few words to my morning class about this. I started off by saying that I gave it a week before the first news story linking the killing to violent video games. I forgot about Jack Thompson, who was on the media scene within eight hours. I didn't expect a second volley from Dr. Phil. Ouch.

I said that any student asking themselves Why This Happened will find plenty of easy answers, all of them wrong. Those wishing to find the truth will have a difficult search, but hopefully a rewarding one.

For those students who wanted to explore their thoughts and feelings on the subject further, I recommended two movies and two games to get them started:

Arlington Road. Granted, the movie is about terrorism and not school shootings, but the lesson is the same: lots of people care more about having the false security that an incident is over, than learning the truth.

Bowling for Columbine. A documentary that examines shooting deaths directly.

Super Columbine Massacre RPG. Despite the obviously-inflammatory title of this game, it examines the anatomy of a school shooting from the inside. My students who played it already said that it made them feel very uncomfortable. And I think that's the point; if you aren't uncomfortable when examining a national tragedy, you're probably taking the easy way out.

Doom. One of the games most often cited as a catalyst in violent crimes. Thus, it's important (especially for students studying video games) to actually play the original game and decide for themselves just how much of a "murder simulator" it really is.

For what it's worth, my students had varied perspectives on the shooting... but we could all agree that our sympathies lay with the victims and their families and friends.

IGF Student Games

One last bit from GDC was the IGF Student Games roundtable. I was sad to see that the room was almost all students, no faculty. There were three IGF judges there, including one who judged student entries, and their advice was invaluable.

If you're a student creating a game, you should be thinking about making it worthy to submit in the IGF when you finish it. If you're a professor running a project-based class where students make a game, you should be thinking about encouraging your students to make it worthy to submit to the IGF. Any student team that becomes a Student Showcase winner gets some media exposure, and will therefore have a much easier time finding jobs in the industry.

My notes from the session, on how to make your student game project as competitive as possible:

• IGF student games should not be full productions. You only get about 5 seconds to hook a judge, and even then they’ll only have time to play your game for about 10 minutes.
• Consider your game as a “Demo”: Get to the “meat” (fun) of the game instantly… within 5 seconds; easy install/config helps a lot; about three good, well-defined levels will give about 10 minutes of gameplay.
• This year there were 108 submissions, 10 Student Showcase winners, and one grand-prize winner. “Don’t enter to be the William Hung of the IGF.” Only enter a game that you think can really compete. All of your first-semester individual student projects should not be entered by rote (although some of them may be good enough to enter). Generally, your game should be a good game.
• Include an automatic Install, and Uninstall. Judges don’t appreciate random stuff that’s stuck on their personal computers. There are plenty of free install apps; use any of them.
• For long-term student projects, you can still submit a project even if some of the original team has graduated. In fact, graduates can still work on the game, as long as they don’t get paid for their effort.
• Judges repeatedly used the word “polish” to describe what they’re looking for in a game, but were clear that this isn’t just about expensive production values. Game should be a complete experience. It shouldn’t feel like there are unfinished features. (Missing levels, sure, but not missing functionality.) Game design should clearly have undergone iteration. It should be fun. Game interface should also be iterated on. Does the game give good feedback? Is the UI “juicy”? Does the game train you to play it?
• Students would do well to check out the non-finalist games of the previous year to see what didn’t win. Decide for yourself why they didn’t win, and make sure your game doesn’t fall into the same trap.
• Focus test your game. A lot. When doing this, don’t tell people how to play it; just sit them down and see if they can figure it out. You learn a lot from watching people struggle, in particular with what player expectations are. One memorable quote from a student team: “We thought everyone was playing our game wrong; then we realized they were playing it right, and we made the game wrong!” It occurs to me that this is good advice for any development team, not just students.
• Make your game single-player (or, if it must be multiplayer, include a one-player version). It’s hard for judges to coordinate to play a multiplayer-only game. Memorable quote: “A multiplayer game is just another person doing the AI for you.”

Common mistakes for student games that keep them out of the top ten:

• Bugs/crashes, art issues, or other obvious flaws (of course).
• Accessibility: what’s happening when you start the game? Does the player have any idea what they’re doing, what the controls are or how the game works?
• Language issues: use clear English in your instructions (this is mostly a problem with foreign teams).
• No gameplay, just walking around in an empty level. No matter how brilliant your game engine is, you need to create at least some content to show it off.
• If the game is clearly in a genre, make it immediately obvious what makes your game different. The judge should not say “great… not another undifferentiated FPS/side-scroller/whatever”.
• Too difficult. Some games are supposed to be difficult and that’s fine, but don’t kill off the judge before they get to the fun part.

Notes from GDC

Most of my notes that are relevant to teaching game design came from the IGDA Educational SIG during the Monday and Tuesday before the main conference. However, there were occasional sessions where I picked up something for this blog during GDC proper. Here are my notes:

From the Academic Group Gathering:

• Note that GDC 2008 is in February. Students working on projects for the IGF this year will have less time to submit.
• There is still interest in 24/7 game development with one team in America, one in Europe and one in Asia. Groups of students who take a quarter/semester hiatus to participate in this project is the most likely way it could happen. Personally, I think the game industry would be very interested in seeing if this works. The results of such an experiment could be used to significantly reduce time to market (with slightly greater cost).
• I doubt anyone in the industry would be willing to stake their current project on this, so if anyone tries it should be college students. Any takers?
• As an educator, talk with companies that give tests when hiring. They won’t give you their test, of course… but you can ask for a sample test that gives the general kinds of things they’re looking for. Collect enough of these from different sources and you can build a pretty solid picture of what the industry wants from your students.

From the Quality of Life roundtable:

• Some people are willing to make sacrifices (including their own QoL) to get a job in the game industry. Most of these people are recent college graduates.
• Problem: everyone who makes these sacrifices becomes part of the problem for everyone in the industry.
• Universities: make sure that your top graduating talent goes to game studios with good business practices, regarding QoL. Do not reward abusive studios with good talent; if the really bad places find they can only hire mediocre talent, it will make that business model much harder.

By the way, if anyone is interested in my notes from the other sessions that have nothing to do with this blog, email me (ai864 at yahoo dot com) and I'll send it to you.

Random Tidbits from GDC for Students

As I mentioned earlier, some of the best conversations at GDC happen between sessions. Here are my notes for students, and student mentors among the faculty (or in industry):

• Consider making a “job/idea board” at your school. Students with game ideas can post their projects, others can pitch in to help if they find a project that sounds good. Forces students to convince others that their idea is worth anything – good practice for industry.
• Apparently, something called “XSI Base” is already a de facto standard for this. I haven't investigated the matter yet.
• You can never remind students enough that they should keep their project scope small and achievable. Attention student game developers: Geometry Wars is fun. So is Tetris. Neither one needs an advanced degree in Computer Science. If you're having trouble coming up with ideas that are small in scope, study retro games!
• Many universities have some kind of “Capstone” experience – students working together in groups to make a complete game. A good rule of thumb: 8 to 18 students per team; one semester pre-production (with final deliverable being a functional prototype), one semester production (final deliverable is a 5 to 10 minute mini-game).
• Amusing suggestion to teachers: “Make all students cancel their WoW accounts at the start of the school year. If they don’t, call their parents.”
• There are lots of game engines out there now, with varying degrees of power versus ease-of-use. Game Maker is great for those with very little technical experience, although it’s mostly limited to 2D retro-games and its framerate and collision detection are only so-so. Torque 2D and GameBrix both seemed popular, and they offer academic discounts. Game Studio A6 interfaces with C++ and supports graphics pretty easily, but has some bugs. With any game engine or authoring tool, having good documentation is key. Others that I heard mentioned later at the conference: ConsoleClassics, Click N Play, The Games Factory. I'll likely spend a good chunk of summer evaluating any demos I can find.

Random Tidbits from GDC for Teachers

Some of the most interesting things I learned at GDC came from hallway conversations, outside of the sessions themselves. I'm glad I carried a notebook with me at all times to record the best ideas. Here are my notes:

Possible assignment for a game design class:

• First, have each student create a game concept.
• Next, have each student create a design document based on the concept of another student who got the same grade as they did.

For a Capstone (student project-based) class:

• In addition to developers (programmers, designers, audio, producers, artists) consider adding one business student in a BizDev role. It’s their job to figure out how to market the current game that the team is working on… and how to fund the next one. This will likely create a number of uncomfortable constraints on the rest of the team, which they will find very familiar once they start working in the industry.
• Suggest to programmers to use generic names for their objects. If you have a flying enemy called a Hawk, call it something like CFlyingEnemy. Often during the course of development, names and art will change – maybe it will become a Vulture or a Biplane or something instead of a Hawk, and the code becomes confusing to anyone who doesn’t know the history of the game’s development. Amusing anecdotal example: in one project, the programmer called all enemies “Baddies” in the code. Some people found this unprofessional… but you can bet any new programmers working with that code know what’s going on!

On Game Design and Architecture:

• Game design is very similar to architecture. In both cases you’re creating the plans for a team to build something.
• So… why do game designers ignore this? Why is Architecture not a required class for all game designers? (I have no answer for this. Anyone want to suggest why this would be a good or bad idea?)

Call for Collaboration:

• Educators who teach game-related courses: post your syllabus online. Got to http://www.igda.org/, log in, then go to Wiki (under the Community heading in the menu), then click on Game Education. There’s a link to add your course to the collection. Follow the instructions from there.If you’re unfamiliar or uncomfortable with editing a Wiki, you can send your course info to the Wiki admins and they’ll post it for you.
• Even if you don't contribute (and shame on you!), the EdSIG Wiki is a great resource if you're setting up a course (or a curriculum) to see what others are doing with the same subject material.

Another Course for Game Design Students

The IGDA Educational SIG at GDC showed me another course that deserves to be part of my proposed curriculum for Game Design majors: Game Appreciation.

Any student who wants to be an artist should take Art Appreciation. Film students take Film Appreciation. Music students take Music Appreciation. Game designers should, therefore, take Game Appreciation.

What would a Game Appreciation course look like? It would involve playing lots of games -- pretty much every game that is widely known in the industry for its gameplay (good or bad). I could offer a list of games, but first I'll welcome all of you to do the same in the comments. At any rate, students would play these games as homework and in class, and then discuss them in class: why the games were important, where the innovations are, what was derivative of what.

Why would this course be useful? First, it's needed as a basis for understanding the art form. Second, it provides the closest thing we have to a critical vocabulary -- "this game is like that other one" -- so it's good to know the right games to compare new ones to. Third, anyone who wants a job in the game industry (especially as a designer) should be familiar with the great works of the past (and present) in order to not appear uneducated. Fourth, it gets your enrollment numbers up because it's an entire course about playing games.

Ohio Game Jam finishes a success

This last weekend was the Ohio Game Jam. We had nineteen brave students... some from across the street, some from as far away as Baltimore. Over a mere 24 hours they created a total of seven working games from six groups, a 116% success rate. I'll post the games and a list of participants on the website as soon as I have everything collected in one place.

As expected, the theme "Nature and Technology" had wildly different interpretations among teams. We also had a number of game types: sim, turn-based strategy, real-time strategy (!), action-arcade, two game-like interactive stories, and one turn-based/real-time action-strategy hybrid.

Lessons learned about game development:

• Keep your scope constrained. Start with a small game whose core mechanics are fun, then expand it as time allows. You end up in a much better position if you already have a working game a few months before alpha, and it's just a matter of polishing, balancing and figuring out what features to add... rather than not having enough time and deciding what to cut. Every project at the game jam was in this happy situation with a few hours to spare; if only more commercial game projects followed suit!
• Not everyone was a jack of all trades, and several groups found themselves in the position where the Game Designer had finished with the initial design, and had to just sit around and wait for the Programmer to reach a first-playable state. One team's designer decided to hover over the programmer and comment on implementation, something akin to the oft-maligned "pair programming", and found great success with it. I suspect this has applications in the industry; pairing up two programmers is questionable because they may not be twice as productive working together as they would be individually... but designers are less expensive than programmers, so having a "programmer and a half" (in terms of payroll) is a much easier pill to swallow. Especially if the designers have nothing else to do on the project anyway.
• Having a balanced team helps. If your team doesn't have any Programmers, you'll be very limited in the kinds of games you can make. If you're missing a Designer, you're in serious danger of not having anything particularly interesting or experimental. Lack of an Artist or Sound person makes your game seem less impressive, and more importantly takes away time from your Programmers and Designers while they're forced to make or find some placeholder art and sound.
• Learn some kind of rapid-prototyping / game-authoring tool ahead of time. Over half of the games used Flash. Others used Game Maker. I've heard good things about (but not evaluated) Torque 2D, Blitz Basic, Dark Basic and Game Brix. Whatever you choose, but learn something. If you're a programmer, you'll probably get stuff done faster using an engine than if you have to write everything yourself from scratch in C++. If you're not a programmer, these tools will give you something to mess around with during downtime when no one's demanding art/music/designs from you.
• The visceral feel of a game matters, so much that it's hard to overstate. The fun of a game has no correlation with the time spent on it. These two concepts together mean that it's better to rapidly prototype a large quantity of crazy ideas, rather than spend lots of resources on the first idea you come up with. This isn't news, but it was demonstrated quite well at the game jam: the overwhelming favorite project of the event was a quick little arcade shooting/dodging game that one person put together in an hour or two while he was was waiting for the rest of his team to wake up.
• That said, the overall level of production values definitely does correlate with the amount of time spent on it. Generally, the best-looking games had been worked on for the longest periods of time. It's important to not confuse production values with fun.

Lessons learned about running a Game Jam, since this was the first that any of us had attended (including me, and I'm running the thing):

• Actually organizing the event is trivial. All you need is to declare a venue and a date/time. "Game jam, my living room, next Saturday" is all you need; the rest is just a bonus.
• Of course, that also limits participation to just you. While some people have no problem with this, I personally think it's more fun if there's a group of people working collaboratively, and getting the word out is the greatest challenge. Especially if you live in Ohio. I found more success promoting the event in my classes, at GDC and on the IGDA's Game Edu mailing list than other methods. Also tried were viral marketing (i.e. asking everyone I knew to tell everyone they knew -- apparently a month isn't long enough for this to take hold), and media coverage (only received two days prior to the event).
• Asking for sponsorship helps, if you know who to ask. We had generous donations of pizza from Papa John's, and some books from AK Peters. Being well-stocked with food, drinks and snacks ahead of time helps greatly.
• For a 24-hour event, allow some time for people to sleep. I had thought that college students would have no problem staying awake and productive the whole time, but it turned out that just about everyone had at least a few hours' sleep, no matter how much caffeine they'd imbibed. (Next time I'll encourage teams to work in shifts, to make sure everyone gets some sleep.)
• Send a reminder email a day or two before to everyone who RSVP'd. I didn't do this, and about five people didn't show even though they'd previously sent me email saying they'd be there.
• Have a guestbook for everyone to sign on their way out. I thought of this, but forgot to actually set it up at the end due to lack of sleep, so I never got everyone's comments.
• Nametags were useful. Color-coded dots so people could identify themselves as Programmers, Designers, Artists and/or Musicians was helpful when people formed groups were also useful.
• Having a theme that's open to interpretation helps you to get a wider variety of games, since teams can go in so many directions, and their first question is always "okay, what does this mean?" If you have a theme in mind ahead of time, however, it makes it much harder for you (as event coordinator) to participate, since you have an unfair advantage. In the future I might find some random way to choose a theme, so that I can be as surprised as everyone else.
• Actually coordinating during the event didn't involve very much effort; there was a lot of down time. Mostly, teams were autonomous, and my role was to foster a spirit of collaboration: "How's it going? Oh, you're having trouble with a bug in Flash? There's a few guys on that other team over there that seem pretty good at Flash, let me introduce you." I also probably should have been the one to make runs for sodas and snacks, but the teams handled this on their own... and it may have been better that way, as it gave participants an excuse to take a five-minute break with a quick walk outside.
• Internet access is very useful to have, mostly because teams can search for stock art and sound effects for placeholders faster than making it themselves. Wherever you run your game jam, make sure there's wireless... or a few hubs and routers.
• Other hardware we found useful: a scanner (lets artists sketch on paper), some basic sound equipment for recording music and voice, and a coffee maker. Participants provided all of these on the fly, as needed; next time I'll try to have them ready beforehand.
• Don't advertise big, elaborate prizes. Any judging you do will be subjective anyway, and you want to give teams incentive to collaborate rather than sabotage. The goal is to have some great games by the end of 24 hours, and it's much easier to have that if everyone's working together.
• Definitely favor small teams over one big team. Extra people don't help you make a better game, so you're better off making more games and increasing the chances of having one that's brilliant.
• Don't be afraid to change teams on the fly if people are having creative differences. Some of our most interesting games came from teams that separated. For a future event, I might consider running slightly larger teams (4 to 6 people) and having each team work on two projects simultaneously, with each individual going back and forth between them to break up the monotony.

Game Designer as Event Host

It occurs to me that if game design is about creating an enjoyable player experience, it must share something in common with other fields that have similar goals: hotel guest services, cruise ship directing, wedding/party planning, and special event hosting. The abstract idea of "customer-centric" thinking and design applies to all of these.

Yesterday, we were fortunate enough to have a special event on campus that was one of the most terribly-run things I've had the misfortune to attend. It was a great case study for my design students; I hope they come back in future years to provide such a powerful object lesson for future classes.

The event was run by some promotions company that was apparently hired by Microsoft to push the Xbox 360, but in the process picked up game-friendly sponsors like Best Buy and (for some reason) Suzuki. They were certainly well-funded; they came with a pimped-out car and a large bus with sponsor decals all over, and they brought forty 360's (I suppose that makes one Xbox 14400, har) and so many plasma screens, and all kinds of giveaway swag. The guys running the event had an average of about ten years experience each. So, they had all the tools and potential for a massively successful event on any college campus. Which makes the whole thing that much more disappointing (and informative).

Among their errors:

• No advance promotion of the event. They had people scattered across campus handing out fliers the morning of. No one I talked to knew anything about it beforehand, in spite of there being rather prominent television, radio and newspaper media all over the place.
• Very loud music was playing at the event, making it impossible to hear any sound from the games themselves. This made the new Dance Dance Revolution game impossible to play.
• All those consoles and not enough controllers. Dance Dance Revolution (a game meant to be played socially) had one dance mat per console, so you couldn't play with a friend (and it was one of those cheap $10 pads too, so you couldn't play any advanced songs). Fuzion Frenzy 2, a party game meant to be played with four people, had two controllers. Gears of War, a first-person shooter known for its excellent multiplayer mode (and equally known for its mediocre one-player) had one controller.
• Some guy was trying to be an emcee, walking around with a microphone and taunting the people who were trying to play. In the words of one of my students, "he was trying way too hard to look like he was cool."
• Overall, the whole thing just felt like it was put together by people who knew a lot about promotional events... and absolutely nothing about games or gamers. The result is similar to what happens when an all-male team of game developers tries to make a game for little girls.

What lessons do we learn about game design from this? Well, that's an exercise I left to my students!

Kurt Squire on Curricular Models

Another wonderful talk from the IGDA Educational SIG at GDC, courtesy of Kurt Squire. These are my notes:


A few years ago, we had: Game Dev programs (DigiPen, Full Sail); “Art and Design” schools (but with few game-specific offerings); ETC at CMU (grad school only); Computer Science; Media Arts & Sciences; Instructional Design; and for college dropouts, the School of Hard Knocks.

Today, we have game design degrees! Why? Popularity (or, increased enrollment); Intellectually interesting; Training for the game industry; Core disciplinary issues: interactivity, teamwork, etc. (carries over to many other fields).

There are lots of different ways to study games.

All faculty who teach games ought to play them, regularly.

Consider a “boot camp” introduction model: low-level courses that show that game development is very hard work, to turn away the students who aren’t self-motivated or serious about making games their career.

What happens outside class is more important than in class. Set up your academic program to encourage out-of-class work. One thing that can help a lot: have your university provide an open lab space where students can work on their own game projects – ad-hoc, informal, driven by excited students.

Have students work in teams. Have your faculty understand (and teach) cooperative learning.

You and your students will have many iterations for everything: individual projects, courses, and overall curriculum. Learn from failures.

Create opportunities for celebration, community ritual. Example: student project showcase at the end of each year.

Game Research Case Studies

There isn't a lot of academic research in the field of game design, and what little there is, I have trouble relating to. At the IGDA Educational SIG at GDC, it was refreshing to see a number of different takes on research that focus on gameplay -- exactly the type of research I'd like to do myself, in those hours when I'm not teaching. Here are my notes from the session:

Jesse Schell (CMU ETC):

• Industry/Academic bridges are mostly 1:1.
• One major problem: many universities can’t hire people with just a BS/BA degree, regardless of industry experience. (Example from last year’s GDC: the Lead Artist for World of Warcraft is unqualified to teach art at many universities. Wait… unqualified?)
• There’s a huge bonus on both sides if this problem can be solved. As people cross borders between Industry and Academy, there is a transfer of technology and information.
• The universities that build the best programs will likely be the ones that are able to find loopholes in the system, creative ways to get experienced industry people teaching their students in some capacity.

James Dargie (EALA):

• Internally, EA has a process that’s something like rapid prototyping, but with artists instead of technical designers.
• Pre-rendered trailer video, takes 1 to 3 months.
• Shows visual style, quality bar and gameplay features at the start of a project.

Jeremy Gordon (Secret Level / SEGA):

• Undirected R&D is attractive to industry since we’re all trying to solve the problems we don’t know about yet.
• But… it requires overtime or extra funding (or both), and there’s no immediate ROI.

Doug Whately (Breakaway Games):

• Breakaway has an interesting funding model internally: Serious Games and Entertainment Games divisions. Serious provides funding for Entertainment, which is treated as funded R&D whose results can be used by Serious.
• (I found out later that there’s a similar symbiotic relationship between Wahoo Studios and NinjaBee, with Wahoo creating AAA games that fund NinjaBee’s low-budget indie games, which in turn are treated as R&D to help Wahoo.)
• Working with universities is hard because of scheduling. Universities work around the academic calendar; game studios work around fiscal years.
• Suggested that some studios might do better if they have rotating undergrad internships throughout the year, encouraging Seniors to take a quarter or semester “sabbatical” to work in the industry for 3-4 months during the school year. In this way, a company can have a steady supply of student interns year-round… not just in the Summer.
• In classroom learning games, expect to see a huge battle between professors. Half will love it because it gives them new tools to teach; half will hate it because it’s an outside intrusion into their acutely-honed, time-tested lesson plans.

John Hopson (Microsoft Games User Research Group):

• Developers are inherently distrustful of anyone trying to tell them how to do their job. This includes academic researchers. If you approach a studio saying “my research shows exactly what you’re doing wrong”… prepare to be ignored.
• Start out with one-on-one: “Give me half an hour of your time, and we’ll show you how to make a better game.” After that works and you’ve built up a small amount of trust, ask for a little more… one baby step at a time. Build long-term trust.
• Schools need to promote their technology to the industry: make sure you show up on a Google search when the industry is looking for you!
• Build cool stuff. If you write a paper for the industry that you think is so great, why don’t you use it? Better to make a working demo, then write a paper that explains how you did it. (Façade is a good example of this.)
• We all have the same concerns as any other field of research that tries to interface with industry. The only difference is that our industry is relatively new.

Doug Church on Academic/Industry Collaboration

The great Doug Church gave a keynote at the IGDA Educational SIG at GDC. Here are my notes from his session:

Research:

• The things the industry wants done, it’s doing already.
• The things the industry doesn’t know it needs… well…
• There is no pattern of discovery in gameplay, i.e. no way to build on previous work. Game AI is in a similar state. (Graphics and Physics do have a pattern of discovery; that’s what SIGGRAPH is for.)
• There is no design publishing culture, and no design or game-analysis critical vocabulary. We’re stuck describing game mechanics as “it’s like this other game”.
• Not much “software publishing” culture at universities.
• Ideally, it would be good to enable undirected research in the Academy.

Sharing Tools/Engines:

• Academics are always asking to use industry game engines to help with their work.
• Industry doesn’t want to inflict their barely-working engine on poor unsuspecting academics. (Engines are usually coupled with the team and processes that built them; just handing an engine to someone else won’t be much help.)
• Also, some companies treat their engine as IP.
• Memorable quote: “If someone stole all the code from Electronic Arts, it would probably hurt them more than help them.”

Knowledge Transfer:

• The people in the industry didn’t learn from textbooks.
• The industry is guild/apprentice like. No shared context, philosophy or vocabulary.
• When an academic tries to approach someone in industry, the response has more to do with timing than anything else: a developer under crunch won’t respond to your emails even if they’d really like to help you.
• The industry has a hard time with long-term commitment. The Academy can’t easily promise specifics or results by a given date. This makes it hard for the industry to fund formal academic research.
• Also, developers are skeptical of formal training, while academics are skeptical of the academic value of games. (Hopefully both of these will change in the future.)

What Next?

• Students are the key stakeholders in everything; put them first.
• More industry/academics working together; for now this is limited to 1:1 collaborations.
• Universities must understand that a game-focused curriculum is not just an interesting backdrop for the “real” education, or a diversion from it; game development courses are an invitation into a community and a chance to choose a future.
• Use iterative processes on different ways to collaborate:
• Lightweight participation is easy. That’s what we do now. We need more 1:1 successes until we get some critical mass.
• Bidirectional placement! Can a developer teach a course in their spare time (or take a year off to do so full-time)? Can a professor work in industry during their sabbatical year?
• Developers need to give academics more access to their efforts, so that good practice can be studied and documented.
• More student group projects! (Amusing possibility: each year’s crop of students must not only create their own game project, but also support the previous team’s software.)
• We need formalized grammar and vocabulary, but it’s uncertain where this will come from. Previous tries from academia were forced/mandated and didn’t work. Not coming from industry, either.
• Overall: we need energy, motivation, mutual respect, and people who understand both sides… like today’s students!
• Both sides need to balance reality with idealism.

Q: How valuable is it to teach students methodologies (e.g. agile development, time estimation)?
A: Specifics are not as important as the experience of trying – and understanding that game development is hard and can go horribly wrong!

Q: How can academics study the industry when it’s so secretive?
A: Indie studios may be more willing to open their doors. Or, cultivate relationships with many individual developers, and contact someone who just shipped a successful game and has some pull in their organization.

The Critical Vocabulary Problem

I saw this touched on briefly at GDC this year, but no solutions were given. That's a shame, because it's not something that I can see solving itself anytime soon, and game designers really need to make some progress here.

The problem is that we really don't have a critical vocabulary in the field of game design. When we talk about game mechanics or dynamics, the best we can do is to compare it with what's been done before: "It's like the sandbox mode of GTA with the combat system from Halo, and the mini-map from Ratchet & Clank."

This is limiting: it prevents us from describing new innovations (I remember people trying to describe Everyday Shooter at GDC, and the best we could do was "you have to play it, then you'll understand"). It also limits us even when discussing purely derivative works; if I haven't played Okami, then you can't compare it to another game and have any real understanding between us.

So, we need a better vocabulary. Which leads to the next problem: everyone writing a game design textbook is trying to solve the problem at the same time, each with their own proposed language.

None of these get absorbed into the collective consciousness of the industry, because no single textbook on game design has been read by enough game designers. But designers in the field aren't trying to create their own vocabulary, either.

As a teacher, this creates additional problems. Suppose I use a textbook that uses a combination of existing industry jargon, and new terminology coined by the authors. I've yet to see a book that makes a distinction between the two, so I have to manually warn my students about which terms are okay to use if they're talking with a designer, and which ones they should ignore (or at least use cautiously). But then, if enough students who studied one particular textbook find themselves in the industry, this terminology could start getting used... and then I'm in the position of trying to predict which of the many textbooks will see widespread adoption in the next few years.

And then there are the teachers out there who have no game design (or game industry) experience, and couldn't tell a good textbook from a bad one, and won't be able to make the distinction between "currently in use" and "proposed" terminology in their classes. My students will be competing with these, and the other students may even sound smarter, with their talk about operational versus constructive rules... even though my students might be better prepared for the industry.

Ultimately, I'm not sure what direction a long-term solution can come from. Industry is too busy to figure this out on its own, and too insular to listen to suggestions from academics. Today's students may carry some critical vocabulary with them, but it's so scattered across many different texts that there's unlikely to be a consensus. I suppose it will ultimately take a single game design book that is so much better than the rest, that it gets adopted by every class overnight. Any volunteers to write it?

I now have a reputation for strange finals...

On Tuesday, I gave the game design final. Students in small teams learned to brainstorm game concepts over the course of the last ten weeks. This time I threw in a few twists. Three times, I changed the requirements. Once, I had one student from each group rotate to a new group (to simulate losing a team member and having to train a new one). Towards the end, I suddenly reduced the time limit, and then added it back when it would no longer do any good.

The students loved it. They totally understood that this was inspired by real-world events, and that all of the new requirements were drawn from previous projects they had done. I was afraid I'd hear a lot of complaints of unfairness, but my fears turned out to be unnecessary.

I did hear of a similar mechanism from another game design teacher at GDC. Instead of having pre-scripted events like mine, she used a "wheel of misfortune" to choose events randomly. I prefer that solution as a way to deflect students' ire (if there is any) -- it's not my fault, it's the wheel!

Conflicting Goals for Game Schools

As I recover from GDC, I'll be posting all of the stuff I learned about teaching and game design. I probably have enough material to keep me busy for the next few months.

I'll start off with an inherent conflict within any sort of game-related program: the desire to attract students, and the need to only graduate the best ones.

On the need to attract students:

• If you're at a liberal arts college that's experimenting with its first game curriculum, you need decent enrollment numbers to show student interest. If your numbers are too low, the program gets canceled.
• More students means more funding, which translates to better equipment and more resources to help your students make great games.
• If your school has a reputation for a 90% dropout rate because you're just that harsh to your students, you'll have a hard time attracting anyone -- even skilled students who can make it, but who might not have the self-confidence to try.
• Failed attempts hurt students a bit too much. If you have two semesters' worth of F's, it would take seven years' worth of straight A's to get back to a 3.5 GPA (which is a requirement for some grad schools and scholarships). Without some kind of grade amnesty/forgiveness, this seems a bit harsh for a program that will obviously interest many students who aren't prepared for it.

On the need to only graduate a few:

• The game industry is still very skeptical of game-related academic programs. Simply slapping a label like "Game Design Major" on your students will not give them any legitimacy when they look for jobs.
• Because of this, your students are effectively representing your school and in fact all schools with game programs whenever they interact with the industry in any way.
• Since it's such a small industry, word gets around very fast. If one company hires one of your students and later finds out they have no idea what they're doing, it will be an uphill battle for any of your future graduates since all of the major studios will "know" that your program isn't preparing its students.
• Even applying for a job is enough to soil your school's reputation. If a student shows a game-specific Major on a resume, attached to the worst cover letter ever written, what does that say about your school?
• The game industry is a harsh world. Treating students gently does not prepare them for cold reality. Better for students to get used to it in school, and those that can't handle the abuse will be happier in the long run to not enter the industry in the first place.

I can see both sides. So far, I've been erring on the side of helping students as best I can, because low enrollment numbers puts my department out of a job. In the future, as our program gets better established, I'd like to shift towards a "boot camp" mentality, with some low-level classes that are overly harsh. This allows students to self-select out of the sequence before they do too much damage to themselves, and guarantees that only the ones who are really serious will continue on to the more "fun" parts. But by then, we may already have a reputation for being too easy on our students, and it will take time to reverse that.

Welcome, new visitors

I've met a lot of new people at GDC already. The two-day workshop on education was an absolute blast, and I enjoyed meeting so many people struggling with the same challenges that I did. This is exactly the spirit in which GDC itself was originally founded -- we're all isolated from each other, forced to reinvent each other's wheels, so let's just get together and share our knowledge so that we can all benefit.

If you're new:

Most of my posts are not time-sensitive, so feel free to browse the archives (and even comment on them). A logical place to start would be my original welcome message, followed by my series of posts on building a game design curriculum.

For those of you looking for the notes from today's talks, the notes from the undergraduate game design session is here (thanks, Beth). The notes from my five-minute case study aren't online in the Education SIG blog right now, but my final exam rules are posted here, and my after-the-fact comments on the final exam are here.

Lies I Tell My Students

I'm not much of a party animal or night owl anyway, so I'll just finish grading all of the assignments at GDC after the day's sessions are over.

Yeah, right.

This would have worked last year when I was a newcomer. This year, I know far too many people in the community. I didn't realize this until last night, when I found enough people at the Marriott ("the new Fairmont") to keep me entertained until past midnight... and this is on Monday, before most people are even here.

Oh well, it seemed like a good idea at the time...

Off to GDC

Well, this is it... I'm leaving in about half an hour for the airport.

For those of you who are going to GDC as well, I hope to see you there. Look for a guy in glasses with a gray hoodie and a backpack, with 1d3 students in tow at any given point in time, and the name "Ian Schreiber" dangling from his neck.

For those of you who aren't going, I'll try to keep this blog updated on the normal schedule... but no promises. Maybe I'll be so busy that I can't post anything. Maybe I'll see so much cool stuff that I'll post much more content than normal.

Teaching: Recent Advice

Recently, another (far more experienced than me) professor gave me some unsolicited advice about teaching. This is the first time that this has happened since I started teaching, and I am grateful for it:

• The best use of student evaluations (especially the numeric parts, i.e. "rate this professor from 1 to 10 in the following areas") is to identify my own relative strengths and weaknesses. There are no absolute criteria to base the numbers on, so knowing that I got a "7" in one category isn't that useful... unless most of my other numbers were significantly higher or lower.
• Sitting in on another professor's class in order to observe their teaching style is fine, but it's considered polite to warn them first and schedule in advance. No, I haven't committed a faux pas here... but I might have, since it never would have occurred to me. If someone sat in on my class unannounced I'd be flattered.
• College students aren't fully alert until around 10 or 11 am. If I get stuck with a 9:00 class, there is absolutely nothing I can do about this; it's a fight with human biology.
• (Corollary 1: If I ever have a say in such things, insist that the earliest classes of the day start at 10, even if it means that the afternoon classes end at 6 instead of 4 or 5.)
• (Corollary 2: If I can't do that, insist that the early-morning classes are the most useless and expendable in the entire curriculum.)
• It's good to end class with a game. It reminds the students why they took my class in the first place; it reinforces what we've learned during the class; and amount of time spent on the game can shrink or expand based on how fast we got through the rest of the content.
• It's good to ask students lots of questions and keep them engaged throughout. As time goes on, I'll learn to spend less time speaking and more time asking good questions and then moderating the conversation. (Should be a useful skill if I ever moderate a GDC roundtable.)