Game Audio 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.

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.

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
 }
}

Game Audio 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

FMOD Namespaces

Key Concepts

Working with Namespaces

FMOD Namespaces in Unity

Understanding PlayOneShot

Example: When You Need Control

Key Takeaway

Event Instances and Nested Namespaces

Interpreting Code: Understanding Game Scripts as an Audio Designer

Interpreting Code: Understanding Game Scripts as an Audio Designer

General vs. Custom Audio Implementation

General Implementation

Custom Implementation

Reading Game Code Without Fear

1. Look at Variable Names

C# Script: `F_Teleporter.cs`