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.

Thoughts on buying gear

Hello! Here are some ideas and tips that I think could help you make better decisions while buying audio equipment.

Think long term

I like to see any piece of gear as an investment so I try to choose products that are known for being robust and durable. There are always cheaper options out there but I don’t mind paying a higher price if I have a better guarantee that the equipment is going to last for longer and be more reliable.

In order to determine durability, a good hint could be that the manufacturer offers a longer guarantee period than legally required and/or a good reputation among veteran users (some detective work in audio forums is a must). It is also a good sign when a product is manufactured in Europe or the US, although this is not very frequent and doesn’t guarantee a higher quality necessarily.

Buying higher end gear is particularly relevant for audio since electronic components are quite important in determining quality and life expectancy. The use of cheap plastic instead of more durable components like metal is also commonplace and something to avoid, specially in field equipment.

Something else to think about is that durable gear is usually well known in the industry and may give clients some extra confidence to hire you before others.

On the flip side, you can’t always afford to buy higher quality equipment and sometimes you may need to opt for entry level gear. This can also happen when you need an specific thing for a gig and don’t have time or money to find the best possible option. In those cases, well, you probably need to bite the bullet but in general my advice would be to wait if you can. Flip more burgers and sweep more floors. Once you have enough to at least access the mid tier, go for it. In my experience, those investments will pay off. Ten fold. You need to spend money to earn money.

I bought a Tascam HD-P2 in late 2011. I chose this model because of its reputation and quality. To this day, I still use it as my main recorder for sound effects. It has also accompanied me through features films and documentaries, on snowy cold exterior days and crazy hot Seville summers. It has never failed or died during a take.

I am not saying the HD-P2 is perfect. It only offers two microphone inputs, the pre-amps are not ultra clean (but they quite good for their price range) and the powering options are limited. Nevertheless, it served me well throughout my first years working in audio, it gave me confidence and allowed me to get a huge return on my investment.

The mighty HDP2. Respect.

Save on the features you don’t need

I think this is key. Don’t get dazzled with fancy stuff that you are never going to use. It is important that you think about the features that you actually need and then look for the best option the market has to offer.

Hopefully, I will have the chance to record more frequently now.

Of course, in order to do that, you need to know what your needs really are, which is the tricky part. Do you prefer more channels or a higher resolution? Bigger memory or longer battery life? If you know what kind of specific work you are going to do, this is going to be easier to decide. Try to narrow your needs and priorities.

I recently bought a Sony PCM D100 because I wanted to have something portable to record on the go. This recorder is quite expensive (for a handheld device) and doesn’t have XLR inputs which for me is a big issue. But the thing is my goal is to have something really portable so I can record in situations when a big rig would be cumbersome.

So I am losing the XLR feature in exchange for great quality of audio, battery life, internal memory and construction. All of them features that are essential if I’m going to use this on the go.

Avoid audio elitism

Sound is something that can be objectively measured but, nevertheless, the way we experience it is quite subjective. People apply all sorts of descriptions to audio like “silky”, “airy” or “muddy”. I’m not saying these are not useful or that these don’t describe real properties but sometimes I think we get caught up in these terms too much.

This problem is twofold. On one hand, sometimes people are so ready to justify their purchase that they start to hear mystical properties in a piece of gear. On the other hand, sometimes we can actually really tell the difference (in terms of clarity or timbre profile) between two pieces of gear but it is so small that it’s only noticeable while soloing and/or A-B testing. If the final consumer is probably not going to tell the difference, is it really that important?

Don’t get me wrong, I still think that audio quality should be a priority but usually when investing in equipment the very expensive stuff gives you diminishing returns. You need to really expend a lot of cash to get from the professional to the “elite” level. Maybe you don’t need to.

So yeah, choose quality but don’t get crazy. Beware of mystical claims and 20K€ cables. I honestly think that if we forced people to take blind A-B tests comparing decent gear with very high end equivalents they would be amazed with how close they can be.

Your sound is as good as your chain’s weakest link

Before buying a new fancy microphone, maybe stop for a second and think about the small stuff. There is always something outdated or in a bad condition. Maybe it would sensible to improve on those weak areas first.

Sure, you don’t need fancy solid gold cables but get yourself some decent ones. Another good example of this could be battery management. If your gear uses batteries of any kind, invest in good chargers. I recommend you get familiarized with the stuff that video and photography folks use. Smart chargers are a great option since they have independent charging cells and programs to keep batteries healthier.

Audio cases (I like Portabrace) are also a great option to make sure your equipment is safe while traveling or on location. I bought my Tascam HDP2 with a Portabrace case and it’s really a worthy investment. The velcros work like the first day eight years later.

This powerex charger is a very nice option if you need an army of batteries for your recorder and/or wireless kits.

Balance Risk and Personality

Some people are more risk averse than others and this is something you need to take into account. In my case, I don’t feel confortable rushing things or spending large sums of money so I try to avoid doing those two things at once. If you are similar to me, remember that at some point you have to take the leap and is going to feel uncomfortable. But that’s good. That’s what they mean when they say “Is good to step out of your confort zone”.

When I bought the Rode Blimp v1, I could not afford anything better. It’s an OK starting point, but I would not recommend it for a long term investment. Not very durable.

If, on the other hand, you tend to rush things, well, take it easy. It may help to give yourself some time to make sure to make the right decision. Sharing your situation with friends or colleagues may help too, you’d be surprised by how much better you can see things when you articulate them out loud and get feedback.

Personally, I don’t like to buy second-hand stuff because I feel like I’m taking a big risk but if you are confortable with that, it’s definitely an option. It helps if you can check the condition in person and knowing the seller is ideal. If you are buying online, using sites with a reputation system is a must. Other than that, second-hand is a risk that may pay off or end up in disaster. So ask yourself: how much more money am I willing to pay to get peace of mind instead?

Reviews are spooky

Any piece of equipment that is reasonably popular is going to have some scary reviews. That’s the nature of the polarized online world: people only bother giving 1 or 5 stars, so there isn’t much nuance. Having said that, reviews are still a valuable resource when used with caution.

My approach is to focus on quality rather than quantity. Sure, you can found many reviews in Amazon nowadays but I would prefer to check audio forums or specialized stores first. You can also check reviews for a product on online stores that you are not planning to use. If you are in Europe, B&H and Sweetwater are great. If you are in the US, Thomann is a fantastic source.

Other than that, your best bet is to join and participate forums like Gearlutz. With time, you’ll get to know people there whose opinion would probably be more valuable than a random Amazon user.

Limit your tools

The Sennheiser MKH 416 was my first mic and almost the only one for some time, forcing me to use it in many different ways (on location, for foley, for SFX, for VO…)

Scarcity may sound like a bad thing but I think you can learn a lot from it. Limiting yourself to a small number of tools forces you to be creative, try new things and of course you will master them. Is hard to do that if you have too much stuff so my advice would be to really make the most of what you have before buying something new.

For me, a good example of this is audio libraries. If you already have a decent amount of sounds, there is probably a lot you can do with them. Doing sci-fi or fantasy sounds, for example, will force you to experiment with what you have around in terms of recording gear and plugins and you will learn far more than if you just buy yet another library.

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.