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.