Ouya Game Jam Postmortem: Pig Eat Ball

New Platform

To help invigorate game development for the new console, a game jam was held for the  Android-based 'Ouya' console. It was a bit of an unusual game jam in that it had no specific theme and had some troubles early on (there was a false start and the rules changed a bit along the way). Buuuut once it got going, it turned out pretty fun. And the event, hosted by KillScreen and named the 'CREATE' jam ended up being very successful with over 160 games made!

The gist was simple, make a game for the Ouya, from scratch, in 10 days. Also, there's +$50k at stake! Playing around with new hardware and trying to make something quick is always fun, but the prize money offered even more incentive to get involved.

New Direction

I created a 4-player party game which has you controlling flying-pig-like creatures trying to eat the most bouncing balls first. The pigs bounce off each other, and if their mouths touch a tennis ball, they eat it. Each ball they eat makes the pig grow bigger. Controls are simple: left stick drives the pig around and any button 'boosts'. The boost propels them forward quickly for a second then they return to normal speed. Pigs have a sensitive tail on their backside. If a pig boosts into another pig's tail, the injured pig will barf out 3 balls.

Do you try to make progress or try to stunt your friend's progress? Ah...just like real life.

The goal of each level can change, but the basic version is to eat X number of balls first. As you play, it becomes a matter of watching the size of other pigs to see if they're beating you, scrambling to eat balls yourself, and if someone is getting too big, you boost and fight each other to make them spit up balls.

What Went Right

1. Don't Follow Your Typical Design: I love violence and gore and guns in my games. Love it! But for this jam I picked no gore, no extreme violence. At most, the pigs spit up balls they've eaten. Pigs can also bump each other.
Picking a design and motif that is unusual for you is a good direction for a short prototype. You may have trouble with it at first, but because everything is so different from what you usually do there should be plenty of new ideas to explore in your own style. Plus at the end, you could end up with something really different than what you'd normally attempt. I'm already really proud of this game--I can show my friends and family and not apologize for the flying guts and bone shards in most of my games! :)

2. Clear, Contained Design: The design for Pig Eat Ball was reasonable in scope. 4 players, bounce around, fight over balls, and bump each other. That's it for a first pass. Everything else is gravy. There's no crafting system, no complex animations, no intense AI. The difficult part, of course, with something simple is to make it interesting and original enough. I relied on my powers of 'crazy' for that--everyone knows pigs and tennis balls go together like honey and jackhammers :)

The other part of a simple prototype is to create an excellent 'fun loop'. Ensure that whatever you have for show when the jam is finished is honestly fun. Not 'fun if you know what we have planned', but fun with what you're playing, right then.

Day 1 Diary: Getting Started

3. Video Diary Motivation: Each morning I recorded what I did the previous day and carefully listed progress. This was an unusual jam since it was pretty long--10 days. That required special diligence to stay motivated. Seeing progress through the video and forcing myself to articulate the important changes each day helped me stay motivated for the next day despite some set backs.

Early quad-sprite tests for rotation, tinting, scaling.

4. Learning Through Examples: The system is Android-based using Open GL ES. Within about 20 hours, myself and another programmer were able to get a respectable, quad-based sprite game skeleton in place on the hardware. That felt really good! But clearly this was only possible with articles and examples from others on the internet. Bootstrapping from examples may be obvious, but was such a big part of the technology side I had to list it.

What Went Wrong

1. Must Playtest with Newbs: The final version submitted to the game jam was pretty fun. BUT, I blew something completely. I was playing the game every day, refining the controls. That's to be expected. I was having a few others play the game each day as well. By the last day, we were all very good at the game.

The game was submitted with horrible collision bugs, but the problems were only noticeable if you were not good at the game! As the screen filled with tennis balls (from players not being good at catching the balls) the framerate would dip, and the collision bugs would begin to show. Players would get stuck in the walls. They'd get stuck in each other. Balls would travel through walls.

Even in a quick game jam, make time to have new people play it and watch what they do!
Yes, this is basic playtesting, but it's something that I think is easy to disregard or forget altogether when you feel you're missing proper menus, control screens, or advanced gameplay. It's easy to get flustered! But letting someone new playtest before you submit is huge and worth the extra time!

An early screenshot before the pigs had distinguishing icons.

2. Dodge Those Rabbit Holes: Several times I found myself spending time drawing art for a special 'how to' screen, or animations better suited for post-prototype development. For a short game jam, you've got to stay focused, and stick only to things that will absolutely be used right then. It's obviously fun to think about the bigger game, but get the 'fun loop' together first!

Day 3 Diary: Collision is Working

3. Watch Your Example Code: Part of the success was quickly learning how to do things in Android from examples. But that can be a double-edged sword as you may be wading into complex code with little understanding. I had trouble getting sounds to play on the Ouya. Was it hardware, code, or the wrong file format? Turned out I was calling 'Release' on SoundPool then trying to use it. SoundPool does not crash or report calls made to it after a Release(), which I found unusual but maybe it's a 'feature'. I fixed this only after slow debugging, forum searching, and reading documentation (precious time lost!).

Our submission made it just in time!

4. Save Time for the Upload: If this is a strictly managed event and you have to upload your game, approximate the upload time and budget for it! We almost didn't make it, only had minutes to spare because the game ended up a bigger upload than from days before. It's also possible for events like this to have their servers crash from so many uploads! I've done several XNA Dream Build Play contents in the past where this has happened. Get a screen shot of your finished upload!
Also, watch out what timezone the game-time is marked to finish (UTC? GMT? EST?).

 Finished Pig Eat Ball game trailer

Fun Loop

My one-sentence, wordy lesson for a game jam or short contest? Ensure you have a demonstrable version of the fun part of your design, made possible because you stayed focused following your articulated, inspired concept.

Diary 6: After Jam, Bugs Fixed

Future

Pig Eat Ball is on schedule for release with the Ouya in April. I love that we're on our way to our first non-violent party game! My inspiration, motivation, and free time come in waves and here they all happened to line up just right. I hope the same can happen for you!