Skip to end of metadata
Go to start of metadata


The FMOD Designer gives sound designers an enormous amount of freedom and hides all of the small details from game programmers and level designers.


The FMOD Designer defines most sound properties internally to prevent them being hidden deep all over the game code. Additionally it supports sound designers, to create behaviors for a sound event and enables programmers to exploit the designed content at run time.

As an example, imagine an helicopter which seamlessly changes it's sound from a muffled flup-flup to a high intense engine sound depending on it's distance. If you shoot it with a gun it will add grinding and crackling sounds depending on the damage parameter.

If it lands the engine automatically slows down because the RPM value gets lowered.

In this picture you can see the distance parameter, actively controlling cross fading of the near and far sounds.

In this picture the damage parameter is visible. It fades in some sound, if the damage is greater than 50%.

For Game Programmers

Sounds can easily be pre-cached or played from a LUA script by either addressing sound files directly or following a naming convention to address events in object space.

The latter is a combination of the project name (red), sound group and sub group names (blue) and event name (green), separated by colons, as shown in the examples below:

  • /sounds/ footsteps : metal : walk
  • /sounds/ weapons : scar/silenced : fire
  • /sounds/ vehicle : truck : engine

Wave file can be play for fast prototyping, but should not end up in the game unless they are marked as being a voice line and known to the Localization Manager:

  • /sounds/ player / zipper.wav

The internal FMOD project name, the project file name, and the folder name it is in have to be equal!

More important than simply playing an event, is to trigger its behavior correctly. With the SoundID provided by function Sound.Play() you can call function SetParameter() to change parameters. If an addressed event has stopped playing or was unloaded function SetParameter() will fail. In most cases all important properties like loop-mode or the relative flag are known to the system already, so they do not need to be set up by the script.

If a sound shall be started with a parameter value which is not zero (like pitch or damage), it may be created using the SoundSystem interface, then the correct values can be set, and finally the sound can be played or passed to an entity's SoundProxy to start the sound. This will prevent any audio glitches on wrong parameter values on startup.

LUA functions


Sound.Play(eventname, position, flags)

Returns SoundID.


Returns bool success.

SetParameter(soundid, parametername, value)

Return bool success.

For Level Designers

Use the SoundBrowser to find the right sound you want to use. It can be opened by the Sandbox main menu entry Sound or is used anytime you click on a sound name field.

In the first view there are all available sound events listed. By clicking Browse all of the sound files can be navigated through.

For Sound Designers

The main tool sound designers will work with is the FMOD Designer. There are some rules which need to be followed when creating new projects and sound events:

  • The Project file name, the internal FMOD project name, and the folder this file is stored in, have to be equal.
  • If there is only one event group in your project you should call it the same as the whole project.
  • Set maximum spawn sounds in the sound definition to a correct value.
  • Set max playbacks in the event definition to a correct value.
  • Specify correct 2D/3D settings in the event definition.
  • Verify only relative filenames are used in the sound definitions.
  • Verify a correct build process by deleting all .fsb and .fev files in the current folder.
  • Activate export of the Programmer Report in the build dialog window.

For Sound Programmers

Pre-caching of sounds and buffers which are used to create an event will be possible with setting a flag at calling GetGroup(). The pointer to the group an event is located in, is stored in the corresponding sound-buffer. The pointer to the instance of an event is stored in the platform-sound. The sound-buffer name is built from project and group name. The event name is stored in the platform sound. If the sound-buffer is not used and the event group gets released, all instances of event will be removed by FMOD-EX, so all sounds are informed that their asset was unloaded.



A Parameter describes a special input variable of a sound event. This can be distance, pitch, damage, alertness, heat, rounds-per-minute (RPM), speed in m/s, or any other abstract attribute.

Parameter value

The numerical value of a parameter.

Parameter range

The min/max value of the parameter value.


A semantical value of a sound, like priority.

Sound event

This is a special sound with properties and parameters attached to it. It can be played and manipulated.

Event group

Several events are organized in groups.

Project file

Several event groups are stored in a project file (Extension: .fdp). These files need to be checked out to change an event which is stored in that project.
So the amount of event groups within one project files needs to be reasonable. When a project gets built it will create an event file and wavebanks.

Event file

This file is used by the sound system to access the events (Extension: .fev). Access can be restricted by encryption.


The sound data of several sound files are stored in a streamable wavebank (Extension: .fsb).

File Extensions




Project file


Event file


Sound bank



  • No labels