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.