Hey everyone! Global Game Jam is coming up this week, so I thought I’d share some tips for being an audio person at a game jam.
Audio people (especially sound designers) are in a weird position; often the work they need to do happens toward the end of the jam and the framework for adding them in ends up ignored in favor of having a non-broken game. We can end up with a folder full of sound effects, none of which are in the game.
I can’t guarantee to anyone that it won’t happen. Game jam games are very unpredictable. But, I have somewhere between 25 and 30 jam games under my belt, mostly as a sound designer. Over all those, I’ve figured out some important ways to make sure I come out of jams with at least one game with sound effects. I’ll post a few over the next couple of days.
I’ll start with a short and simple one: Implement your sounds if you can. If you’re in charge of putting your sounds in the game, they’re much more likely to be there. It’s a rule I’ve seen play out in multiple jam games over the years. It makes sure that someone’s dealing with that folder worth of sounds and putting it in the game.
There are multiple possible reasons for this:
-It makes other programmers’ work easier, especially the programmers who don’t have a lot of experience implementing audio.
-It means someone’s actively making sound a priority.
-It means that while other people are scrambling to fix a very broken game at the last minute, someone stays dedicated to the audio.
It’s common, understandable, and okay if you can’t implement sound yourself at all. I started out unable to, and I still don’t focus on it, doing my best to have middleware incorporated into the game to make it easier.
So, if you can’t implement your sounds, make sure you’re involved and around the teams you’re on. Just being there and recording sounds while one of the other people on the team programs helps. It’s a reminder that that folder of sounds is there and someone’s working hard to make them.
A little story about that:
My first Global Game Jam was in 2016. I had started going to meetups at Philly Dev Night earlier that month. I was there with my laptop, a copy of Wwise, a decent amount of experimenting and studying the documentation, my computer, my microphone, and recorder.
Shortly after the start of the jam, the WI-fi and graphics card on my computer both stopped working. I eventually determined that some catastrophic failure had happened on the motherboard. Either way, that meant I couldn’t connect to the project in source control, but even if I could, the computer couldn’t load the game engine. Basic graphics capabilities were intact enough that I could edit audio though.
So, I parked myself in the middle of the team and got to recording. I recorded, edited, and RX’d two days worth of sounds and had them ready by the end of the jam. Some of them ended up implemented, though it ended up being somewhat moot. The working branch of the project ended up corrupted right before the jam deadline. So, most of the sounds (maybe all) weren’t implemented by the end. The game itself had bigger problems than that though.
While the project ran into fatal Git Issues, my presence at the least made sure that a significant amount of the sounds were implemented before those problems.