Upcoming Events

Looking for something game-related for your students (or you) to get involved in? Here's what my calendar looks like for the next few months:

Health Games Challenge: this weekend (May 21-23)! A 48-hour game jam (i.e. build a game from scratch in a weekend) based on the Apps for Healthy Kids competition. We have seven sites: Boston MA, Seattle WA, Albany NY, Athens GA, Fairfax VA, Orlando FL, and Pittsburgh PA - site info is available on the event website. If you're not near a site, you can still participate from home; send an email to info@healthgameschallenge.org stating your intentions. I like game jams to begin with, as they provide a great experience in a short time; this one in particular is interesting because the end result might actually do some good in the world. (Full disclosure: I'm one of the organizers for this event.)

Games in Education and Computer Science: June 3-4. Registration is closed for this workshop, but if any of you happen to be going, I'll see you there. Participants will work together to identify problems and solutions in the space of using games in engineering / computer science education. Work groups will producer reports (similar to Project Horseshoe), so expect a post here, after the fact.

Game Education Summit: June 15-16. I attended this last year in Pittsburgh, and there is no better place to meet people who are interested in the intersection of games and education. This year it takes place in Los Angeles (a bit far for me to drive, so unfortunately I can't attend this time), but highly recommended if you're in the area and/or have a travel budget.

Origins: June 23-27. This consumer-focused game convention takes place in Columbus, Ohio and is the third largest such event in the world (after Gen Con and Essen Spiel). Teachers get in free as usual (you need to show some kind of academic credentials). While there are some education-focused sessions, mostly it's about immersing yourself in playing all manner of non-digital games. This makes it more useful for game designers than, say, programmers or game audio folks.

Protospiel: July 9-11. I went to this last year and it was the most amazing experience I've ever had as a game designer. It is essentially a small gathering of non-digital game designers who spend a weekend playtesting each other's games. These are people who understand games, design, and playtesting, so it is about the best kind of feedback you can possibly get. Potentially instructive for students who want to see what real playtesting is like. The down side is that it's in Ann Arbor, Michigan, so it may not be in your area. If you are in the Austin, Texas area, there's also the inaugural Protospiel South coming up soon (May 28-30).

Overall, it's looking to be a busy and eventful Summer!

Game Jams in the Classroom

Just talked at GDC yesterday for a whole five minutes, on applying Global Game Jam in the classroom in five non-obvious ways (you know, other than "get students to participate"). I think I was talking too fast for anyone to actually take notes, so here is the gist:

1. Have students read post-mortems and do a cumulative analysis.

The "post-mortem" is a tradition in the game industry: after a project is released, a reflection on what went right and what went wrong in the process (or as I put it: "figuring out why your game sucked as badly as it did"). You can find these on Gamasutra and in Game Developer magazine, and you can even see student post-mortems on Game Career Guide. And to start with, reading these is valuable for students so that they can see the patterns and get a feel for the most common pitfalls and dangers of game development.

Beyond this, though, it's instructive to have students search for Game Jam post-mortems (these are unofficial and tend to be on individual participants' blogs, so you have to do some digging to find them). The interesting thing is that a lot of themes in industry post-mortems on 5-year AAA projects also appear in Game Jam post-mortems (scope control, pipeline problems, engine difficulties, team communication, etc.). So a lot of the same lessons apply on how to develop a game, whether the game takes 2 days or 10 years.

2. Game Analysis

I teach a class called "Game Criticism and Analysis" (sort of like art criticism or film criticism, but with games). The goal is to be able to play games and analyze them in a way that's a little more sophisticated than "it's good" or "it sucks."

Normally, analyzing a full game is really hard in a class, because many games are very long to play ("80+ hours of gameplay!" is a common marketing tactic), and even shorter games are still 8 to 10 hours, which is hard to justify if you want students to analyze a new game each week.

Game jam games offer a solution. Because they are made in a short period of time, they tend to play quickly and have relatively simple systems, lending them to play in class or as homework without taking too much time.

3. Minimum bar for student projects

For "capstone" and other project-based courses where students work individually or on teams to make complete games over an academic term (or several), game jam games provide a realistic, achievable yardstick to measure project quality. I mean, these games were made in 2 days, so your students should be able to do at least as well with 15 weeks.

The best, most clever Game Jam games can be used as a source of inspiration for students, that they should be able to do better with so much more time. They can be used as a grading rubric, letting students know the quality level you expect (and informing the teacher about this as well).

4. Achievements

We tried some new things at Global Game Jam this year, among them Xbox-Live style "Achievements": totally optional extra challenges to allow experienced developers to really push their boundaries. It allowed people to seek their own level of challenge and comfort.

I see no reason similar things can't be implemented in most class assignments. (We already offer "extra credit" but "Achievement Unlocked" sounds so much more fun.) You can offer extra points, or you can simply make it available for the purpose of bragging rights.

5. Fix a broken game

As you might imagine, with only 48 hours, some games don't actually work. Maybe the team overscoped and had to make drastic cuts at the end. Or maybe the programmer stayed up a little too late and wrote some terribly insane code at 3am and now the entire thing is a mess. The whole project team would like nothing better than to sweep the whole thing under the rug and pretend it never happened (and hopefully take away some life lessons about how to not make games).

Additionally, there is often a disconnect between classes (where students typically start with a blank slate and write a complete, simple program from scratch) and industry (where you are almost always working with someone else's pre-written code, not even counting the use of game engines).

Luckily, one of the rules for Global Game Jam is that everyone (in theory at least) has to submit their complete game (including source code)... working or not. This suggests an interesting assignment: find a game that has the source code posted that doesn't actually run, and assign a programming team to fix it, while staying as close as possible to the original design intent.

Your students will hate you. They will complain that the people writing this code were horrible programmers. They will complain that the code is a mess, and that they just want to rewrite it all from scratch. They will probably use a lot more profanity than you are used to hearing from them. In other words... they will start to sound a lot more like professional game programmers :-)

Project Horseshoe

So, I went to Project Horseshoe this year, not knowing exactly what to expect, but hearing from survivors of earlier years that it was awesome. I was not disappointed, and now I understand what it is all about.

The format is highly similar to a game jam. The first night, we collect in one place and have introductions and casual conversation. Bright and early the next morning, we brainstorm a bunch of potential projects to work on, and then aggregate around a few that are of passionate interest. Then we spend the rest of that day and most of the next day working on our projects. At the end of the second day, we present our results to the entire group. I've praised game jams before, so if you like that kind of "get lots of amazing stuff done in a very short period of time" you'll understand the appeal of an event like this.

There are two key differences between PH and a game jam. The most obvious is that in PH we are not making video games from scratch, but rather brainstorming the solutions to difficult problems facing the game industry (for example, my group worked on how to build ethical decision-making into games, in a way that is more sophisticated than a choice between pure-good and pure-evil). So it is more of a "game design jam" than a "game jam."

The second difference is the quality of people. PH is invite-only. This is similar to the difference between the Global Game Jam (open to all) and the Indie Game Jam (invite-only among a small circle of professional game devs). Both methods can work well, either a focus on quantity or quality... as long as the "quantity" method includes some way for the great stuff to bubble up to the top. PH is in the latter camp.

All reports (from this year and previous years) can be found here.

Relevance to teaching:

• Some reports may be directly relevant to student projects. For example, in one class this quarter, I see one student proposing a game with ethical decision-making and three students writing proposals for Facebook games, both of which are topics covered this year.
• In a course on the game industry, game design, or game criticism/analysis, one possible assignment could be to read a report of the student's choosing and present it to the class -- the same way other courses might do the same with reading and presenting a current research paper or foundational article from the field.
  

Global Game Jam article on Gamasutra

For those of you who are wondering what was going on during the Global Game Jam, Stephen Jacobs wrote up a fantastic blow-by-blow account of the action. His article is on Gamasutra.

I'm even quoted a few times in the article.

Speaking Schedule

Yesterday, I was in Savannah giving a presentation with Brenda at SCAD to other educators about the use of games as a teaching tool. It was intended as a combination of my earlier Origins presentations and our Game Design Improv event.

I learned something interesting here: when talking about games in education, I take for granted that most of the time I'm talking to educators who already play games heavily (or teach game development), so the use of games in the classroom is not a hard sell. In this case I was speaking with professors from art history, photography, audio, film, media studies, and several other fields that are not directly related to games. We spent a lot of time discussing whether games were worthwhile for classroom use at all, and if so in what situations. It was a wonderful discussion that really challenged us all, and it's a discussion I'm not used to having. I was also impressed by the high degree of game literacy from these professors who were not gamers; participants referenced a number of game industry personalities and important games. Apparently it's not just game designers who study other media; they're paying attention to us, also.

Coming up, I've got a few speaking engagements. I'm speaking at GDC, both times during the Education Summit. I speak twice: I'm doing the next iteration of Game Design Improv with Brenda, and also speaking with Susan Gold and Gorm Lai about the results of the Global Game Jam.

The month after that, I'll be at GDX (here's last year's site, the new one isn't up yet), speaking about the relationships between art history and game design -- basically, why game designers should take at least one art history class, and why they should pay attention. (Short answer: because we may feel like games are a new medium and we're blazing new trails, but an awful lot of what we're doing with games-as-art is stuff that the art world already addressed hundreds of years ago, and we need to understand this so we don't keep reinventing the wheel.)

Global Game Jam this weekend

After many months of planning, site wrangling and organizing, the Global Game Jam will take place this weekend. We have 54 host sites in 51 different cities, 24 countries and 14 time zones. We're currently looking at somewhere in the neighborhood of 2000 participants. It's pretty amazing how big it's grown in just the last few months.

I'll be providing realtime support to the sites for the entire weekend (minus the time when I'm sleeping) from my home office in Columbus.

If you're not already signed up, see if there's a location near you.

2nd Ohio Game Jam: Results

I coordinated the second Ohio Game Jam this past weekend. I didn't make a game myself, although I did assist all the teams in very minor ways, so I got to see a little bit of everything. As such, I probably learned as much as any participant.

Lessons learned about running a Game Jam:

• Event planning is a lot harder than I thought it was. Last year, everything just fell into place, and there was a minimum of hassle. This year, it seemed like everything was an uphill battle, from finding a venue (which had to be changed last-minute due to a large-scale power outage) to recruiting participants (since I don't have reliable web hosting for the Ohio Game Jam website right now). For anyone else thinking about hosting a game jam, start planning at least a few months in advance and come up with contingency plans for everything. Hopefully the up-front work will be wasted and things will run smoothly for you, but if they don't then you'll be more prepared than I was.
• Things to take care of (either through soliciting donations/sponsors, providing yourself, or asking participants to bring their own): physical space; computers; open work space (for designing on paper); physical prototyping materials (blank paper, lined paper, graph paper, pens and pencils, and anything else you have on hand); food and drink; sleeping space (preferably with no light); and a large area where all participants can gather (for introductions at the beginning, and presentation of work at the end).

Lessons learned about game development:

• It's impossible to understate the importance of rapid prototyping. All three teams knew about this already, and yet they all made the mistake of trying to implement the complete game mechanics in one go, leaving them all with only 4 to 6 hours of time after "first playable." It's very easy to say that it's important to have something up and running really quickly, and quite another to actually do it; defining the minimum functionality set for playability is a skill, and one that not all designers are strong at.
• Corollary: trade off everything for speed when doing a rapid prototype. For artists, no need to have polished art when a stick figure works just as well for playtesting, and can be done in five seconds. For programmers, all that stuff about proper code structure and good commenting and re-use and maintainability that was drilled into you in every CS class you ever took... all of that goes out the window, because it takes extra time to make your code readable, and time is the one thing you don't have.
• Save early and often and back up. Sounds obvious, but one team had a computer crash that caused them to lose about an hour of work... when there was only 45 minutes to go before development ended.
• If you have a programmer shortage on your team, don't design a game that requires complicated game logic or AI. If you have more than one programmer, choose a development tool that allows you to work on code concurrently (two teams used Game Maker, which is hideously bad at merging two projects, for all of its other benefits).
• Game development experience helps in a game jam... but not much. Looking at the output of the teams, you wouldn't be able to tell which ones had industry professionals and which did not. (When I participated in a Game Jam, I noticed the same thing; I don't feel like my own project was any better for all of my experience, which is humbling.) I'm not sure why this is; perhaps, for all the benefits of field experience, lack of sleep ends up being the ultimate equalizer.

For those who are curious, here's the rundown of what happened at the event:
We had 13 people working in 3 teams, with a total of one game per team created (3 games total).
I gave teams a dual constraint: first, choose a social issue and create a game to spread awareness of that issue; second, design the game to be propagated through a social network like Facebook. As long as we're making games, we may as well try to save the world, right?

One team tackled the issue of financial responsibility and personal spending habits. The core concept was that people have two stats, Money and Happiness, and that there is a tradeoff where spending too much money on luxury goods causes you to run out of money (which makes your happiness go way down), but of course spending no money at all on luxuries also causes happiness to decrease, so the trick is to find a reasonable middle ground where there's plenty of money left over but also enough nice stuff to be happy. The game itself was a top-down scrolling game where the player's avatar wanders through a store looking for the cheapest necessity items, and maybe picking up a luxury item or two on the way. There were other AIs running around: other shoppers which were minor obstacles to work around, salesmen who would convince you to buy a luxury item against your will (while giving you minimal happiness in exchange), and thieves who would just steal money from you. The game created was incomplete, but could make use of social networking by allowing players to buy things for their friends (which increases both of their happiness) and competing with others on your friends list for achievements (most money, most happiness, fastest purchase of necessity items, etc.).

A second team examined the environment, specifically choices that governments make with regard to energy policy, in a turn-based resource-management strategy game. You control a small city with access to randomized natural resources, and choose what land to develop in what way (building hydroelectric dams over rivers, wind turbines in windy areas, solar panels, nuclear plants, etc. -- or of course you could develop the land as a commercial/housing area to attract more people to your city). You have a carbon footprint based on your population and the type of economy you have (fossil fuel-based, hybrid or pure electric), and a cap that's based on your population; if you go over your emission limit, you receive heavy fines. If you don't produce enough power for your population, you suffer blackouts and eventually you'll start losing population. You also have to balance all of this building against your available funds, of course. In Facebook, this game would also allow you to trade carbon emission credits and power with your friends, and also have leaderboards for largest city.

The third team took on the issue of child labor sweatshops. In their overhead-view action game, you played a child trying to escape from a shoe factory. You could pick up various shoes lying around each level (with tradeoffs for each: boots were powerful but slow, while flip-flops could be thrown quickly and accurately but did minimal damage). Your goal in each level was to pick up shoes and use them to knock out the adult supervisors, then talk to the kids to get information (which helped you progress in the game, and also gave you real-world information about sweatshop conditions). The game could propagate socially simply by having a high-score list, but did not include ways for different players to interact with one another otherwise.

Game Jams!

Game Jams are great; I'm a huge fan of them. (Roughly defined, a Game Jam is an event where individuals or small teams work together to develop a complete game or working prototype from scratch in a short period of time, typically one or two days.) You get about as much insight into the game development process in a weekend as you'd normally get in a three-year AAA development cycle. You get to experiment with new tools, processes, or designs in a risk-free setting (after all, even if you fall flat on your face, all you've lost is a weekend... and think of the wisdom gained that would normally cost millions of publisher dollars). You get to meet and work with new people you haven't met before. For students, it's about the best practical experience you can get outside of class. For educators, it gives the kind of insight that's hard to get when you're not working in the industry full-time. For working professionals, it offers the opportunity to grow professionally and hone your skills in a way that's normally not possible when you're in the middle of a development grind.

For those of you in or near Columbus, Ohio, the second Ohio Game Jam is scheduled for the weekend of September 20-21 (starting at 2pm on Saturday and going until roughly 4pm Sunday). Since there's limited space, I'm trying to get a head count ahead of time, so I'll send the location to people who RSVP by email to ai864 at yahoo dot com. Feel free to pass on this info to anyone else you know in the area. The event is free, and open to all ages and skill levels.

For those of you not in Columbus but still somewhere on Planet Earth, there's also the Global Game Jam, a 48-hour event starting at 5pm Friday, January 30, 2009 (in your local time zone). This event is many Game Jams happening concurrently at a number of sites around the globe. More info will be added to the website in the coming months, once the list of host venues is finalized. Contact info is on the Global Game Jam website.

Pittsburgh Game Jam games available for download

As I've mentioned a couple times before, I participated in the 2007 Pittsburgh Game Jam. The games themselves are posted here.

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.

I Came, I Saw, I Jammed

Participating in a game jam is a very different experience than coordinating it. Each game really is like a full AAA development cycle, time-compressed down to less than 48 hours; spending a weekend on this can practically give you as much experience as working on a full game, so I highly recommend it to students and professionals alike. We even had a fair population of people who have never made a game before at all, so I would recommend this for instructors as well.

In true Post-Mortem fashion, here's how it went for my team:

What Went Right:

• Multiclass Developers. On a small team with such a short deadline, having people who only know how to do one thing can lead to some precious time wasted; designers must sit on their hands while waiting for the programmer to implement their designs, while programmers and artists have to wait at the start until they know what they're supposed to make. Since team size is constant over the project (you can't scale up after "pre-production" like you can in industry) you need to make sure everyone is occupied constantly. I was a programmer/designer for my team, along with two artist/designers and a designer/audio guy. We all collaborated to get a basic concept quickly, and then everyone had some content to work on once we were done. Lesson for industry: The value of generalists with multiple skills increases in proportion to the rigidity of team size.
• Research. The goal was to make a game for kids age 8-12, which none of us had done before. I took the liberty of scouring Gamasutra for relevant articles, and talking to colleagues about what kinds of design rules are different when designing for this age group. I'm glad I did; we did not have the benefit of anyone sharing tips on this at the start of the event, nor did we have the opportunity (or the time) to focus test. Lesson for industry: If your project involves targeting a demographic that doesn't exist on your development staff, make an extra effort to remedy this.
• Constantly Shippable Code. We had something playable within a few hours of starting. It wasn't complete but it did run. This gave us the advantage of flexibility; no matter when we ran out of time, we knew that we would at least have something to show for it. Lesson for industry: Always have something to show. I think this is even more important in a world where deadlines can change, and publishers can unexpectedly drop by and ask to see how far along you are.
• Concept and Technology. We first asked ourselves how we could keep the control scheme so simple and obvious that we wouldn't need any text to explain it; we came up with the idea that you controlled a paper airplane by "blowing" on it, using a flicking motion on the touch pad to blow wind that would cause the plane to move in that direction. I think we got that part of the game feeling pretty good. In the process we also managed some things that Python and Pygame (the required language for this hardware) were never intended to do: smooth-scrolling backgrounds, and adaptive background music that would gradually get more frantic and intense the faster you scrolled.

What Went Wrong:

• Scope. We designed a game that we knew we could finish within the allotted time. Unfortunately, it took exactly the alotted time, so we had no time remaining at the end for polishing the graphics, sound or gameplay. As a result, our final project was one of the least compelling games of the jam. Lesson for industry: Design games that can be made in far less time than you have, and then use the extra time in the schedule to polish what you have in an extreme fashion.
• ...And More Scope. Our audio designer went AWOL on the last day of the jam, with his work left unfinished. As a result, we had to divert some resources away from art just so that we had at least some background music, and what we ended up with was just thrown in at the last minute. The final game sounds horrible, even though it has the capability of sounding amazing. Lesson for industry: Avoid having people on your team who are irreplaceable, in case they get hit by the proverbial bus (ours might have been hit by an actual bus for all we know). Thank goodness we didn't have a multi-million dollar development project at stake!
• ...And Even More Scope. We originally expected to have 14 regions in the final game, because the artists were able to finish the first region in only an hour or so, and at that rate that left them plenty of time. But the artists couldn't sustain such a high rate of work after sleep deprivation set in, and cut down to 7 regions... and four of those were thrown in at the last minute, so we should have cut down to only three or four (and just made those look really good). We also lost a lot of time to an undocumented technical limitation: Pygame blows up if any sprite is more than 14400 pixels wide, so instead of having one massively wide background we had to break it up into several regions, with one screen-length overlapping from each region to the next. This forced the artists to re-work a lot of their original files, costing valuable time that wasn't accounted for in the original schedule. Lesson for industry: Design your core mechanics to have scalable content. If your game needs a large number of levels to be playable, and you run into scheduling difficulties, you're in trouble. If your game can support a short play experience but becomes boring and repetitive if you try to add an extra 20 hours of gameplay time, you're also in trouble. Best case is a game that works no matter how much content you have, so that you can add exactly as much as time allows and know that it will be fine.
• Concept is Nothing; Execution is Everything. Our execution was okay (especially considering we only had a couple of days) but not spectacular. A lot of great ideas were simply not implemented in a way that made them realize their potential. I tell this to my students over and over again, but saying it is one thing and experiencing it is another. The winning games were all very simple concepts with relatively little content, elegant mechanics and a high "fun" factor. Lesson for industry: Maybe the lesson here should be, make all of your mistakes in Game Jams rather than on big-budget projects. If you ever want to try a new development methodology (maybe you've always worked in Agile development and wonder what could possibly go wrong if you try to design everything up-front in a comprehensive design doc, or you've never done Rapid Prototyping, or you want to see the effect of a lengthy preproduction, or something), try it in Game Jam form, with the understanding that an hour of a Game Jam is roughly equivalent to a month on a large project if you're trying to compare schedules. You'll probably learn a lot about what works and what doesn't work, without wasting huge development resources.

I'll update this post with a link to the games, as soon as it's online.

Pittsburgh Game Jam

This November 16-18, I'll be attending the inaugural Pittsburgh Game Jam. If any readers of this blog happen to be in the area, drop by and say hi!

This is exciting on multiple levels for me. For one, I haven't been back to my alma mater since I graduated (the ETC didn't even exist last time I was on campus, and I hear we eventually got a new Student Union too). Also, for all the talk of how great Game Jam events are, and even though I've coordinated one of them, I've never actually been a participant... and I'm looking forward to seeing what I'm capable of under extreme duress. Lastly, this particular Game Jam requires making games for young children -- a demographic I haven't had much experience with to date, so it will be nice to gain some additional understanding of the design constraints for this market.

Strangely, I'm signed up as a Programmer, not as a Game Designer. An event coordinator told me that they have a shortage of Programmers, which surprised me -- back when I was an undergrad, even the English and Humanities majors knew some programming (not typical of most college campuses, but CMU is a haven for computer geeks of all stripes). This is a school where they gave out free floppy disks to boost attendance at football games. And there's a programmer shortage? Well, it gives me an excuse to learn Python, which I've been putting off for a couple of years now, so I can't complain about the hand I'm dealt.

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.