DriftWood is an exploration game where you, as the player, can give and take properties to objects. You take on the role of an astronaut lost on a new planet to discover a world and understand what happened there and where its inhabitants are.
Genre: Exploration, Playground, Reflexion
Engine: Unity 3D
Team size: 6 members
Project duration: 8 Month (October 2024 - Mai 2025)
Support: Pc
Engine: Unity 3D
Team size: 6 members
Project duration: 8 Month (October 2024 - Mai 2025)
Support: Pc
My contibution:
Sound Design
- Reflection on sound intentions and references
- Sound production and design with reaper and fmod
- Integrating sound from fmod into unity
- Production of sound documentation for the project
Game Programmer
- Creation of tools and audio systems to help the integration of events and Fmod functions in Unity
- Writing technical documentation for tools and systems
- Reflection on sound intentions and references
- Sound production and design with reaper and fmod
- Integrating sound from fmod into unity
- Production of sound documentation for the project
Game Programmer
- Creation of tools and audio systems to help the integration of events and Fmod functions in Unity
- Writing technical documentation for tools and systems
Exemple of some of the Tools and audios system i realise in this projects
FMod Events Referenced in Scriptable Object
To create a Fmod instance in Unity, you need to use the string link or Fmod Reference.
The string link name to be exported each time the Fmod event changes is a problem that makes integration fairly complex and can easily create errors that quickly become time-consuming, and make integrating the sounds into the project more complex since the sound designer and programmer have to communicate the names of the variables and Fmod events to each other.
So for this game, we developed a Scriptable Object (SO) that will be used to give names and information to each of the FMod events. To do this, we have listed in the SO each of the Fmod reference variables that the sound designer and programmer will need. In this way, once a sound designer has completed an FMod event, he can enter it in the associated FMod reference, and the programmer can start to implement the sounds before all the events have been completed.
The only flaw in this system that needs to be improved is the creation of new FMod references in the SO, which is not optimal and requires direct modification of the SO script.
Music Emitter Component
For this project, we needed an efficient system to manage the emission of music according to the zone in which the player is located, necessary to achieve the desired effect of layered music (discussed in the composition and music design section).
To help us do this, we've created a component that you need to enter:
- The Fmod reference of the desired music
- The action to be applied, between Play, Stop and Switch (to change Layer)
- The moment at which the action is to take place, between Start, Enter or Exit of a trigger, or Destroy
- And finally, the Layer to transition to, which has an impact on Play and Switch.
To help us do this, we've created a component that you need to enter:
- The Fmod reference of the desired music
- The action to be applied, between Play, Stop and Switch (to change Layer)
- The moment at which the action is to take place, between Start, Enter or Exit of a trigger, or Destroy
- And finally, the Layer to transition to, which has an impact on Play and Switch.
The main advantage of this system is that, whatever the music reference, it checks whether the music instance already exists or not, and if it does, it retrieves the instance to modify it, rather than creating a new one.
Conversely, if the instance does not yet exist, it will create a new instance from the Fmod reference.
The script then takes the information about the trigger time, applies the action to be performed and defines the active layer, in order to apply the necessary modifications to the designated instance.
Conversely, if the instance does not yet exist, it will create a new instance from the Fmod reference.
The script then takes the information about the trigger time, applies the action to be performed and defines the active layer, in order to apply the necessary modifications to the designated instance.
The major shortcoming of this system, which needs to be improved, is that if several actions are to be performed on the same object, the component has to be duplicated and the input values changed.
When FMod sound instances are created using the script in unity, an instance is created. However, if the instance is not stored or kept in the script and is no longer easily accessible, and if it is necessary to change parameters on this instance or to stop it, this complicates matters and requires a lot of variables to be created in the project script.
However, we have created a system that allows us to create a large number of sound instances, while storing them using a system of nested dictionaries, which we have called the Sound Encyclopaedia.
A first dictionary serves as a repository for all the GameObjects on which sounds are played, and which therefore have sound instances.
And for each GameObject key in this dictionary, there is another dictionary, in which all the instances of this GameObject key are stored, ordered by their FMod reference, previously entered in an object that links FMod and Unity.
And for each GameObject key in this dictionary, there is another dictionary, in which all the instances of this GameObject key are stored, ordered by their FMod reference, previously entered in an object that links FMod and Unity.
This Encyclopaedia has no maximum size, just like the dictionaries for each GameObject, so you can theoretically put as many GameObjects and sound instances as you like.
However, this system has one rather beneficial limitation. It means that for each GameObject in the Encyclopaedia, only one sound instance per existing FMod reference can be stored.
So a GameObject cannot have two identical sound instances.
Although this may seem like a limit in reality, it avoids overloading memory with sound instances, and with good management of the instances that are created and needed, coupled with a clean-up of other unnecessary instances, this limit becomes a time-saver.
So a GameObject cannot have two identical sound instances.
Although this may seem like a limit in reality, it avoids overloading memory with sound instances, and with good management of the instances that are created and needed, coupled with a clean-up of other unnecessary instances, this limit becomes a time-saver.
