Hi everyone!
I’m the Technical Audio Designer for a gaming studio that has an audio team of six people. While some folks are in the fmod project more than others, it’s not unusual for everybody to work in fmod on a somewhat day-to-day basis, which has created some conflict issues. In my career so far, I’m typically the only person working in audio, and have always been the sole operator of the FMOD project, so I’m hoping to get some advice on what a workflow should look like for the team to minimize issues moving forward.
The issues we’ve had are largely very identifiable and preventable, like - the team not communicating on which specific areas in the project they are working in, and submissions are made with changes made on the same exact event.
More notably however, we’ve had some issues where I’ll pull in the latest changes from our Sprint branch (via Github) and find that we’ll have anywhere from a handful of files to hundreds of assets that are listed as #modified, paired with the 'This version of the file format is not supported error." In the latest case, each persons project had different files with the error (or not at all). In this particular case, the #modified files (when viewed directly from the assets folder) had extremely small file sizes (<200 bytes).
Currently how this studio operates, each individual creates their own branch for a days worth of work. Pull Requests are then submitted at the end of their day, and then one of the programmers reviews and commits them into the Sprint branch, where we would pull from the following day.
So - I’m hoping to get some recommendations, as someone not necessarily new to audio, but new to working with a larger audio team. What are some standard workflow do’s and don’ts when multiple people are working on the same fmod project? I’m hoping for both preventing large issues like described above, but then also just to gain some general wisdom from those who are experienced with big audio teams.
Things like:
-Individuals should/should not build and submit banks from their individual branches
-Should we all work on the same GitHub branch, or continue using individual branches?
-I’ve read recommendations on setting up our own repository that we can manage outside of the games projects - is this the standard?
-Any general project recommendations? We’ve made a switch from File Paths to GUID’s which has helped manage problems when an event name has been changed.
Some extra notes:
Unity 2022.3.13f1
FMOD 2.02.21
Github
All team members are Mac users (I’m on an M2 Max Sonoma - unsure of the other team members specifics)
Thanks for the read!
Travis
1 Like
Some screenshots from the file size problem we encountered as described above:
It seemed like this was isolated to the individuals machine, where if I hopped into someone else’s branch, I wouldn’t see the same thing. This most recently was on probably around ~300 assets. We were able to fix it by deleting the assets folder, and replacing it with a backup (redownloading the repository wouldn’t fix the issue).
Also - I meant to mention above that were are currently using the latest fmod recommended .gitignore file in the project as well.
When it comes to source control, there never tends to be a one and only best solution. It will always depend on the team and their needs.
FMOD Studio is integrated with several of the most common source control systems, and can support additional source control system integrations via scripts. See Using Source Control.
Using the source control integration in FMOD Studio can help with multiple people working inside the same project at the same time. However, you can choose to keep your FMOD Studio project in your repo with you Unity project if you like, you will just need to handle merging and resolving manually.
We also have documentation for using Source Control on the Unity side, which it sounds like you have already found.
You probably don’t want everyone building their own set of banks and submitting them since there will be changes from others that need to be included. Instead you could set up a build task from command line that, once all the changes have been submitted for that day, builds the banks into the Unity project and generates new cache files to be submitted.
2 Likes
Thanks for the reply Cameron! I definitely have seen the integrated source control system that FMOD has. As we’re using github for the main project repository this feels like something we wouldn’t be able to do, but maybe it’s common to set up our own repository for the audio team for this purpose?
As far as setting up a build task from the command line - is there a resource that I could reference to help me set something like that up? Would I need the integrated FMOD source control active for this to work? After some of the issues described above, we’ve adjusted our workflow to where I’m the only one committing bank build updates, which seems to be working well so far - but if this was automated that seems like a great solution!
Lastly - any ideas on what happened with the files becoming super small in the description above? That was a huge headache that we’d like to avoid…!
I’m not sure if it’s more or less common than other methods, but it sounds like something that might be able to help your case.
FMOD Studio has a command line tool that can be used to trigger the banks to be built, this doesn’t require source control or anything special.
This looks like it could be an issue with Github LFS there should be some options in your Github repo settings around this.
Hello Travis. Every group has unique needs and I’ll tell you what works for us. We work with CryEngine and Perforce. We have a team of 5 who work with FMOD Studio. Everyone has his part of project (parent event folders) so we can work parallelly. When one of us makes changes which are ready to commit, he just writes to group chat about that and he proceeds to his commit. After that everyone gets latest FMOD project and it goes like this on and on. Not perfect or most efficient, but it just work for us. Good luck with your project!
1 Like
