Audio Implementation on DAD 424 Sound Design for Games

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.