Hi,
I would like to share some suggestions regarding possible improvements to the Unity Integration for people/teams like us, who have built their own extensions on top of it in the form of Unity Packages.
We have created our own layer on top of the core components of FMOD so that we can simplify certain workflows and gain other benefits. This extension is created as a Unity Package so that we can easily reuse it in future projects. This resulted in us running into a couple of issues which we think might be worth looking into so that other teams who might be in a similar position in the future have easier time making their own custom packages.
The simpler issue affects the ability to re-use the build-in editor features FMOD comes with. The prime example being the event browser, allowing you to easily reference the audio events you want to play. When making custom components, features like these are priceless and having to re-implement them would be a lot of unnecessary work. Currently the EventBrowser class is not marked as public, making it not possible to use it without having to modify the plugin’s source code. This obviously is not a major issue but having to do this with any future updates would certainly be annoying. Another class in a similar position is EditorUtils. It would be great if these and possibly other editor components were made public by default, making it easier for us to reuse them.
A more complicated problem would be making FMOD not dependant on being placed under the Plugins folder. Ideally, the FMOD integration should be contained inside the our package to preserve the modular nature of packages. Sadly, as of now, a lot of the plugin is coded in a way where it is dependant on being under this specific folder. This caused some early issues with the “images” folder that we had to work around by copying it from the package, which by all means and purposes is not ideal.
This approach worked fine until we started making builds of our project, where we ran into constant errors of platform implementations not being found as they were expected to be under the Plugins folder. The approach of copying them also didn’t help this time around because this resulted in there being duplicate implementations which confused the build process. Not to mention the already stated issue that this should not be the way to handle this because it completely breaks the idea of package structure. There is also the option of just moving the package content from the package folder into the plugins folder but then you run the risk of someone accidentally removing some of it and not being able to fix the issue without completely reimporting the entire package. In the end we were forced to directly change the behaviour of the Platform.GetBinaryFilePaths() method to override where the binaries are looked up.
Dealing with this issue lead us through a lot of hoops that made us aware of a lot of inconsistencies in regards to how file paths are handled throughout the plugin. You would assume that with the plugin folder structure being the same, you would in the worst case only need to change the base path such as the RuntimeUtils.PluginBasePath property. This is sadly not the case, as a lot of places either prepend this path with the “Assets/” string, resulting in invalid path errors or for example straight up directly reference the Application.dataPath field, as is the case in the already mentioned Platform.GetBinaryFilePaths() method. This way of handling paths leads me to believe that either the plugin was build with the clear intention of being placed in this specific folder and/or was later on bent over in a lot of places to at least work there with no thought being put into making it more flexible.
It would be lovely if this could be reworked and make it possible for us to choose the base plugin folder. The plugin folder can still be used as default but being able to set this up in the FMOD settings would be great.
Thanks for considering any of these and sorry for the long post.
