Monday, December 31, 2007
Students wishing to win the IGF some day should take a good, hard look. This is the bar you need to meet or exceed as a student project.
Note that you do not need to be brilliant at all aspects of game development. Crayon Physics and Poesysteme have rudimentary graphics at best. The Misadventures of P.B.Winterbottom was done using some very simple scripting in Flash. Mayhem Intergalactic isn't particularly original game design (it's basically a "mod" of the board game RISK).
I do not point this out to put down this year's winners. All twelve are outstanding games (and I judged some outstanding games that did not make the list), especially considering that they are student projects. Rather, I say this as a word of encouragement to those students who are intimidated. Yes, the bar is high. But if you can truly excel in one or two areas of game development, even if you are lacking in the others, you've got a shot. Design and create the kind of game that really shows off your strengths, rather than complaining about your weaknesses.
Saturday, December 29, 2007
Three ways to use games in class:
- Play games as a classroom activity. This is obvious and it's effective, but it has several limitations. Games are great at teaching concepts, especially system models, processes and cause-and-effect relationships. They're terrible at teaching content, making them unsuitable for content-heavy classes. Also, most games are made for 1 to 4 players, and don't scale well to a 25-student class. Lastly, these require a good deal of "game literacy" on the part of the teacher, making it not suitable for all teachers; most classroom games are some crude form of Jeopardy!, only because the teachers lack the game experience to go beyond.
- Discuss the games that students have played in relation to the course content. This is easy: ask "has anyone played a game that has ____?" and then compare and contrast between the content in the game versus that in the class. This also has limitations. Not all students are avid gamers, so the comparisons will only be useful to a subset of the class. It also requires game literacy on the part of the teacher, to provide examples when the students can't think of any.
- Modify your teaching style to be more game-like. Add elements to your class that make them just as engaging and interesting as a game (for the same reasons). This is the hardest way to use games, but by far the most rewarding and least limited.
- Games are interactive, not passive. It is the interesting player decisions that make the game. Include interesting decisions in class. This includes classroom discussions, a choice of topics or homework problems (with varying tradeoffs so that the more interesting ones are also harder or contain other "fun" rewards), and asking the class questions (either to individuals or by having everyone "vote").
- Applying flow theory (making the content at an appropriate level of challenge) is not obvious, because different students have different skill levels. One way to do this is to include multiple layers of depth to your topics; explain first what's going on conceptually at a fundamental level, then go into the details every student needs, and then offer additional insights for the advanced students. Another great place to do this is homeworks and exams, offering a variety of basic, intermediate and advanced problems so that all students can find their own level of challenge.
- Use as many different kinds of fun as you can think of in your classes...
- Exploration fun is difficult when you're stuck in a classroom, but field trips (especially open-ended ones where students are free to explore the area rather than being herded like cattle) can tap into this. If you have computers in the classroom, you can ask students to search the Web for information relating to a topic, providing a kind of exploration as they navigate from one page to another.
- Social fun is easy: group assignments, class discussions, and other collaborative exercises.
- Collection fun is something that happens mostly at the K-6 level, where teachers hand out gold stars and stickers. If you're teaching at a more advanced educational level, you may have to be inventive.
- Physical fun: include various physical objects that can be passed around the room in your discussions. Include "eye candy" -- neat-looking photos or illustrations that you can show around. Try including some music or other interesting sounds if you can tie them to class topics. Get the senses involved! I once had a physics teacher who would bring "props" to just about every class, such as throwing around a super-bouncy-ball when talking about elastic collisions; I know another professor who would make the entire class get up and stretch when she noticed students nodding off.
- Puzzle solving fun: ask open-ended questions, especially those that students really have to think about before answering. Group discussions and case studies fit this nicely. Some classes have content that is inherently a kind of logic puzzle (especially in the maths and sciences). In these cases, it helps to approach these as puzzles or mysteries, rather than as problems or exercises. Who ever heard of having a "problem" that was fun? What percentage of your students enjoy "exercise" as a recreational activity? Why do we use such not fun words to describe a fun process?
- Character advancement fun: is automatic in any class that builds on its own content over time (the kinds of classes where the final doesn't have to be "cumulative" because you need all the previous stuff to solve the latest questions anyway). At the beginning of the class, try showing the skills and concepts as a "tech tree" -- the same as you'd see in World of Warcraft or Diablo 2 or Civilization.
- Competition fun: here's where we see the old quiz-show standby. Formal debates can trigger this kind of fun too, as can informal debates that emerge spontaneously during class discussions on controversial topics.
As a parting shot, notice that most successful games are made with the players first in mind... not the creators, and not the content. Approach your classes the same way: design your classes around the students first, not the content and certainly not the teacher!
Monday, December 24, 2007
Games are fun. Most classes are not. You may notice students sitting at the back of your lecture hall playing with their DS rather than paying attention. It's worth asking the question: what does that silly little video game have that the lecturer doesn't? After all, it's just a game, but this class is important. Why shouldn't the lecture be getting students' undivided attention? And more importantly -- is there anything we can do as educators to change that?
To answer these questions, we first start by asking what makes games fun (and what makes classes less fun).
What makes games fun?
- Well, if we knew that, we wouldn't be a "hit-driven" industry (a nice way of saying that 90% of commercial games lose money). Still, the game development community has a better understanding of this than the teaching community, and there are a few useful theories that most game designers are familiar with. What follows is a small sample of a much greater body of work.
- Csikszentmihalyi's theory of "flow": you get deeply engaged in a task (any task, including "work") when it provides a challenge in line with your skills. Too hard and it's frustrating, too easy and it's boring... but if it's just right, it's magic.
- Corollary: as you perform a task more, your skills improve. If the task stays the same, you will eventually become bored. The tasks that keep you in the flow longer are those that increase in difficulty.
- Raph Koster's Theory of Fun: Games are fun because they're really good at keeping the player in the flow. Also, flow is fun because you're learning. (You may or may not be learning useful things from playing games, but you are learning something, and the brain finds that pleasurable.)
- Noah Falstein's Natural Funativity: Learning is probably fun because it's evolutionarily beneficial. The things that helped our ancestors when they lived in caves and trees are the same kinds of things that we find "fun" today.
- LeBlanc et al's MDA Framework: The word "fun" is not terribly useful because it isn't descriptive, and doesn't suggest how you create it. There are actually many kinds of fun: exploration, physical sensation, social experience, competition, advancement, collection, puzzle solving, and many others. These are all present to greater or lesser degrees in games; we're talking about a continuum, not a binary either/or composition of fun.
- Note that all of these kinds of fun can be traced back to hunter/gatherer survival skills. Social skills are important because we can work together to hunt animals that are too large or powerful for a single one of us. Exploration is important so that we can have larger areas of territory to find food in. Collection is simply the "gatherer" half of hunter/gatherer.
If learning is the source of fun, then, it actually seems strange that classroom lectures aren't inherently engaging. I believe the reason for the disconnect is that lectures are so far removed from the kinds of "learning" that ancient humans had to do for survival, that it does not trigger our play-instinct. Our pedagogy has outpaced our biological evolution.
Now you know the basics of what fun is and where it comes from. Next time I'll talk about how to apply this knowledge directly to the classroom. In the mean time, think about it yourself...
Friday, December 21, 2007
I swear, leaving the industry was the best thing that ever happened to my game development career. Oh, the irony.
Monday, December 17, 2007
In spite of the fact that the only constraints were technological (design for the XO platform, using Python and Pygame), and there was not a single mention of experimental gameplay or innovation in game design, a surprising number of games were highly experimental in nature (though sad to say, not mine). What follows is a rundown of, in my opinion, the most important games of the Jam and why students, teachers and professional developers alike should pay attention.
XO Maze (by Team Thailand), the winner of the jam, was a four-player cooperative maze game (if you've never heard of the "maze game" genre, think Pac-Man) with fog of war. Design lessons: Whenever a new innovation in gameplay is added to a genre (like fog of war in RTS games), someone should revisit all older games of all genres and see if the new mechanic will work with old games. In this case, it works beautifully. Another interesting thing: the developers originally wanted network play but it was broken, so they "settled" for having four-player on a single computer. The result was actually better than if they had network play -- it turns out, four players crowded around a single keyboard gives a uniquely satisfying experience when playing co-op. With all of the rush for modern consoles to have games that are all network-enabled, we must not forget the joy of sitting next to your friend and playing games on the same couch.
Caketown (by Team Argentina) is a puzzle game where you click on stuff to make other stuff happen; the object is to get the strangely cute zombie-animals to find each other, which lets them eat cake (don't ask, just see for yourself). Only two levels created during the Jam, but after playing them you can see the potential. Design lessons: This is a great experiment in UI. There aren't really any printed instructions or text, but the visual clues are still there to tell you what to do, and if you can't figure out the iconic signs you can figure things out experimentally by clicking on the stuff that obviously looks like it can be clicked on. If you're working on a game that requires the player to go through an hour-long tutorial just to figure out the basic rules of the game, try taking a look at this and seeing how the graphics and art (even environmental art) can do wonders to teach the gameplay.
Head Cat (by Team Brazil) is my personal favorite game of the Jam; the only reason it didn't win is that the judges were mostly 8 to 12 year olds, and the creators of this game admitted that they ignored the judging and just made the game that they wanted to make (it's clearly targeted at a slightly older audience). The gameplay is something between Lemmings and The Incredible Machine. The goal is to get your programmable robot to the cat; the cat then happily goes to sleep on the robot's head (anyone who has ever owned a cat will instantly understand this). Design lessons: This is a great example of what I unsuccessfully tried to teach my Capstone class last year -- namely, to attempt depth of mechanics instead of breadth (especially when working on a time-limited project, such as a Game Jam game or a semester-long class project). There are only a few player verbs in Head Cat: the drill (breaks blocks beneath you), the balloon (slows your rate of falling), the magnet (pulls you up if there's another magnet overhead), and the ability to detect running into walls and floors and reverse direction. Each of these was clearly easy to implement, and yet look at the variety of levels and challenges! The developers even had time to include a full level editor, and I imagine you could make 50 or 100 levels with just the mechanics that exist in the game, alone. Incidentally, it's also an example of how a cute theme can take a decent game and make it instantly memorable.
Honestly, all of the games were impressive for some reason or another. Fruitix (Team Ethiopia) is something like a retro-arcade version of Harvest Moon. Red Bird (Team Tibet) is a timing-based puzzle game, something like a Match-3 game where all panels are the same color and their position matters rather than their color. Star Catcher (Team Peru) had some very satisfying 2D physics and a full level editor (remember that these games were made in about 36 hours). Tumble Boy (Team Libya) did what I tried and failed to do: get scrolling to work on the XO at a reasonable framerate -- and it not only included a level editor, but made it accessible as a plaintext file that you could edit in notepad. Light Ball (Team Nigeria) was another impressive physics game, with the interesting mechanic that you're trying to prevent the sun from going out -- so you have to balance your limited ammunition with the limited time that the sun has left, and in the mean time the screen starts going dark (making gameplay more difficult). I guess what I'm saying is, download and play all the games; you'll be happy you did.
And play with the sound on. All of the games have sound; sometimes it's critical to gameplay, other times it's just amusing, but I can't think of any game that had actively horrible sound. Except perhaps my own, as I explained.
Thursday, December 13, 2007
Some of the entries I've seen are so amazing that I can't believe it's a student team and not a commercial product. Others are so bad that I wonder why they even bothered submitting. Still others, I never even got to see because they crashed before starting. With this in mind, I present some advice to future IGF entrants (student and otherwise) based on the common mistakes I've seen this year.
Find the fun in the first 30 seconds. I was given 21 games that I had to judge. That means realistically, each game is not getting ten hours of play. If the really cool stuff is on the last level, I might never see it. If the really cool stuff isn't even in the game (say, you're making a demo for an RPG and all you've got is the first dungeon where you have to kill 50 rats), you fail -- make one of the later, more fun levels for your demo instead.
Include level select and other cheats. Suppose I'm playing through your five-level demo, and my machine crashes near the end of level 4. Do you think I'm going to replay everything just to see level 5, or do you think I'm going to assume I've seen enough and move on? If I can jump immediately to level 5 with a level select, maybe I'll give it another try; if I have to replay the entire game, forget it. Likewise, if the first level is so difficult that I lack the skills to make it past, give me "god mode" so I can at least see the rest of your content.
Include single-player mode. Not everyone has a gaming group they can play with. If I'm judging on my own, and you require 4 or 8 player simultaneous, I won't be able to review your game at all. If you add AI opponents that allow single-person play, this at least lets me play around with the mechanics somewhat. If you don't have the time or skills to implement a full AI, have the opponents sit there and do nothing and call it a one-player "tutorial". Either way, at least let me play.
Avoid mods. Just like not everyone has a group of gaming buddies, not everyone owns a copy of Unreal or Half-Life. If your game is a mod that requires judges to have software other than your game itself, it might not get judged by as many people. If you must make a mod, be very clear about it in the requirements list when you submit your entry; this is just courtesy, so that judges lacking the ability to play don't waste time on it.
Avoid crashes. It should seem obvious, but I saw some games that actually crashed on startup! Test your installer on a few "virgin" machines before submitting. These last three points can actually be summarized as one: let me play your game!
Don't overhype in your description. Each game has a brief text description. I read it when I'm waiting for the game itself to download. Some people are really full of themselves, telling me all about how original their game is or how great their graphics are or how fun the game is. Don't insult me; I should be competent enough to judge your game on its own merits, not on your opinions of your own game. This actually has the opposite effect for me; if you tell me how original your game is, it just makes me think really hard about what other game(s) yours is derived from. Unless your name is Peter Molyneux, leave the hype to the marketing people.
Make sure the player is having fun, not the computer. Sid Meier's immortal advice rings true in a surprising number of student games. Your game might have an amazing AI or some really complicated mechanics under the surface, but if I can't see, predict and understand them then I'm not really having fun as the player. Try giving your game to someone who knows nothing about it and has never seen it before, and after they play ask them what's going on. Anything they can't tell you is something you need to work on.
Grow a thick skin. Judges can submit anonymous feedback, and we're told that it's perfectly okay if we're harsh (as long as we're also constructive). No game is perfect, especially a student game, so expect everything you've put your soul into to be ripped to shreds. (If it makes you feel any better, you'll get to go through this again once you get into the industry, when some reviewer for IGN trashes the game that you put the last three years of your life into.)
Monday, December 10, 2007
Instructors say things like:
- "This looks like an ambitious project."
- "That's an aggressive schedule."
- "I think you're being very optimistic."
What students hear, respectively:
- "You're an ambitious student. You've got tons of initiative. You're a real self-starter. That's a valuable thing to have in the world."
- "You've got the guts to do what it takes, without letting obstacles get in your way. Go get 'em, you aggressive tiger you!"
- "You never lose hope or let things get you down, and you've got a positive attitude. I value your optimism."
What the professor actually means, in all three cases:
- "You don't have a snowball's chance in Hell of completing this project. It's way too much work and/or way too advanced for the time you've got available, and if you attempt it you're going to fail miserably... if you don't kill yourself in the process. Reduce your scope and bring things back to something remotely reasonable. But... if you insist on trying and failing anyway, in spite of my repeated warnings, it is your right and privilege to try. But don't say I didn't warn you."
I think we professors need to be a bit more clear. Next time I see an overly "aggressive" student project, I'll be a bit more direct when I say so.
Tuesday, December 04, 2007
And that's what makes Qantm unique - we're not a university, because what people don't realise is that with a university it takes at least three years to change a course. If a lecturer now sees that companies are using a new language to program in, it'll take him three years to implement it in the course.
This is simply not true. There is a subtle but important difference between the content of a course, the course listings in the catalog, and the course curriculum. I will explain.
Course content is the stuff that actually gets taught within a single course. In my Game Industry Survey course, I have modified the content in minor ways on a day-to-day basis; for example, if the Activision/Vivendi merger happened the day before my talk about game publishers and how EA is by far the largest, you can bet I'd be modifying that content the same day. I certainly wouldn't be waiting three years before I started talking about it in class! Minor stuff like this gets incorporated all the time.
Granted, minor content changes like that aren't quite as drastic as, say, switching from Java to C# in an intro programming class. In that case, the instructor might have to wait until the next quarter/semester before changing the language around, but it can certainly be done. And even if the game industry suddenly decides tomorrow that every programmer absolutely must know C# from now on and it's the last week before finals, an instructor could still modify the last lecture of the quarter by talking a little about this newfangled C#, and how it's similar to the language we learned during this course and how it's different, and that all of the students should learn it on their own over winter break if they want to get jobs, or whatever. There's still no three-year delay.
Course listings, i.e. what courses are available for students to take, can obviously not be modified in the middle of a semester. However, they can (and frequently are) modified on a semesterly basis in the form of "Special Topics" courses. Special Topics is this wonderful catch-all that lets professors offer whatever the heck they want. Sometimes it involves the professor talking about their (very narrow) area of research; sometimes it's a brand-new course that should be added to the curriculum, but the professor wants to try it out just to make sure; sometimes it's a course that's important but offered so infrequently that it never got its own dedicated course number; and sometimes it's just an off-the-wall experimental course idea that a professor has just been dying to try out one of these days.
At any rate, there's always a selection of Special Topics in each department, and they change on a regular basis. Again, no three-year lag time here.
The course curriculum is what changes every 3 years (an approximation -- I'd assume that at a four-year institution it would change every 4+ years, while a two-year community college could modify their curriculum every 2+ years). These numbers are not set in stone, by the way: they are a practical consideration. How can an established university build a reputation for producing quality graduates if the core curriculum of this year's graduating class is different from last year's? This is not (entirely) about universities being slow, bloated bureaucracies... I mean, they are, but that's beside the point... this is about universities not kowtowing to every little whim and fad of the industry, and waiting for trends to become established before they force them on the unsuspecting student population.
So, let's suppose a new programming language becomes popular. C# is so 2005, today it's all about Ruby (not really, this is just a contrived example). Starting next quarter, a Programing in Ruby special topics course magically appears. Academic advisors let their students know that Ruby is the next big thing in the game industry, and they'd better learn it before they graduate if they want even so much as a job in QA or the mail room or something, and they're highly encouraged to take the special topics course if they don't just learn it themselves over winter break. Unfortunately, it only counts as an elective, but creative advisors might be able to substitute the special topics for the Programming in C# course that used to be a core requirement; for students who took that already, at least it's a programming elective. A few years later when it's time to revamp the curriculum, the Ruby course displaces the C# course, and all is well.
Until two years later when the industry suddenly decides that Ruby is so 2008, and the thing that everyone really needs to know is this newfangled C+@#$ (where you program by shouting profanities at the computer, with voice-to-text support in the IDE), and the cycle begins again.
Oh, and one other quote from that stupid article that I feel the need to correct:
Initially there was no master plan for SAE, for colleges and things, but it turned out that I invented practical education, because nobody before me was doing that. In a way I formalised education.
I'm supposed to believe that it never occurred to anyone in the thousands of years that humans have inhabited the planet, to have education that's actually practical? If David Braben invented practical education, then I invented the internet.