Emergent Design: Magnetic Whiteboards

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

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

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

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

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

Final Exam, Second Season

In the Fall, I had a gameshow-like final exam in my Game Industry Survey class. I was happy with the results. Originally I planned to ask everyone two questions, but due to time constraints we only had time for one. This time I'll limit the number of buzz-in responses to make sure we don't get stuck on a single question for too long, so now there can be two questions for everyone.

This was my thinkinguntil someone pointed out the obvious to me: last time I had 16 students, this time I have 27. Oops.

I really don't want to have everyone's final exam grade come down to a single question. I'm thinking of adding a written section at the end, including some questions that everyone must answer. Maybe some essay questions (similar to Fall's "bonus questions" except that they're a part of the raw grade and not a bonus), plus perhaps some quick written fill-in-the-blanks (similar to Fall's "lightning round" except asked of everyone rather than just one person at a time). I don't particularly like this solution because it makes the exam more traditional, but I'm not sure what else to do at this point. Suggestions?

Emergent Design: Prisoner's Dilemma mods

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

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

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

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

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

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

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

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

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

Teaching a class the second time is different

The content for my Game Industry Survey class today was identical to what it was in the Fall.

On my Fall notes, I have in my own hastily-scribbled handwriting for Lecture #5: "I thought this would take a lot of time so I rushed through it, and ended up an hour short." This time, knowing better, I didn't bother rushing. I had plenty of time -- an extra hour in a two-hour class!

The students had other ideas. We got into a class discussion on ESRB ratings and the responsibility of retailers (and parents and legislators); and another discussion on whether rentals were good or bad for the industry as a whole, and how they changed the business decisions of what games got funded. Great stuff, and very much on topic, but neither of these topics were brought up by students in the Fall.

Between these debates and my relaxed pace we only had ten minutes left at the end to play Guitar Hero, and we never got to watch the awesome developer interviews on the disc (or look at the Accordion Hero website) -- I'll have to save those for next time. So much for relying on my notes from last time; the students are different, and therefore, so is the course!

Update on Grading Methods

A long time ago I was thinking about different ways to grade a class. For the intro class, Game Industry Survey, I ultimately decided on scoring out of 1,000,000 points -- it's more accessible, and any given assignment feels uplifting even if you only got 50% (which most students don't, since it's not supposed to be a difficult class). It served its purpose: it amused the class on the first day and set the stage for this being more about fun and learning than traditional skill-and-drill.

In the interest of science, I decided to use the Zelda Heart method for my Game Design Workshop-like class this Winter. The students are already (mostly) familiar with me as a teacher, they're ready to take a step towards being a game designer, so I wondered if they'd be more open to alternate grading styles. So far, the reaction is very positive; students chuckled when they saw a "life meter" on the last page of the syllabus, and they realized (without me having to point it out) that turning in assignments late amounted to "poison damage". So far this seems to be working... at least for an advanced class.

Flash as the ideal tool for student game development?

Flash seems to have an awful lot of things in its favor as a platform, from a student perspective:

• It's (relatively) easy to learn and work with, especially for non-programmers.
• It supports a lot of common game behavior (capturing mouse/keyboard input, drawing sprites, playing sounds and animations, collision detection) right out of the box.
• ActionScript is extremely expressive and powerful when you need it to be.
• Content management (art, animation, sound) is absolutely trivial.
• It's cross-platform, so it doesn't matter if some students prefer Macs and others use PCs.
• The end result is playable in a Web browser, making it a nice addition to a student's online website/resume.

The only down sides I see:

• It's definitely NOT priced for a student budget. But if the school already has some educational copies in their computer labs that are available for student use...
• If you're a programmer, you should really be using C++ (or maybe Java) since that's what pretty much everyone in the industry uses. Flash experience won't get you a C++ Programming job, or at least won't let you prove your C++ skills. This can be mitigated by providing other code samples, and using Flash simply to show that you can work on a project with students from other disciplines. And if you're anything other than a programmer, then this does demonstrate your technical ability.

Is there anything I'm missing here?

Innovation in Retro Gaming

Retro-style games are great for student projects because of their small scope of implementation, and necessary focus on gameplay. The down side is that all of those older genres have been done to death -- they've been around the longest, so they've had the most time to have every last drop of innovation squeezed out of them. Right?

And yet, this was the task set before my Capstone students: come up with something that can be done in twenty weeks with relatively little programming.

They came up with a surprising revelation: one particular genre, the 2D platformer, still has a lot of life left in it because of a curious property: every successful game takes the basic platformer mechanics and adds just one or two "gimmicks", so all you have to do is choose a gimmick that hasn't been done before. And I think they're right, looking at successful platformer franchises and their gimmicks:

• Mario = hidden stuff
• Sonic = go really fast
• Castlevania = short-range attack with whip
• Pitfall!, Prince of Persia, Impossible Mission = time limit to complete the entire game
• Metroid, Blaster Master = explore a huge map, gaining access to new areas as you get more powerups
• Mega Man = choose the order of stages, earn boss's weapons
• Incredible Machine, Lemmings = build and/or destroy the platforms as you go

There are some interesting ideas there, but really, they don't even scratch the surface of what's possible. There's a lot of room for new gimmicks that haven't been explored yet, which is why we're still seeing new 2D platformers in this day and age:

• Gish = blob physics
• LocoRoco = rotation and gravity
• Braid = time reversal

So, it would seem this is a promising direction for aspiring game developers who want to create something interesting on a student's schedule/budget.

What I've Learned So Far

Just taking stock of a few things I've noticed now that Fall is over and Winter is starting...

College students are very excited about the concept of taking a course about video games. However, getting the word out to students outside your department is really hard.

If you're introducing new courses to a curriculum, start at the most basic level and build up. If you have the opportunity to teach an upper-level Special Topics class in something that you (as a teacher) are passionate about, but it requires some background material that the students might not have yet... Just Say No. Or rather, Just Say Yes But Next Year! Don't be afraid that this year's graduating students will "miss out" -- if they can only take one course, it's better for most seniors to leave with a 100-level "intro to the industry" course that points them in the right direction, anyway.

For every homework that you assign, ask yourself: how long will it take me to grade this? Is there some way I can have students do the same kind of work, but that's easier to grade? That said, students seem to appreciate if you take the extra time to give them meaningful, personalized feedback on their assignments.

If you make yourself available to chat with students a few minutes before and after each class, don't expect any visits during your office hours.

Keep soft copies of everything you do for a class, and keep it all organized as you go. Keep it in one central location, ideally a thumb drive or laptop -- if some of your notes are at school and others at home (or worse, the same notes are in both places but one is a more up-to-date version) it's a nightmare to sort out.

Teaching: Grading an Interdisciplinary Class

One of my upcoming classes basically amounts to a group of students working together in a team to make a game. I expect them to have some great experiences, and the classroom is a much better place than the first industry job to make some serious beginner mistakes. So, I'm really excited about this one.

Then there's the question of grading. If I have a programmer, a couple of designers, a producer, an artist, maybe a sound guy, all working on different aspects of the same project... how do I grade them?

So far, I've come up with several possible methods:

1) The "I know it when I see it" method. No quantitative grading at all, I just assign whatever grade I feel the student deserves. While this would probably give the grades that are the most in line with what students have done, it's a terrible stress on the students themselves, and it puts a lot of burden on me to Get It Right. And if a student complains that they got an unfair grade, I have no defense.

2) The project-based method. I grade the final project, not the individual students. Everyone gets exactly the same grade. I don't like this, because it doesn't allow for variation in student abilities.

3) The discipline-based method. I grade the programming on the final project, and anyone who was a Programmer gets that grade. I do the same with design, art, audio and production. Everyone gets graded on their own work... except that you quickly realize that everyone's work affects everyone else. Maybe the game has a brilliant design, but it just can't be implemented by the programmer(s) in the amount of time we have; this is an issue with design and programming and production, so who gets a lower grade?

4) The method I'd like to try is a hybrid between project and discipline. I grade the final project on its various aspects, and each student gets a different weighting of those aspects based on their role:

• Programmers: 40% programming, 5% design, 10% art, 10% audio, 15% production.
• Designers: 15% programming, 40% design, 5% art, 5% audio, 15% production.
• Artists: 5% programming, 10% design, 40% art, 10% audio, 15% production.
• Audio: 10% programming, 5% design, 10% art, 40% audio, 15% production.
• Producers: 15% programming, 10% design, 10% art, 5% audio, 40% production.
• Everyone also has 20% class participation. Class time is roughly the equivalent of team meetings, and not showing up for work is obviously bad.

Where the five categories are roughly defined as:

• Programming: does the game work? How buggy is it?
• Design: is the game fun?
• Art: does the game look good?
• Audio: does the game sound good?
• Production: did the game get finished on time with all of the intended features?

I'm hoping to impress on the students that their work affects the rest of the team, and the rest of the team's work affects them, and that in the industry they're ultimately "graded" on the sales of the final game above all else.

Culture Shock: Iterative Design is not Iterative Design

When designing a game, most people at least give lip service to the concept of iteration: that is, no one gets it right on the first try, EVER, so build some time into your schedule to make major changes that you'll find along the way. It's the game developer version of the saying from engineering, "build one to throw away". I'm sure other fields have their own jargon for essentially the same thing.

Of course, with games (especially for console), once you ship your game you're done. No more iteration for you! If you're lucky and the original game is Good Enough, you might be able to improve some things in the sequel... but you can never go back and actually change the first one. "Remakes" of old games are incredibly rare.

Designing a class is just the opposite. I taught Game Industry Survey once already, and I'll teach it again two more times this year. Each time, I get to look at the results from previous classes and iterate on the design, improving weak points, tweaking the grading system, updating the content, and generally making the whole thing better. And I get to do this again and again, with fresh students each time who don't have any previous experience with earlier versions.

This property of classes encourages risk-taking. I can do something crazy like make each homework worth a hundred thousand points, and if it doesn't work then I can just apologize to the current class and change it next time around. It's quite a different environment from the risk-averse environment of the game industry, and the only thing that changes is that I get to redo my work after it "ships".

Recycling a course is harder than it sounds

At first glance, teaching the exact same course with the exact same material should mean an absolutely trivial amount of work (like, none at all). In practice, there are a lot of details that add up. It's still nowhere near the amount of work to create a course from scratch, but neither is it zero. Tasks include:

• Revising the syllabus. The course meets at different dates and times, assignments are due on different dates, there's a new call number, and there was probably some confusion over something from the last class that needs rewriting.
• Revising all homeworks and other assignments. I suppose I could be lazy and give exactly the same work, but that just gives an unfair advantage to anyone who knows someone who took the class before. I'd rather make subtle changes that keep the spirit of the work the same, while still making it impossible to copy from an earlier revision. I need to change minor details like the date that's due on each homework, anyway.
• Changing the content. It turns out that I have fewer courses in the Winter than in the Fall (due mainly to my being absent for GDC), so I have to choose what content to eliminate. This is something like choosing which of your children to shoot. I'll probably compromise by holding optional evening classes to cover the missing content, and offering extra credit to anyone who shows.
• With less "required" content, that means I have to revise the final exam to remove any questions about material that won't be covered in class.
• In general, going over all of my handwritten notes from Fall, and incorporating all the stuff I learned about what to do (and what not to do) into my written notes.
• And naturally, since the game industry keeps changing, I need to look over all the content and remove or modify anything that's no longer current.

I had no idea recycling involved so many details, until I sat down to actually do it...

Recycling a course is harder than it sounds

At first glance, teaching the exact same course with the exact same material should mean an absolutely trivial amount of work (like, none at all). In practice, there are a lot of details that add up. It's still nowhere near the amount of work to create a course from scratch, but neither is it zero. Tasks include:

• Revising the syllabus. The course meets at different dates and times, assignments are due on different dates, there's a new call number, and there was probably some confusion over something from the last class that needs rewriting.
• Revising all homeworks and other assignments. I suppose I could be lazy and give exactly the same work, but that just gives an unfair advantage to anyone who knows someone who took the class before. I'd rather make subtle changes that keep the spirit of the work the same, while still making it impossible to copy from an earlier revision. I need to change minor details like the date that's due on each homework, anyway.
• Changing the content. It turns out that I have fewer courses in the Winter than in the Fall (due mainly to my being absent for GDC), so I have to choose what content to eliminate. This is something like choosing which of your children to shoot. I'll probably compromise by holding optional evening classes to cover the missing content, and offering extra credit to anyone who shows.
• With less "required" content, that means I have to revise the final exam to remove any questions about material that won't be covered in class.
• In general, going over all of my handwritten notes from Fall, and incorporating all the stuff I learned about what to do (and what not to do) into my written notes.
• And naturally, since the game industry keeps changing, I need to look over all the content and remove or modify anything that's no longer current.

I had no idea recycling involved so many details, until I sat down to actually do it...

Winter Break is a Hoax

With only one week between the Winter and Spring quarters, I effectively need to prepare for all of my Winter and Spring classes right now. This involves two brand-new classes, plus the administrative details of the classes I'm repeating (like changing the dates on the syllabus). I also have some short-term industry contract work, and some game-related R&D that I'm supposed to be doing at home.

So far, I've been about as busy as I was during Fall.

I always thought that whole "22 weeks of paid vacation per year" thing sounded too good to be true...

Fast Group Board/Card Games

One of my courses this Winter will focus on the rapid design of game concepts. While most of the games will be digital in nature, I think it's important to have at least some grounding in physical card and board games, as the boardgame industry has permanent ties to the video games (for several reasons).

One project I'd like to do will involve eurogames, and in particular I'd like to demonstrate a number of these games in class. Ideal games can be played with a large number of people (6+ "players", with the ability for several people to play as a single team), have simple rules that can be explained in a minute or two, have a total playing time of 15-30 minutes or less (although for games with multiple rounds, 15 minutes or less per round is acceptable), and can be played without specialized components (in case I don't actually own it in my collection and can't find a copy in time). Oh, and it should be fun, at least for the first few times.

So far I've come up with 6 Nimmt, Diamant, Circus Flohcati and Tutankhamen. If anyone has other suggestions, please post a comment here. Thanks!

Teaching: Groups of Three

With my first set of courses done, I'm looking ahead to the next set. One course in particular offers an interesting challenge.

The course is basically a set of game design exercises, meant for small groups (three or four; I think five would be excessive). Each exercise would go something like this:
Tuesday in class: We play a game or set of games, and analyze them from a game design perspective. The choice of games is relevant to what we'll be doing for the project.
Tuesday-Thursday, homework: Students perform some kind of preliminary market analysis that will be relevant to the project, so they won't be starting from square one. For example, if they'll be designing a game to fit a license, this is where they'd take a look at the license.
Thursday in class: Project is assigned. Groups brainstorm ideas together, and submit their best idea at the end of class.
Thursday-Tuesday, homework: Groups take their best idea and flesh it out into a full concept (one or two pages). Something that would be presentable at a business meeting.

Now, the obvious problem here is that it's an awful lot of work outside of class.

Here's what I'd like to do: delegate the homeworks to one person in each group, and rotate it around. With groups of three students each, and nine projects total in the course, that means each student would have a total of six homeworks, none more than a page or two. Much more manageable.

But what do I do if the number of students isn't divisible by 3?

Culture Shock: Class Post-Mortems

In the game industry, it's traditional to do a post-mortem at the end of a project: everyone on the development team sits down and tries to identify what went right and what went wrong, as a way of avoiding past mistakes on future projects. I wanted to bring that same spirit to my classes, particularly the one that I'll be teaching again immediately after winter break.

Now, in both cases, brutal honesty is hard to come by. If you're working on a development team, your desire to be honest for the good of the company is tempered by your desire to not tell your boss why he sucks. Likewise, it's hard for students to tell a professor why his class sucks if he hasn't yet submitted final grades. So that much, I'm used to.

That said, there's a self-selection bias that exists in a classroom but not in industry. That is, at a game company everyone on the team shows up for the post-mortem, because it's part of their job and they're getting paid for it, so the people who got burned on the project will be there as advocates for change. After a class is over, the students who hated the experience are going to leave as soon as possible; they don't want to stick around for a post-mortem. The only students who remain will be the ones who were already loving the class and don't want it to end, so any comments will be skewed very positive. Meanwhile, the students who struggled and had real issues won't be there to let me know, so I'm likely to repeat my mistakes by catering to a certain breed of student while possibly alienating others. (Don't get me wrong. The students who participated made some great suggestions that I'm going to implement next time around; I just want more information from a wider range of perspectives, because that tends to lead to more surprises.)

I suppose that's what the student course evaluations are for, but I don't really trust those either. Many students don't take them seriously and will comment more on the professor's hair style than teaching ability; also, it doesn't give me the ability to ask targeted questions ("what do you think about Homework #4?") so the comments may be too general. Oh, and I had my evaluations done about two-thirds of the way through the course, so anything that happened in the last third won't be represented on the evals.

I was thinking of perhaps using class time to conduct a post-mortem, as a way of forcing the issue, but then I'd have to remove something else -- so I'd be cheating my current students out of valuable class time, in order to benefit the students next quarter. Not really fair.

Any other ideas of how I might get honest feedback from all my students -- both the ones that love the course, AND the ones that hate it?

Final is done!

Overall, it went very well, and I'll definitely consider this style of game-demo-exam in future classes. Things I learned, in no particular order:

• I'm not exactly a whiz with video cameras. Even though the final was taped, I have no idea if it recorded sound, or even if it recorded at all, so it's a good thing I wrote everything down as I went.
• Preparation is key, and I didn't do enough of it. In particular, I forgot to make sure there was a PS2 in the room, so I had to take a short recess in order to hunt one down and connect it. Time was very short, and delays like this were deadly.
• Students were absolutely terrified going into the exam; this comes from the prospect of being asked only two or three direct questions, and what if I draw a total blank? As soon as we started, everyone was much more at ease -- it felt a lot like the discussions we've had in class all along -- and I think many of them forgot they were even taking an exam :)
• Students had a tendency to repeat each others' answers, weighing in with their opinion, apparently forgetting that I was only asking for NEW information. These took up a lot of time, particularly on open-ended questions in which everyone had an opinion they wanted to share. I need a new rule to prevent getting bogged down on a single question; I'm considering limiting the "buzz-in" responses to something like three per question instead of unlimited.
• I realized when I had asked a single round of questions that we were about an hour and a half into a two-hour exam, and decided on the fly to go immediately to the "lightning round", and then ask some bonus questions (individually written responses on index cards) with whatever time we had left. This ended up being a reasonable way to deal with time pressure. Unfortunately, it did mean that there was more of a focus on older games (and more class lecture, less reading and terminology) than I'd have liked.
• This really only works with a very small class (<20),>
• Ask the most interesting and thought-provoking questions first, so students can get into the spirit of the exam and really start paying attention. Save the most fun, entertaining questions for last, so students will leave the exam (and the course) on a positive note.
• It helped to talk like a gameshow host, referring to students as "players" or "contestants", asking for a round of applause for our sponsors, and having parting gifts. First because it sounds so ridiculous that it really removes tension, second because it makes the video camera in the room feel more natural.
  

Marble Sadness

There are times in your life when you realize that it's nearly impossible to share some experiences of your youth with the next generation.

Those kids who saw the Star Wars movies starting with Episode I (instead of IV like the rest of us) will never be able to experience that shock of finally realizing, after all of the conflict, that Vader is actually Luke's father. You just can't un-see the new trilogy to experience the old trilogy with a clean slate.

Similarly, a couple of weeks ago I found (to my surprise) that most of my students had heard of Marble Madness, a wonderful arcade game first released around the time that today's college students were just being born. Why? Because the game has been ported to just about every console machine Atari could get its hands on. My students haven't seen an arcade model (many didn't even know it was an arcade game), but they've seen the NES version.

This is a shame, because there has never been (to my knowledge) a decent port of this game to a home system. The great thing about this game is its play control: you roll this heavy trackball and your marble on the screen moves in the same way. Converting it to a d-pad control simply doesn't work, because it removes that visceral rolling that forms the core of the game; it's like playing a dance/rhythm game with the sound turned off.

So, all of these kids today think of Marble Madness as this mediocre race game for console with lousy play control, not as a perfectly wonderful arcade game with the curse of never surviving a port intact. And that makes me sad.

Teaching Backwards

Due to low enrollment in one of my Winter courses, the focus of the course has changed to something completely different. This happened all of a sudden at the very end of classes this quarter, so it's a bit unsettling.

I'm excited about the content though. This will be a pure design course, with no art or programming to get in the way. It's project-based: students will work (probably in groups) on a set of exercises. I'll cover some physical card and board games, and some paper designs (and project proposals) for digital games. I plan to keep the students on their toes by offering them interesting sets of constraints; I did this before on a semi-regular basis at Hi-Score, so expanding that into a full class shouldn't be too hard.

Here's the strange thing, though. This Fall, I taught a course about rapid prototyping and iterative design, from a technical game design perspective; this was a course where students were expected to actually implement their ideas, sometimes doing some light programming or scripting in the process. It's a pretty advanced course for undergraduates.
Meanwhile, this Winter I'll be teaching a practical game design class. And this Spring I'll teach a game design class that covers the theoretical foundations of the field.

Through a set of circumstances outside of curricular matters, I'll teach these courses in the reverse order that students should be taking them!

Lesson learned: next time I'm introducing a new set of courses to an existing curriculum, offer the lower-level ones with fewer prerequisites first.

Culture Shock: Going Independent

Occasionally, a jaded game developer gets fed up with harsh industry practices and decides to strike out on their own, starting their own game company to make their own games. This usually involves moving to a cheaper apartment and eating ramen for awhile.

And occasionally, I'd imagine a jaded university researcher gets fed up with stuffy academic bureaucracy and decides to strike out on their own, doing research as a commercial venture. This also involves ramen, unless they manage to secure a grant first.

If a teacher decides they've had enough of the system, though, there's not much they can really do. Tutoring, maybe, but it's not really the same. I suppose it's because academic programs are accredited; you could start your own university, but it takes millions of dollars, and there's no easy way to do it "on the cheap" that I can tell.

Not that I'm looking to do any of this, mind you. It's just one of those differences I noticed the other day.