Today I’m rounding out my recap of GGJ 2020, the day before GGJ 2021.

---

I woke up around 10 and spent the rest of the day up to the deadline working. I was kinda an island, with the team’s work going on around me. I wasn’t as dead-to-the-world as I’ve been in the past, but I was definitely focused elsewhere. At some point a photo was taken of the whole team. I’m looking at the page for the game on GGJ’s site and I definitely look dazed.

By the end of it, we had a playable game that had a bunch of sound in it. It wasn’t perfect or complete, but it was, well, playable and had a bunch of sound. I consider that a victory.

I took a quick look at what the rest of the teams had developed (they were pretty great this year). I left before the closing events had finished to make sure I caught the right train. I didn’t want to repeat Saturday night’s mistake (and, uh, 2019’s mistake now that I think about it) since I was being picked up from the train station.

The rest of the week until the showcase event, I polished up the audio. I fixed some outstanding bugs that I spent a huge amount of fatigued time on and ended up being easy to fix. I also managed to design sounds for three or four more kinds of junk, and Dan designed more as well. I was able to throw a couple more sounds toward Øa-sys as well.

The showcase on Thursday was enjoyable, too. So many of the Philly games turned out nicely, too. You can see the site’s games here: https://globalgamejam.org/2020/jam-sites/philly-global-game-jawn/games.

I had a few takeaways from this. Some of them just aren’t relevant now, since in-person jams won’t be happening for a while.

What keeps being clear, though, is that getting enough rest in these jams is productive in itself.

I definitely worked better after sleeping on Saturday. In 2016 and 2017 I probably had a total of four hours of sleep per jam. Don’t do that for obvious reasons. 2018 and 2019 each had nights where I didn’t get sleep (though 2019’s was not intentional; I had caffeine too late in the day) with the other night only having about five hours of sleep. Both of those had issues where I was stuck coding something that could’ve been quickly fixed.

In 2020 I was actually productive after sleeping eight hours on Saturday, even though I was tired from travelling the night before. Saturday into Sunday I was stuck on a problem for over an hour with a quick fix again. It wasted an hour or more that I could’ve just, y’know, slept through and approached with clearer eyes the next day.

---

Tomorrow night is the kickoff of Global Game Jam 2021. It’s being held online but still around all the local sites. It’ll be a new experience, spread out over four days instead of two. Hopefully that’ll mean less crunch and more rest. We’ll see how it changes and what ways GGJ and our local site have found to adapt. I’m looking forward to it.

I’m continuing my recap of GGJ 2020 today since this week is GGJ 2021. We pick up with my having arrived home tired at 2:00 AM after a whole lot of highway driving and train riding.

---

I actually got eight hours of sleep that night. I ended up back at the jam around 3:00, if I recall correctly. Dan and I were building an audio design spreadsheet that I contributed to while I rode the train into the city, going off of his notes of what was discussed after I left.

A little about audio design docs at a game jam: they’re useful in setting up things and marking what’s been done for your teammates. I usually find that I reach a point where if I’m working in middleware, the project outgrows the document, and for game jams especially, the game changes too fast.

On getting there I found out one if the teams we had planned on working with us, um, wasn’t. That was an unfortunate surprise. One of the other teams had already been unclear about whether they’d want additional sound design, so we weren’t too surprised about that team not returning.

That left us with one remaining team, which was the team working on Space Trash, which fortunately was where we were already planning on focusing most of our energy.

Quick summary of the game: the player character’s ship has crashed on a planet. To repair it well enough to leave, the player needs to collect the junk orbiting around the planet. At the end of every day, the ship runs out of fuel and crashes back to the surface.

I decided to take on the audio implementation using FMOD Studio and Dan would do most of the sound design with me handling the rest. Music would be a collaboration between Andrew Davis, who was working using LSDJ and a Game Boy (or maybe a Game Boy Advance), and Zach Tridico.

Story and writing was provided by Heidi Kalloo, with Heidi and Nooka Dascalu handling art. Mark Black and Phil Simmons handled programming and focused on the actual game mechanic design.

Dan and I set up a repo for the FMOD project. I would be the designated audio person to have access to the Unity project, which Mark set up using Unity Collab as source control.

I can’t speak much about the game design part of the project. I trusted the rest of the team to get that, especially with their focus on getting a game loop running. (Side note, I’m very grateful that they focused on having a working game loop. It’s good practice. In a game jam having a working game is the only way the sound, art, et cetera is going to be seen, after all.) This is especially important since I pretty much put on my headphones and worked on sound through a decent amount of development.

The implementation is something of a blur so I’m gonna talk about it like it happened all at once. It’s the part where I sat and stared at my laptop for hours ignoring everything around me.

I had the opportunity to become more acquainted with FMOD’s Unity integration after basically spending a year without doing the scripting part myself. Mark and especially Phil were extremely helpful with any issues I had. They were pretty great with commenting their code for where I might need to put sounds too (saving me a lot of unnecessary work when time was at a premium. Thanks!), and helping me with how they were using scriptable objects (which I’ll admit I wasn’t quite comfortable with at first; I was definitely out of practice). Most of that happened on Saturday night and Sunday morning.

At some point on Saturday, Dan and I picked up some work on one of the other games, Øa-sys. Dan provided music and I was able to get them some extra sound effects. The last build of the game I saw didn’t have them implemented, but as I’ve said before, that’s the risk of not implementing them on my own.

Sound recording on-site was fun as always. Since we needed to record junk, I needed to acquire some junk to record. I’d already had the foresight on Saturday to bring some pie tins that I’d collected. But, it wasn’t enough junk. So I decided to, uh, crowdsource that.

Being a sound recordist takes a certain kind of shamelessness. I don’t always have it but I definitely did when going around to each team and asking them for their trash so I could record it. Dan and I then went about looking for a place to record.

Since it was held at a college, there were actual music studios a couple of floors up. Of course, they required booking significantly in advance by actual students at the university, so that didn’t happen.

We had by then been joined by a couple of students there who were working on music and sound for Devil’s Desktop: I.T. Hell. We were all able to use one of the practice rooms to start recording. We recorded a bunch of pie plates at first. After that, Dan and I left them to record their own music. My memory of the order of events is a little unclear at this point. I remember pizza was delivered, Dan left for the night and I did some more recording, this time on my own.

I kinda live for that kind of prop recording; just me, a mic, some junk, and my recorder. That junk yielded a huge amount of content in this case.

When recording and pizza had ended, I settled into the work of roughly editing the junk recordings and implementing them, both into FMOD events and into Unity. I filled out the sounds that Dan couldn’t get to with some of my own. As I said, it’s a bit of a blur. I worked until 5:00, maybe, then eventually found a comfy chair to fall asleep in.

This upcoming week is Global Game Jam 2021. In tribute to that, a year later, I’m finally going to post my recap of Global Game Jam 2020. After the jam, I jumped right into a big sound design push for GDC 2020. Then, the world fell apart and I spent a decent amount of time adjusting to game audio in a socially-isolated world. I’ve written this out over the past year.

---

So the first day, I had to drive directly from my day job to take the train into the city, with the idea that I’d go to the jam, get settled on a team or two, then take the train back to my car and drive home for the night. Then, I’d take the train in on Saturday and stay the night. It was cheaper than three days of parking in the city and much safer and more pleasant than driving in Center City during rush hour.

It meant, though, that I would lose a lot of time to traveling. I did, and traveling was unpleasant and tiring. A quick guess is that I lost around 5 hours of the jam to travel.

Kickoff was pretty normal as far as the GGJ kickoffs have been. It was much calmer than Thorsten Wiedemann’s workout video keynote from GGJ 2018, at least. The icebreakers that PGM had were pleasant too and definitely got my mind working on design ideas.

Multiple interesting projects began to take shape. At some point, I ended up teaming with Dan Halma, splitting up sound design work on what we thought were two or three projects.

All the members of the team that was making Space Trash decided to go out for Chinese food when everything was settled, along with a few other people. That kind of meal is actually one of my favorite things about overnight game jams. It’s a great way to get to know folks that you may already be acquainted with or have just met. It’s also helpful to ceremonially focus the team to start working together. It’s not necessary, of course, but it’s pleasant. I think I’ve had some variant on it for five of the six in-person faster jams I’ve been present at. It’s a nice ritual that helps focus the entire team for the following couple of days. You don’t even need to talk about the game. In my experience, it’s a much better team builder than any actual team-building exercise.

I’m going to miss that this year. I wonder what we can do instead.

After a pleasant meal and some good tea, I broke off from the group. Due to some issues with SEPTA’s new ticket machines, I missed the train I’d planned on catching. Which is all to say, I ended up waiting at the station an extra hour and getting home, exhausted from an hour of driving, by 2:00 AM.

Part 2 will be published tomorrow. Turns out I remember much more than I thought I did. See you then.

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.

Edit: Maximilian Poirier has a comprehensive walkthrough of what should be included in source control for Wwise projects.

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.

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

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.