A few weekends back I participated in the WhammyJammy 48-hour audio game jam here in San Francisco. A game jam, for the rest of the tech world I guess, is usually called a hack-a-thon. The basic idea is, a bunch of folks get together, take a theme, and then have 48-hours to make something playable. Whatever you call them, game jams are a ton of fun and are a great way to work on new things, learn, and meet cool people. They’ve become pretty popular in the games world of late, especially with the recent indie game creators revolution. There are so many tools for rapid development now days that creating really great games in 48-hours is actually pretty realistic assuming you know what you’re doing.

Folks playing "Bass Jumper"

Folks playing the completed “Bass Jumper” game at the end of the jam.

Whammy Jammy was organized in part by Steven An, who I met at this year’s IndieCade conference. Turned out we were both San Francisco area game devs and he let me know about the jam. Before WhammyJammy I’d done two Global Game Jams, SCAD’s 24-Hour Generate Jam, MolyJam, my own 48-hour Ludum Dare prep jam, and Ludum Dare 23 so suffice to say I’ve had a fair bit of rapid development experience. I haven’t gotten to do as many SF jams as I’d like and I’d had a great time at MolyJam meeting other Bay Area game creators so I had high hopes.

WhammyJammy’s turn-out was pretty small compared to the 150+ participants I’m used to from Atlanta GGJ events but the size turned out to be really good. PinchIt.com generously lent us their beautiful office space in SF’s Mission distict right next to the BART station. We started out generally meeting everyone and pitching around a bunch of audio game ideas. After an hour of or so of chatting and pitching,we broke up into groups and and started brainstorming more on ideas that had some heat.

Pitching Ideas Around

Pitching Ideas Around

I had mentioned wanting to do a physical space game. I’ve been inspired a lot in the last year by Doug Wilson’s J.S. Joust work and a lot of the physical games work coming out of the NYC Indie scene and have wanted to spend a jam messing with a physical space game. There were some other folks with interest so we came up with some ideas:

Jump Rope Game:
We were playing around with the idea of accelerometers on jump-ropes or maybe a tug of war game with generative audio events. Maybe a team that pulls towards high pitches and one towards low. We had a lot of heat around this idea but couldn’t solidify it into a game we were happy with.

Hunter Hunted:
One of the sound designers on the team told us about a folk game kids at a summer camp he helped at played a lot called, “hunter hunted”. The kids would form a circle around two blindfolded players and an “object of power”. The first player to find the object of power and hit the other player with it wins. We pitched around some ideas for using a soundscape to enhance the game. Maybe tracking players and generating panned audio but nothing stuck and tech constraints were gonna be a bit high for 48 hours.

We ended up with a pitch for a rhythm game without dance pads. Players would stand around a central point (we really wanted this to be a large bass amp) that would shoot notes out to player. Players would want to jump as high and land as hard as they could while remaining on time so score the most points. Pushing shear strength and airtime over the dexterity associated with traditional rhythm games.  We ended up deciding that considering the 48 hour scope this was our best bet.

We all broke off onto various tasks. I pulled a bunch of code I’d written for another physical computing project. That came in three large parts. The first was the actual arduino code for interpreting the accelerometer data and sending it to the PC over a serial connection. The next was code for grabbing the data from the arduino and doing a bunch of signal processing and display so we would understand what the actual data looked like and come up with the right processing and analysis. And the final piece we pulled from me was the socket server bridge between processing and flash so we could build the game quickly and have it running on Mac and PC with low friction. We didn’t know who’d be running the final version as we’d yet to solve audio output. Few of us had tried to output to a bass amp before.

Jim Crawford of “Frog Fractions” fame, did most of our gameplay programming. He and Eliot Lash (who was great jumping from task to task as needed, hitting front-end, back-end and hardware) worked together to integrate the processing-flash bridge from my (hacky) example code into the game. He also worked with Sam and Brett, our audio guys, to come up with a snazzy MIDI based encoding system for all our gameplay note hits for each player.They could simply create a MIDI track along side their audio track with all of the gameplay data for the song. It worked out really well and by the end of the jam we had a few tracks they composed as well as some tracks they beat mapped for the midi system. Can’t say how great it was to get to work alongside audio folks again. Reminded me of my audio engineering work back in Atlanta.

Steven did a great job refactoring my hacked together signal analysis code, making it far more performant, and even spiffed up the front-end of the processing script to make it read far more easily and made it work great with multiple arduino inputs. By the end of the jam the processing side of things was running great and the updated front end helped out a ton with debugging. Steven tried a bunch of different signal analysis tricks throughout the jam. We regularly got to watch him jumping up and down with an accelerometer while looking intently at a data monitor.

Sam and Brett

Sam and Brett playing one of the other jam games

Sam Ballard and Brett Shipes were our audio pros for this one. They both had a ton of great ideas and feedback during the early concept stages and really did some terrific work once we hit production. I can’t pretend to understand all the ins-and outs of their work but they both composed some fun songs and worked to make sure everything worked with our gameplay. The accelerometers had trouble with rapid jumping so they worked their songs out so they could have spaces between the jumps for each player and fast sets were spread amongst other players. Brett kept having his equipment blow fuses which speeks a bit to old SF wiring but he was able to work around it once we figured out what was going on. And if I recall Sam beat mapped the JoCo cover of “We Will Rock You” which makes me very happy.

For my part, I worked closely with Eliot to figure out the best way to mount our accelerometers and arduinos. I wanted to mount the accelerometers close to the microcontrollers and have players pocket the whole system, tethering them to the computer with long USB runs. Eliot was concerned there was a high chance of shorting out the arduino, especially considering our breadboard wiring. He proposed that we make long wire runs with the accelerometers soldered on the ends. Was a fair bit more work, but after some hacking, ended up working nicely. We didn’t crush any electronics the whole weekend.

My other bit was mounting the projector. We really wanted to vertical mount and project onto the floor but we were fighting low ceilings and didn’t have a good way to mount onto it anyway. I toyed with the idea of mounting on the fire escape and playing on the street below but that seemed to offer more problems than solutions. I ended up mounting the projector at a really extreme angle on the top of a bookcase. Picked up some bungee cords Sunday morning and used them to keep the projector nicely mounted. I was actually really surprised how well it worked.

We demoed the game Sunday evening and not only did it work, we actually had a lot of fun playing it. Using accelerometers over dance pads was probably not the best idea gameplay wise due to bits of inaccuracy but I think we all learned a lot and there’s definitely a certain magic to just jumping on the floor and having it just work. Next steps would be to go wireless and make the accelerometer data more useful. Overall though it was quite a bit of fun and I know I learned a lot.

Playing games at the end of the jam

Playing games at the end of the jam

Some of the other projects that got presented were really cool too. One of my favorite parts of a jam is getting to see what everyone else produced in the time. There’s always a certain camaraderie with everyone going through the same 48-hour insanity together so no matter what comes out on the other end you want to celebrate what everyone else has done.

Steven put together a great little video of some of the games from the jam. You can watch it here: