Game Jam Tips for Sound Designers Part 3

AKA Oh god, not Git.

Have great respect for source control. It’s absolutely necessary to collaborate with a team. Unless you’re going to only give sound files to a team and have no interaction with the project itself, you’ll want to at least know the basics of how to push and pull to/from a Git repository using a Git client. Currently GitHub’s client is very straightforward but only works if the team is using GitHub.

But always be cautious with it. A badly coordinated push or weird merge can ruin a project or at least make it unplayable while everyone scrambles to fix it. It’s happened to multiple projects I’ve worked on. That sort of thing isn’t likely to be as much of an issue in normal life (changes can be rolled back or discarded and people are usually more careful about where they work). Game jams, especially one or two day jams like Global Game Jam, are at greater risk.

So how do you as the audio person decrease the chances of Git disaster?

First: Make sure the repository knows what changes to ignore and what not to ignore. This is especially true with audio middleware which will need extra files added to that list. FMOD, for example has a list of extra files to be added to the .gitignore file. If those aren’t added, you’ll end up with a whole lot of unnecessary merge conflicts and annoyed programmers.

From my experience, I’ll suggest keeping an eye on what files the client software you’re using ignores by default. When I last used Sourcetree with Wwise, it ignored necessary files for the integration to work properly. It was maddening.

Next: Practice discipline with the files you edit and push. While merging code is possible in Git, merging other files means choosing between whose version of that file is correct or not.

That means communicating with the rest of the team about what you’re working on to avoid those conflicts.

It means keeping an eye on all files that might’ve been changed since you last pushed your changes and make sure that only the files that you want to be updated or added in the repository are pushed. Engines can update files that don’t need to be changed or pushed to the repository. It’s annoying.

Finally: Limit the amount of people who push to the repository. I would suggest that all audio pushes to the main repo go through one person. If multiple people are editing events in middleware, I suggest using a repo specifically dedicated to the audio project itself, hosted completely separately from the main project’s repo.

From there, the person who pushes to the main repo can build banks. That keeps all changes to the sound updated with limited files changed in the main repository.

That’s actually pretty easy in FMOD Studio, enough that I’m genuinely recommending it.

Game Jam Tips for Sound Designers Part 2

Hi folks. It’s the eve of Global Game Jam so I have another tip or two left for sound designers to get their sounds into games.

This is another pretty simple tip: Work on multiple games and collaborate with other audio folks.

Not all game jam games are in any way playable by the end of the jam, regardless of whether they have sounds in them. I have a pretty large list of jam games I’ve worked on that are mostly broken if not completely nonworking. Having a hand in multiple games is an easy way to limit your risk. If one game falls apart, there’s still the chance that one of the others works.

To be a bit less calculated about it all, there’s often a bunch of good ideas floating around. Assuming there’s enough work for everyone, feel free to get in on more than one project you find interesting.

That said, I’ve always found it best to collaborate with other audio people. Game jams have limited time, so working with multiple audio people helps to make sure that:

-Each game gets its due

-You don’t burn yourself out too much

-There’s enough work to go around (if that’s an issue at your site). It makes sure you don’t take over the games other people want.

This is a good way to take on different roles (composer or sound designer) and find games that play to your strengths in each.

That could mean the team has a dedicated sound designer and a dedicated composer, which I try to make sure happens with the teams I’m on. I’ve even worked on a few teams where there are three or more audio people and they’ve made it much easier to ensure all the needed audio is completed.

Note, though, that having multiple sound designers complicates using the game in a reel to make sure you don’t end up accidentally taking credit for other peoples’ work.

Collaborating also means you get to work closely with other audio people. You can learn from them, to say the least. In a more idealistic sense, it also helps strengthen the bonds of the game audio community. In my experience,* I’ve found that the game audio community tends to be self-supportive and collaborative.

*admittedly, cishet white male experience

Game Jam Tips for Sound Designers Part 1

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.