Read on Twitter
The rhetoric I've been exposed to, concerning the use of audio middleware for game jams, is that it's generally more effort than it's worth.
I've put together a thread on some of my observations around the use of FMOD with Unity for jams:
Enjoy, and feel free to disagree!
I've put together a thread on some of my observations around the use of FMOD with Unity for jams:
Enjoy, and feel free to disagree!
(As a note: Much of this applies to other middleware solutions and game engines, but I'll be focusing on FMOD + Unity here because it's what I'm most familiar with.)
So first off, there are a few cases where you definitely shouldn't worry about using FMOD for your game jam:
1. You plan to have either no sound, or only basic informational sound in your jam project.
(Bonus points for the restraint!)
(Bonus points for the restraint!)
2. You know your audio scope and how to implement all of the features within that scope into Unity, off the top of your head.
(Even if you're pretty confident, but not 100% sure you know how to do it, I'd still recommend considering FMOD)
(Even if you're pretty confident, but not 100% sure you know how to do it, I'd still recommend considering FMOD)
3. Just want to use stock Unity audio... like, for fun or something.
(This is totally fine, and discouraging failure is the last thing I want to do.)
(This is totally fine, and discouraging failure is the last thing I want to do.)
With that out of the way, when should you definitely use FMOD (or middleware) for your Unity jam projects:
1. You're working with an audio person who would like their sounds to function properly in the project.
(Some audio people like integrating their own stuff -- some don't! Talk to your audio people!)
(Some audio people like integrating their own stuff -- some don't! Talk to your audio people!)
2. You're doing audio and you'd like it to function properly in the project.
3. Someone's doing audio and you're at all worried about being able to get it in on time.
(I'll get into why this will buy everyone more time in a bit)
(I'll get into why this will buy everyone more time in a bit)
4. You value the iterative process.
(An extension of the previous note)
(An extension of the previous note)
A note: FMOD doesn't make games sound better. But it does make getting to the place where games sound better a much faster, easier process.
The intimidating part about FMOD (beyond the learning curve attached to anything that's "new"), from my experience and observation, is the initial integration process.
(Shameless plug: I have a video coming out about this next week)
(Shameless plug: I have a video coming out about this next week)
When you've done it a few times, it takes about 5 minutes, but your first time setting it up, it can take a fair bit longer than that, and there are a couple frustrating pitfalls for a jam situation.
Here's a link to the documentation tutorial: https://www.fmod.com/resources/documentation-unity?version=2.1&page=integration-tutorial.html#setting-up-the-fmod-project
Here's a link to the documentation tutorial: https://www.fmod.com/resources/documentation-unity?version=2.1&page=integration-tutorial.html#setting-up-the-fmod-project
A few things come to mind when it comes to integration pitfalls:
1. Set your integration up as Single (usually this, for jams) or Multi-Platform Build. This allows you to separate the FMOD project from the Unity project, so you don't have to push around a few hundred (or thousand) MB extra with your git commits.
2. While you're in the FMOD Settings panel, adjusting your build path/settings, also turn off the Debug Overlay, and save your team from the frustration of trying to figure out how to do it themselves.
3. Also, when it comes to git, you can safely ignore the log and cache files that FMOD generates.
4. Finally, DO NOT move any of the three folders that FMOD auto-generates. This will break the integration and cause a bunch of headaches.
As for why you should use FMOD for jam projects:
While it can take even up to an hour or two to get set up properly, if you're new to using it, it'll pretty much always make up for that in time saved.
While it can take even up to an hour or two to get set up properly, if you're new to using it, it'll pretty much always make up for that in time saved.
Organizationally, you'll have a lot less clutter (other than the three auto-generated folders) in your project because the majority of your audio logic and audio files will all just end up in a single (or small handful of) "bank" file(s).
(Manually add this "Banks" folder)
(Manually add this "Banks" folder)
It also lets whoever is working on audio test and tune audio and audio logic, to a degree at least, prior to having features audio is tied to, in place. A huge plus, given that audio finalization generally comes pretty close to last.
When events are properly integrated, you can still go back and tune audio without overwriting anyone's scene or prefab work -- it all just gets updated to the bank files.
Additionally, FMOD provides a bunch of built-in super simple, necessary features, at the click of a button, that would take a fair bit of time to build in Unity. Things such as sample, pitch and volume randomization, multi-sound layering, fades, and tempo quantization.
This facilitates getting to a better baseline much more quickly, but also facilitates iterating on work much more quickly than if you were to use stock Unity audio.
Final thoughts:
If you're still concerned, practice the day before! -- The git stuff is the most common pitfall.
Final thoughts:
If you're still concerned, practice the day before! -- The git stuff is the most common pitfall.
This ended up being a lot longer than I was intending -- if you made it this far, thanks for sticking with me, and hope you got something out of it!
