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.