How to create a Scatterer Instrument in Wwise

/

When users migrate from FMOD to Wwise, the scatterer instrument is usually one of the most missed features. Let’s see how we can recreate its behaviour within Wwise but first, a quick overview at the instrument in FMOD (skip if you want).

FMOD’s Scatterer Instrument

This instrument essentially provides us with two handy features. On one hand, we can control how often sounds from a playlist will be triggered. This can be based on regular time or on musical tempo. On the other hand, we can also control the positioning each sound instance.

Spawning

We can control the spawn interval with a min and max spawn interval value. Additionally, we also have a spawn rate knob which is very handy if we want to automate the spawning rate with a game parameter. For example, we could have a scatterer instrument for birds chirping and the spawning rate is reduced as the weather gets worse.

Something to always keep in mind with spawning is that each element in our playlist will use a voice. A fast spawning rate plus a high polyphony can result in a lot of voices, specially if you have several scatterer instruments so keep in them in check if you have a limited voice budget which is usually the case for mobile or portable VR.

In world 3D vs full 2D

If you have a min/max distance that is not 0, FMOD will play the sounds around the emitter in a random position between the two values. Note that this positions are “in world”, as if they had they own emitters in the game world. This is very nice for things like birds around a tree or water splashes in a lake.

Now, keep in mind that even if you don’t have a spatializer on your event, having a non 0 min and max distance on a scatterer instrument will effectively make that event 3D. This is important to remember if (like me) you are playing your events through custom code and have checks for 2D/3D.

A different use case for a scatterer instrument is: what if we just want to play sounds around the listener in a “non in world”, 2D way? To do this, you would need to firstly not have a spatializer on the event which is probably already the case, if you were just creating a 2D ambience. Then, you need to set the min and max distance to 0. This will result in all sounds having the same volume and pan but that can be easily fixed by just randomizing this values. In fact, the scatterer instrument already has a “Vol Rnd” knob that you can use for this.. To change the panorama, you will need an extra effect on the track or you can also randomize the event panner if you want to affect everything at once.

Recreating voice spawning in Wwise

Firstly, we need to create a random container with all the Sound SFXs or other containers that we want to use. By default, a random container just plays one of its items following whatever randomization settings you have. So each time an event tries to play the container, we would just get one sound or voice. We can change this by changing the Play Mode from “Step” to “Continuous”. Now our container will try to play the complete list of objects we have. We can then make this loop so we cycle randomly through the list without ever stopping.

To control how often the sounds play, activate “Transitions” and choose “Trigger rate”. This allow us to control how often sounds are spawned in a similar way as in FMOD. You may want to randomize the duration value so sounds don’t play at a predictable rate.

On the example above, you can see that sounds will spawn at a rate between 0.5 and 2 seconds. We now have an easy way to control how often we spawn sounds. Of course, we would need to probably create an stopping event if we want to stop our sounds spawning at some point. Now we just need to figure out how to play these sounds around the game world.

Managing 2D/3D positioning in Wwise

In the positioning tab, under the 3D position section, we can find three different modes:

  • Emitter: This will make the position always the same (the position from which we have played the event). Use this if you don’t want any movement at all.

  • Emitter with Automation: This will take this same emitter position and add some movement that we can control. Use this if you want the sounds to be played in world, around the emitter. This will use whatever attenuation values you have set. You can even set paths with movement (think birds flying around). This will achieve the same effect as playing an FMOD 3D event with an scatterer instrument with a non 0 min and max distance.

  • Listener with Automation: Same as above but the sounds play around the listener. Make sure to tick “Hold Listener Orientation” if you want the sound to be completely 2D and thus independent on the listener movement. This means the sounds won’t feel like they come from an specific point in the world but a predetermined position in the panorama. Your attenuation settings will be respected though. Use this for purely 2D ambiences. This will be same effect as an FMOD scatterer instrument with 0 min and max distance and no spatializer.

When setting the 3D position automation, make sure you choose “Step“ so each time a sound spawns, a different path is chosen. You can also use “Random” if you want the position to change in a non predictable way.

In conclusion

After using both middleware I went from “is a shame Wwise doesn’t have a scatterer instrument kind of container” to “Wwise can re-create all the scatterer behaviour and even make it better!” so there’s that. Let me know how it works for you and if you find any issues yourself.

Differences between FMOD & Wwise: Part 1

/

After working with FMOD everyday for a couple of years, I started a new job where we are using Wwise. This change give me the chance to think about the differences between the two.

Let me be clear, I don’t particularly advocate for either of them but it is interesting to think about their different concepts and workflow. You can also consider these notes a companion if you are migrating from FMOD to Wwise like I did.

Event Workflow: separating content and action

Events are the minimal functional unit for playing audio. This is is a concept that is shared by both softwares but the workflow is quite different.

On FMOD, events are self-contained in the sense that the event itself has a timeline where you can add any audio that you want. I think this is more straightforward and DAWish which is very novice friendly. You also have an audio bin where all your audio assets sit, ready to be added to events. All the rules that determine how audio will play at runtime can also be found on each event, on the Event Macros section. Have a look at this article if you want to know how these work.

An FMOD event allows you to clearly set different tracks, parameters and plugins to affect the sound during gameplay.
You also set the general event behaviour in terms of 3D positioning, envelopes and parameters.

Wwise does this very differently, which might be confusing at first. To start with, there is no audio bin per se, but we use a “Sound SFX”. These don’t represent a single audio file necessarily, but a “channel” that plays audio. But don’t really think about Sound SFXs as channels in the sense of a mixing desk or DAW, they are more like containers with a set of rules to describe how to play audio. So things like pitch, volume, looping or insert effects live on Sound SFXs on Wwise. On FMOD, these would live on each track within an event. But Wwise Sound SFXs also contain things like positioning settings which in the case of FMOD live on the event level.

A Sound SFX feels like a weird concept at the start but it makes sense if you think about it as a “behaviour container” for audio.

But if we want to play audio from our game with Wwise, Sound SFXs are not the thing we need to call. We need to create an event which in turn can play our Sound SFX. In other words, Wwise separates content and action, while FMOD keeps them together. Is one better than the other? I don’t think so, they are just different approaches to solve the same problem and you just need to get used to each way of them.

Actor-Mixers that don’t mix but kinda

These guys are also a bit weird, specially at first. Despite their name, they are NOT the main way you want to mix your game. Actor-Mixers don’t act as a bus for all the Sound SFXs that they contain, so their audio signals are not really combined at this level. That happens on buses and auxiliars on the Master-Mixer Hierarchy, which are the best option for actually mixing your game.

So Actor-Mixers act as a yet another container, they are useful for setting effects, positioning or parameter curves for a bunch of Sound SFXs at the same time. Remember when I said Sound SFXs were behaviour containers? Well Actor-Mixers are kind of the same thing, they are basically a group of Sound SFXs that share the same behaviour.

Actor-Mixers can be confusing. They have “mixer” in their name, they have faders in their icon… but they don’t actually bus any audio. They just dictate behaviour. Not very intuitive.

Grouping SFXs like this is useful if you want to tweak things in the same way for a bunch of Sound SFXs and also if maybe you want to do general mix tweaks but they are probably not the best option for most mixing work, particularly dynamic mixing based on states.

Is hard to find an equivalent on FMOD to the Actor-Mixer, the closest thing could be a mix between VCAs and effect chain presets but it is fundamentally a very different way to organize things.

Game Calls: a radical difference in philosophy

This illustrates yet again the difference in approach on each middleware. Is going to sound odd but bare with me.

So Wwise uses this concept of “Game Calls” which are basically orders that the game sends to Wwise. These usually match event names like for example “Play_Jump” or “Stop_MainMusic” but if you think about it, game calls are in reality generic and ambiguous in the sense that they don’t have to do what their names suggests.

So an approach that maybe makes more sense with Wwise is to give game calls names like “Protagonist_Jump”. We know that the character jumped so now is our job to decide what audio should do to reflect that action. Usually, this means playing a Sound SFX but it could also mean stopping or pausing other Sound SFX, maybe even changing some other audio’s settings. This philosophy gives you more flexibility but it takes a bit to wrap your head around it. That’s why, when you set up a Wwise event, you can do all sorts of actions in there, although 90% of the time, you probably just want to play or stop audio.

Events offer many types of actions. For me, it helps to think about events not as a “Play this audio” order but as a “Something happened” piece of information. Our job as sound designers is to decide what to do with this information.

Contrast this with FMOD, where the game engine is always explicit in how it sends orders. When using the FMOD API, we directly and explicitly say “play this event” or “stop that event” so, for the most part, there is no room to do anything else, although you can break this workflow a bit by using command instruments.

This difference in philosophy is something that I don’t usually hear people talking about. Is subtle but I think is one of the keys to understand how Wwise and FMOD do things differently. The net result is that Wwise keeps a bit more logic control on the middleware side but pays the price of being a bit more confusing. FMOD, on the other hand, is more straightforward but more control resides on the game engine side since the calls are always specific. To summarize this point:

Wwise: Game calls are ambiguous, not necessarily tied to an specific action like playing audio.

FMOD: Game calls are unambiguous and very specific: tied to an specific event and action.

Work Units & Source Control

On Wwise, everything resides on a container called “Work Unit” from Sound SFXs to events and parameters. YES, another container! This is a bit weird, since it feels like the type of thing that is not usually user facing but an internal system to organize files. Work Units are really .xml files which is funny because FMOD also uses this format but the files are not as visible to the user.

The idea is to organize things in these different containers, so different people can work on the same project. They won’t conflict as long as they work on different units.

This makes a lot of sense until you realize that FMOD doesn’t have anything similar to this and it works nicely anyway when sharing a project with others, at least in my experience. I have used SVN source control, not even the official implementation that FMOD has (this gave me issues), just plain sharing the FMOD project files with SVN. You won’t conflict as long as you don’t work on the same event or mixer bus so FMOD is actually more granular than a work unit, is like each element is its own working unit!

Containers vs instruments

Wwise containers work in a kind of similar way to FMOD instruments. Roughly, you can make the following comparisons:

Wwise FMOD Notes
Sound SFX Single Instrument They work in the same way.
Random Container Multi Instrument Similar randomization options.
Sequence Container -- FMOD allows this by allowing many instruments on an event. Is probably easier to setup too.
Switch Container -- Om FMOD, you woud just use a parameter sheet or trigger conditions on instruments.
Blend Container -- FMOD does this natively on its timeline since you can crossfade instruments based on time or parameter values.
-- Event Instrument Wwise doesn't allow nested events in the same way as FMOD does but you have more flexible event actions.
-- Scatterer Instrument Can be recreated in Wwise!
-- Programmer Instrument Nothing like this on Wwise, but there is no need since game calls are ambiguous.
-- Command Instrument Same as above.
-- Snapshot Instrument On Wwise, you can always trigger states from an event an achieve the same result.

So as you can see, between Wwise and FMOD, there is no perfect option. I particularly miss the scatterer instrument in Wwise but is true that it has its limits and annoying things in FMOD anyway. For example, the fact that it always plays a sound the first time you enter the instrument, without respecting the spawning time.

On the other hand, on Wwise, you don’t have these specific instruments like the programmer or command instruments but there is no need really, since you can add as many actions as you want to an event.

I just think you need to get used to the differences and learn to think in a different way for each piece of software. Advantages and disadvantages on both sides for sure. In engineering, every decision is a trade off.

More thoughts coming on part 2!

Tutorial Wwise en Español - Parte I: Introducción

/

Note for my english readers: Sorry this article is not in your language but I wanted to write something for the spanish speaking community since there aren’t many resources on game audio in my native tongue. If I see that there is demand, I would be happy to translate this into english although most of the content can be found in Audiokinetic’s official resources.

Dada la falta de recursos en castellano para aprender sonido para videojuegos de una forma práctica, me he decidido a escribir este tutorial como forma de iniciación en este, algo misterioso, mundo.

Voy a tratar de explicar algunos de los conceptos básicos que son necesarios para entender como funciona esta disciplina. He decidido mencionar y nombrar los conceptos clave en inglés por que así creo que te será mas fácil familiarizarte con la jerga del sector además de permitirte poder buscar ayuda online utilizando los términos en su idioma original.

Utilizaré Wwise, posiblemente el motor de audio más utilizado en la industria, pero ten en cuenta que estas ideas y prácticas se pueden aplicar, con ciertas modificaciones conceptuales, a otros software también.

Preámbulo sobre Diseño Interactivo

Antes de entra en harina, quería comentar que si hasta ahora solo has trabajado en disciplinas sonoras lineales como producción, mezcla musical o sonido para cine, hay ciertas consideraciones que debes tener en cuenta a la hora de trasladar tu trabajo a un medio interactivo como son los videojuegos.

Es imposible predecir como cada jugador va a comportarse por lo que el diseño de sonido y la mezcla debe considerar todas las posibles relaciones entre los elementos sonoros del proyecto. En comparación, un mezcla para un medio como cine es lineal y estática, luego una vez mezclada la película, esta siempre va a sonar igual, asumiendo que el medio de reproducción es medianamente fiel.

En contrapartida, los juegos son mas impredecibles y ningún jugador va a interactuar con el entorno de la misma manera por lo que el diseñador de sonido deberá implementar sistemas que ayuden a que la mezcla final provea la información mas relevante posible, manteniendo a la vez la estética y estilo que queremos transmitir.

Un ejemplo de esos sistema es el manejo de prioridades. Veremos ver cómo es posible dar prioridad a ciertos sonidos por encima de otros para asegurarnos de que los elementos más importantes, como diálogos, música o las acciones del protagonista nunca queden ahogados en la mezcla por sonidos del entorno que quizás no son tan relevantes.

Otra consideración a tener en cuenta es el manejo de la repetición. Si una acción es muy común en un juego, como por ejemplo saltar, y tiene un sonido asociado, el jugador va a escuchar este sonido cientos de veces. Veremos que métodos y estrategias podemos implementar para añadir mas variación y diversidad a sonidos frecuentes incluso aunque contemos con pocos sonidos a nuestra disposición.

Por último, un diseñador de sonido para juegos también debe tener siempre presente que cuenta con un número finito de recursos para realizar su trabajo. Debemos asegurarnos que tanto a nivel de memoria como de CPU no nos excedemos del “presupuesto” que se nos concede ya que la mayor parte de los recursos suelen ser destinados para el apartado gráfico.

Middleware

Este es el nombre que recibe el tipo de software que va a hacer de puente entre nuestros sonidos y el propio motor del juego. Wwise es el que voy a usar en este tutorial pero hay muchos otros que también son utilizados en la industria como por ejemplo Fmod o Fabric. Conocer uno de ellos te va a ayudar mucho a familiarizarte con los demás, puesto que trabajan con conceptos similares, aunque ten en cuenta que a veces resuelven el mismo problema de formas muy diferentes.

Estos middleware se pueden integrar en motores conocidos como Unity, Unreal o Source e incluso pueden funcionar junto a cualquier otro software o incluso hardware (¡como en coches!), siempre y cuando se utilice la sintaxis de programación adecuada. Por otro lado, los motores de juego mas grandes (Unity, Unreal, etc) tienen sus propias herramientas de audio que actúan en realidad como un middleware integrado por lo que a veces no utilizan Wwise o Fmod. Todo depende de las necesidades del proyecto y las preferencias del equipo.

En lo que a nosotros respecta, vamos a ver como usar Wwise en general, sin concretar como interactúa con ningún motor en particular. Una gran ventaja de usar Wwise, en vez de las herramientas de audio propias de un motor, es que como diseñador tendrás mas independencia a la hora de diseñar e integrar sonidos sin necesidad de que la persona encargada de la programación tenga que ayudarte con cada cambio que hagas.

Aprender las funciones y conceptos básicos de Wwise te va ayudar a comprender un poco mejor cómo funciona el audio para videojuegos y de paso te dará los conocimientos necesarios para en el futuro saltar a otro middleware con más facilidad, de la misma forma que, por ejemplo, aprender Pro Tools te ayudaría a usar Nuendo.

Descarga, Instalación y Materiales

Vamos al turrón, pues.

Veo imprescindible que pongas las manos en la masa y a medida que explique distintos conceptos puedas ir poniéndolos en practica en tu propio proyecto de Wwise. Para ello, vas a necesitar descargar todo el software necesario.

Ve a la pagina oficial de Wwise y debes descargar el launcher con el que podrás administrar todas las distintas versiones y materiales.

Una vez en el launcher, debes instalar la última version de Wwise (latest) e incluir también los elementos que ves en la imagen inferior. Dentro de Samples, veras LIMBO y Cube, estos son dos juegos que podrás usar para poner tus propios sonidos y aprender como Wwise interactúa con un juego real. Por otro lado, a la derecha verás que puedes elegir distintas plataformas que Wwise tendrá en cuenta cuando prepare los archivos de audio para el juego. En principio, elige tu propia plataforma (Windows o Mac) o ambas incluso si quieres.

Para que te sirva de referencia, este tutorial ha sido realizado en la version 2019.1.4.7065. Si estás leyendo esto en algún punto en el futuro, posiblemente tu versión será más avanzada pero la mayoría de cosas deberían ser razonablemente iguales.

Hay algo más que vas a necesitar. Wwise ofrece un curso de introduccion oficial que es gratuito y en el que se incluyen varios ejercicios. Desgraciadamente, este curso no existe en castellano, pero vamos a utilizar algunos de los recursos que el proyecto ofrece para poder poner en practica este tutorial y de hecho estoy basando esta primera parte en gran medida en la primera lección de ese curso. Puedes descargar los materiales aquí. Una vez descargado estos archivos, debes moverlos al mismo directorio donde reside Cube, el primer juego que vamos a utilizar como ejemplo. La ruta sería:

  • Windows: Program Files (x86)/Audiokinetic/Wwise 20xx.x.x.xxxx/Cube

  • Mac: Applications/Audiokinetic/Wwise 20xx.x.x.xxxx /Cube

Por cierto, si te ves con el inglés necesario para hacer el curso oficial, creo que es la mejor introducción que puedes darle a Wwise y lo considero mas completo y exhaustivo que el mío. Si en cambio prefieres una introducción en castellano, sigue leyendo y quizás después te animes a saltar a la version oficial.

Si ya tienes todo descargado e instalado, estás listo para abrir Wwise por primera vez.

Primera toma de contacto con Wwise

Ejecuta tu versión de Wwise desde el propio launcher.

Nada mas abrirse, veras el Project Launcher que suele contener los proyectos que has abierto recientemente y en tu caso estará seguramente en blanco. Empieza por crear un nuevo proyecto en blanco (New…) y guárdalo en el mismo directorio donde guardaste los archivos de Cube, pero en este caso en la carpeta de la lección 1.

Puedes llamar al proyecto como quieras pero es importante que lo guardes en este lugar para poder luego conectar nuestro trabajo con el juego más fácilmente. Verás también que hay una sección llamada “Platforms“, asegúrate de añadir tu plataforma (Windows o Mac) si esta no aparece ya.

Una vez listo, y tras un aviso sobre licencias que por ahora no nos interesa, nos encontraremos con un proyecto de Wwise vacío.

No dejes que tanto panel te intimide, vamos a ir viendo cómo funciona cada cosa poco a poco. Por ahora, fíjate que si vas a la carpeta donde has creado el proyecto, verás que contiene un archivo con extension .wproj ademas de un montón de carpetas. Este sistema de carpetas es cómo Wwise organiza todos los elementos necesarios para hacer funcionar al sonido de un juego y son imprescindibles para que el archivo de proyecto .wproj funcione. Es algo parecido a las sesiones de Pro Tools o Cubase, necesitas tanto el propio archivo de proyecto como todas las carpetas asociada a él.

Project Explorer

Wwise divide su interfaz en “views“ que son cada uno de los paneles que puedes ver y que tienen un botón de cerrar, otro de ayuda más algunos extra para otras funciones dependiendo de que view se trate. Vamos a fijarnos un momento en la view “Project Explorer” que es la que puedes ver en la parte superior izquierda de tú proyecto..

Wwise tiene una forma curiosa de organizar la información, bastante diferente a otros programas de audio que quizás has usado hasta ahora. Cada una de las pestañas que ves en esta view contiene diferentes tipos de objetos, que se van usar más tarde para determinar el comportamiento del sonido en el juego. Puedes ver a estos objetos como la unidad funcional mínima en Wwise. Vamos a ver brevemente qué tipo de objetos se alojan en cada pestaña, aunque más tarde los veremos en más profundidad:

  • Audio: Esta pestaña es la única que va realmente a conectarse con los archivos de audio de nuestro proyecto. También podemos crear aquí buses de una forma similar a cómo se hace en un DAW.

  • Events: Aquí estarán alojados los objetos que recibirán información desde el juego de forma que podamos lanzar los sonidos que sean necesarios en los momentos idóneos.

  • SoundBanks: Estos son los archivos finales que van recopilar toda la información que permitirá al juego tener sonido. Contendrán tanto los sonidos en sí mismos como todas las instrucciones y programación para que se comporten de la forma que nosotros hayamos diseñado.

  • Game Syncs: Aquí se van a alojar todos los objetos que recogerán las instrucciones que vienen del juego pero no son necesariamente eventos que disparan sonidos, sino variables y estados que nos darán información como la salud del personaje, si está en un mapa u otro o en qué tipo de material está caminando el personaje.

  • ShareSets: Esta sección alberga los diferentes efectos, curvas de atenuación y otros elementos software que el juego va a utilizar. Como el nombre indica, “Share”, estos elementos son compartidos entre los distintos eventos que diseñemos.

  • Sessions: Podemos encontrar aquí distintas sesiones que nos facilitaran mezclar los distintos elementos sonoros del juego de una manera cómoda sin necesidad de jugar.

  • Queries: Por último, esta sección te permite crear búsquedas dinámicas y personalizadas para encontrar distintos elementos en tu proyecto, lo cual es muy útil cuando este empiece a crecer de tamaño.

Cómo puedes ver, todas las pestañas comparten una estructura similar. Hay distintas carpetas conteniendo categorías de elementos y luego cada elemento en particular esta siempre contenido dentro de una “Work Unit”. Estos archivos son los que van contener toda la información que luego el juego leerá para entender cómo debe manejar el sonido. Se trata de archivos tipo XML y fíjate que si vueles a tú explorador de archivos y miras la estructura de carpetas de tu proyecto, veras algo similar a lo que aparece en el Project Explorer.

No te preocupes si no entiendes todos los objetos que aparecen en el Project Explorer, iremos viendo cuando se usan y por qué poco a poco. Aunque ya mismo podríamos empezar a importar sonidos a Wwise, esto no tiene mucho sentido sin un juego al que poder conectarlos. Vamos a ver cómo podemos hacer esto primero.

Usando Cube

Este juego tipo Quake nos va a servir para poner en práctica todos los conceptos que vamos a ir aprendiendo. Para abrirlo, ve al launcher y en la sección de Samples, elige Wwise. Debajo, verás listado Cube y sólo tienes que hacer click en “Run Cube“ para iniciarlo.

Juega un poco para familiarizarte con el entorno y los sonidos, si te aparece un aviso de tu cortafuegos, déjale acceso por que necesitaremos que se pueda comunicar libremente con Wwise. Date una vuelta por el mapa y dispara la escopeta unas cuantas veces. Cierra el juego usando escape y quit game.

Conectando Cube con Wwise

En estos momentos, Cube tiene todos los sonidos funcionando pero en nuestro caso, queremos quitar estos sonidos para poner los nuestros y así poder practicar. Para hacer esto, debemos eliminar todos los archivos contenidos en la siguiente carpeta:

  • Windows: Program Files (x86)/Audiokinetic/Wwise 20xx.x.x.xxxx/Cube/cube/soundbanks

  • Mac: Applications/Audiokinetic/Wwise 20xx.x.x.xxxx/Cube/cube/soundbanks

Dentro de esta carpeta verás una carpeta por cada plataforma que puedes usar (Windows y Mac posiblemente). Elige tu plataforma y elimina todo el contenido que hay dentro. Alternativamente, también puedes copiar este contenido a otro lugar como el escritorio en caso de que quieras volver al sonido original del juego.

Una vez esta carpeta este en blanco, vuelve a ejecutar Cube y verás que todo el juego esta en silencio ya que no tiene los archivos necesarios para reproducir ningún sonido. En este momento, el juego está en un estado similar al que nos encontraríamos al empezar nuestro trabajo de sonido, vamos a ver como podemos conectar todo lo que ocurre en el juego con Wwise y así poder crear el paisaje sonoro que queramos.

Vuelve a tu proyecto vacío en Wwise. En el menu superior, tienes diferentes secciones como Project, Edit, Views, etc... Busca una llamada “Layouts“. Esta nos permite cambiar lo que nos muestra Wwise para que podamos trabajar en distintas secciones de nuestro proyecto. El layout por defecto es “Designer” que nos permite trabajar con sonidos y eventos. Vamos a cambiar al siguiente layout, “Profiler” que usaremos para conectarnos con cube. Fíjate que también puedes usar F6 para hacer esto rápidamente.

Una vez en Profiler verás que todo esta mas bien vacío. Si tienes Cube cerrado, ábrelo de nuevo y una vez esté el juego funcionando vuelve a Wwise y busca el botón indicado en la caja roja de la captura inferior y que indica “Connect to Remote Platform“.

En la ventana que aparece verás que Wwise ve que una instancia de Cube está abierta. Haz click en “Connect“ y verás como la sección Capture Log se empieza a llenar de información. No te preocupes si dice que hay plug-ins que no encuentra, no los necesitamos por ahora. Ve a Cube y dispara una vez la escopeta. Vuelve a Wwise y verás que ha aparecido un nuevo mensaje indicando que el juego ha pedido a Wwise el evento de disparo de la escopeta y no lo ha encontrado, ya que nuestro proyecto está vacío. No hay problema, de esto nos encargaremos ahora. Puedes parar ya la captura (botón verde en la imagen superior).

Game Calls, Events, Actions & SFX Objects

Antes de poder integrar nuestro primer sonido, es crucial que comprendamos la diferencia entre estos cuatro conceptos. Veámoslos uno a uno con el ejemplo del disparo de la escopeta.

Las “Game Calls” son las ordenes que Wwise va a recibir desde el propio juego indicando cualquier información útil que pueda afectar al sonido. En nuestro caso, el juego ha visto que la escopeta ha sido disparada, por lo que envía esta información a Wwise para que este pueda reproducir el sonido que corresponda. Ten en cuenta que nosotros como diseñadores muchas veces no tenemos control de estas Game Calls, si no que es el equipo de programación el que se encarga de prepararlas. Por ello, es muy importante que nos pongamos de acuerdo en la nomenclatura que se va a usar ya que necesitamos que el nombre que el juego envía y el nombre que Wwise espera, coincidan exactamente.

Los “Events” son una de las formas que tiene Wwise de recibir Game calls. Puedes entenderlos como “receptores” de información que viene del juego y que Wwise entonces traduce en una determinada respuesta que puedes diseñar. En el ejemplo de la escopeta, fíjate que cuando vimos el Profiler, aparecía que el juego estaba intentando activar un evento llamado “Fire_Shotgun_Player“. Ya sabemos entonces que este es el nombre que debemos dar a nuestro evento y que debe ser exactamente ese para que funcione. Cabe señalar también que, pese a que los nombres deban ser exactos, Wwise va a convertir todos los nombres de objetos (y un evento es un tipo de objeto) a minúsculas por lo que podemos usar mayúsculas en los nombres si queremos.

Una vez el evento se ha activado es obvio que queremos disparar el sonido que preparemos para la escopeta. Esta sería una Action contenida dentro de nuestro evento, en este caso una action “Play“, que simplemente va a reproducir un sonido. Por ahora con esto nos basta, pero es bueno que te hagas a la idea de que los eventos pueden contener otras “Actions“ diferentes como por ejemplo detener un sonido o alterarlo de diferentes maneras.

Por último, el “SFX Object” es por fín el objeto en Wwise que va a contener el sonido que vamos a escuchar en el juego. Ten en cuenta que estos objetos no son los sonidos en si mismos, si no más bien actúan como canales mediante los cuales se reproducen archivos de sonido. Algo así como pistas en un DAW. Como veremos mas adelante, varios SFX Objects pueden apuntar hacia un mismo archivo de sonido, sin necesidad de que tengamos que importar ese sonido varias veces. De nuevo, conceptualmente esto es similar a importar un sonido a un DAW y hacer una copia en otra pista para hacerle un tratamiento diferente.

Creando un Evento

Pongamos en practica los conceptos que hemos aprendido. Vuelve al layout “Designer“ y dentro de la view Project Explorer abre la pestaña de eventos. Como hemos visto, aquí podremos crear los objetos que recogerán game calls, de forma que sepamos cuando lanzar sonidos.

Fíjate que dentro de la pestaña de eventos, hay una jerarquía con dos tipos de objetos, “Events“ y “Dynamic Dialogue“. Por ahora a nosotros sólo nos interesa la sección de events. Verás que hay una “Default Work Unit“ y aquí es donde alojaremos nuestro evento.

Hay varias maneras de crear un evento pero por ahora, como en la imagen superior, puedes hacer click derecho en al Default Work Unit, elegir “New Child” y luego Event. Llama al evento “Fire_Shotgun_Player”. Recuerda que el juego está esperando que tu evento tenga ese nombre exacto. También podrás ver que este nuevo evento se ha creado como “child“ o hijo de la Default Work Unit. Esto es algo común en Wwise, los distintos objetos suelen tener una relación jerárquica entre ellos.

Importando Audio

Una vez creado nuestro evento, necesitamos importar el efecto de sonido en sí. Para tratar con archivos de sonido, vamos a ir a la pestaña Audio, dentro del Project Explorer. Una vez aquí, verás que hay varios elementos pero nosotros simplemente necesitamos localizar la Default Work Unit dentro de la carpeta “Actor-Mixer Hierarchy“. Esta carpeta es básicamente donde vamos a alojar a todos nuestros sonidos. Fíjate que la parte superior de esta view hay un montón de iconos que representan los distintos tipos de objetos que esta Work Unit podría contener. Todos estos tienen su utilidad, que veremos en el futuro, pero por ahora crea un nuevo objeto tipo “Sound SFX“ (icono con un altavoz) y nómbralo “escopeta_disparo“. Fíjate que el nombre del objeto Sound SFX puede ser cualquiera, incluso uno en castellano ya que el juego nunca verá este nombre sino el del evento.

Notarás que el nuevo objeto creado aparece con texto rojo. Esto nos indica que aun no hay ningún archivo sonoro asociado a él. Solucionemos esto. Puedes hacer click derecho en el objeto y elegir “Import Audio Files…“. En la ventana emergente, elige “Add Files“ y puedes usar este sonido de freesound por ahora o bien el sonido que venia con este tutorial en la siguiente ruta:

  • C:\Program Files (x86)\Audiokinetic\Wwise 2019.1.4.7065\Cube\Wwise-101_v2017.2\Lesson 1\Audio files for Lesson 1.

O también puedes elegir un sonido de tu propia librería. Sea como sea, es importante que uses una version de audio en la mejor calidad posible (normalmente en wav). Esto puede parecer en un principio poco eficiente ya que estos archivos ocuparan mucho espacio pero a la hora de compilar el audio para nuestro juego, podremos comprimir y optimizar el espacio utilizado de diferentes maneras.

Una vez importado el sonido, puedes seleccionarlo y reproducirlo usando la barra espaciadora. Verás que Wwise tiene una pequeña sección de transporte en la zona inferior que te permitirá reproducir objetos que emitan sonido lo cual también hará que los medidores de sonido de la derecha nos indiquen los niveles de nuestro audio. Además, verás que en parte central ahora aparecen un montón de opciones con las que configurar y programar nuestro sonido. Algunas de las funciones que ves, te sonarán de cualquier otro software de audio, mientras que otras serán nuevas para ti. Poco a poco iremos viendo lo que todas estas opciones nos ofrecen.

Uniendo SFX Objects y Events mediante Actions

Ahora que tenemos nuestro sonido en Wwise, necesitamos asociarlo con el evento de disparo que creamos antes. Fíjate que ahora en la esquina inferior izquierda podremos ver en la view “Event Viewer“, el evento que creamos antes, “Fire_Shotgun_Player“ y nos esta indicando “Missing“ ya que este evento no tiene ninguna acción asociada.

Si lo seleccionamos, la vista central cambiara para mostrarnos las acciones que el evento posee, que por ahora es ninguna. Elegiremos “Add“ en la parte inferior izquierda de esta view para solucionar esto.

Veremos que nos dan muchas posibles acciones a añadir pero en nuestro caso solo necesitamos una acción “Play”. Una vez la acción está creada, debemos especificar qué objeto será el que se reproduzca. En nuestro caso, arrastraremos al área señalada (Target) nuestro SFX Object, “escopeta disparo“.

Una vez hecho esto, verás que si vas a la pestaña de Events y seleccionas el evento “Fire_Shotgun_Player“, este ya hará sonar nuestro sonido de disparo.

Creando SoundBanks

Ya estamos casi listos para probar nuestro sonido dentro del juego pero antes necesitamos compilar todo el trabajo realizado en un SoundBank. Cuando hacemos esto, estamos “empaquetando“ tanto los sonidos de nuestro proyecto como las instrucciones que gobiernan su utilización en una serie de archivos que podrán ser leídos por el juego en tiempo real.

Vamos entonces a cambiar la layout a “SoundBank“. Lo primero que necesitamos es crear un nuevo SoundBank dentro de, como viene siendo habitual, la Default Work Unit. En el centro de este layout verás un botón que dice “New…“, haz click y nómbralo “Main“.

Este será el SoundBank principal que usaremos para transmitir sonidos al juego. Ten en cuenta que el juego conoce este nombre por lo que, al igual que en el caso de los eventos, la nomenclatura debe ser exacta.

Una vez creado nuestro SoundBank, deberemos añadirle eventos, los cuales serán los elementos fundamentales que usará. En la esquina inferior izquierda, verás, en la sección “Event Viewer” nuestro evento, que deberás arrastrar hasta tu SoundBank “Main“. Ahora nuestro SoundBank ya tiene al menos un evento asociado.

Como puedes ver en la parte superior derecha, cada SoundBank va asociado a un tipo de plataforma (sistema operativo, consola, etc) y a un idioma. Este es el caso ya que para diferentes sistemas es posible que necesitemos ajustar las características de nuestro proyecto de forma diferente. Una versión en móviles, por ejemplo, podría necesitar que reduzcamos los recursos que el audio utiliza. Por otro lado, los distintos idiomas nos permitirán mantener diferentes versiones de los diálogos y voces de una forma más cómoda.

En nuestro caso, sólo estamos usando una plataforma (Windows o Mac) y un idioma (English(Us)) por lo que seleccionaremos estas dos. Antes de generar nuestro SoundBank debemos configurar la carpeta en la que este se va a crear. Para esto, hacemos click en “User Settings“.

En esta ventana podremos determinar la ruta y esto será crucial por que si no, Cube no podrá encontrar los sonidos que estamos generando. Haz click en “Override Project SoundBank Paths” y luego en el botón con los tres puntos. Debemos elegir la misma ruta donde Cube espera encontrar los archivos de audio. Usa la misma ruta que ves en el texto inferior dependiendo de la plataforma que estés usando:

  • Windows: C:\Program Files (x86)\Audiokinetic\Wwise 2019.1.4.7065\Cube\cube\soundbanks\Windows

  • Mac: Applications\Audiokinetic\Wwise 2019.1.4.7065\Cube\cube\soundbanks\Mac

Ya estamos listos al fin. Haz click en OK y luego en “Generate Selected“

Probando la Escopeta

Una vez hemos generado el SoundBank, Cube va a poder ver los archivos necesarios para poder reproducir el sonido del juego tal y como nosotros los hemos preparado aunque en este caso, sólo el sonido de la escopeta estará disponible. Lanza Cube de nuevo o reinícialo si ya estaba abierto y maravíllate al oír tu creación cada vez que disparas la escopeta.

Sumario

Aquí concluye la primera parte de este tutorial, espero que te haya podido servir de ayuda como introducción al sonido para videojuegos en general y Wwise en particular.

Si tienes dudas o cualquier problema, puedes escribirme a contactme [ arroba ] javierzumer.com. Mientras tanto, dejo por aquí un glosario con todos los conceptos que he ido introduciendo en este tutorial. !Hasta la próxima!

  • Middleware: Tipo de software que en nuestro caso hace de puente entre los recursos de sonido y el juego que los utiliza.

  • Proyecto de Wwise: Se compone tanto de un archivo con la extensión .wproj como de una estructura concreta de carpetas.

  • View: Nombre que recibe cada “mini-ventana“ dentro de la interfaz de Wwise.

  • Project Explorer View: Tipo de view que permite ver todos los tipos de objetos que el proyecto tiene y que se organiza en pestañas.

  • Objects: Unidad funcional mínima que usa Wwise para determinar el comportamiento del audio en un proyecto.

  • Work Unit: Archivo tipo XML donde se alojan distintos tipos de objetos en un proyecto de Wwise.

  • Layout: Conjunto de views que podemos cargar para poder trabajar más fácilmente en determinadas áreas de un proyecto.

  • Designer Layout: Disposición de views que nos permite trabajar con sonidos y eventos.

  • Profiler View: Disposición de views que nos permite acceder a información en tiempo real enviada desde el juego además de mostrar cuántos recursos está utilizando el motor de audio.

  • Game Call: Instrucción o información transmitida desde el juego hasta Wwise.

  • Events: Objeto de Wwise que recibe información sobre cuando cierto evento ha ocurrido en el juego.

  • Actions: Instrucción que un evento puede contener y que puede reproducir, pausar, parar o alterar sonidos en distintas maneras.

  • SFX Object: Tipo de objeto que contiene un archivo de audio.

  • SoundBank: Objeto donde empaquetamos todos los sonidos e información necesaria para dirigir su comportamiento y que el juego va a leer en tiempo real.

Dear Devs, 7 Reasons why your Game may need Audio Middleware.

/

There are several audio middleware programmes on the market. You may have heard of the two main players: Fmod and Wwise. Both offer free licenses for smaller budget games and paid licenses for bigger projects.

So, what is Audio Middleware? Does your game need it?

Audio Middleware is a bridge between your game's engine and the game's music and sound effects. Although is true that most game engines offer ready to use audio functionalities (and some of them overlap with the features explained below), middleware gives you more power and flexibility for both creating, organizing and implementing audio.

Here are the seven main reasons to consider using middleware:

1. It gives Independence to the Audio Team.

Creating sound effects and music for a game is already a good amount of work, but that is barely half the battle. For these assets to work, they need to be implemented in the game and be connected to in-game states and variables like health or speed.

This connection will always need some collaboration between the audio team and the programming team. When using middleware, this is a much easier process since once the variables are created and associated, the audio team will be free to tweak how the gameplay will affect the audio, without the need to go into the code or the game engine.

2. Adaptive Music.

Music is usually linear and predictable, which is fine for linear media like movies. But in the case of video games, we have the power to make music adapt and react to the gameplay, giving the player a much more compelling experience.

Middleware plays an important role here because it gives the composer non-linear tools to work and think about the soundtrack not in terms of defined songs but of different layers or fragments of music that can be triggered, modified and silenced as the player progresses.

3. Better handling of Variation and Repetition.

Back when memory was a limiting factor, games had to get by with just a few sounds, which would usually meant repetition, a lot of repetition. Although repetition is certainly still used to give an old school flavour, is not very desirable in modern, more realistic games.

When something happens often enough in a game, the associated sound effect can get boring and annoying pretty fast. Middleware offers tools to avoid this, like randomly selecting the sound from a pool of different variations or randomly altering the pitch, volume or stereo position of the audio file each time is triggered. When all these tools are combined, we end up with an audio event that will be different each time but cohesive and consistent, offering the player a more organic and realistic experience.

4. Advanced Layering.

Layering is how we sound designers usually build sounds. We use different, modified individual sounds to create a new and unique one. Middleware allows us to, instead of mixing down this combination of sounds, import all these layers into different tracks so we can apply different effects and treatments to each sound separatelly.

This flexibility is very important and powerful. It help us to better adapt the character and feel of a sound event to the context of the gameplay. For example, a sci-fi gun could have a series of layers (mechanical, laser, alien hum, low frequency impact, etc) and having all these layer separated would allow us to vary the balance between them depending on things like ammo, distance to the source or damage to the weapon.

5. Responsive Audio tools.

Sound effects are usually created using linear audio software, like Pro Tools, Nuendo or Reaper. These are also called DAWs (Digital Audio Workstations). The tools that we can find in DAWs allow us to transform and shape sounds. Things like equalization, compression and other effects are the bread and butter of audio people. Most of the modern music, sound effects and movies that you´ve ever heard came from a DAW.

But the issue is that once you bounce or export your sound it’s kind of set in stone, that’s how it will sound when you trigger it in your game. Middleware software not only give us the same tools that you can find in a DAW. More importantly, it also give us the ability to make them interact with variables and states coming from the game engine.

How about a monster whose voice gets deeper as it gets larger? Or music and sound effects that get louder, brighter and more distorted as the time is running out?

6. Hardware & Memory Optimization.

Different areas of a game compete for processing power and usually audio is not the first priority (or even the second). That´s why is very important to able to optimize and streamline a game´s audio as much as possible.

Middleware offers handy tools to keep the audio tidy, small and efficent. You can customize things like reverbs and other real time effects and also choose how much quality you want in the final compression algorithm for the audio.

7. Platform flexibility & Localization.

If you need to prepare your game for different platforms, including PC, consoles or mobile phones, middleware makes this very easy. You can compile a different version of the game’s audio for each of the platforms. Memory or hardware requirements may be different for each of them and you’ll need to maybe simplify sound events, bake-in effects or turn a surround mix into an stereo one.

You can also have a different version per language, so the voice acting would be different but the overall sound effects and treatment of the voices would be consistent.

I hope this gave you a bit of a taste of what middleware is capable of. When in doubt, don´t hesitate to ask us, audio folks!
Thanks for reading.

An Introduction to Game Audio

/

Talking to a fellow sound designer about game audio, I realised that he wasn't aware of some of the differences between working on audio for linear media (film, animation, TV, etc) and for interactive media (video games).

So this post is kind of my answer to that. A brief introduction to the creative depth of video game sound design. This would be aimed to audio people who are maybe not very familiar with the possibilities this world offers or just want to see in which way is different to, say, working on film sound design.

Of course there are many differences between linear and interactive sound design, but perhaps the most fundamental, and the most important for somebody new to interactive sound design, is the concept of middleware. In this post, I’ll aim to give beginners a first look at this unfamiliar tool.

I'll use screenshots from Unearned Bounty, a project I've been working on for around a year now. Click on them to enlarge. This game runs with Unity as the engine and Fmod as the audio middleware.

Linear Sound vs Interactive Sound

Video games are an interactive media and this is going to influence how you face the sound design work. In traditional linear media, you absolutely control what happens in your timeline. You can be sure that, once you finish your job, every time anyone presses play that person is going to have the same audio experience you originally intended, provided that their monitoring system is faithful.

Think about that. You can spend hours and hours perfecting the mix to match a scene since you know is always going to look the same and it will always be played in the same context. Far away explosion? Let's drop a distant explosion there or maybe make a closer FX sound further away. No problem. 

In the case of interactive media, this won´t always be the case. Any given sound effect could be affected by game world variables, states and context. Let me elaborate on those three factors. Let's use the example of the explosion again. In the linear case, you can design the perfect explosion for the shot, because is always going to be the same. Let's see in the case of a game:

  • The player could be just next to the explosion or miles away. In this case, the distance would be a variable that is going to affect how the explosion is heard. Maybe the EQ, reverb or compression should be different depending on this.

  • At the same time, you probably don't want the sound effect to be exactly the same if it comes from an ally instead of the player. In that case, you'd prefer to use a simpler, less detailed SFX. One reason for this could be that you want to enhance the sound of what the player does so her actions feel more clear and powerful. In this case, who the effect belongs to, would be a state.

  • Lastly, is easier to make something sound good when you always know the context. In video games, you may not always know or control which sounds will play together. This forces you to play-test to make sure that sounds not only work in isolation but also together and in the proportions that usually the player is going to hear. Also, different play styles will alter these proportions. So, following with our example, your explosion may sound awesome but maybe at the same time dialogue is usually being played and is getting lost in the mix and you'd need to account for that.

After seeing this, linear sound design may feel more straightforward, almost easy in comparison. Well, not really. I´ll explain with an analogy. Working on linear projects, particularly movies, is like writing a book. You can really focus on developing the characters, plot and style. You can keep improving the text and making rewrites until you are completely satisfied. Once is done, your work is always going to deliver the same experience to anyone who reads the book.

Interactive media, on the other hand, is closer to being a game master preparing a D&D adventure for your friends. You may go into a lot detail with the plot, characters and setting but like any experienced GM knows, players will somewhat unpredictable. They will spend an annoying amount of time exploring some place that you didn´t give enough attention to and then they will circumnavigate the epic boss fight by some creative rule bending or a clever outside the box idea.

So, as you can see, being a book writer or working in linear sound design gives you the luxury of really focusing on the details you want, since the consumer experience and interaction with your creation is going to be closed and predictable. In both D&D and interactive media, you are not really giving the final experience to the players, you are just providing the ingredients and the rules that will create a unique experience every time.

Creating those ingredients and rules is our job. Let's explore the tools that will help us with this epic task.

Audio Middleware and the Audio Event

Here you can see code being scary.

Games, or any software for that matter, is built from a series of instructions that we call code. This code manages and keeps track of everything that makes a game run: graphics, internal logic, connecting to other computers through the internet and of course, audio.

The simplest way of connecting a game with some audio files is just calling them from the code whenever we need them. Let's think about a FPS game. We would need a sound every time the players shoots her shotgun. So, in layman's terms, the code would say something like: "every time the players clicks her mouse to shoot, please play this shotgun.wav file that you will find in this particular folder". And we may don't even need to say please since computers don't usually care about such things.

This is how all games were done before and is still pretty much in use. This method is very straightforward but also very limited. Incorporating the audio files into the game is a process that is usually called implementation and this is its more rudimentary form. The thing is, code can be a little scary at first, specially for us audio people who are not very familiar with it. Of course, we can learn it, and is an awesome tool if you plan to work in the video game industry, but at the end of the day we want to be focusing on our craft.

Middleware was created help us with this and fill the gap between the game code and the audio. It serves as a middle man, hence the name, allowing sound designers to just focus on the sound design itself. In our previous example, the code was pointing to specific audio files that were needed in any given moment. Middleware does essentially the same thing but puts an intermediate in the middle of the process. This intermediate is what we call an audio event. 

An example of audio events managing the behaviour of the pirate ships.

An audio event is the main functional unit that the code will call whenever it needs a sound. It could be a gunshot, a forest ambience or a line of dialogue. It could contain a single sound file or dozens of them. Anytime something makes a sound, is triggering an event. The key thing is that, once the code is pointing to an event, we have control, we can make it sound the way we want, we are in our territory.

And this is because middleware uses tools that we audio people are familiar with. We'll find tracks, faders, EQs and compressors. Keep in mind that these tools are still essentially code, middleware is just offering us the convenience of having them in an comfortable and familiar environment. Is bringing the DAW experience to the game development realm.

Audio middleware can be complex and powerful and I'd need a whole series of posts to tell you what they can do and how. So, for now. I'm just going to go through three main features that should give you an idea of what they can offer.

I - Conventional Audio Tools within Middleware

Middleware offer a familiar environment with tracks, timelines and tools similar to the ones found on your DAW. Things like EQ, dynamics, pitch shifters or flangers are common.

This gives you the ability to tweak your audio assets without needing to go back and forth between different softwares. Probably you are still going to start from your DAW and build the base sounds there using conventional plugins, but being able to also do processing within the middleware gives you flexibility and, more importantly, a great amount of power as you'll see later.

II - Dealing with Repetition and Variability

The player may perform some actions over and over again. For example, think about footsteps. You generally don't want to just play the same footstep sound every single time. Even having a set of, say 4 different footsteps, is going to feel repetitive eventually. This repetitiveness is something that older games suffer from and that generally modern games try to avoid. The original 1998 Half-Life, for example, uses a set of 4 footstep sounds per surface. Having said that, it may still be used when looking for a nostalgic or retro flavour the same way pixel art is still used. 

Middleware offer us tools to make several instances of the same audio event, sound cohesive but never exactly identical. The most important of these tools are variations, layering and parameter randomization.

The simplest approach to avoid repetition is just recording or designing several variations on the same effect and let the middleware choose randomly between them every time the event is triggered. If you think about it, this imitates how reality behaves. A sword impact or an footstep are not going to sound exactly the same every single time, even if you really try to use the same amount of force and hit on the same place. 

You could also break up a sound into different components or layers. For example, a gunshot could be divided in a shot impact, its tail and the bullet shell hitting the ground. Each of this layers could also have their own variations. So now, every time the player shoots, the middleware is going to randomly choose an impact, a tail and a bullet shell sound, creating a unique combination.

Another cool thing to do is to have an event with a special layer that is triggered very rarely. By default, every layer on an event has a 100% possibility to be heard but you can tweak this value to make it more infrequent. Imagine for example a power-up sound that has an exciting extra sound effect but is only played 5% of the time the event is called. This is a way to spice things up and also reward players who spend more time playing.

An additional way of adding variability would be to randomize not only which sound clip will be played, but also their parameters. For example, you could randomize volume, pitch or panorama within a certain range of your choice. So, every time an audio clip is called, a different pitch and volume value are going to be randomly picked.

Do you see the possibilities? If you combine these three techniques, you can achieve an amazing degree of variability, detail and realism while using a relative small amount of audio files.

See above the collision_ashore event that is triggered whenever a ship collides with an island. It contains 4 different layers: 

  • A wood impact. (3 variations)

  • Sand & dirt impacts with debris. (3 variations)

  • Wooden creaks (5 variations)

  • A low frequency impact.

As I said, each time the event is triggered, one of this variations within each layer will be chosen. If we then combine this with some pitch, volume and EQ randomization we will assure that every instance of the event will be unique but cohesive with the rest.

III - Connecting audio tools to in-game variables and states.

This is where the real power resides.

Remember the audio tools built-in into middleware that I mentioned before? In the first section I showed you how we can use these audio tools the same way we use them on any DAW. Additionally, can also randomize their values, like I showed you in the second section. So here comes the big one.

We can also automate any parameter like volume, pitch, EQ or delay in relation to anything going on inside the game. In other words, we will have a direct connection between the language of audio and the language the game speaks, the code. Think about the power that that gives you. Here are some examples:

  • Apply an increasing high pass filter to the music and FX as the protagonist health gets lower.

  • Apply a delay to cannon shots that gets longer the further away the shot is, creating a realistic depiction of how light travels faster than sound.

  • Make the tempo of a song gets faster and its EQ brighter as you approach the end of the level.

  • As your sci-fi gun wears off, the sounds get more distorted and muffled. You feel so relieved when you can repair it and get all its power back.

Do you see the possibilities this opens? You can express ideas in the game's plot and mechanics with dynamic and interactive sound design! Isn't that exciting? The takeaway concept that I want you to grasp from this post is that you would never be able to do something this powerful with just linear audio. Working on games makes you think much harder about how sound coming from objects and creatures behaves, evolves and changes. 

As I said before,  you are just providing the ingredients and the rules, the sound design itself only materializes when the player starts the game. 

You can see on the above screenshot how an in-game parameter, distance in this case, affects an event layers' volume, reverb send and EQs.

How to get started

If I have piqued your interest, here are some resources and information to start with.

Fmod and Wwise are currently the two main middleware used by the industry. Both are free to use and not very hard to get into. You will need to re-wire your brain a bit to get used to the way they work, though. Hopefully, reading this post gave you a solid introduction on some of the concepts and tools they use.

If I had to choose one of them, Fmod could look less intimidating at first and maybe more "DAW user friendly". Of course, there are other options, but if you just want to have a first contact, Fmod does the job.

There are loads of resources and tutorials online to learn both Fmod and Wwise, but since I think that the best way to really learn is to jump in and make something yourself, I'll leave you with something concrete to start from for each of them:

Fmod has these very nice tutorials with example projects that you can download and play with.

Wwise has official courses and certifications that you can do for free and and also include example projects.

And of course, don't hesitate to contact me if you have further questions. Thanks for reading!