Sunday, January 28, 2007

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.

Friday, January 26, 2007

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?

Wednesday, January 24, 2007

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.

Saturday, January 20, 2007

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!

Wednesday, January 17, 2007

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.

Sunday, January 14, 2007

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?

Wednesday, January 10, 2007

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:

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.

Monday, January 08, 2007

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.

Monday, January 01, 2007

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.