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.