FMOD on DAD 424 Sound Design for Games

Building Dynamic Footstep Sounds in Unity with FMOD and Raycasting

Tue, 21 Oct 2025 00:00:00 +0000

Introduction

Creating immersive game soundscapes often comes down to subtle details—like the sound of footsteps adapting to different surfaces. In this tutorial, we’ll expand upon previous FMOD parameter work by integrating Unity’s physics system to detect materials underfoot. Using raycasting and tags, we’ll dynamically alter footstep sounds to reflect the player’s environment—be it grass, stone, puddles, or earth.

This guide walks through each step: tagging surfaces, scripting raycasts, and linking an enum-backed FMOD parameter for a responsive, data‑driven footstep system. If you follow along from top to bottom, you’ll go from a blank scene to fully adaptive footsteps.

Recap: Where We Left Off

In the previous session, we created a simple FMOD event that played footstep sounds through Unity animation triggers. We:

Created a footstep event in FMOD with a “Material” parameter.
Wrote a Unity C# script to instantiate, play, and destroy the event on each step.
Linked animation events to ensure footstep sounds triggered precisely in sync.

Now, we’ll enhance that system so footsteps automatically change depending on what surface the player is walking or running across.

Step 1: Setting Up Tags in Unity

Tags let you label objects and detect them in scripts. Each surface type gets a unique tag.

Navigate to Edit → Project Settings → Tags & Layers.
Under Tags, click + and add:
- Earth
- Stone
- Puddle
- Grass

Assign these tags to relevant scene objects—terrain, stairs, platforms, etc. Apply the tag to the collider you expect the raycast to hit (often on the same GameObject that has the Mesh Collider or Box Collider).

Tagging even a few surfaces is enough to test. Later, we’ll expand this system to cover more materials using Physics Materials or Terrain Textures.

Step 2: Script Framework

Start by defining an enum for surface types and the core fields/methods in your player script. Add this to your player controller (or a dedicated audio component on the player).

An enum is a new data type we haven’t used yet. It lets us define a set of named constants, which we can use to represent discrete values (like surface types). This makes our code more readable and less error-prone than using raw integers or strings.

using UnityEngine;
using FMODUnity;
using FMOD.Studio;

public enum MaterialType { Earth = 0, Stone = 1, Puddle = 2, Grass = 3 }

public class F_Player : MonoBehaviour
{
 [SerializeField] private LayerMask groundLayerMask;
 [SerializeField] private float rayDistance = 1.5f;

 private MaterialType currentMaterial;
 private RaycastHit hitInfo;
 private Rigidbody rb;

 private void Awake()
 {
 rb = GetComponent<Rigidbody>();
 }

 private void Update()
 {
 // Step 4 will explain this debug line
 Debug.DrawRay(transform.position, Vector3.down * rayDistance, Color.red);
 }

 public void PlayRunEvent(string eventPath)
 {
 if (string.IsNullOrEmpty(eventPath)) return;
 MaterialCheck();
 EventInstance run = RuntimeManager.CreateInstance(eventPath);
 RuntimeManager.AttachInstanceToGameObject(run, gameObject, rb);
 // Step 6: we'll create/start the FMOD event and set the parameter
 }

 private void MaterialCheck()
 {
 // Steps 3–5: raycast and set currentMaterial
 }
}

Notes:

Enum names must match tags exactly: Earth, Stone, Puddle, Grass.
groundLayerMask should include only layers containing walkable geometry.
rayDistance defaults to 1.5m; adjust to your character height.

Step 3: Raycasting to Detect Surfaces

The script casts a ray downward from the player to find the surface beneath:

if (Physics.Raycast(transform.position, Vector3.down, out hitInfo, rayDistance, groundLayerMask))
{
 // hitInfo.collider is the surface collider we tagged
}

transform.position = Player position
Vector3.down = Direction toward the ground
rayDistance = Ray length (default 1.5m)
groundLayerMask = Limit detection to your environment layers (e.g., Environment, WaterGeometry)

In the Inspector, assign the groundLayerMask to include only layers with tagged ground geometry.

If you find gaps on stairs or steep terrain, consider a small sphere cast:

if (Physics.SphereCast(transform.position, 0.1f, Vector3.down, out hitInfo, rayDistance, groundLayerMask))
{
 // Slightly more forgiving than a thin ray
}

Step 4: Visualize the Ray

The script draws the ray each frame for easy debugging:

Debug.DrawRay(transform.position, Vector3.down * rayDistance, Color.red);

View this in the Scene window as you move the player to ensure correct origin and length.

Step 5: Tags → Enum Mapping

Inside MaterialCheck() and Raycast if statement, add this code to convert the detected tag into the enum value:

if (System.Enum.TryParse(hitInfo.collider.tag, out MaterialType material))
{
 currentMaterial = material;
}

TryParse: Attempts to map the tag (e.g., “Stone”) to MaterialType.Stone.
Safe update: Only assigns currentMaterial when parsing returns true; otherwise the previous value remains.
Optional default: If you want an explicit fallback when parsing fails, add an else:

if (System.Enum.TryParse(hitInfo.collider.tag, out MaterialType material))
{
 currentMaterial = material;
}
else
{
 currentMaterial = MaterialType.Earth; // default
}

Step 6: FMOD Parameter Setup

The script sets the parameter via, which you’ll add inside PlayRunEvent before starting the event:

run.setParameterByName("Material", (float)currentMaterial);

Step 7: Full Script

Here’s the complete script with all steps combined:

using UnityEngine;
using FMODUnity;
using FMOD.Studio;

public enum MaterialType
{
 Earth = 0,
 Stone = 1,
 Puddle = 2,
 Grass = 3
}

public class F_Player : MonoBehaviour
{
 [SerializeField] private LayerMask groundLayerMask;
 [SerializeField] private float rayDistance = 1.5f;

 private MaterialType currentMaterial;
 private RaycastHit hitInfo;
 private Rigidbody rb;

 private void Awake()
 {
 rb = GetComponent<Rigidbody>();
 }

 private void Update()
 {
 Debug.DrawRay(transform.position, Vector3.down * rayDistance, Color.red);
 }

 public void PlayRunEvent(string eventPath)
 {
 if (string.IsNullOrEmpty(eventPath)) return;

 MaterialCheck();

 EventInstance run = RuntimeManager.CreateInstance(eventPath);
 RuntimeManager.AttachInstanceToGameObject(run, gameObject, rb);
 run.setParameterByName("Material", (float)currentMaterial);
 run.start();
 run.release();
 }

 private void MaterialCheck()
 {
 if (Physics.Raycast(transform.position, Vector3.down, out hitInfo, rayDistance, groundLayerMask))
 {
 Debug.Log("Hit material: " + hitInfo.collider.tag);
 if (System.Enum.TryParse(hitInfo.collider.tag, out MaterialType material))
 {
 currentMaterial = material;
 }
 }
 }
}

References:

Driving FMOD Parameters from Unity: Teleport Sound Example

Mon, 13 Oct 2025 00:00:00 +0000

Introduction

In this tutorial, you’ll build a reactive teleportation sound system by controlling FMOD parameters from Unity using C#. You’ll learn to:

Create and automate parameters in FMOD
Instantiate and attach FMOD events in Unity
Dynamically set parameter values via C# scripts
Trigger sound transitions via Unity collision events

FMOD Parameters are made up of a range of values that can be adjusted in real-time inside our game. This allows us to create dynamic audio that responds to gameplay events, such as a player entering a teleporter.

FMOD Setup

Before diving into code, we’ll first build the teleporter event in FMOD. This event demonstrates how to use both built-in and user parameters to control sound behavior dynamically.

Goal

We’re designing an event that:

Loops a magical hum sound for a teleporter object.
Uses the built-in Distance parameter to fade out low frequencies as the listener moves away.
Uses a custom Trigger parameter to fire a secondary teleport sound when the player enters the teleporter.

When done, your FMOD setup will let Unity control when the teleport sound plays—while FMOD automatically handles distance-based EQ changes.

1. Create the Event

Open FMOD Studio.
In the Assets Browser, find Teleporter Loop Stereo 01 under Audio Bin → Interactables → Teleporters.
Create a new event named Teleporter in the SFX/Interactables folder.
Drag Teleporter Loop Stereo 01 onto Track 1 at the beginning of the timeline.

2. Loop Region and Asynchronous Playback

Create a loop region around the first second of the timeline. This keeps the playhead cycling near the start while the loop plays.
Select your sound instrument and:
- Enable Async playback. This ensures the sound plays to completion even if the playhead remains in the loop region.
- Enable Loop While Playing.
- Enable Cut (cut playback when untriggered) — so when the loop region deactivates, playback stops immediately.

Sound Instrument Settings: Async, Loop While Playing, and Cut

Async

Controls whether a sound keeps playing after the playhead leaves its region.

ON – plays to completion; good for one-shots like explosions.
OFF – stops when the region ends; use for loops tied to the source (e.g., footsteps, engines).

Loop While Playing

Makes the instrument repeat while it remains triggered.

Combine with Async ON to loop freely until untriggered.
Combine with Async OFF to loop only within the region.

Cut

Determines what happens when an async loop is untriggered.

ON – stops immediately; use for UI or speech.
OFF – plays out or fades naturally; use for ambiences.

Note: In current FMOD versions, Cut mainly affects async looping instruments. For overlap control, use Polyphony = 1 or Steal Oldest instead.

Example	Async	Loop	Cut	Notes
Explosion	ON	OFF	OFF	Rings out naturally
Footsteps	OFF	ON	ON	Stops instantly
Ambience	OFF	ON	OFF	Continuous loop
UI click	ON	OFF	ON	Prevents overlap

3. Add and Automate the Distance Parameter

The Distance parameter is one of FMOD’s built-in parameters. There are six built-in parameters: Distance, Direction, Speed, Orientation, Elevation, and Cone Angle.

Built-in parameters automatically update based on the listener’s position relative to the sound source in 3D space.

See more information here: FMOD Built-In Parameters

To add and automate Distance:

Click the “+” icon → choose Add Parameter Sheet → New Parameter.
Name it Distance and choose the Built-In type for Distance.
On your track, insert a 3-Band EQ effect (right-click near the track fader → Add Effect → EQ → 3 Band EQ).
Right-click the Low Gain knob on the EQ and choose Add Automation. Then click Add Curve and select Distance.
1. You have now connected your Distance parameter to the low-frequency gain control on the EQ.
You’ll see a red automation curve appear under the track.
Draw the curve so that as Distance increases, the low end fades out.

This simulates real-world behavior—low frequencies carry farther, so as the player gets closer, you regain that low-end presence.

4. Create the Custom Trigger Parameter

Now we’ll add the parameter Unity will control.

In the Parameters tab, click “+” → Add New Parameter.
Choose Discrete type (whole-number values).
Name it Trigger.
- Discrete values are ideal for toggling between on/off or state-based conditions.
Set its range:
- Min: 0
- Max: 1
In your event:
- Place the second sound (Teleporter Walk Through 01) under the same track or on a new one.
- Go to the Loop region and open its Trigger Conditions panel.
- Set it to play when Trigger = 1.
For the looping hum track:
- Open its Condition Sheet and add a condition to disable playback when Trigger = 1.
- Add a short fade-out automation for smooth transition.

When Trigger switches from 0 to 1, the looping hum fades, and the teleport sound plays once.

5. Fine-Tune Spatialization

On the Master Track, open the Spatializer effect.
Adjust Min Distance and Max Distance values so the attenuation curve fits your in-game scale (e.g., smaller values for tight interior scenes, larger for outdoor).
Preview using the 3D Preview window in FMOD to confirm how the sound falls off with distance.

6. Save and Build

Finally:

Save the project.
Assign your event to the Master Bank.
Build your banks (File → Build → Build Banks).

You’re now ready to load this event in Unity.

7. Test in FMOD Before Unity

Play your event in FMOD:

Drag the Distance slider to watch the EQ automation respond.
Set Trigger = 1 to hear the teleport sound override the loop.

You should observe:

The low-end fading out naturally as Distance increases.
The teleport sound firing instantly when Trigger hits 1.
The loop stopping cleanly when the parameter condition disables it.

This confirms everything is wired properly before moving to C# integration.

Unity Scene Setup

Find the teleporter in the scene. Its the TransitionStart game object.
Make sure the teleporter has a Box Collider (or whatever shape), set to Is Trigger.
Place your player (e.g. “Ellen”) in the scene. This will make our sounds easier to test.
- Find Ellen and change her transform position to X: -145, Y: 21.3, Z: 43.
- Alternatively, copy the position of the TransitionStart object then paste it into Ellen’s transform, then adjust the X position by -5 to start just outside the trigger.
Disable or remove other objects so they won’t interfere during testing by unchecking their active state in the Inspector.

C# Script: `F_Teleporter.cs`

Create a script under your Scripts/FMDO Scripts folder named F_Teleporter.cs and attach it to your teleporter object (the same object holding the trigger collider). Here’s the full script:

using UnityEngine;

public class F_Teleporter : MonoBehaviour
{

 FMOD.Studio.EventInstance tHum;
 void Start()
 {
 tHum = FMODUnity.RuntimeManager.CreateInstance("event:/SFX/Interactable/Teleporter");
 FMODUnity.RuntimeManager.AttachInstanceToGameObject(tHum, gameObject, GetComponent<Rigidbody>());
 tHum.start();
 }

 // Update is called once per frame
 void OnTriggerEnter(Collider other)
 {
 // Could also use other.CompareTag("Player") for more robust checking if the Player game object had the tag "player"
 if (other.name == "Ellen")
 {
 tHum.setParameterByName("Trigger", 1, false);
 }
 }

 void OnDestroy()
 {
 tHum.stop(FMOD.Studio.STOP_MODE.IMMEDIATE);
 tHum.release();
 }
}

Key Points

CreateInstance(path) must match exactly the FMOD event path.
AttachInstanceToGameObject(...) aligns spatial 3D behavior (so position/distance is tracked).
setParameterByName("Trigger", 1f, false) changes your Trigger parameter.
- The false flag means you don’t bypass seek speed — FMOD seeks based on your parameter settings.
release() frees memory and ensures no audio leaks after object destruction.

Testing & Debugging

Hit Play in Unity.
Move the listener close to the teleporter — you should hear the ambient loop with full low frequencies.
As you back away, low frequencies fade (due to the Distance → EQ automation).
Walk into the trigger: the teleport sound plays, and the loop stops or fades.

If things don’t work:

Confirm the collider is set to Is Trigger.
Double-check your player object’s name (or change the script to use a tag).
Ensure the FMOD event path is correct and that the event’s bank is loaded.
In FMOD Studio, verify your parameter mapping and that Trigger = 1 is correctly wired.

Simplifying Sound Playback in Unity with FMOD’s PlayOneShot Command

Mon, 13 Oct 2025 00:00:00 +0000

Introduction

In game audio, efficiency matters. When designing sound interactions in Unity using FMOD, there are many cases where you only need a sound to play once—like when a player picks up an item or activates a switch. Writing full event-handling code for each instance can quickly become cumbersome.

That’s where FMOD’s PlayOneShot command comes in. This function provides a fast, elegant way to trigger short, non-looping sound effects in your game world without manually managing event instances. In this guide, we’ll walk through how to use PlayOneShot and PlayOneShotAttached, explain how Unity’s trigger system ties in, and unpack key technical concepts like Vectors, Colliders, and Layers.

What Is PlayOneShot?

FMOD’s PlayOneShot command allows you to play an FMOD event anywhere in your game with a single line of code. When the command is called, it automatically plays the event and then cleans up after itself when the sound finishes—no need to store or release the event manually.

This makes it ideal for simple, one-off sound effects such as button clicks, weapon pickups, or door openings.

For instance, if we want to trigger a short sound effect when a player picks up their melee weapon, PlayOneShot lets us do it with minimal setup.

Setting Up the Event in FMOD

Create a new 3D Action event called Staff Collect and add your audio file (for example, Switch Activated 01).
Assign the event to your Master Bank.
Organize it neatly under SFX → Interactables.
Save your project and build your banks.

Once you’ve done that, switch back to Unity to implement the sound event.

Action Events are perfect for short, non-looping sounds that play once and then stop. They are typically used for sound effects triggered by player actions or environmental events.

Using Triggers in Unity

A Trigger in Unity is an invisible area that detects when objects (like your player) enter or leave it. Triggers are built using colliders with the Is Trigger box checked. When something passes through, Unity can perform specific actions—such as playing a sound.

For our weapon pickup example:

The StaffTakeTrigger object in your scene will act as the trigger.
It already has a Sphere Collider attached with Is Trigger enabled.
When the player enters this area, Unity can detect the interaction and execute our FMOD command.

We’ll connect this trigger to our FMOD event using a custom script.

Writing the Trigger Script

Go to your FMOD Scripts folder and create a new C# script called F_StaffCollectTrigger attach it to the StaffTakeTrigger object.

Delete the default Start and Update functions, as we won’t need them for this simple interaction.

Inside the script, we’ll use the OnTriggerEnter function. This Unity event function runs automatically when another object enters the trigger’s collider.

using UnityEngine;

public class F_StaffCollectTrigger : MonoBehaviour
{
 void OnTriggerEnter()
 {
 FMODUnity.RuntimeManager.PlayOneShot("event:/SFX/Interactables/StaffCollect", transform.position);
 }
}

onTriggerExit is another useful function that runs when an object leaves the trigger area. You can use it for sounds that should play when the player exits, like a door closing. onTriggerStay runs continuously while an object remains within the trigger.

This is all it takes to trigger the Staff Collect sound effect when the player enters the area.

However, we can improve this setup by specifying where in 3D space the sound should be played.

Understanding Vectors in Unity

To position sounds accurately, we need to work with Vectors—data types that store coordinates and direction.

Vector2 holds x and y coordinates (useful for 2D games).
Vector3 holds x, y, and z coordinates (used in 3D games).

In Unity, almost every object’s position, rotation, and scale are stored as Vector3 values. To access the current position of your object, you can reference its Transform component.

Here, transform.position retrieves the Vector3 position of the object this script is attached to (the trigger). This is shorthand for GetComponent<Transform>().position.

If you want to play the sound at a different location but related to the trigger, you can create a new Vector3:

Vector3 pos = transform.position + Vector3.up * 1.5f;
FMODUnity.RuntimeManager.PlayOneShot("event:/SFX/Interactables/StaffCollect", pos);

This example plays the sound 1.5 units above the trigger’s position.

Layers and Collision Setup

For the trigger to work correctly, Unity needs to detect when the player enters the trigger area. This requires proper setup of Layers and Colliders.

The object acting as the trigger must have a collider with Is Trigger checked.
The player object must either:
- Have a Rigidbody component, or
- Be on a layer compatible with the trigger’s layer.

You can manage these interactions in Unity’s Layer Collision Matrix under Edit → Project Settings → Physics. Ensure that the Player layer can interact with the Environment layer (or whichever layer your trigger belongs to).

Tags and Layers help organize objects in your scene and control how they interact. Tags are used for identifying objects, while Layers are used for collision detection and rendering.

Here you can see the Layer Collision Matrix in Unity, which defines how different layers interact with each other. See that the Player layer can collide with the Environment layer, allowing our trigger to detect when the player enters.

Using PlayOneShotAttached

While PlayOneShot requires a position vector, FMOD also offers a variant called PlayOneShotAttached. This version automatically plays an event at the location of a specific game object.

Here’s how to use it:

void OnTriggerEnter()
{
 FMODUnity.RuntimeManager.PlayOneShotAttached("event:/SFX/Interactables/StaffCollect", gameObject);
}

The gameObject reference points to the object this script is attached to—in this case, StaffTakeTrigger. This makes it an elegant alternative when you want to link the sound directly to an object’s position.

If you want to attach the sound to another object in the scene, you can define a public GameObject variable in your script and assign it through the Unity Inspector:

public GameObject Obj;

void OnTriggerEnter()
{
 FMODUnity.RuntimeManager.PlayOneShotAttached("event:/SFX/Interactables/StaffCollect", Obj);
}

This approach provides flexibility for triggering sounds from different points in your game world.

Limitations and Next Steps

While PlayOneShot and PlayOneShotAttached are great for quick, lightweight sound triggers, they come with a limitation: you can’t manipulate FMOD parameters after triggering them.

For cases where you need to control parameters dynamically (for instance, changing pitch or volume in response to player movement), you’ll need to use full event instances instead.

We’ll explore this in the next module: Interacting with FMOD Parameters—where you’ll learn how to adjust event behavior in real time for adaptive sound design.

Conclusion

The PlayOneShot and PlayOneShotAttached commands streamline the process of triggering short, non-looping sounds in Unity. Combined with Unity’s trigger system and a solid understanding of Vectors and Layers, they allow you to quickly prototype interactive sound behaviors.

Challenge 3: Health Crate Audio

Mon, 04 Nov 2024 00:00:00 +0000

Overview

In this challenge, you’ll design and implement the audio behavior for the Health Crate in Unity using FMOD. The crate should emit a looping hum before interaction and trigger a one-shot burst when the player collects health.

Objectives

Integrate FMOD events with Unity using correct namespaces and instance management.
Implement 3D spatialization so the audio responds to distance.
Use parameters to automate playback and control transitions.
Apply event lifecycle management to avoid leaks and redundant instances.

Criteria (12 Points Total)

Follow the criteria below to complete the challenge:

Criteria	Points
All sounds are 3D and get louder as the player approaches	3
The looping hum stops once the player collects health	3
Instances are properly destroyed when no longer needed	2
FMOD namespaces are used to shorten your code	2
The one-shot triggers only when the player interacts with the health crate	2
Bonus: Add a delay to the one-shot that increases as the player’s health decreases	3

Hints & Resources

Audio files are in your FMOD project under: Audio Bin → Interactables → Health Boxes
- Box Loop (for the hum)
- Box Open (for the one-shot)
Lessons that may help:
- Using Play-One-Shot’s
- Automating Audio with Parameters: Part 1 & 2
To find the player’s health, open the Damageable script on the Ellen GameObject.

Deliverables

Short video (1–2 minutes): Demonstrate the crate’s audio behavior in-game.
- Show the 3D hum changing with distance.
- Interact with the crate to trigger the one-shot.
- (Optional bonus) Demonstrate the delay effect at different health levels.

Reflection Prompt

Write 100–150 words explaining:

How you structured your FMOD event.
How you managed start/stop logic in Unity.
(If you completed the bonus) How your delay changes with player health.

Controlling Audio From Multiple Scripts

Mon, 04 Nov 2024 00:00:00 +0000

Overview

A hands-on guide to managing one FMOD event from different places in your Unity game. By the end, you’ll be able to start music in one script and safely stop or change it from another, without duplicate sounds or messy references.

Learning goals

Understand when to use instance (non-static) vs class-wide (static) variables
Create and manage a single FMOD EventInstance for music
Trigger fades and parameter changes from other scripts
Avoid common pitfalls like invalid handles and race conditions

What you’ll build

A MusicScript that starts a looping music event
A trigger script that fades the music when the player enters a zone
An optional UI control to change a music parameter (e.g., intensity or low-pass)

Static Vs Non-Static Variables Refresher

Here’s a simple example to clarify the difference between non-static and static data types in C# — especially in a Unity scripting context.

Example: Player Score

using UnityEngine;

public class Player : MonoBehaviour
{
 public int playerScore = 0; // Non-static (instance-based)
 public static int totalScore = 0; // Static (shared across all players)

 void Start()
 {
 playerScore = Random.Range(1, 10);
 totalScore += playerScore;
 }
}

How this works

Non-static (playerScore) Each Player object keeps track of its own score. If you have 3 Player GameObjects, each will have a different playerScore value.
Static (totalScore) This value is shared by all Player objects. Every time a new Player adds its score, totalScore updates globally. You can access it from anywhere with Player.totalScore—no need to reference a specific Player instance.

Why it matters

Use non-static when each instance should have its own data. Example: individual enemies with their own health or position.
Use static when there should be only one value shared across all instances. Example: total score, global music controller, or global game state flag.

Approach 1: Instance-based control (non-static)

Use this when the music belongs to a specific GameObject in the scene and you want to wire references explicitly in the Inspector.

MusicPlayer.cs

using UnityEngine;
using FMODUnity;

public class MusicPlayer : MonoBehaviour
{
 [SerializeField] private EventReference musicEvent;
 public FMOD.Studio.EventInstance MusicInst;

 void Start()
 {
 MusicInst = RuntimeManager.CreateInstance(musicEvent);
 MusicInst.start();
 }

 void OnDestroy()
 {
 MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 MusicInst.release();
 }
}

F_Teleporter.cs (fade music on trigger)

There are two ways to reference our MusicPlayer here. One is to use Unity’s find methods to search for it in the scene; the other is to create a serialized field and drag the reference in the Inspector. The latter is preferred for performance and clarity.

Method 1: Using a find method (not recommended for performance reasons)

// Example only — prefer the serialized field approach below
// var musicPlayer = GameObject.Find("Music Object").GetComponent<MusicPlayer>();
// or
// var musicPlayer = FindObjectOfType<MusicPlayer>();

Method 2: Using a serialized field (preferred)

using UnityEngine;

public class F_Teleporter : MonoBehaviour
{
 [SerializeField] private MusicPlayer musicPlayer; // drag your MusicPlayer object here

 void OnTriggerEnter(Collider other)
 {
 if (!other.CompareTag("Player")) return;

 // Check if the music instance is valid before stopping
 if (musicPlayer != null && musicPlayer.MusicInst.isValid())
 {
 musicPlayer.MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 }
 }
}

Why choose this: it’s explicit and great for scenes with multiple independent music or ambience controllers. You control exactly which instance you’re touching by wiring it in the Inspector.

To finish, select the GameObject with the F_Teleporter component and drag the GameObject with the MusicPlayer script into the Music Player field in the Inspector.

Approach 2: Class-wide control (static)

Use this when there’s exactly one music instance for the whole scene or game and you want to access it from anywhere without passing references.

MusicScript.cs

using UnityEngine;
using FMODUnity;

public class MusicScript : MonoBehaviour
{
 [SerializeField] private EventReference musicEvent;
 public static FMOD.Studio.EventInstance MusicInst;

 void Start()
 {
 if (!MusicInst.isValid())
 {
 MusicInst = RuntimeManager.CreateInstance(musicEvent);
 MusicInst.start();
 }
 }

 void OnDestroy()
 {
 if (MusicInst.isValid())
 {
 MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 MusicInst.release();
 }
 }

 public static void SetMusicParam(string name, float value)
 {
 if (MusicInst.isValid())
 MusicInst.setParameterByName(name, value);
 }
}

F_Teleporter.cs (fade music on trigger)

using UnityEngine;

public class F_Teleporter : MonoBehaviour
{
 void OnTriggerEnter(Collider other)
 {
 if (!other.CompareTag("Player")) return;

 if (MusicScript.MusicInst.isValid())
 {
 MusicScript.MusicInst.stop(FMOD.Studio.STOP_MODE.ALLOWFADEOUT);
 }
 }
}

Why choose this: it’s quick and convenient when you truly have a single, global music state. Anywhere in code can reach it via the class name.

When to use which

Use instance-based if:

You have multiple music or ambience controllers
You want explicit Inspector wiring and easy prefab testing

Use static if:

There is only one music instance
Many systems need to access it without passing references
You’re building a lightweight global music controller

Troubleshooting checklist

Does your Player have the Player tag and a collider/rigidbody appropriate for trigger events?
Is the FMOD event assigned in the Inspector and valid in FMOD Studio?
Are you calling stop on a valid instance? Check MusicInst.isValid() before using it.
Are you starting the event before trying to stop it? Initialize in Start and verify logs.
For static mode, do you accidentally create multiple MusicScripts? Guard with isValid().

Clean-up and lifecycle tips

stop ends playback; release frees the handle. After stopping with ALLOWFADEOUT, release the instance when you’re truly done with it.
If music should persist across scenes, mark the music GameObject with DontDestroyOnLoad and manage transitions centrally.
Avoid GameObject.Find. Prefer serialized fields (instance approach) or the class name (static approach) for clarity and performance.

Quick reference

Instance-based access: keep MusicInst non-static and pass references via the Inspector.
Static access: make MusicInst static and reach it from anywhere with MusicScript.MusicInst.
Always check isValid before using an EventInstance.
Stop with ALLOWFADEOUT, then release when finished.

Controlling FMOD Busses with Unity Sliders (Part 2)

Wed, 12 Jun 2024 00:00:00 +0000

In this tutorial, we will cover how to control the volume of your FMOD buses (like Music and SFX) using Unity sliders, and more importantly, how to make sure those sliders remember their positions when your player changes scenes.

Part 1: Setting the Volume

The Code

In your Bus Control script, create a new public function. Let’s call it VolumeLevel. This function needs to accept a float parameter, which will represent the data coming from the slider.

Inside the function, we use the FMOD API command .setVolume().

public void VolumeLevel(float newSliderValue)
{
 // 'Bus' is the variable where you stored your FMOD Bus path earlier
 Bus.setVolume(newSliderValue);
}

Understanding FMOD Volume Floats

It is important to understand how FMOD interprets these numbers. FMOD faders use a logarithmic scale (decibels), but the API uses a linear float scale between 0 and 1.

1.0f: This equals the volume the fader was set to when you built your banks in FMOD. (If your fader was at 0dB, 1.0 = 0dB. If it was at -10dB, 1.0 = -10dB).
0.0f: This equals -infinity dB (silence).
0.5f: This is roughly -28dB (depending on the curve), effectively half the “fader distance” between the start point and silence.

Part 2: Connecting the UI Slider

Now that the logic exists, we need to hook it up to the Unity UI.

Select your Slider object in the Unity Hierarchy.
Find the Slider component in the Inspector.
Look for the “On Value Changed (Single)” event box at the bottom.
Click the (+) icon to add a listener.
Drag the GameObject containing your Bus Control script into the “Object” slot.
In the function dropdown, look for your script name and select VolumeLevel.

Crucial Step: When selecting the function, you will see it listed twice: once under “Dynamic float” and once under “Static Parameters.”

Select the Dynamic Float version. This ensures the function receives the actual current value of the slider as the player moves it.

Part 3: The “Scene Reset” Problem

If you play your game now, the sliders will work. However, you will notice a bug if you switch scenes.

Let’s say the player lowers the volume to 50%. When they walk through a portal to Level 2, the scene reloads. FMOD is smart—it remembers the volume is at 50%. However, the UI Slider is just a dumb object; it reloads from the prefab and resets visually to its default position (usually 100% or 0.9).

Now you have a slider showing 100% volume, but the audio is playing at 50%. We need to sync them up when the scene starts.

Part 4: syncing Sliders with `.getVolume()`

To fix this, we need to tell the slider where the bus volume is actually located the moment the script starts. We do this using the .getVolume() command.

The Challenge with `.getVolume()`

This command is slightly unique because it outputs two distinct values. It requires two out variables:

Volume: The value set by the setVolume command (User input).
Final Volume: The value calculated after combining user input with FMOD modulators or automation.

We only care about the first one (User input).

The Solution

First, update your script to include the UI namespace, or Unity won’t recognize what a “Slider” is.

using UnityEngine;
using UnityEngine.UI; // Don't forget this!

Next, inside your class, create a reference to the Slider and variables to hold the volume data.

private Slider slider;
private float busVolume;
private float finalBusVolume;

Finally, in your Start() function, grab the slider component and sync it to the FMOD bus:

void Start()
{
 // 1. Get the slider component attached to this object
 slider = GetComponent<Slider>();

 // 2. Get the current volume from the FMOD Bus
 // We pass in our two float variables to catch the data
 Bus.getVolume(out busVolume, out finalBusVolume);

 // 3. Update the slider visual to match the FMOD bus volume
 slider.value = busVolume;
}

Summary

By using setVolume dynamically and getVolume on initialization, you create a seamless experience for the player.

On Start: The script checks FMOD to see what the volume should be and updates the slider visual.
During Gameplay: The slider updates the FMOD bus using the Dynamic Float event.
On Scene Change: Even though the UI destroys and reloads, the Start function runs again, grabs the persistent FMOD volume, and snaps the slider back to the correct position.

Now your audio settings menu is robust and persistent across your entire game!

Creating Audio Zones and Dynamic Mixing with Snapshots

Wed, 12 Jun 2024 00:00:00 +0000

In our previous tutorial, we mastered Playback States to control when sounds play. Now, we’re going to control how they sound based on the game environment.

Have you ever noticed how audio changes when a character walks into a cave (reverb kicks in) or when they are low on health (the sound gets muffled and bass-heavy)? In FMOD, these dynamic mixing changes are handled by Snapshots.

In this guide, we will cover:

What Snapshots are and how to create them.
Creating a Reverb Zone using Triggers.
Handling signal routing (so your UI clicks don’t echo!).
Creating a “Low Health” filter using Parameters.

What is a Snapshot?

Think of a Snapshot as a “preset” for your FMOD Mixer. When active, a Snapshot can change the volume of buses, toggle effects on and off, or change effect parameters.

There are two main types:

Overriding: Forces values to a specific state (good for absolute changes).
Blending: Adds changes on top of existing values (good for layering).

For this tutorial, we will focus on Overriding snapshots to create distinct audio zones.

Part 1: The Reverb Zone (Trigger-Based)

Let’s create a system where entering a tunnel applies reverb to our sound effects.

Step 1: FMOD Setup

Go to the Mixer window in FMOD.
Create a Return Bus for Reverb if you haven’t already, and add a Reverb effect to it.
Go to the Snapshots tab and create a new Overriding Snapshot named “Reverb Zone 1”.
Deselect your snapshot for the time being.
Select the SFX Bus and add a Send to the Reverb Return Bus. Set the send level to around -6dB (adjust to taste).
Scoping: When you select the snapshot, your mixer faders will turn into yellow outlines. This means they are “scoped out” (unaffected).
1. Select the snapshot again. Mixer controls will appear with yellow outlines, meaning they are currently scoped out.
2. Click the reverb send level on the SFX Bus so it becomes fully yellow, indicating it is scoped in and will be driven by the snapshot.
When you select the snapshot, the reverb send will be set to the value defined in the snapshot.
Modulation: To make the reverb fade in smoothly, right-click the Snapshot’s Intensity dial (in the deck area) and add an AHDSR Modulator. This ensures the reverb doesn’t snap on/off instantly.

Step 2: The Unity Script

Open Level 2 in Unity. This scene has more tunnels that we can use for testing reverb.

In Unity, Snapshots are treated almost exactly like Events. We create an instance, play it, and stop it.

Create a cube object with Create > 3D Object > Cube. Scale it to form a tunnel entrance and set its position so the player can walk through it. Make sure to set the cube’s collider to Is Trigger. Call it Reverb Zone. Also make sure the layer is set to Environment.

We’ll leave the Mesh Renderer on so you can see the zone in the scene, but in a real game, you would likely turn this off.

Create a script called F_ReverbZone and attach it to the Reverb Zone object.

using UnityEngine;
using FMODUnity;
using FMOD.Studio;

public class ReverbZone : MonoBehaviour
{
 private EventInstance reverbSnapshot;

 void Start()
 {
 // Create the instance just like a normal event
 // Note: The path starts with "snapshot:/"
 reverbSnapshot = RuntimeManager.CreateInstance("snapshot:/Reverb Zone");
 }

 void OnTriggerEnter(Collider other)
 {
 if (other.CompareTag("Player"))
 {
 reverbSnapshot.start();
 }
 }

 void OnTriggerExit(Collider other)
 {
 if (other.CompareTag("Player"))
 {
 // Allow the AHDSR to fade it out naturally
 reverbSnapshot.stop(STOP_MODE.ALLOWFADEOUT);
 }
 }

 void OnDestroy()
 {
 reverbSnapshot.release();
 }
}

Step 3: Fixing the Signal Path (The UI Echo Problem)

If you test the game now, entering the zone will reverb everything sent to the SFX bus—including your UI menu clicks! That’s not what we want. We need to split the signal.

In the FMOD Mixer:

Delete the send that goes from the SFX bus to the Reverb bus.
Create two new Group Buses under your main SFX bus: call them In-Game and UI.
Route your footsteps, attacks, and environmental sounds into In-Game.
Route your menu sounds into UI.
Place the Reverb Send on the In-Game bus only.

Now, your UI remains crisp and dry, while the game world echoes around you.

Part 2: The Distance-Based Zone (Automation)

Sometimes you don’t want a hard trigger; you want the effect to get stronger as you get closer to a specific object.

FMOD Setup

Create a new snapshot (e.g., “Reverb Zone 2”).
Instead of an AHDSR on the Intensity dial, right-click and Add Automation.
Select the built-in Distance parameter.
Draw a curve:
- At 5 meters, Intensity = 100%
- At 10 meters, Intensity = 0%

Unity Script

Since this relies on distance, we must tell FMOD where the snapshot is located in 3D space.

Create an Empty GameObject called Reverb Zone 2 and position at (-1, -3, 28.5). Create a new script and attach to the gameObject:

void Start()
{
 reverbSnapshot = RuntimeManager.CreateInstance("snapshot:/Reverb Zone 2");
 reverbSnapshot.start(); // Start immediately

 // Attach the instance to this object so FMOD knows its location
 RuntimeManager.AttachInstanceToGameObject(reverbSnapshot, transform, GetComponent<Rigidbody>());
}

void OnDestroy()
{
 reverbSnapshot.stop(STOP_MODE.IMMEDIATE);
 reverbSnapshot.release();
}

Part 3: The “Low Health” Filter (Parameter Control)

A common game mechanic is muffling audio when the player is dying. We can achieve this by controlling a Snapshot via a script parameter.

Step 1: FMOD Setup

Add a 3-EQ Effect to your In-Game bus.
Create a Snapshot called “Low Health”.
Scope in the High and Mid bands of the EQ and turn them all the way down (leaving only low frequencies).
Right-click the Snapshot’s Intensity dial and select Expose as Parameter.
Set the range of the parameter from 1 to 5.
Invert the curve:
- When Parameter = 5 (Full Health), Intensity = 0% (No filter).
- When Parameter = 1 (Low Health), Intensity = 100% (Fully muffled).

Step 2: Linking Health to Audio

In your Player Controller script, you need to update the snapshot whenever health changes.

FMOD.Studio.EventInstance healthFilter;

void Start()
{
 healthFilter = RuntimeManager.CreateInstance("snapshot:/Low Health");
 healthFilter.start();
 healthFilter.release(); // Release immediately so it cleans up when stopped
}

// Call this function whenever the player takes damage or heals
public void SetHealthSnapshot() {
 healthFilter.setParameterByName("Intensity", m_Damageable.currentHitPoints); // currentHealth should be between 1 and 5
}
void OnDestroy()
{
 healthFilter.stop(STOP_MODE.IMMEDIATE);
}

By hooking the UpdateAudioHealth function into your existing damage logic (using Unity Events or direct method calls), your audio will dynamically react to the player’s survival status.

Summary

Snapshots are powerful tools that move beyond simple “Play/Stop” commands. By treating them as Event Instances in code, you can:

Trigger reverb zones using Colliders.
Automate audio changes based on 3D Distance.
Drive mix changes using gameplay variables like Player Health.

With these tools, you’ve now covered the core pillars of FMOD implementation: Events, Parameters, Playback States, and Snapshots.

FMOD Namespaces

Wed, 12 Jun 2024 00:00:00 +0000

Key Concepts

Namespaces group related types in C# and avoid name collisions.
Using directives (using ...;) make types in a namespace available without full qualification.
Unity and FMOD both expose APIs through namespaces that you reference from your scripts.

Recap: Namespaces & Classes in Unity When you create a new Unity script, you’ll see using directives at the top—these specify namespaces. They let you access types from Unity’s API without fully qualifying them. Below that, each script defines a public class that usually inherits from MonoBehaviour, which provides lifecycle methods like Start() and Update(). MonoBehaviour lives in the UnityEngine namespace.

You can view the definition of classes like MonoBehaviour in Visual Studio using “Go To Definition,” which helps to reveal their structure and included namespaces.

Block-scoped and file-scoped namespaces:

// Block-scoped (common in Unity projects)
namespace UnityEngine
{
 public class MonoBehaviour : Behaviour
 {
 // class contents
 }
}

File-scoped (C# 10+):

namespace UnityEngine;

public class MonoBehaviour : Behaviour
{
 // class contents
}

Working with Namespaces

Create a new script in Unity called MyScript.cs to explore namespaces.

If you remove a using directive (for example, using UnityEngine;), references like MonoBehaviour will no longer resolve and you’ll get compiler errors. You can also declare your own namespaces to organize custom scripts.

For example, using a traditional namespace declaration:

namespace MyNamespace {
 public class MyClass { }
}

To use MyClass, either add using MyNamespace; to the top of another script or fully qualify it as MyNamespace.MyClass.

MonoBehaviour derives from the Behaviour class (also in UnityEngine). Use “Go To Definition” in your IDE to trace the inheritance chain and see which namespaces types come from.

FMOD Namespaces in Unity

FMOD commands for game audio, like PlayOneShot, rely on namespaces just like Unity does. Example component:

using FMODUnity;
using UnityEngine;

public class PlayEvent : MonoBehaviour
{
 [SerializeField] private string eventPath; // or use EventReference

 void Start()
 {
 // Positional one-shot
 RuntimeManager.PlayOneShot(eventPath, transform.position);
 // Or, to attach to a GameObject:
 // RuntimeManager.PlayOneShotAttached(eventPath, gameObject);
 }
}

Here:

FMODUnity is the FMOD Unity integration namespace.
RuntimeManager is a class within FMODUnity.
PlayOneShot/PlayOneShotAttached are methods on RuntimeManager.

To see how these work, open the FMOD integration scripts in your project (for example, RuntimeManager.cs) and inspect how namespaces and classes are organized. Declaring using FMODUnity; lets you call RuntimeManager.PlayOneShot(...) without repeatedly writing the full namespace.

Go and find your Unity project’s FMODUnity folder (usually under Assets/Plugins/FMOD/src) to explore the FMOD classes and their namespaces.

Understanding PlayOneShot

Common overloads you’ll use in Unity:

// Positional one‑shot at a world position
RuntimeManager.PlayOneShot(string eventPath, Vector3 position);
RuntimeManager.PlayOneShot(EventReference eventRef, Vector3 position);

// One‑shot attached to and following a GameObject
RuntimeManager.PlayOneShotAttached(string eventPath, GameObject go);
RuntimeManager.PlayOneShotAttached(EventReference eventRef, GameObject go);

Notes:

Fire‑and‑forget: these methods return void. You can’t stop or change parameters afterwards. For control, use FMOD.Studio.EventInstance or a StudioEventEmitter.
Position vs attached: PlayOneShot uses a fixed Vector3 at spawn time; PlayOneShotAttached follows the GameObject’s transform.
EventReference vs string: EventReference is type‑safe and assignable in the Inspector; a string path is quick but error‑prone.

Example using an EventReference field:

using FMODUnity;
using UnityEngine;

public class PlayEventRef : MonoBehaviour
{
 [SerializeField] private EventReference eventRef;

 void Start()
 {
 RuntimeManager.PlayOneShot(eventRef, transform.position);
 // Or follow this GameObject:
 // RuntimeManager.PlayOneShotAttached(eventRef, gameObject);
 }
}

Example: When You Need Control

// For parameter control, don't use PlayOneShot:
var instance = RuntimeManager.CreateInstance("event:/Music/Stinger");
instance.setParameterByName("Intensity", 0.8f);
instance.start();
// ... later, you can modify or stop it ...
instance.release();

Key Takeaway

The GUID overload is the “real” function - the EventReference and string versions are just convenient wrappers that convert their input to GUID and pass it along. This is a common design pattern called the Telescoping Pattern or Overload Chaining.

Bottom line: PlayOneShot functions are perfect for simple one-off sounds that don’t need runtime control.

Event Instances and Nested Namespaces

FMOD exposes nested namespaces, such as FMOD.Studio.EventInstance:

FMOD is a namespace.
Studio is a nested namespace inside FMOD.
EventInstance is a struct inside Studio.

Open up the definition of EventInstance in Visual Studio to see its members and methods. EventInstance is a value type (struct) representing a playable instance of an FMOD event.

Struct: A value type that holds data directly, unlike classes which are reference types.

public struct EventInstance
{
 // Methods and properties for controlling the event instance
 public RESULT start();
 public RESULT stop(STOP_MODE mode);
 public RESULT setParameterByName(string name, float value);
 // ... more members ...
}

See if you can find methods like start(), stop(), and setParameterByName() in the definition.

If you use types from FMOD.Studio, add the appropriate using directives:

using FMOD;
using FMOD.Studio;

Alternatively, fully qualify names (for example, FMOD.Studio.EventInstance).

Streamlining Your Scripts Unity sometimes adds unused namespaces to your scripts by default. Visual Studio will gray out those not needed; clean them up to keep your code clear.

Wrap-Up By understanding and leveraging namespaces you can:

Organize code clearly and avoid name collisions.
Use shorter, clearer code with using directives or fully qualified names when appropriate.
Navigate Unity and FMOD APIs more confidently during audio implementation.

How to Use Playback States to Control Audio Flow

Wed, 12 Jun 2024 00:00:00 +0000

When implementing dynamic audio in Unity using FMOD, you often need to know exactly what an audio event is doing at any given moment. Is it playing? Is it stopping? Has it already stopped?

This is where Playback States come in.

In this tutorial, we will explore what FMOD Playback States are, how to access them in your C# scripts, and how to use them to fix a common audio bug: the “stuttering” sound effect on UI sliders.

What is a Playback State?

A Playback State is a tool from FMOD’s API that allows us to check the status of an Event Instance. It returns the current status of the audio as an Enumerator (Enum).

The five main states returned by the API are:

PLAYING
STARTING
STOPPING
STOPPED
SUSTAINING

By accessing these states, we can write logic that prevents sounds from overlapping or triggering incorrectly.

Part 1: Setting Up the Variable

To use Playback States, you first need to define a variable to store the state information. Open the MusicPlayer script.

Inside your class, declare a variable of type FMOD.Studio.PLAYBACK_STATE:

private FMOD.Studio.PLAYBACK_STATE musicPlayState;

Note: You can omit FMOD.Studio if you are already using that namespace at the top of your script.

Part 2: Retrieving the State

To see what your audio is doing, you need to use the .getPlaybackState() command. This command queries the event instance and outputs the result into the variable we just created.

If you want to track the state in real-time, place this logic in your Update() function:

void Update()
{
 // Assuming '_musicInst' is your FMOD Event Instance
 _musicInst.getPlaybackState(out musicPlayState);

 // Debug to the console to see the state change
 Debug.Log(musicPlayState);
}

How it works:

While Playing: The console will log PLAYING.
Entering a Portal/Stopping: If you trigger a stop command, it switches to STOPPING.
Finished: Once the audio fades out completely, it switches to STOPPED.

Important: getPlaybackState only checks the state on the specific frame it is called. If you only put this in Start(), it will likely only ever say STARTING because it never updates again.

Part 3: A Practical Example (The UI Slider Fix)

One of the most useful applications for Playback States is preventing audio spam.

Imagine you have a volume slider in your Settings menu. You want a sound effect to play when the user moves the slider so they can hear the volume level. However, if you simply tell the sound to Start() every time the slider value changes, the sound will restart every single frame the mouse moves. This creates a messy “machine gun” stuttering effect.

We can use Playback States to ensure the sound only starts if it isn’t already playing.

Step 1: The Setup

In FMOD: Create a 2D Event (e.g., LevelTest) in a “UI” folder.
1. Add some test sounds into a Multi Instrument.
2. Ensure the event is sent to the SFX bus.
In Unity: Open your F_BusControl script.

Step 2: Modify the Script

// ... Your existing using statements ...

public class F_BusControl_class : MonoBehaviour
{
 // .. . Your existing variables ...
 EventInstance levelTestEvent;

 // Start is called once before the first execution of Update after the MonoBehaviour is created
 void Start()
 {
 // ... Your existing bus setup code ...

 // only assign the event if its actually an SFX
 if(busPath == "SFX")
 {
 levelTestEvent = RuntimeManager.CreateInstance("event:/SFX/UI/LevelTest");
 } else
 {
 levelTestEvent.release();
 }
 }

 public void VolumeLevel(float newSliderValue)
 {
 bus.setVolume(newSliderValue);
 levelTestEvent.start();
 }
}

You can hear that the sound stutters when you drag the slider quickly. We need to fix it by telling it to only start if th sound is not already playing.

We can use playback states to fix this issue:

// ... Your existing using statements ...

public class F_BusControl_class : MonoBehaviour
{
 // .. . Your existing variables ...
 EventInstance levelTestEvent;
 PLAYBACK_STATE pbState;

 // Start is called once before the first execution of Update after the MonoBehaviour is created
 void Start()
 {
 // ... Your existing bus setup code ...

 // only assign the event if its actually an SFX
 if(busPath == "SFX")
 {
 levelTestEvent = RuntimeManager.CreateInstance("event:/SFX/UI/LevelTest");
 } else
 {
 levelTestEvent.release();
 }
 }

 public void VolumeLevel(float newSliderValue)
 {
 bus.setVolume(newSliderValue);
 if(busPath == "SFX")
 {
 // Check the playback state before starting the event
 levelTestEvent.getPlaybackState(out pbState);

 if (pbState != PLAYBACK_STATE.PLAYING)
 {
 levelTestEvent.start();
 }
 }
 }
}

Now, when you drag the slider, the sound will play once. It will only play again after the previous instance has finished, resulting in a smooth, non-stuttering audio experience.

Summary

By using Playback States, you gain precise control over when your audio triggers. You are no longer just telling FMOD to “Play”; you are asking FMOD “Are you busy?” and acting accordingly.

This simple check is essential for creating polished UI sounds, managing dynamic music transitions, and ensuring your game’s audio sounds professional and clean.

Interpreting Code: Understanding Game Scripts as an Audio Designer

Wed, 12 Jun 2024 00:00:00 +0000

Interpreting Code: Understanding Game Scripts as an Audio Designer

When designing sound for games, we often spend our time inside FMOD, Wwise, or Unity’s audio windows—triggering events, mixing layers, and crafting dynamic soundscapes. But at some point, we hit a barrier: to make our sounds respond to gameplay, we need to understand the game’s code.

This post walks you through the fundamentals of reading and using existing scripts—without needing to become a full-on programmer. It’s about collaboration, curiosity, and creative problem-solving through code.

General vs. Custom Audio Implementation

Audio in games generally falls into two categories:

General Implementation

These sounds use built-in tools from Unity or FMOD. You don’t need to touch other scripts to make them work. Examples include ambient loops, trigger-based footsteps, or teleport sounds using Unity’s collider system.

Custom Implementation

These sounds rely on code written by developers. They interact with the game’s systems—like dynamic music that changes when the player enters combat or a car engine pitch that follows RPM.

Aspect	General Implementation	Custom Implementation
What it is	Uses built-in tools in Unity or FMOD; no script edits needed	Relies on developer-written code; hooks into gameplay systems
Examples	Ambient loops; trigger-based footsteps; teleport sounds via colliders	Dynamic music reacting to combat; engine pitch following RPM

To handle these, you’ll need to identify where the relevant variables and functions live in code.

Reading Game Code Without Fear

Let’s use Unity’s PlayerController script (from the 3D Game Kit) as an example. Even without programming experience, you can learn a lot by exploring the script methodically.

1. Look at Variable Names

Names like JumpSpeed, Gravity, or m_ReadyToJump tell you their purpose. If a variable is public, you’ll also see it in Unity’s Inspector—meaning you or another script can adjust it at runtime.

In another script attached to Ellen you could have:

public class EllenAudio : MonoBehaviour
{
 // Reference to the PlayerController script
 private PlayerController pc;

 void Start() {
 // Get the PlayerController component
 pc = GetComponent<PlayerController>();
 pc.JumpSpeed = 10.0f; // Example of accessing JumpSpeed variable
 }
}

You might also spot variables like:

bool m_IsGrounded;
bool m_PreviouslyGrounded;

These booleans (true/false variables) control jumping logic. Understanding their behavior helps us know when to trigger audio—like footsteps, landings, or jump sounds.

2. Read the Programmer Notes

Most scripts include comments after //. These notes explain why a line of code exists. For example:

// Whether or not the input state and Ellen are correct to allow jumping

Comments like this tell you the intent behind a variable—perfect clues when you’re connecting audio to gameplay.

3. Trace Variables in Code

In Visual Studio or VS Code, double-click a variable to highlight every place it’s used. Follow it through the script to see where it changes value.

You can also right click and select “Find All References” to see every instance of that variable in the script.

For example, you might find:

void FixedUpdate()
{
 m_PreviouslyGrounded = m_IsGrounded;
 CalculateVerticalMovement();
}

FixedUpdate() runs 50 times per second—ideal for physics checks. Here, the code tracks whether Ellen was on the ground last frame versus is on the ground now. That’s exactly the kind of information you could use for sound triggers.

Debugging to Learn

Debugging isn’t just for programmers—it’s an auditory designer’s microscope. By adding a simple print statement, you can watch how the game behaves in real-time.

Add this line to your script:

Debug.Log("IG: " + m_IsGrounded + " PG: " + m_PreviouslyGrounded);

When you run the game, Unity’s Console will display the variables each frame. Jump, and you’ll see them flip from true to false and back again.

To filter specific moments, use an if statement:

if (m_PreviouslyGrounded != m_IsGrounded)
 Debug.Log("Grounded state changed!");

This reports only when the player leaves or touches the ground—an exact moment you might trigger a landing sound or dust effect.

We could use this information now to play a jump sound when the player leaves the ground and a landing sound when they touch down.

Searching Through Scripts

Large scripts can feel overwhelming. Thankfully, you can search them.

Ctrl+F (Windows) or Cmd+F (Mac) brings up a search bar. Search for a term like die, and you might find a function:

void Die()
{
 // Called when the player loses all health
}

Now you’ve found the perfect place to play a “death cry” sound.

A Custom Audio Example

Once you find the Die() function, adding sound is simple:

FMODUnity.RuntimeManager.PlayOneShotAttached("event:/Player/Death", gameObject);

That single line links FMOD to Unity, playing your event when the player dies. You can test it instantly—jump into the water or get hit by an enemy, and your audio should trigger when the character respawns.

Knowing When to Collaborate

Sometimes you’ll find that the data you need—like enemy states or vehicle speed—comes from complex systems spread across many scripts. When that happens, it’s best to collaborate with the programmers. They can create clean hooks for audio events faster than you can reverse-engineer the code.

However, by understanding the basics, you can communicate clearly:

“I noticed there’s a bool inCombat variable in EnemyAI.cs. Could we use that to switch FMOD music states?”

That kind of precise collaboration makes your work more efficient—and helps the whole team.

Practice: Explore the PlayerController

Here’s your challenge:

Open the PlayerController script.
Find the PlayAudio() function—used to trigger one-shots for footsteps, jumps, and impacts.
See what conditions must be true before it runs.
Use Debug.Log() to print out those variables to the Console.
Try connecting one of them to an FMOD event.

You’ll be surprised how much you already understand—and how quickly “interpreting code” becomes part of your creative toolkit.

Closing Thoughts

Understanding code isn’t about becoming a programmer. It’s about reading the systems behind your sounds, identifying where to connect, and knowing when to collaborate.

By interpreting scripts, you gain control over how your soundscapes react to gameplay—and make your audio as dynamic as the worlds you build.

Attaching Audio to Animations with FMOD and Unity

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

This post walks through a practical pipeline for triggering FMOD sound events from Unity Animation Events so your character’s footsteps, landings, and swishes line up precisely with what’s on screen. We’ll build a reusable C# function that can be called from any Animation Event and, later, accept the FMOD event path as a parameter—setting us up to drive parameters (like surface material) in a follow-up lesson.

What You’ll Build

An FMOD event for a footstep, with a Material parameter that selects between multiple surface types.
A Unity C# function that:
- Creates and attaches an FMOD event instance to the player at runtime,
- Starts the event,
- Releases the instance,
- Accepts a string parameter for the FMOD event path (so you can reuse it across many animations).
Animation Events in Unity that call your C# function exactly when each foot hits the ground.

FMOD Setup: A Single Footstep Event, Many Materials

Create a 3D event named Ellen_Run in the SFX/Ellen folder that plays one footstep per trigger.

Add a user parameter named Material and set it to Hold (so the footstep that already triggered won’t switch mid-play if the parameter changes). Add four values representing different surface types:

Earth
Stone
Puddle
Grass

Set the parameter to Hold during playback to allow the current footstep to complete even if the player moves to a different surface.

Add a Multi Instrument (right-click, then Add Multi Instrument) for each material value and add the appropriate footstep samples for that surface. Enable Shuffle in the Multi Instrument settings to randomize footstep playback.

Now, when you select different values for the Material parameter, you’ll hear footsteps on different surfaces.

Save your project and build your banks before switching back to Unity.

Unity Project Setup

Create a script named F_Player and add it to your player (Ellen) GameObject. This script will own all player-related SFX behaviors.

The Reusable One-Shot Function

We’ll implement a “play one-shot with control” pattern: create an instance, attach it to the player, start it, and release it—while still allowing parameter control if we need it later.

Here’s a simple implementation using a new PlayRunEvent function. We use a public function so that Unity Animation Events can call it directly. For now we hardcode the event path; in the next section we’ll update the function to accept a string parameter so different animations can play different events.

 public void PlayRunEvent()
 {
 EventInstance run = RuntimeManager.CreateInstance("event:/SFX/Ellen/Ellen_Run");
 RuntimeManager.AttachInstanceToGameObject(run, gameObject, GetComponent<Rigidbody>());
 run.start();
 run.release();
 }

Why this approach instead of RuntimeManager.PlayOneShot(...)?

It gives you full control over parameters (e.g., Material) per trigger.
It’s easy to reuse: different animations can pass different event paths into the same function.

Hooking Up Unity Animation Events

Animation Events in Unity let an animation call your function at a specific frame. For footsteps, add an event exactly when each foot contacts the ground.

Locate Ellen’s run animations in the Project window:
- 3DGameKit/Art/Animations/AnimationClips/Characters/Ellen/
- Expand the Ellen Run Forward FBX to see its clips (forward, diagonal, etc.).
Preview the clip in the Inspector. If you see “No model is available for preview,” drag the Ellen model into the preview window from Art/Models/Characters/Ellen.
Find the Ellen_Run_Forward clip and click it to open the Animation tab. Click Edit to unlock it for modification.
Open the Events tab on the animation.
Scrub the timeline to the exact frame the foot contacts the ground.
Click Add Event. In the Function field, enter PlayRunEvent.
Add a second event for the other foot.
Click Apply to save the clip modifications.
Play the scene and run forward; you should hear a footstep on each contact.

Important: The script containing the target function must live on the same GameObject that plays the animation via an Animator. Otherwise, the Animation Event won’t be able to find your function.

Add the Event Path Parameter

Now that the events are triggering, let’s pass the FMOD event path as a string parameter so we can reuse this function for other animations (like landing or attacking) later.

Edit your F_Player script to update PlayRunEvent to accept a string parameter for the event path, as shown below.

 public void PlayRunEvent(string eventPath)
 {
 EventInstance run = RuntimeManager.CreateInstance(eventPath);
 RuntimeManager.AttachInstanceToGameObject(run, gameObject, GetComponent<Rigidbody>());
 run.start();
 run.release();
 }

In your Animation Events, update each event to pass the event path string: event:/SFX/Ellen/Ellen_Run (or whatever your event path is).

Understanding C# Parameters

We defined PlayRunEvent(string eventPath) so each animation can pass its own FMOD event path. This is a value parameter: the Animation Event provides a string, Unity passes it into your function at call time, and you use that to create the event instance.

This pattern scales nicely:

Walk clip → event:/SFX/Ellen/Ellen_Walk
Land clip → event:/SFX/Ellen/Ellen_Land
Attack clip → event:/SFX/Ellen/Ellen_Slash

You keep one function and let animations decide which event to play.

Common Pitfalls

The function name in Animation Events must match exactly, including case.
The script with PlayRunEvent must be on the animated GameObject (the same one with the Animator).
Don’t forget to click Apply after editing Animation Events; missed applies are a classic time sink.
Always call release() after start(); this defers cleanup until playback ends.
If your footstep feels off by a few frames, adjust the event position slightly in the animation timeline—what looks like “contact” in the mesh may need a tiny lead or lag to feel right in-game.

Helpful Links

More complete version with error checking and parameterization:

using UnityEngine;
using FMODUnity; // FMOD Unity integration
using FMOD.Studio; // FMOD Studio API

// by including these namespaces, we can use FMOD types directly

public class F_Player : MonoBehaviour
{
 // Optional: cache components you’ll likely need
 private Rigidbody _rb;

 void Awake()
 {
 _rb = GetComponent<Rigidbody>();
 }

 // Called by Unity Animation Events. Pass an FMOD event path, e.g. "event:/SFX/Ellen/Ellen_Run"
 public void PlayRunEvent(string eventPath)
 {
 if (string.IsNullOrEmpty(eventPath))
 {
 Debug.LogWarning("PlayRunEvent called without a valid FMOD event path.");
 return;
 }

 EventInstance run = RuntimeManager.CreateInstance(eventPath);

 // Attach to this GameObject so the sound follows the player and 3D attenuation works as expected
 RuntimeManager.AttachInstanceToGameObject(run, gameObject, _rb);

 run.start();
 run.release(); // Safe: schedules the instance for cleanup after playback finishes
 }
}

FMOD on DAD 424 Sound Design for Games

Building Dynamic Footstep Sounds in Unity with FMOD and Raycasting

Introduction

Recap: Where We Left Off

Step 1: Setting Up Tags in Unity

Step 2: Script Framework

Step 3: Raycasting to Detect Surfaces

Step 4: Visualize the Ray

Step 5: Tags → Enum Mapping

Step 6: FMOD Parameter Setup

Step 7: Full Script

Driving FMOD Parameters from Unity: Teleport Sound Example

Introduction

FMOD Setup

Goal

1. Create the Event

2. Loop Region and Asynchronous Playback

Async

Loop While Playing

Cut

3. Add and Automate the Distance Parameter

4. Create the Custom Trigger Parameter

5. Fine-Tune Spatialization

6. Save and Build

7. Test in FMOD Before Unity

Unity Scene Setup

C# Script: F_Teleporter.cs

Key Points

Testing & Debugging

Simplifying Sound Playback in Unity with FMOD’s PlayOneShot Command

Introduction

What Is PlayOneShot?

Setting Up the Event in FMOD

Using Triggers in Unity

Writing the Trigger Script

Understanding Vectors in Unity

Layers and Collision Setup

Using PlayOneShotAttached

Limitations and Next Steps

Conclusion

Challenge 3: Health Crate Audio

Overview

Objectives

Criteria (12 Points Total)

Hints & Resources

Deliverables

Reflection Prompt

Controlling Audio From Multiple Scripts

Overview

Learning goals

What you’ll build

Static Vs Non-Static Variables Refresher

Example: Player Score

How this works

Why it matters

Approach 1: Instance-based control (non-static)

MusicPlayer.cs

F_Teleporter.cs (fade music on trigger)

Approach 2: Class-wide control (static)

MusicScript.cs

F_Teleporter.cs (fade music on trigger)

When to use which

Troubleshooting checklist

Clean-up and lifecycle tips

Quick reference

Controlling FMOD Busses with Unity Sliders (Part 2)

Part 1: Setting the Volume

The Code

Understanding FMOD Volume Floats

Part 2: Connecting the UI Slider

Part 3: The “Scene Reset” Problem

Part 4: syncing Sliders with .getVolume()

The Challenge with .getVolume()

The Solution

Summary

Creating Audio Zones and Dynamic Mixing with Snapshots

What is a Snapshot?

Part 1: The Reverb Zone (Trigger-Based)

Step 1: FMOD Setup

Step 2: The Unity Script

C# Script: `F_Teleporter.cs`

Part 4: syncing Sliders with `.getVolume()`

The Challenge with `.getVolume()`