Tutorial Wwise en Español - Parte VI: Mezcla

/

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.

Control y Equilibrio

A medida que un proyecto crece, más y más sonidos se añaden y puede ser difícil mantener un buen balance entre ellos. De poco sirve tener sonidos geniales si se pierden en el barullo de una batalla o suenan tan fuertes que resultan desagradables.

Veamos entonces algunas de las herramientas de las que disponemos para mantener siempre un buen control de todos nuestros elementos sonoros.

Schematic Layout

Como su nombre sugiere, esta opción nos muestra una vista esquemática de todos nuestros objetos sonoros y su relación con Actor-Mixers y buses. Esto es útil cuando queremos saber de un vistazo cómo se conectan los elementos de nuestro juego. En nuestro caso, tenemos un proyecto muy sencillo pero en un juego completo esta vista puede ser de gran ayuda. Puedes acceder a este layout simplemente en el menú principal "Layouts - Schematic” o usando F9.

Como puedes ver, las líneas continuas indican relaciones jerárquicas padre-hijo (para elementos contenidos en random containers o Actor-Mixers, por ejemplo), mientras que las líneas discontinuas muestran enrutamientos de audio, como cuando enviamos la salida de un objeto sonoro a un determinado bus. En el ejemplo, puedes ver que los distintos Actor-Mixers estan enrutados al bus “Environmental”.

Este layout no sólo nos muestra las relaciones entre todos estos elementos sino también podemos usarlo para hacer ajustes rápidos de mezcla. En principio, si seleccionas cualquier objeto sonoro, verás que puedes reproducirlo usando el transporte en la parte inferior o la barra espaciadora. Podemos entonces hacer aparecer muchos más parámetros para cada objeto y así ajustar nuestra mezcla desde esta misma vista.

Si miras en la esquina inferior derecha de esta Schematic View, verás una rueda dentada. Haz click y selecciona algunos de los elementos que ves en la imagen inferior.

Como puedes ver, ahora estos sencillos elementos se amplían, mostrándonos mucha más información. Puedes ajustar distintos parámetros de mezcla como el volumen, pitch y filtros. También puedes ver qué tipo de randomización hay y dónde, qué tipo de posicionamiento sonoro y si un determinado elemento está siendo afectado por un parámetro, switch o state.

Sessions

Vamos a ver algunas otras herramientas más concretas si cabe con las que contamos para controlar la mezcla de nuestro proyecto. De paso, esto también nos introduce un nuevo tipo de objeto en Wwise, las sesiones. Las puedes encontrar en la pestaña Sessions, dentro del project explorer del Layout Designer (ver captura).

Estas sessions nos permiten crear, recibir y enviar información de nuestro proyecto de distintas maneras, siendo las tres relacionadas con la mezcla. A grandes rasgos, para esto sirve cada tipo:

  • Soundcaster Session: Nos permite colocar objetos sonoros y sus GameSyncs asociados en un cómodo panel donde podemos hacer ajustes.

  • Mixing Sessions: Nos permite crear una mesa de mezclas virtual que nos mostrará faders, insertos, panorama de una forma muy parecida a un DAW.

  • Control Surface Session: Nos permite conectar una superficie de control física con nuestro proyecto para controlar parámetros con ella. No veremos esta sección en profundidad, pero es bueno que sepas que esto es una opción si tienes una superficie de mezcla.

Crear una nueva Soundcaster session

Empecemos por las soundcaster sessions, que como decía nos permite colocar los elementos que deseemos en un panel configurable. Para crear una nueva sesión, ve a la pestaña de sesiones y dentro de la “Default Work Unit” y crea una nueva Soundcaster session de la misma manera que puedes crear objetos sonoros. La puedes llamar como quieras, yo la he llamado SFX, por ejemplo.

Una vez creada, puedes acceder a ella haciendo click en View (en el menú principal de Wwise) y eligiendo Soundcaster sessions. También puedes usar el atajo Shift + S.

Nos aparece entonces una ventana que nos muestra todos los GameSyncs de nuestro proyecto, es decir, los Switches, RTPCs, Triggers y States. Si ves que no hay contenido en estos GameSyncs, pulsa en el botón que dice “Show All”. Por ahora, no vemos ningún objeto sonoro ni evento pero para añadirlos, sólo tienes que arrastrarlos al panel.

Como puedes ver en la imagen inferior, puedes arrastrar todo tipo de cosas, objetos sonoros como random containers, eventos, Actor-Mixers, etc… Una vez añadidos puedes hacer play en varios de ellos y así cómodamente recrear cómo se comportaría el sonido mientras se juega. Puedes, por ejemplo, disparar el ambiente y luego los pasos y ver cómo está el balance de ambos. Hacer ajustes rápidos en este panel es también muy cómodo.

Mira también que tienes todos tus switches y RTPCs muy a mano por lo que puedes ir cambiándolos para ver cómo estos afectan a los sonidos. Puedes simular por ejemplo andar por distintas superficies o cómo la salud del personaje se reduce.

Una última nota sobre las soundcaster sessions es que puedes crear varias diferentes lo que puede ser muy útil para probar los sonidos de, por ejemplo, un determinado nivel del juego o una determinada arma o mecánica de forma aislada y ordenada sin necesidad de andar buscando todos estos sonidos en tu jerarquía de objetos sonoros.

Mixing Sessions

Este tipo de sesión nos permite construir una mesa de mezclas configurable con la que podremos tener más control “táctil” de todos nuestros sonidos. De nuevo, podemos también crea varias de estas sesiones para trabajar con distintos conjuntos de elementos cada vez.

En este caso, tenemos un Layout que nos pemitirá ver estas mixing sessions. Haz click en Layout > Mixer o usa F8 en el teclado. Fíjate lo que se nos abre. Arriba, vemos una view llamado “Mixing Desk” que es la que contendrá nuestra mixing session. Abajo vemos algo con lo que ya estamos familiarizados, la soundcaster session que creamos antes. Esto tiene mucho sentido por que podemos usar el panel inferior para lanzar sonidos y el superior para hacer la mezcla en sí, obteniendo lo mejor de ambos mundos.

Para ello, vamos a crear una mixing session. Selecciona las flechas en la parte superior izquierda (ver imagen) y haz click en “New…”. Puedes llamarla SFX también pero ten en cuenta que para proyectos más grandes deberemos usar nombres más específicos para cada una de nuestras sesiones si queremos evitar confusión.

Nos aparece una mixing session que por ahora no tiene elementos pero para poblarla solo tenemos que hacer lo mismo que con la Soundcaster Session y arrastrar distintos objetos sonoros, Actor-Mixers y Buses al Mixing Desk. Verás que, en este caso, no puedes arastrar Eventos, ya que estos sólo son disparadores de los propios objetos sonoros, ergo por ellos no fluye audio realmente. Una vez añadidos unos cuantos elementos, puedes usar la barra lateral para bajar la vista de mezcla y ver todos los elementos disponibles, ya que no suelen caben en la view (esto depende de tu resolución de pantalla).

También puedes ocultar los elementos que no necesites, haciendo click en la rueda dentada que he marcado en amarillo en la imagen superior.

Como puedes ver esta vista recuerda mucho a una mesa de mezclas ya sea física o en un DAW. Disponemos de faders (parte inferior), control de panorama, envíos, insertos, etc… y todo al alcance de nuestra mano. También podemos randomizar parámetros en esta vista. Con esta disposición, estaríamos listos para hacer cualquier ajuste en la mezcla de nuestro entorno sonoro de una forma cómoda y muy visual.

Apuntes sobre Filosofía de Mezcla para Audio Interactivo

Ya os he dado las herramientas de las que dispondremos para nuestras mezclas pero otra cuestión es cómo usarlas. Es difícil responder a esta pregunta por que cada proyecto necesitará cosas diferentes. Aún así un buen comienzo sería pensar qué es importante en la mezcla y asegurarnos que la construimos teniendo en cuenta los elementos que queremos que siempre estén presentes y sean protagonistas.

Los jugadores van a actúar de formas impredecibles por lo que tenemos que asegurarnos que nos anticipamos en lo razonable a esto. Herramientas como ecualización, o compresión con sidechain pueden ser también muy útiles para dar prioridad a unos elementos respecto a otros. Imagina por ejemplo filtrar frecuencias en ciertos elementos para dar espacio a otros que se suelen dar a la vez o usar sidechain para bajar la música y el sonido ambiente ligeramente cuando hay diálogos presentes.

Tienes que empezar a pensar en la mezcla como una serie de reglas dinámicas y prioridades más que un mero conjunto de niveles como ocurriría en una obra lineal. Crear esta serie de dependencias es algo que debes desarrollar a medida que trabajas en diferentes proyectos y te das cuenta de que dispones de un espacio sonoro (y de procesamiento) limitado y debes hacer el mejor uso posible de él.

En la siguiente y última sección de este tutorial, veremos como las herramientas de optimización también nos pueden ayudar en este sentido y deben usarse en consonancia con las de mezcla.

Sumario

En esta sexta parte, hemos visto todo lo relacionado a mezcla. 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 esta parte. !Hasta la próxima!

  • Schematic Layout: Esta configuración de views nos permite ver nuestros elementos sonoros de una forma esquemática que nos muestra tanto sus relacions jerárquicas como de enrutamientos de audio.

  • Soundcaster Sessions: Tipo de objeto dentro de la pestaña Sessions que nos permite disponer en un panel los objetos sonoros que deseemos, inclutendo eventos, buses y Actor-Mixers.

  • Mixing Sessions: Sesión que nos permite agrupar objetos sonoros y buses en una vista muy similar a una mesa de mezclas.

  • Control Surface Sessions: Sesión que podemos crear para conectar una controladora de mesa física que tengamos con determinados parámetros dentro de Wwise y así poder controlarlos de forma táctil.

Tutorial Wwise en Español - Parte V: Flujo de señal y Efectos

/

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.

Controlando la señal sonora

En esta entrega vamos a ver cómo podemos asegurarnos de tener bien organizados nuestros objetos y hacer una buena gestión de cómo las distintas señales de audio fluyen por nuestro proyecto. Ten en cuenta que un juego finalizado contiene cientos de sonidos por lo que necesitamos tener control de todos ellos de una forma fácil y accesible.

Es importante recordar que, a diferencia de una mezcla lineal, aquí estamos trabajando con un medio interactivo en el que debemos preparnos para cualquier acción que pudiera ejecutar la persona que está jugando.

Actor-Mixers

La primera herramienta y la más esencial para controlar la señal sonora son los Actors-Mixers. Estos nos permiten agrupar un conjunto de sonidos a los que queremos aplicar los mismos cambios en sus parámetros como por ejemplo volumen o randomización en el pitch.

Un juego podría agrupar los objetos sonoros de la siguiente manera:

  • Entorno

  • Ambiente

  • Musica

  • Diálogo

  • Armas

  • Foley

En el caso de nuestro humilde proyecto de Cube, no tenemos muchos sonidos que agrupar, pero aún así puedes crear uno para cada categoría. Para ello, sólo tienes que seleccionar la Default Work Unit donde tienes todos los objetos y crearlos con click derecho y New Child >Actor Mixer. También puedes crear uno para nuestros objetos de ambiente (ambiente 1, ambiente 2 y pájaros). Te dejo una captura de cómo ha quedado el mío. Los Actor-Mixers pueden tener un color asignado que nos puede ayudar a indentificar mejor los distintos elementos de nuestro proyectos. Puedes aplicar colores haciendo click derecho en el Actor-Mixer y eligiendo “Set Color”.

Comportamiento y funcionabilidad de los Actor-Mixers

Verás que un Actor-Mixer tiene la misma ventana de Property Editor que cualquier tipo de objeto (imagen izquierda). Si en esta ventana aplicas un cambio de volumen de +1dB, por ejemplo, esto sería igual que ir a cada uno de los objetos contenidos dentro del actor y hacer este mismo cambio uno a uno. Si los objetos hijos tienen sus propios valores de volumen (digamos -3dB y +5 dB, por ejemplo), el Actor-Mixer aplicará su valor “encima” de este, de forma que nos quedaría -2dB y +6 dB. En otras palabras, los valores que des a un Actor-Mixer nos son impuestos a sus hijos, si no que se suman, como si de un VCA se tratase.

Quizás tengas la impresión de que entonces todos los elementos dentro de un Actor-Mixer están siendo mezclados juntos cómo si en un DAW enviaras la saida de un conjunto de pistas al mismo bus pero este no es el caso. Los Actors-Mixers no funcionan como buses sino como VCAs. De hecho, veremos pronto que Wwise sí que permite meclar sonidos pero para hacer esto utiliza un tipo de objetos llamados precisamente “Buses”, que veremos luego.

No quiero liarte. Básicamente piensa en los Actors-Mixers como VCAs o como grupos que te permiten cambiar (sumando valores, no imponiéndolos) cualquier parámetro de los objetos hijos.

Actor-Mixers en grandes proyectos

Puede merecer la pena que te pases de nuevo por el proyecto de Wwise de Limbo y mirar cómo está organizado, ya que este proyecto es muy grande y complejo. Mira cómo lo sonidos se organizan en los distintos objetos que hemos ido viendo en este tutorial (random, sequence, switch y blend containers) y estos a su vez se agrupan en Actor-Mixers y carpetas virtuales.

Piensa en qué casos necesitarías un Actor-Mixer y en qué otros te bastaría con una carpeta virtual, que es básicamente un mero contenedor sin ninguna funcionabilidad.


Master Mixer Hierarchy

Si estás en el layout designer y te fijas en la jerarquía de objetos verás que todos los objetos sonoros que hemos visto hasta ahora, incluídos los propios Actors-Mixers se sitúan en la llamada “Actor-Mixer Hierarchy”. Esta jerarquía engloba a todos los objetos que producen sonidos pero recuerda que no mezclan el audio de ninguna manera.

Pero esto tenemos la otra jerarquía que puedes ver encima, la “Master-Mixer Hierarchy”. Es aquí donde podemos ver los buses de los que hablamos antes y que realmente van a mover el flujo de audio de una manera similar a un DAW o una mesa de mezclas.

Si te fijas en tu proyecto, deberias ver uno llamado “Master Audio Bus”. Por defecto, todos tus sonidos acaban en este bus y es el que Wwise ha estado usando hasta ahora para mezclar el audio proveniente de todos los objetos. Si ves otros buses, los puedes ignorar por ahora.

Audio Buses

Fíjate en el property editor de cualquiera de tus sonidos o actor-mixers y verás que hay una sección que nos indica a qué bus va dicho objeto. Verás que también nos aparecen unos controles de volumen y filtro que nos permiten controlar cuánto queremos enviar a dicho bus.

Si seleccionas el bus en sí, verás que nos ofrece un control del volumen general del bus y un medidor grande por el que podremos ver el audio que fluye por el bus si reproducimos cualquiera de nuestros objetos.

Aquí llega lo complicado. Verás también que una sección llamada “Voice” donde encontramos unos controles llamados muy similares a los que veíamos en los Actor-Mixers, volumen, pitch y filtros. Estos controles, esencialmente funcionan como si de un Actor-Mixers se tratara, es decir, actúan sumándose a los valores de los objetos hijos de igual manera que si hubiéramos ido a cambiarlos uno a uno.

¿Por qué tanta redundancia? Bueno, por ofrecer más control sobre las fases de ganancia de la mezcla, para que puedas ajustar los niveles en el lugar donde tenga más sentido en cada caso de forma que tengas sufciente rango dinámico siempre que lo necesites. Tengo un artículo sobre el concepto de Gain Staging en general que te puede ayudar en este sentido.

Usando el Layout “Voice Profiler” para seguir el flujo de señal

Como ves la cosa se está complicando y ya hay varios lugares diferentes en los que podemos afectar distintos parámetros. Para aclararnos un poco, podemos utilizar el layout “Voice Profiler”. Selecciona este layout y si te aparece un aviso como el que ves en la imagen, simplemente haz click en la rueda dentada y en la ventana de “Profiler Settings” activa “Voice Inspector Data”.

Una vez hecho esto, comienza la captura haciendo click en el botón de “Start Capture” (cuadrado verde). No necesitamos iniciar el juego para esto. Selecciona entonces un objeto sonoro, como el teletransportador y reprodúcelo. Verás entonces que en la parte central aparece una visión gráfica de las distintas etapas de mezcla que están afectando a este objeto sonoro (cuadrado rojo), además de una visión esquemática (amarillo) que nos indica cada una de las fases que afectan al volumen y el resultado final.

Como puedes ver en mi captura, estoy cambiando los niveles en varias etapas y estas se suman para llegar al valor final. Cada vez que un sonido esté sospechasamente bajo o alto de volumen esta herramienta puede ayudarte a saber de dónde viene el problema. Recuerda que si no ves los valores en tiempo real es por que necesitas inciar una captura y, de nuevo, no es necesario que el juego esté abierto para que funcione.

Organizando nuestros Buses

Como ya he comentado, los buses sí que hacen una mezcla física (bueno, digital) de las señales sonoras. Puedes pensar en ellos como canales en un DAW o mesa de mezclas.

Los buses nos dan otra capa más de control de ganancia pero con la ventaja de que podemos trasladar sus señales directamente al motor de juego de forma independiente. Esto nos puede servir para dar control del balance de la mezcla a los propios jugadores. Posiblemente te hayas dado cuenta que en muchos juegos, como jugador, puedes controlar los niveles de la música, efectos y diálogos independientemente. En el casos de los juegos que usan Wwise, esto se puede conseguir usando diferentes buses.

Vamos entonces a crear algunos buses para diferenciar disintos elementos de nuestro juego. Vuelve al layout Designer y busca en la parte superios de la pestaña “Audio” la “Master-Mixer Hierarchy”. Verás un “Master Audio Bus” y quizás algún otro. Este “Master Audio Bus” es el responsable de que puedas oír el audio que sale de Wwise. Es básicamente una salida máster que se conecta con tu tarjeta de sonido. En el caso de cuando juegas a Cube, este bus es el que manda la señal de audio al juego.

Por ello, todos los buses que creemos deben ir a parar al master o, dicho de otra manera, deben ser hijos de él. Selecciona el “Master Audio Bus” y crea entonces dos nuevos buses y llámalos “Entorno” y “Música”. Verás que se crearán como hijos.

Una vez hecho esto, vamos a asignar nuestros objetos sonoros al bus correspondiente ya que por ahora, todos los objetos van directamente al Máster. La tarea es más fácil ahora que tenemos nuestros Actor-Mixers ya creados. Elige cada uno de ellos y verás que en el Property Editor podemos seleccionar el bus de salida. Haz click en el botón con los tres puntos y elige el bus llamado “Entorno”. Repite el proceso con todos los Actor-Mixers. Por ahora, no tenemos música en el juego pero ya sabemos que cuando la tengamos, tendremos el bus preparado.

Efectos mediante inserto

Una de las ventajas de trabajar con Wwise es que podemos aplicar distintos efectos a determinados sonidos o grupos de sonidos directamente, sin necesidad de tener que salir a otro programa.

La forma más sencilla e intuitiva de hacer esto es por inserto, es decir, aplicando el efecto a un sonido en su totalidad de la misma manera que se haría en un inserto en un DAW.

Por ejemplo, vamos a aplicar un flanger a nuestro sonido de teletransporte, para darle un toque extra. Vamos a nuestro objeto sonoro y si te fijas, el Property Editor tiene una pestaña llamada “Effects” que no hemos usado hasta ahora.

Una vez en esta pestaña, verás que nos aparece un panel donde podemos crear hasta cuatro insertos pero hay un problema. No podemos crear ninguno por ahora. Esto es por que, por defecto, este objeto sonoro está heredando las propiedades de su padre, es decir, el Actor-Mixer llamdo “Entorno” y este no tiene ningún inserto.

Quizás pienses que la solución sea crear los insertos en el Actor-Mixer y esto definitivamente funcionaría pero no sería lo ideal. Por ahora, sólo hay un sonido en este Actor-Mixer, pero en el futuro, seguro que vamos a querer poner otros sonidos como por ejemplo un sonido de puerta. El flanger sólo queremos que afecte al teletransportador por lo que aplicárselo a todo el Actor-Mixer no es muy buena solución.

En cambio, podemos seleccionar la opcíón “Override parent” que verás en la parte superior de la pestaña “Effects”. Esta opción básicamente le dice a Wwise que este objeto va a ignorar la configuración heredada de su padre y va a tener una propia. Verás que la misma opción aparece en otros lugares de Wwise y siempre implica lo mismo: ignora la configuración del elemento padre y sigue la tuya propia.

Hecho esto, podemos crear nuestro efecto. Haz click en el botón y busca “Wwise Flanger”. En la ventana emergente, selecciona “Default Working Unit”. Una vez insertado, reproduce el sonido y puedes cambiar de preset con los botones que aparecen (“Prev, y Next). También puedes hacer click en “Edit” para ajustar el sonido a tu gusto.

Efectos mediante auxiliar

Cuando queremos aplicar un efecto a un conjunto de sonidos, la forma más cómoda en Wwise sería usar un bus auxiliar. Estos funcionan de una manera muy similar a los auxiliares en un DAW. Tienen además la ventaja de que estos buses auxliares pueden ser activados y desactivados desde el propio juego, a medida que se necesiten, de forma que el sonido original siempre queda inalterado.

Una de las aplicaciones más obvias de esto sería una reverb. No sería nada práctico aplicar reverb a nuestros sonidos mediante inserto, ya que entonces estaríamos alterando el sonido desde la raíz y no sería fácil ir cambiando de reverb a medida que la jugadora cambie de espacio. Los auxiliares son una mejor solución, ya que no sólo nos permiten ir cambiando de espacio, sino también hacerlo de forma gradual.

Vamos entonces a crear un bus auxiliar y una reverb en nuestro juego. En este caso, queremos una reverb para los pasillos del mapa. Si vas a la “Master-Mixer Hierarchy”, verás que además de crear buses, también tienes la opción de “Auxiliary Buses”. Crea uno que sea hijo de nuestro bus “Entorno”. Esto tiene sentido por que sólo queremos que los sonidos del entorno como pasos, armas o el teletransporte se vean afectados. Cosas como la música o una voz en off no deberían tener esta reverb por lo que tiene sentido crear este auxiliar como hijo de nuestro bus “Entorno”. Vamos a nombrar al auxiliar “env_corridor”.

Que el nombre esté en inglés ya te puede dar una pista de que este nombre no lo podemos cambiar. Esto es por que el mismo motor del juego sabe en qué zonas del mapa se debería usar una reverb de pasillo y cuando el jugador entre en una de ellas, va a llamar a un auxiliar con un nombre establecido en el código del juego.

Una vez creado el auxiliar, ve a sus insertos y crea una Wwise RoomVerb. Puedes usar un preset como Room_Medium por ahora u ajustarlo luego.

El sigiente paso en decidir a qué sonidos queremos aplicar el efecto. Vamos a ir primero al Actor-Mixer que hemos llamado “Jugador”. Verás que en el Property Editor, debajo del área dónde podemos elegir el bus de salida hay una zona para buses auxiliares. En el primero slot, selecciona nuestro auxiliar.

Si ahora seleccionas los pasos y los reproduces, verás que la reverb se está aplicando. Como puedes ver, también podemos controlar la cantidad de sonido que enviamos al auxiliar. Por defecto el valor es 0, que enviaría toda la señal en su nivel nativo.

Si te fijas, tenemos ahora un pequeño problema. El objeto “Salud” también está siendo afectado por la reverb, ya que estaba también en el mismo Actor-Mixer pero probablemente esto no es lo que queremos. Este sonido debería sonar siempre igual y la reverb del lugar en el que estemos no debería afectarle. ¿Se te ocurre como solucionar esto? La mejor manera sería usando la opción “Override Parent” y eliminando el envío al auxiliar para este sonido.

Ya tenemos un envío funcional pero, ¿Cómo sabe Wwise que el jugador está en una zona de reverb? Ahora mismo, tal y como lo tenemos todo configurado, estaríamos enviando nuestros sonidos a la reverb en todo momento sin ton ni son. Para poder controlar esto, una solución es relegar el control de los auxiliares al propio motor de juego. Elimina el envío haciendo click derecho y seleccionando “Set User Auxiliary Send 0” y “None”. Ahora, verás que en la parte superior podemos seleccionar “Use game-defined auxiliary sends”.

Fíjate que los nombres de todas estas opciones nos dicen perfectamente lo que están haciendo. User-Defined son envios que controlamos nosotros desde Wwise mientras que “Game-Defined” se controlan desde el código del propio juego.

En el caso de Cube, todo está configurado para que cuando la jugadora pise los pasillos, el auxiliar que hemos creado entre en juego y luego su volumen se desvanezca a medida que se aleje de ellos. Ya tenemos una reverb funcional en los pasos.

Ahora sólo nos queda repetir la operación y envíar todos los otros objetos sonoros que queramos a la reverb. Como puedes ver, los Actor-Mixers nos facilitan esta tarea. Recuerda que sólo queremos enviar los elementos que tiene sentido que se vean afectados como por ejemplo la escopeta mientras que el sonido ambiente probablemente no lo necesite.

Ya puedes re-construir el SoundBank y probar en el juego como queda. La reverb se aplica a las zonas que el juego considera pasillos. Si no las encuentras, nada más salir, a tu derecha tienes un ejemplo. Prueba a ajustar la reverb en Wwise para encontrar la que te guste.

Sumario

En esta quinta parte, hemos visto como podemos controlar el flujo de señal en Wwise además de los efectos. 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 esta parte. !Hasta la próxima!

  • Actor-Mixer: Objeto que vive en la jerarquia del mismo nombre y nos permite agrupar sonidos a los que queremos aplicar los mismos cambios parametrales. Estos cambios serán sumados a los parámetros que tengan los elementos hijos. Los Actor-Mixer no realizan ningún tipo de mezcla de sonido, sólo controlan parámetros.

  • Master-Mixer Hierarchy: Jerarquía que encontramos en la pestaña de “Audio” y dentro del layout “Designer” y nos permite crear diferentes buses.

  • Buses: Objetos por los que sí que fluye el audio y se mezclan los distintos elementos cuyas salidas dan a ellos. Serían el equivalente a un canal o pista en un DAW.

  • Master Audio Bus: Este es el bus en el que se mezclan todos los sonidos y efectos de Wwise y conecta directamene con nuestra tarjeta de sonido para poder escuchar.

  • Auxiliary Bus: Tipo de bus especial que nos permite enviar señal desde cualquier objeto sonoro para así aplicar un determinado efecto. Funcionan de forma similar a las pistas auxiliares de un DAW.

  • Auxilary Sends: Fundamentalmente, hay dos maneras de hacer un envío hacia un bus auxiliar:

    • User-Defined: Este es un envío manual (configurado en Wwise por nosotros) y que siempre estará activo todo el tiempo a no ser que cambiemos la cantidad de señal enviada mediante un RTPC o State.

    • Game-Defined: No podemos controlar la cantidad enviada desde Wwise sino que es el código del propio juego el que dicta cuánto envía y a qué auxiliar.

  • Voice profiler: Layout que nos permite ver visualmente todos las etapas por las que pasa un sonido hasta llegar a la salida master y así poder como cada uno le afecta en términos de volumen, pitch y filtros.

  • Efectos: De igual manera que en un DAW, puedes insertar efectos en cualquier objeto sonoro, Actor-Mixer o bus auxiliar.

  • Overrride Parent: Función que encontramos en muchos lugares en Wwise y nos permite ignorar la configuración del elemento padre para poder aplicar una diferente para un determinado elemento hijo.

Creating an Undipped M&E

/

What is an M&E

M&E stands for “Music & Effects”. You may also see it written as “ME” or “MandE”. In some places it is called “International Version” or “International Track”.

As the name suggests, the M&E is a stem that includes all the music, sound effects and foley but no dialogue. This stem is then used by dubbing studios to create a version in a different language.

If we are mixing a drama and this international version is required, every sound effect and foley element that was captured with the dialogue in location (like maybe steps, cloth movements, doors, etc) needs to be re-created since it will be lost when removing the original dialogue.

In the case of documentaries, we may keep the onscreen interviews audio for the international version (which will be dubbed on top in the new languague) but not include the voice over.

Creating and Using M&Es

When you build a mixing session, you need to consider the M&E so any audio with dialogue or even with any recognizable language (like an ambience track) doesn’t end up on the M&E. Specific reverbs per stem are also required if we want to deliver them more easily.

This is easy to achieve on any DAW with just buses and auxiliars. Here is a very simplified diagram showing how you a routing example. Bear in mind that this can get much more complicated fast as you add more tracks and deal with surround. I’ve also omitted VCAs and reverbs for the sake of simplicity.

As you can see, with this routing, the M&E Print would be free of any dialogue.

What is an undipped M&E and how is it useful?

In this context, “dipping” is simply the act of lowering the music and/or FX to acomodate dialogue or narration, as you can see on the picture below.

https://blog.frame.io/2017/08/09/audio-spec-sheet/

If we deliver an M&E created form the session above, you can see how the music would go down everytime there is dialogue on the mix which may not be ideal in some cases. So we would say that that M&E is dipped.

On the other hand, an M&E would be undipped if music and SFX levels don’t change to acomodate dialogue and instead are constant during the whole duration. Depending of the nature of the show we are working on, this may be what our client needs.

For cinema and dramatic content in general, a standard M&E (dipped) is usually sufficient since most dialogue has lipsync, meaning the person talking can be seen in shot when delivering the lines. Why is this relevant? Because when dubbing this kind of project into another language, the timing for each line is going to roughly be the same, so there the dips in volume will match.

But in the case of documentaries or some TV shows, things can be different. In this case, we may have narration or voice overs which don’t have any lip sync. We need to remember that some languagues are more or less condensed than others so narration may take more or less time.

So, imagine you give a dipped or standard M&E to the client and they start recording voice over on their languague. On this M&E levels are moving up and down to make room for the narration on the original language but these moves may not match the narration on the new one! In that case, they are going to be fighting our automation constantly to accomadate their newly recorded dialogue. Not ideal.

A better solution would be to give them an M&E that doesn’t dip at all, levels remain constant so that the dips can be done later, when the new languague is recorded. Let’s see how to do this.

How to create an undipped M&E

There are a few possible options on how to do this but this is what makes the most sense to me. Bear in mind that this basic structure may change (a lot) depending on the project’s needs. I think that, when possible, it is ideal to deliver both dipped and undipped to the client. My routing is build to do this. Let’s have a look:

As you can see, it looks a bit similar to the previous one but a bit more complex. The first thing to consider, is that we are now differentiating between synced dialogue and VO. This is because they need to be mixed in a different way. As you can see, only the VO is going to the Mix Master, while the synced dialogue is going to the M&E. This is not always the case, but is quite common to leave the original voice on an interview and dub on top of it with the new languague. Other than that, things flow in a similar fashion.

The other big concept to keep in mind is where to do automation. You would normally automate music on their own tracks and this is what we would do in our case but only for music that goes with synced dialogue. This is because in this case, we don’t mind having dips on the M&E. But for the case of music that goes with VO, we would have a problem if we automate the track itself, since all these changes are going to go directly to the M&E, which is what we want to avoid!

The solution then, is to do the automation on the M&E Master auxiliar everytime that the dips are around narration and VO. Once this is done, we can get two sends from this track. One of them would be a pre-fader send which would become our undipped M&E. The other would be post-fader send or just an output, which would be dipped. That way, we can easily bounce both. As you can see, I have labeled some tracks with A, B or C to indicate where the automation would be done.

The main drawback of this method is that, on occasion, you may feel like fighting between two automations (the track themselves and the M&E master auxiliar), specially when the editing goes from on screen interviews to narration very fast. I don’t see any good solution to this other than keeping the session tidy and making clean fader movements.

Something to keep in mind is that for some situations or for some people a better approach could be to do absolutely every music and effects automation on the M&E master and just don’t act diferently depending on dialogue having lypsinc. This could also work but it is a matter of taste and client needs.

Conclusion & Resources

So that’s pretty much it. This technique is a nice one to have on your toolbox. If you have been asked to deliver an undipped M&E now you know how to do it and why. This video below explains the same idea with some examples on a Pro Tools session. have a listen for extra info. Thanks for reading.

Tutorial Wwise en Español - Parte IV: Posicionamiento y Panorama

/

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.

Bienvenidos a la cuarta parte. En esta entrega, vamos a tratar unos de los temas que quizás es más diferente en el audio interactivo y supone un cambio de paradigma respecto al audio lineal. Se trata del posicionamiento y panorama de los sonidos de nuestro juego.

Si lo piensas, en los medios lineales como cine o música, la perspectiva sonora siempre es la misma. Si decides que una guitarra va a estar ligeramente a la derecha en el panorama, esta será su posición para todos los oyentes (siempre y cuando sus altavoces o auriculares estén correctamente configurados).

En cambio, en videojuegos tenemos muchas veces el caso de un personaje que anda libremente por un entorno 2D o 3D. ¿Cómo sabemos entonces de donde tendría que venir el sonido si el personaje no para de moverse?

Listeners & Emitters

Es por esto que los juegos usan estos dos conceptos que paso a explicarte. Por un lado, los listeners (“escuchadores”) son objetos que usa el motor de juego para determinar cuál es el punto en el espacio del juego que está recibiendo el audio. Son como unas orejas o micrófonos virtuales que van a recoger el sonido del entorno. Habitualmente el listener se coloca justo en la cámara que representa la visión del personaje, al menos en juegos en primera persona. Para juegos en tercera persona, es posible situar el listener en el propio modelo del personaje o bien el la cámara que estarás algo más atrás, esto depende del juego en concreto y su estilo.

Por otro lado, los emitters (“emisores”) hacen justo lo que te estás imaginando: hacer de puntos de propagación de un sonido en el motor del juego. En términos de Wwise, se suelen asociar concretamente con un evento. No todos los eventos usan un emitter pero normalmente todos los emitter conectan con uno o más eventos.

¿Por qué es esto útil? Porque el juego está constantemente calculando la distancia en 3 las coordenadas entre todos los emitters y el listener (que sólo suele ser uno). Esta distancia es transmitida desde el juego hasta Wwise en tiempo real.

Como diseñadores, nosotros no podemos controlar este constante flujo de información entre emitters y listeners pero sí que podemos determinar cómo estos datos vas a afectar a cada objeto para que, por ejemplo, un sonido se siga oyendo pese a estar bastante lejos (por que quizás es importante).

A tener en cuenta

Antes de entrar en harina es importante que tengas en cuenta que Wwise cambió en 2018 la forma en la que entiende y configura el posicionamiento y panorama. Lógicamente, yo voy a explicarlo de la nueva forma pero ten en cuenta que si encuentras información anterior a 2018 es posible que no se aplique a versiones más modernas de Wwise.

En todo caso, y para ayudar a los que quizás ya hayan usado Wwise antes y estén usando este tutorial como refresco, a medida que nos encontremos con algunas de estas diferencias conceptuales, mencionaré cómo se entendían antes y cómo se entienden ahora. Puedes encontrar la info completa sobre este cambio en este artículo oficial (en inglés).

ShareSets & Attenuations

De la misma manera que en la entrega anterior introducimos los GameSyncs, vamos ahora a utilizar la siguiente pestaña que la Designer Layout nos ofrece: “ShareSets”. En general, los ShareSets son un conjunto de configuraciones que cómo su propio nombre indica, se pueden compartir entre distintos elementos de nuestro proyecto. A diferencia de los GameSyncs, que conectan directamente con distintas variables del propio juego, los ShareSets funcionan internamente en Wwise en respuesta a diferentes condiciones y estados en el juego.

Uno de estos ShareSets se llama “Attenuation” y nos permite determinar cómo la distancia entre un listener y un emitter controla el volumen del sonido además de otros parámetros (como el pitch, un filtro paso alto o un ecualizador completo). En otras palabras, nos permite personalizar las curvas de atenuación de cada sonido para que podamos determinar cómo de rápido cae el nivel sonoro de un emisor a medida que nos alejamos de él en el entorno 3D.

Creemos entonces una curva de atenuación para Cube. Puedes continuar con el proyecto de Wwise que deberías tener de la parte anterior de este tutorial.

Desde el Layout Designer, selecciona la pestaña ¨ShareSets¨ y crea una nueva curva de atenución. En principio, puedes llamarla como quieras como por ejemplo, “atenuacion_objetos”.

Introducir un sonido en el espacio 3D

Vamos a poner en funcionamiento esta curva creando nuestro primer sonido con posicionamiento en el espacio 3D. Anteriormente, Wwise llamaba a estos sonidos simplemente ”3D” pero esto ya no es exactamente el caso. Explicaré un poco más sobre esto en breve.

Por ahora, necesitamos considerar qué sonido debería tener un posicionamiento fijo. Si lo piensas, desde la perspectiva del propio jugador, no hemos necesitado hacer esto hasta ahora por que los sonidos que hemos usado anteriormente, como pasos o la escopeta siempre iban a sonar en el mismo sitio con respecto al jugador. En otras palabras, son sonidos cuyo punto de origen se mueve con el jugador por lo que el emitter y el listener nunca se acercan ni se alejan entre sí, o dicho de otra manera su distancia relativa se mantiene constante.

¿Pero qué ocurre si necesitamos que un sonido tenga su propio posicionamiento independiente del jugador? Anteriormente, Wwise llamaba a estos sonidos “3D” pero son actualmente denominados “listener relative”. Es decir, estos son los sonidos en los que el listener y el emitter pueden acercarse o alejarse, tienen un posicionamiento relativo.

Veámoslo en acción. Vamos a introducir un sonido para el teletransportador que hay en Cube. Buscamos un sonido constante que indique al jugador dónde va a poder encontrar estos portales. Puedes usar este sonido o cualquiera de tu librería. Importa el sonido en un SFX Object y llámalo cómo quieras.

El sonido que te enlazo lo grabé yo mismo con un micrófono que registra campos electro magnéticos y usé un microondas como fuente. Si lo utilizas, vas a necesitar ir al Source Editor (doble click en el nombre del propio archivo de audio importado, no el SFX Object). Una vez en el editor, debes elegir un área del sonido que te guste y limitar el sonido a esa área usado los cuadrados blancos de la zona inferior. Luego, en el “Sound Property Editor” debes poner el sonido en loop y yo he ajustado un poco el volumen y pitch. Juega un poco con todos los parámetros hasta obtener algo que te guste.

Una vez listo, verás una pestaña llamada “Positioning” en el Property Editor. Aquí es donde vamos a poder determinar cómo se comportará el lugar de origen del sonido. Debes tener en cuenta que nosotros desde Wwise no podemos colocar un sonido en el espacio 3D del juego, es decir, no controlamos donde está el emisor, sólo podemos recibir información de este y decidir qué hacer con ella.

Es el equipo de programación y diseño los encargados de colocar el emitter en su lugar correcto, en este caso donde haya portales teletransportadores. Como decía antes, lo que sí es nuestro trabajo es detemrinar cómo esta distancia va a afectar al sonido.

Usando la pestaña de posicionamiento

Veamos qué opciones nos ofrece esta pestaña, voy de arriba a abajo. Para empezar, verás que podemos elegir qué porcentaje de sonido queremos enviar al canal central en una configuración surround. Esto por ahora no nos atañe pero es bueno que sepas que esto se puede controlar aquí.

A continuación, “Speaker Panning” nos permite decidir cómo va se va a dictar el posicionamiento de un determinado sonido. La opción por defecto, “Direct Assignment” va a obtener la posición del sonido de la relación entre el emitter y el listener, luego esta es la opción que nos interesa para un sonido 3D. Por otro lado, “Balance-Fade” va a ignorar cualquier emitter y listener y podremos determinar de qué lugar del campo estéreo o surround queremos que provenga nuestro sonido. Como podrás comprender esto sólo va a ser aplicable a sonidos cuya posición no cambia con el movimiento del jugador, es decir, los sonidos que tradicionalmente se han llamado “2D”. Veremos más tarde cómo funcionan estos sonidos.

“Listener Relative Routing” puede ser algo confuso. En general, necesitas que esta opción esté activa para casi todos los sonidos de tu juego ya que así te aseguras de que Wwise tenga en cuenta donde está el emitter y el listener a la hora de calcular todo lo relacionado al sonido. Hay situaciones en las que quizás necesites desactivar esta opción pero por ahora la podemos dejar tal cual casi en todos los casos.

“3D Spatialization” es donde podemos realmente decidir que nuestro sonido sea 3D. Por defecto, vemos “None” que implicaría que no hay ningún tipo de posicionamiento 3D. Esta es la mejor opción para elementos cuyos emitters no se mueven con respecto al listener (jugador) como por ejemplo la música no diegética del juego, el sonido ambiente o los pasos.

En nuestro caso, y para el sonido del teletransporte, sí que queremos posicionamiento 3D por lo que vamos a seleccionar “Position + Orientation”. Esto significa que Wwise no sólo tendrá en cuenta la distancia entre la posición del emitter y del listener sino también su orientación, es decir si el jugador está mirando hacia el portal, en la dirección contraria o cualquier estado intermedio.

La siguiente opción, “Speaker Panning / 3D Spatialzation Mix” nos permite combinar ambas opciones, es decir, nos da un crossfade entre el sonido posicionado en 3D dentro del motor de juego y uno cuyo origen viene determinado por la asociación a un determinado lugar en el campo estéreo o surround. Esta opción puede ser útil cuando un sonido es muy importante y no queremos que se pierda en la mezcla incluso cuando el jugador está muy lejos de la fuente del sonido.

Y ya hemos llegado al lugar donde podemos definir qué curva de atenuación queremos usar. Como puedes ver, podemos seleccionar “Attenuation” si queremos que nuestro sonido caiga en volumen a medida que el jugador se aleja del emisor. Como podrás imaginar, esto es lo que queremos que pase para la mayoría de los objetos del entorno 3D.

Ajustando nuestra curva de atenuación

Lo primero que necesitamos es hacer click en el icono con flechas y elegir la curva que creamos antes, “atenuación_objetos”. Una vez hecho esto, haz click en “Edit…” para configurar la curva.

La pantalla que encontramos aquí quizás te suene de cuando vimos los RTPC en la entrega anterior. De hecho, es básicamente la misma con la diferencia de que el parámetro que se controla es siempre la distancia entre el emisor y el listener y esto no se puede cambiar.

Puedes empezar por reproducir el sonido y cambiar la distancia con la bandera del gráfico. Cómo puedes ver, el nivel cae a medida que nos alejamos pero ¿cómo sabemos cuánto cambio es mucho o es poco? Para ello debemos tener en mente cómo funcionan las unidades de distancia en nuestro juego. Esto depende de cada caso, pero en Cube una unidad equivale a unos 0.25 metros aproximadamente. Esto te puede dar una idea aproximada pero la mejor manera es quizás probar en el propio juego hasta encontrar una curva que funcione. Esto no sólo implica que la sensación de distancia sea realista sino también que sea útil respecto a cómo funciona el juego. Es decir, si es vital para el jugador poder oír los teletransportadores para guiarse por el mapa en medio de una batalla, quizás nos convenga que el nivel no caiga demasiado rápido al alejarse de ellos.

Otro concepto importante a tener en cuenta es la distancia máxima, que puedes ver en la parte central dercha de esta ventana. Esta será la distancia a la que nuestro objeto ya no se escucha, es decir el nivel cae a cero. Es importante ajustar este valor bien por que nos va a dictar la escala de nuestra curva. En nuestro caso 50 es un buen valor ya que representaría unos 12.5 metros.

Ahora podemos alterar nuestra curva hasta encontrar una que nos suene bien a medida que alteramos la distancia. Muchas veces es una buena idea que el nivel no siempre igual de rápido sino más rápido al principio de forma que sólo oigamos el máximo nivel cuando estemos realmente cerca. Por supuesto, no hay reglas fijas en esto y experimentando es cómo puedes encontrar los valores que funcionan en cada caso.

Algo que también puedes probar es hacer que el filtro paso bajos también reaccione con la distancia de forma que perdamos parte de los agudos cuando nos alejamos del sonido. Esto es una buena forma de imitar lo que ocurre en la realidad, donde el aire puede absorber parte de estos agudos si el sonido recorre una cierta distancia.

Algo a tener en cuenta es que es posible que una vez ya tengamos nuestras curvas listas, más tarde durante el desarrollo del juego, cambie la escala que estábamos usando en las distancias y ahora nuestra curva es demasiado corta y larga. No es necesario re-hacer la curva a mano. Basta con cambiar la distancia máxima (por ejemplo cámbiala de vuelta a 100) para que la curva se re-escale.

Una vez listas nuestras curvas de distancia (y recuerda que luego las probaremos en el juego para poder hacer más ajustes) nos queda determinar cómo el ángulo de incidencia va a alterar el sonido. Para ello activamos el cono de atenuación (“Cone Attenuation”) y vemos que en el gráfico circular aparecen 3 zonas con distintos tonos de gris. Cuánto más oscuro es el gris, mayor es el ángulo entre emisor y listener siendo 180 el máximo, es decir en este caso el emisor (teletransporte) está detrás del listener (jugador). Puedes cambiar cómo de amplias o estrechas son estas tres zonas con los controles “Inner angle” y “Outer angle”.

Algo muy a tener en cuenta es que quizás pienses que en el gráfico el centro representa el listener (jugador) pero es justo al contrario, lo cual puede ser bastante confuso. El centro representa al emisor (que estaría estático en este gráfico) y el círculo blanco que podemos mover sería el listener (jugador), de forma que la línea dorada que sale de él nos dice hacia donde mira. Si intentas mover este círculo blanco verás cómo el ángulo y también la distancia afectan al sonido pero date cuenta de que no se está vambiando el panorama. Es decir si colocas el jugador a la derecha del emisor vas a poder oir cómo la distancia y el ángulo cambia el sonido pero el sonido no vendrá de la izquierda (que es donde estará el emisor). En otras palabras, este gráfico llamado “Attenuation Preview” es eso, una previsualización de la atenuación, no del panorama.

Ahora que tenemos claro cómo funciona, vamos a configurar el “Cone Attenuation”. El valor “Max attenuation” nos dirá cuánto cae el nivel cuando el jugador está totalmente detrás del emisor, es decir a 180º. -6dB es el valor por defecto y nos servirá por ahora pero puedes probrar otros. Por otro lado, también podemos usar el ángulo para afectar a un filtro paso alto y uno paso bajos. Prueba a añandir 20 como valor en el filtro paso bajos y escucha el resultado a medida que mueves el círculo blanco que representa al jugador. Verás cómo manteniendo la misma distancia pero cambiando el ángulo, el sonido se amortigua y cae en volumen cuando está detrás lo cual de nuevo imita a lo que ocurre en la vida real.

cono.png

Probando el sonido del teletransporte

A estas alturas ya sabes lo que necesitamos hacer para integrar un sonido nuevo en el juego. Tenemos ya el SFX Object configurado y listo pero aún nos falta el evento. Crea un evento llamado “Emitter_Teleport” y añádele una acción que reproduzca el sonido que acabamos de crear. Si tienes dudas, consulta entregas anteriores de esta serie.

Ahora sólo queda que añadas el evento al SoundBank (dentro del layout SoundBank) y generes un nuevo banco. Prueba ahora cómo el sonido se comporta cuando te alejas y te acercas. Intenta también ponerte de espaldas al portal para ver cómo eso afecta al sonido. Si vuelves a Wwise para ajustar la curva de automatización, recuerda que debes crear de nuevo el banco para oír los cambios.

¿Por qué usar curvas?

Quería remarcar que cuando hemos configurado la atenuación del teletransporte, no estábamos realmente cambiando los parámetros del SFX Object ni del evento si no de la curva de atenuación en sí que puedes encontrar en la pestaña “SharedSets”. Esto es tremendamente útil por que cuando continuemos trabajando en el juego podremos aplicar la misma curva a otros objetos como una cascada, una radio o un frigorífico. En general, nos servirá para cualquier elemento que queramos que tenga una curva similar.

Y si necesitamos que algún otro objeto tenga una curva de atenuación diferente (como por ejemplo con una caída en nivel más acusada) no tenemos más que crear una curva nueva y aplicarla a los elementos que deseemos.

Speaker Panning (antes conocidos como sonidos 2D)

Ya hemos aprendido a trabajar con sonidos que poseen un emitter situado en el entorno 3D del juego. Esto es muy útil pero no siempre queremos que un sonido provenga de un punto concreto. El ambiente o la música pueden ser ejemplos de eventos sonoros que no tendrán un emitter concreto sino que su lugar en el panorama surround se definirá de una forma similar a cómo lo hacemos en un DAW tradicional.

Wwise llama a este método de trabajo “Speaker Panning”, dando a entender que lo único que definimos es de qué altavoz o altavoces del entorno surround o estéreo provendrá nuestro sonido. Vamos a poner esto en práctica con un ambiente para nuestro juego. Crea dos nuevos SFX Object con este y este sonido u otros que prefieras.

Vamos a usar ambos sonidos para crear un ambiente general. Ve al primero de los sonidos y haz click en la pestaña “Positioning”. Debemos asegurarnos que “3D Spatialization” está configurado como “None” ya que no queremos ningún tipo de posicionamiento 3D del sonido. En “Speaker Panning” vemos que la opción por defecto es “Direct Assignement”. Esto significa que el sonido va a quedar posicionado según se determine mediante la relación emitter-listener.

Si en cambio eliges “Balance-Fade” verás que podemos hacer click en “Edit” para abrir una ventana donde podemos panear el sonido de una forma similar a cómo haríamos en un DAW. Como ejemplo, digamos que paneamos este sonido ligeramente a la izquierda como en la ilustración y un poco hacia atrás. Haz algo similar con el segundo sonido pero esta vez colócalo hacia la derecha.


Una vez listo, necesitamos un evento para disparar este ambiente que hemos creado. Podemos usar el evento “Map_Loaded” que creamos en la parte III. Re-construye la build y prueba el resultado. Quizás tengas que ajustar niveles un poco para equlibrarlo todo.

Ahora que tenemos un ambiente básico podríamos añadir algunos elementos que sí estén posicionados alrededor del jugador, en 3D. Por ejemplo, podríamos tener algunos pájaros. ¿Pero cómo podemos hacer esto si no hay emitters para los pájaros en el juego?

3D con posicion automatizada

Si vuelves a nuestro SFX Object del teletransportador y haces click en la pestaña ¨Positioning”, verás que nos hemos dejado una sección al final llamada “3D Position”. Aquí vemos que se nos ofrecen 3 opciones:

  • Emitter: Esto significa que la posición del sonido viene definida por el propio juego, es decir, donde el juego tenga posicionado el emitter. Esta es la configuración por defecto y la usarás en la mayoría de casos.

  • Emitter with Automation: Wwise va a usar la posición del emitter y luego además le va a aplicar una cierta variación o movimento que nosotros configuremos. Útil cuando quieres darle algo de movimiento y randomización a ciertos sonidos puntuales.

  • Listener with Automation: En este caso, Wwise va a ignorar al emisor (si es que lo hay) y simplemente usará la posición del listener. Esto es muy útil para sonidos que no están posicionados en el entorno 3D del juego (luego, no tienen emitter) y queremos que provengan de distintos lugares alrededor dle jugador.

Vamos a probar a usar esto para que nuestro sonido ambiente tenga más variedad e inmersión. Descarga este sonido y añádelo como SFX Object. Puedes también usar cualquier otro sonido pero asegúrate de que está aislado más o menos bien del ambiente en el que se grabó. Ahora ve al “Source Editor” y elige alguno de los sonidos. Usa los fades para que entrada y salida del sonido sea algo más suave.

Una vez listo, duplica este Sfx Object y repite la misma operación pero usando un graznido diferente. Intenta tener 3-4 diferentes. Una vez listo empaqueta estos objetos en un random container seleccionando todos y haciendo click en “New Parent - Randon Container”.

Vamos ahora al random container y tenemos que configurarlo para que actúe de la forma que deseamos. Esto te va a servir para repasar algunos concepto y quizás aprender alguno nuevo. Primero, vamos a encargarnos de que cada vez que se dispare nuestro container, este aparezca en un lugar al azar alrededor del jugador. Una de las maneras en las que podemos hacer esto es mediante la automatización 3D que comentamos previamente. Ve a la pestaña “Positioning” (dentro del random container).

Debemos definir la “3D Spatialization” como “Position” y la “3D Position” como “Listener with automation” ya que queremos que el sonido se distribuya en disintos lugares alrededor del jugador. Una vez hecho esto, hacemos click en “Automation”. Verás que puedes crear una serie de posibles caminos (“paths”), que el sonido seguirá tras ser disparado, pudiendo elegir entre ellos al azar. Crea unos 4-5 “paths” diferentes y haz que cada uno tenga un lugar diferente alrededor del jugador. Estos pueden ser simples puntos o líneas por las que el sonido se moverá durante su duración. También puedes alterar la altura del sonido (eje Z) para que los sonidos provengan de arriba u abajo pero en nuestro caso no es necesario.

Verás que debajo de la lista de “paths” aparece una sección llamada “Random Range”. Esta nos permite añadir cierta randomización a las coordenadas de nuestro sonido en los ejes que ves. Prueba a poner un poco en cada uno de tus “paths”. Left/Right es la que notarás más. En la sección “Play Type”, escoge “Random” y “Pick new path when sound starts” para que cada vez que un nuevo sonido sea llamado, este use un path diferente al azar.

Por último, nos queda definir cuándo queremos que nuestros pájaros se oigan. Fíjate en la configuaración que he usado en la imagen inferior. El “Initial Delay” me ayuda a que el sonido no suene nada más inciar la partida pero además he randomizado esos 3 segundos de delay para que puedan ser -1 o + 6 segundos. Esto quiere decir que cada vez que iniciemos el juego, el primer pájaro sonará entre el segundo 2 y el 9 lo cual nos da una buena variabilidad.

Por otro lado, he elegido un “Play Mode” continuo, con la opción “Loop” activada. Esto es por que queremos que nunca se dejen de oir pájaros durante toda la partida. El problema de esto es que estarían constantemente sonando por lo que necesitamos usar una “Transition” de tipo “Delay”. Con esto conseguimos que al menos haya 5 segundos entre un sonido y otro. Como puedes ver, yo además he randomizado este delay para que pueda ser entre 2 y 11 segundos.

Con toda esta configuración, conseguimos que los pájaros suenen con una frecuencia randomizada pero controlable y cada que suenen aparezcan en un lugar diferente del entorno estéreo/surround.

Ya sólo nos quedaría añadir este contenedor al evento que estamos usando para el ambiente, re-construir y probar el resultado en Cube. Te animo a que pruebes distintos ajustes hasta encontrar la que te guste.

Sumario

En esta tercera parte, hemos visto todo lo relacionado a panorama y posicionamiento. 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 esta parte. !Hasta la próxima!

  • Listener: Objeto que vive en el motor de juego (no en Wwise) y define donde es el punto de escucha para el jugador.

  • Emitter: Objeto que también vive en el motor de juego y que funciona como el emisor de un determinado evento sonoro.

  • ShareSet: Pestaña en el Layout Designer que agrupa varios objetos que son compartidos entre los diversos elementos de nuestro proyecto de Wwise.

  • Attenuation: Tipo de ShareSet que nos permite aplicar una curva de atenuación a cualquier objeto de nuestro proyecto. Esto nos permite controlar cómo la distancia entre su emitter asociado y el listener afecta a distintos parámetros sonoros.

  • Pestaña Positioning: Dentro de la ventana “Property Editor” donde podemos modificar todos los parámetros relacionados con un determinado objeto, esta pestaña todo lo que concierne a panorama y posicionamiento.

  • Speaker Panning: Dentro de la pestaña de posicionamiento, esta opción nos deja elegir entre:

    • Direct Assignment: La posición de un sonido se calcula a través de la distancia entre emitter y listener. (sonido 3D)

    • Balance-Fade: Se ignoran emitters y listeners y la posición se puede determinar como un balance entre los distintos canales del campo estéreo o surround. (sonido 2D)

  • 3D Position: Opción que nos permite posicionamientos avanzados y automatizables que pueden depender del emiter o del listener.

Tutorial Wwise en Español - Parte III: Game Syncs

/

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.

En esta parte 3 vamos a profundizar en cómo podemos recibir información desde el juego y usarla para alterar nuestros sonidos. Esta es una parte muy importante del trabajo de diseño en un juego puesto que queremos que el mundo sonoro reaccione antes las acciones que la persona que juegue realice.

Vuelta a Cube

Para esta parte del tutorial, vamos a volver a usar el primer juego que usamos, Cube. Puedes abrir el mismo proyecto que usamos en la primera parte o bien empezar de cero. También puedes abrir el proyecto original desde el launcher por si quieres echar un ojo, este es un proyecto mucho más sencillo que el de Limbo y puede ser didáctico ver cómo está organizado.

Game Syncs

En el Layout Designer, hasta ahora hemos ido trabajando con las tres primeras pestañas: Audio, Eventos y SoundBanks que nos han permitido hasta ahora administrar prácticamente todo lo necesario para introducir nuestros propios sonidos. Esto siempre y cuando el equipo de programación y nosotros nos pongamos de acuerdo en la nomenclatura. Recuerda que el nombre de los eventos y los soundBanks debe ser preciso puesto que en el código del propio juego estos serán llamados específicamente.

Ahora vamos a introducir la siguiente pestaña, Game Syncs, que, como comentaba en la introducción, nos permitirán recibir información del juego y cambiar cómo nuestros sonidos se comportan en tiempo real. Imagina por ejemplo que la cantidad de munición afecte al sonido del arma, la hora del día cambie el ambiente sonoro o pausar la partida cambie la música. Este es el tipo de cosas que podemos hacer con Game Syncs y, como eventos y SoundBanks, también necesitan de precisión en su nomenclatura. Veamos poco a poco los cuatro tipos que Wwise nos ofrece:

  • Game Parameters.

  • Switches.

  • States.

  • Triggers.

Game Parameters (RTPCs)

Este tipo es quizás el más intuitivo. Nos permite enviar a Wwise una variable que toma un valor numérico en un determinado rango. Ejemplos de Game parameters, también llamados RTPC (Real Time Parameter Control) serían la salud del personaje, la velocidad de un vehículo o los segundos restantes de partida. Cualquier cosa que se pueda describir con un valor numérico.

Fíjate también que en el nombre se incluye “Real Time” por que estos valores se están enviando a Wwise constantemente, de forma que los sonidos afectados reaccionan en tiempo real.

Vamos a crear uno de estos parámetros en Cube. Desde el Designer Layout ve a la pestaña de Game Syncs. Verás que hay una carpeta física por cada tipo de Game Sync. Dentro de Game Parameters, selecciona la Default Work Unit y crea un nuevo Game Parameter. Lo llamaremos “PlayerHealth”. Recuerda que este nombre ya viene definido en el código del juego por lo que debe ser exacto.

Verás entonces que en el Property Editor (parte central superior) puedes elegir el rango que tendrá nuestro parámetro. En este caso, la salud irá de 0 a 100. Recuerda si creáramos otro parámetro relacionado con distancia o tiempo, podremos elegir cualquier rango que tenga sentido y se haya consensuado con el equipo de programación. La distancia podría medirse en metros en juego de carreras o en años luz en uno de naves espaciales. También se podrían usar unidades arbitrarias que tengan sentido con el editor que se use para el mapeado. En cualquier caso es importante ponerse de acuerdo en este aspecto y tener una idea de la escala que estás usando en cada momento.

En nuestro caso, hemos determinado que la salud va de 0 (muerto) a 100 (vida máxima). Repito que esto no lo decidimos nosotros si no que se define en la programación del juego. También se nos requiere elegir un valor por defecto (Default). Como aparecemos en el juego con la vida al máxima, usaremos 100.

Aplicando RTPCs

Ya tenemos nuestro parámetro pero por ahora no está haciendo gran cosa. Vamos a crear un nuevo sonido de latido de corazón que sonará cuando nuestra salud es baja. Crea un nuevo SFX Object a partir de este sonido u otro que te guste similar. Esto me sirve para recordar que idealmente Wwise acepta audio sin comprimir por lo que en el caso de querer usar el audio que he enlazado habría que convertirlo en wav. Esto es aceptable para nuestras prácticas pero idealmente siempre debemos usar grabaciones originales y sin comprimir. Recuerda que al crear nuestro banco podremos determinar cuánto y cómo comprimimos el audio, pero esto lo veremos en más detalle en el futuro.

Nombra al SFX Object como quieras (recuerda que sólo necesitamos respetar los nombres de eventos, SoundBanks y Game Syncs). En el Property Editor ajusta su volumen y haz que se reproduzca siempre en bucle.

Una vez listo, necesitamos también crear el evento que va a disparar nuestro sonido. En principio, puedes pensar que sólo queremos lanzar este evento cuando nuestra salud baje de un cierto valor. Esta manera sería totalmente válida pero vamos a hacer algo más interesante. Nos convendría que el evento estuviera siempre reproduciéndose para poder ir introduciéndolo gradualmente. Crearemos entonces un evento llamado “Map_Loaded” ya que este evento se inicia cuando cargamos cualquier mapa y no se para nunca durante toda la partida. Una vez creado, no olvides asociar una acción de Play al objeto con el sonido de corazón que creamos previamente.

Puedes probar ahora a añadir este nuevo evento al soundBank y compilar un nuevo banco de sonidos. Si ahora juegas a Cube, notarás que el corazón suena todo el tiempo. Buena señal de que nuestro evento funciona pero desde luego necesitamos ajustarlo para que sólo se oiga cuando la salud sea baja.

Ajustando las curvas RTPC

Para ello ve al Layout Designer y selecciona nuestro SFX Object con el sonido de corazón. Si te fijas en el Property Editor verás varias pestañas. Normalmente hemos usado la llamada “General Settings” pero ahora es nuestro oportunidad de usar otra. ¿Ves alguna que te llame la atención? Bingo, hay una llamada RTPC.

Cuando la seleccionas, en un principio todo estará vacío. Lo primero que necesitamos especificar es a qué parámetro queremos afectar. En la parte inferior izquierda, selecciona el botón con flechas y elige “Voice Volume”. Ese será el valor que usaremos en el eje de Y. Para el eje de X, pulsa en el siguiente botón que ahora aparece y selecciona el parámetro que creamos al principio para la salud del personaje que estará en la ruta: Game Parameters > Default Work Unit > PlayerHealth.

Una vez listo nos aparecerá una gráfica que representa la relación entre la salud del personaje y el volumen del sonido del corazón. Fíjate que puedes cambiar el valor del parámetro (Player_Health) arrastrando la “bandera” que ves en el centro del gráfico. También puedes usar la barra espaciadora para reproducir el sonido a medida que cambias el parámetro.

Pronto te darás cuenta que las cosas están al revés de lo que pretendemos. Ahora mismo el sonido solo suena en su máximo volumen cuando la saludo es 100. Lógicamente queremos que ocurra lo contrario. Puedes usar los puntos en los extremos de la gráfica para cambiar los valores. También puedes crear nuevos puntos haciendo doble click y haciendo click derecho en la curva, puedes elegir una forma diferente como logarítmica o exponencial.

Una vez retocado, deberías tener algo parecido a lo que ves arriba. No oiremos prácticamente nada entre 100 y 50. A partir de ahí el nivel subirá hasta ser máximo con 0 salud.

Algo interesante que nos ofrece esta forma de editar parámetros es que podemos ajustar distintas cosas a la vez. La salud del personaje ya está afectando el nivel del sonido pero también podría afectar a un filtro de paso bajo. Para ello, debemos crear una nueva pareja de valores asociados tal y como hicimos antes usando los botones con flechas. Elige esta vez “Voice Low-Pass Filter” y el mismo parámetro “PlayerHealth”. Verás que aparece una nueva curva en otro color que podemos ver a la vez que al anterior siempre que tengamos ambas seleccionadas.

Ajusta esta segunda curva para obtener un resultado similar al anterior. Puedes escuchar el resultado a medida que cambias el valor de salud. En mi caso, he intentado que cuando empezamos a oír el corazón este suene más amortiguado, como si viniera desde detrás de una puerta y a medida que la salud baja el sonido de vuelve más claro y prominente.

También he añadido una tercera curva relacionado con el pitch (tono) para que el ritmo del corazón aumente cuando la salud baja de 20 a 0. Cuando termines, mueve la bandera mientras reproduces el objeto para probar el resultado.

Una vez listo, podremos crear un nuevo soundBank y probarlo en Cube aunque te darás cuenta de que no hay enemigos que te puedan “ayudar” a que tu salud baje. Podrías cargar otro nivel que tenga enemigos pero esto nos sirve para descubrir otra funcionalidad que tiene el transporte en Wwise.

Ve a al pestaña de Eventos y selecciona “Map_Loaded” que es el evento que estaba reproduciendo el sonido de corazón. Si reproduces el evento posiblemente no oirás el corazón puesto que 100 era el valor por defecto para la salud. si te fijas en la parte inferior central (dentro del Layout Designer) verás el transporte con el que podemos controlar la reproducción de objetos o eventos en Wwise. En el centro, puedes ver cuatro botones cada uno con el nombre de un Game Sync diferente.

Podemos usarlos para manipular los distintos valores que vendrían del juego en tiempo real si estuviéramos jugando pero con la comodidad de poder cambiarlos a nuestro antojo y con el juego cerrado. Puedes ver esto como una especie de “simulación” de lo que pasaría con un objeto o un evento cuando los valores se cambian de una determinada manera.

Si eliges entonces RTPCs verás que aparece “Player_Health” como opción. Esto es por que Wwise puede ver qué los objetos llamados por el evento “Map_Loaded” están asociados con ese parámetro. Puedes entonces reproducir el evento y cambiar el valor de la salud para ver si funciona como deseas sin necesidad de abrir las curvas RTPC.

Blend Containers

Ahora que tienes una buena idea de lo que es un RTPC, hemos sentado una buena base para comentar otro de los contenedores que Wwise utiliza. Recuerda que ya vimos los random containers que lanzan sonidos al azar partiendo de un conjunto y los sequence container que los lanzan en listas de reproducción.

El siguiente es el Blend Container. Como su nombre indica (blend se podría traducir como mezclar o combinar) este tipo de contenedor nos permite combinar diferentes objetos de una forma dinámica según como un parámetro o RTPC cambie.

Vamos a aplicar de nuevo esta idea a nuestro sonido de salud baja. El sonido de corazón quizás no es demasiado claro y fácil de oír en medio de una intensa batalla. Vamos entonces a añadir un segundo sonido que solo oiremos si la salud cae a niveles críticos. Importa este sonido u alguno otro similar que prefieras en Wwise. Una vez listo, selecciona este y el latido de corazón, haz click derecho y elige New Parent > Blend Container. Puedes nombrarlo “Salud” o como prefieras. Te debería quedar algo similar a la imagen inferior, con el Blend Container conteniendo a ambos sonidos.

Ajustando un Blend Container

Si ahora seleccionas este nuevo contenedor y echas un vistazo a la view “Property Editor” (parte central superior), verás que nos aparece una nueva opción llamada “Blend Tracks” y un botón para editar. Haz click en él y verás que todo aparece bastante vacío. Lo primero que necesitamos crear es una nueva “Blend Track”. Estas pistas son dónde vamos a poder alojar nuestras curvas que nos permitirán personalizar cómo se comportarán nuestros sonidos según cambien determinados parámetros.

Creamos una nueva que podemos llamar “Salud”. Una vez hecho esto, si vuelves a la ventana principal de Wwise y te fijas en la parte central inferior verás que se listan los “children” (hijos) que están dentro de nuestro blend container y a la derecha nos aparece la pista que hemos creado. Por ahora está vacía pero para solucionarlo sólo tenemos que arrastrar nuestros objetos a ella. Debería quedarte algo similar a lo que ves en la imagen siguiente.

Una vez listo, volvemos a nuestra ventana de edición del Blend Container (“Blend Tracks”). Verás en la parte superior izquierda una caja que podemos confirmar donde dice “Crossfade”. En nuestro caso este es el comportamiento que deseamos puesto que queremos que ambos sonidos se entremezclen paulatinamente. Una vez confirmado esto, verás que justo a la derecha un botón de vuelve clickable y ahora podemos elegir nuestro parámetro “Player _Health”.

Como puedes ver, por defecto el primer sonido (corazón) sonaría de 0 a 50 y el segundo de 50 a 100. Lógicamente, este no es el comportamiento que queremos. Lo primero que necesitamos hacer para hacer nuestra vida más sencilla es cambiar el orden puesto que solo queremos el Beep cuando queda muy poca salud. Puedes hacer esto en la lista de Blend Tracks que usamos antes. Una vez hecho esto, es sencillo ajustar los sonidos para que se solapen de una forma que nos guste. Recuerda que siempre puedes escuchar el container para ver como queda y también que todo el trabajo que antes aplicamos al sonido de corazón sigue funcionando. Debería quedarte algo similar a esto:

Una vez terminado sólo nos quedaría probarlo en el juego o usar el propio transporte de Wwise que como recuerdas nos ofrece la posibilidad de manipular cualquier RTPC mientras reproduces un objeto.

Espero que esto te de una buena idea del poder que pueden tener estos Blend Containers. Un uso muy común para ellos es para motores de vehículos de forma que podemos ir de un sonido menos revolucionado a otro más intenso según las RPM del motor. También quizás te diste cuenta que se usan en los pasos de Limbo para pasar de una superficie a otra (como tierra-barro-agua) y así poder controlar cómo de rápido es la fusión entre este tipo de sonido según te acercas a un lago, por ejemplo.

Switches & Switch Container

Y ya sólo nos queda por ver un último tipo de container, el Switch Container que viene asociado con otro tipo de Game Sync: Switches. De nuevo el nombre nos da pistas ya que switch significa intercambiar. Este tipo de contenedor nos permite cambiar de unos sonidos a otros según cambie este nuevo tipo de Game Sync. Veamos cómo funciona.

Si recuerdas, el anterior Game Sync que vimos es el Game Parameter o RTPC que suele recoger valores numéricos dentro de un rango y que describe diferentes variables en el mundo del juego. En cambio, los Switches nos ofrecen otro tipo de funcionalidad. En vez de usar un rango de valores numéricos, usan unos determinados estados pre definidos. En otras palabras, mientras que los RTPC miden cantidad los Switches miden calidad o tipo.

Para el juego de Cube necesitamos añadir pasos a nuestro personaje. Por suerte la programación del juego ya contempla esto y siempre que movamos al personaje, el juego va a estar pidiendo a Wwise que lance un evento de pasos. Hasta ahí esto funciona bien pero tenemos el problema de que podemos andar por distintas superficies como tierra, arena, metal, etc. Necesitamos entonces diferenciar entre todas estas superficies. Una manera de hacer esto sería que el programador pida un evento diferente en cada tipo de superficie.

Otra manera, quizás más flexible, podría ser definir el material de cada superficie del juego para que un único evento general de pasos se adapte y lance los sonidos apropiados en cada momento. La ventaja de este sistema es que podemos usar la información de estos materiales para otras cosas también como por ejemplo un sonido de salto o de cuerpo cayendo al suelo.

Para esto, creamos un Switch por cada superficie y los agrupamos en un Switch Group. Fíjate que los Game Parameters que vimos antes no se agrupaban de ninguna forma puesto que lo que los definía era su propio valor numérico pero en el caso de los Switches necesitamos siempre englobarlos en un Switch Group.

Otros ejemplo de uso de los Switches podría darse en un juego en el que podemos cambiar el motor de nuestro vehículo. Cada tipo de motor tendría sus sonidos asociados en un switch diferente y todos ellos se asociarían en un switch group que iría ligado al vehículo. Como puedes ver, en general, los switches son útiles cuando tenemos un número de opciones que el juego va a necesitar intercambiar según progrese la partida.

Definiendo los materiales en Cube

Lo primero que necesitamos hacer es crear un nuevo Switch Group. Si dentro del Layout Designer vas a la pestaña de Game Syncs verás una carpeta llamada Switches. Dentro de la Default Work Unit, crea un nuevo Switch Group y nómbralo “Material”. Una vez creado, podrás crear diferentes switches dentro de este grupo. Puedes pensar en un Switch Group como un interruptor y los Switches contenidos dentro como cada una de las posiciones en las que se puede poner dicho interruptor.

Crea pues un nuevo switch por cada material que usa Cube. Fíjate que los nombres están en inglés ya que el juego ya tiene pre establecido llamar así a cada uno de los posibles materiales. Cambiar estos nombres requeriría ponerse de acuerdo con el equipo de programación por lo que por ahora usaremos los que ya nos vienen definidos:

  • Concrete

  • Grass

  • Gravel

  • Metal

  • Sand

  • Stone

  • Tile

  • Water

  • Wood

Importando múltiples sonidos

Una vez definidos los materiales, lo siguiente que necesitamos es crear los pasos para cada superficie. Puedes usar aquí tus propias librerías si quieres pero para facilitar las cosas, lo más sencillo sería recurrir a los sonidos que venían con el tutorial oficial del curso básico de Wwise. Lo deberías tener de la parte primera pero descárgalo si no lo encuentras. Dentro de ese zip encontrarás los pasos en la siguiente ruta:

  • Wwise-101_v2017.2/Lesson 3/Audio files for Lesson 3/Footsteps

Para importarlos vamos a usar un nuevo método. Como habitualmente, haz click derecho en la Default Work Unit donde se alojan tus sonidos (carpeta “Actor-Mixer Hierarchy”) y haz click en “Import Audio Files…” pero esta vez elige “Add Folders…” en la ventana emergente y selecciona la carpeta entera llamada “Footsteps”.

Si te fijas, con esta opción Wwise crea una estructura de carpetas que usará cuando importe los sonidos. Esto es de gran ayuda, especialmente por que podemos modificarla a nuestro gusto antes de importar los sonidos. Verás que cada tipo de material (Concrete, Dirt, etc…) está organizado en carpetas virtuales y todos ellos están contenidos a su vez en otra carpeta virtual llamada “Footsteps”. Vamos a cambiar algunas cosas para ajustarlas a nuestras necesidades.

Para empezar, las carpetas que contienen cada tipo de material nos vendría bien que fueran Random Containers, ya que queremos que cada paso sea uno elegido aleatoriamente. Puedes cambiar esto con el menú desplegable que cada elemento tiene en la columna central. Una vez hecho esto, necesitamos cambiar también la carpeta principal llamada “Footsteps” en un Switch Container ya que vamos a usar nuestros materiales antes creados para decidir qué grupo es el que sonará. Al final, debería quedarte algo similar a esto:

Una vez importado, verás que se nos crea una bonita estructura de carpetas para la que no hemos tenido necesariamente que mover y colocar todo a mano. Quizás incluso te recuerde un poco a las jerarquías de carpeta que Limbo tenía y es que este tipo de organización es la mejor forma de mantener en orden de una forma lógica y funcional tus sonidos.

Asignando sonidos a materiales

Si ahora eliges nuestro nuevo y flamante Switch Group verás que en el Property Editor nos aparece una función nueva llamada “Switch”.

En ella, debemos primero seleccionar nuestro Switch Group, “Material” y también que Switch queremos que se use por defecto, que en nuestro caso será “Concrete”. Con esto, estamos diciendo a Wwise que utilice los Switches contenidos en este grupo como referencia y que en caso de no encontrar ninguno asociado use “Concrete”.

Ya sólo nos queda asignar los sonidos que queremos que cada material use. Te habrás dado cuenta de que tenemos muchos materiales y sólo 4 tipos de sonidos. Esto puede ser algo habitual durante el desarrollo de un juego, se utilizan primero sonidos provisionales que luego iremos sustituyendo.

Seleccionando aún nuestro Switch Container, verás en la parte inferior que de la misma manera que previamente podíamos asociar objetos a las distintas blend tracks de los Blend Containers, podemos también asociar los distintos objetos contenidos en nuestro Switch Container a los distintos materiales.

Screen Shot 2019-12-19 at 11.42.58.png

Por ahora no hay nada asociado pero podemos ir arrastrando el tipo de sonido que creamos mejor encaja con cada material. Recuerda que si dejas un material sin asociación, se utilizará el material por defecto que nuestro caso es “Concrete”. También ten en cuenta que puedes asociar el mismo sonido a varios materiales. Ve asociando sonidos según veas más lógico hasta obtener algo similar a esto:

Probando los pasos

Antes de probar en el juego, recuerda que puedes también usar el transporte de Wwise. Seleccionando el Switch Group que contiene todo los pasos, reprodúcelo y prueba cada una de los materiales.

Para poder implementar estos pasos en Cube, como siempre necesitamos un evento. Crea un nuevo evento y llámalo “Foot_Player”. Añade a este evento una acción que reproduzca nuestro Switch Container “Footsteps”. Si necesitas repasar cómo se hacía cualquiera de estas cosas, puedes consultar la primera parte de esta serie.

Ahora sólo queda crear un nuevo SoundBank (no olvides añadir el nuevo evento al banco) y abrir el juego para probar el resultado de nuestro trabajo. No hay demasiados materiales diferentes en el mapa por defecto pero podrás oír la diferencia de sonido en los pasos entre el interior y el exterior.

States

Ya hemos visto dos de los cuatro Game Syncs que Wwise ofrece. Por un lado, los Game Parameters nos permiten recibir información numérica desde el juego como el nivel de salud, velocidad de un coche o hora del día. Los Switches, en cambio, nos permiten comunicar a Wwise cambio cualitativos como por ejemplo qué material está pisando nuestro personaje o qué tipo de cañón se está usando en un arma.

Veamos ahora los States que pueden resultar conceptualmente un poco confusos al principio. Funcionan de forma similar a los Switches en el sentido de que no usan valores numéricos sino valores cualitativos determinados. Como los Switches, también se agrupan en grupos, en este caso en State Groups.

¿Cual es la diferencia entonces? Mientras que un Switch Group afecta de forma local a unos determinados sonidos (como los pasos que acabamos de implementar) un State Group se utiliza para eventos globales que pueden afectar a muchos sonidos a la vez.

Piensa por ejemplo que el material usado en los pasos se considera algo local por que cada entidad que se encuentre en el mapa (otros jugadores, enemigos…) estará utilizando su propia instancia de este Switch Group. Los States Groups, en cambio, se aplican a eventos globales como por ejemplo que el jugador haya pulsado pausa, esté en un determinado menú o se encuentre bajo el agua.

Estos eventos van afectar a como percibiremos varios sonidos a la vez. Por ejemplo, si el jugador se sumerge quizás queramos aplicar un filtro pasa bajos a todos los sonidos del entorno e incluso podríamos hacer que la música del juego suene más lejana y amortiguada.

La ventaja de los States es que podemos aplicar los cambios que asociemos a ellos de forma gradual pudiendo controlar cómo de rápidos son estos cambios.

Creando States

En Cube, podemos crear un State Group que reciba información del juego sobre el estado del personaje y en caso de morir, podamos hacer que por ejemplo nuestro sonido de salud baja se apague gradualmente. Recuerda que ahora mismo, el sonido de alarma que tenemos programado para la salud baja va a seguir sonando incluso aunque la salud sea 0 por lo que parece una buena idea hacer que se desvanezca cuando morimos.

Vamos allá pues. Sigue el mismo proceso que con los Switches pero esta vez elige crear un nuevo State Group bajo la Default Work Unit correspondiente, dentro de la pestaña de Game Syncs. Crea un nuevo grupo y llámalo “PlayerLife“. Dentro del grupo, crea dos estados, “Dead” y “Alive”. Recuerda que, como el juego ya está preparado para enviar las Game Calls con estos nombres exactos, es importantes mantener los nombres tal cual.

Una vez hecho esto, vamos a personalizar el comportamiento global que queremos que estos estados tengan. Selecciona el State Group “PlayerLife” dentro del Layout Designer y verás que en el Property Editor podemos crear transiciones personalizadas aunque por ahora aparece todo vacío.

Hacemos click en “Insert” para crear una nueva transición. En el campo “From” elegimos “Alive” mientras que en “To” seleccionamos “Dead”. Verás que podemos definir cuánto tiempo queremos que dure la transición entre ambos estados. En este caso, desde vivo a muerto queremos que dure unos 5 segundos para que los sonidos se vayan desvaneciendo lentamente. Creamos otra transición pero esta vez de muerto a vivo y hacemos que dure 1 segundo ya que cuando hagamos re-spawn queremos que los sonidos vuelvan a la normalidad más rápidamente.

Aplicando States a nuestros sonidos

Un vez los estados están definidos, debemos decidir cómo van a afectar a los distintos objetos que tenemos. Selecciona nuestro Blend Container “Salud” y fíjate que en el Property Editor tenemos una ventana que indica “States”. Selecciónala y añade el State Group que hemos creado. Como puedes ver, nos aparece varias maneras de manipular el sonido para ambos estados. En nuestro caso, lo que queremos es que el nivel del sonido caiga al morir por lo que en “Voice Volume” indicaremos -96dB en el estado “Dead” ya que este es el nivel mínimo que Wwise maneja. También podrías cambiar el valor “Voice Pitch” para que el tono del sonido caiga si el personaje muere. En el State “Alive” en principio no necesitamos cambiar nada.

Si quieres ver cómo queda y posiblemente ajustar los valores a tu gusto, recuerda que puedes reproducir el Blend Container y luego cambiar los valores RTCP y los States con las cajas que puedes encontrar a la derecha del transporte.

Como los States son de ámbito global, podemos afectar a muchos otros sonidos. Por ejemplo, podríamos hacer que cuando el personaje muere, siga oyendo los pasos y disparos de sus enemigos alrededor, pero muy amortiguados, como si estuviera perdiendo la conciencia. Puedes aplicar un cambio de estado similar al que ves en la imagen inferior a los objetos de pasos y disparo de escopeta. Esto haría que cuando muramos un filtro pasa bajos entre en acción gradualmente.

Por supuesto, ya que nuestro juego apenas tiene unos pocos sonidos, no podemos hacer mucho más con el estado de muerte, pero imagina las posibilidades. Quizás la música sonaría más lejana y con reverb, el ambiente exterior se apaga y suena distante y a los sonidos más cercanos les aplicamos un delay con feedback para obtener un efecto de aturdimiento.

En definitiva, los States nos permiten afectar globalmente a los sonidos y su mezcla para conseguir transmitir ciertos estados especiales.

Triggers

Si recuerdas nuestra lista inicial de Game Syncs, sólo nos quedan por mencionar los Triggers. No los vamos a ver en uso en este tutorial puesto que se utilizan para implementar elementos musicales. Los Triggers pueden básicamente disparar distintas frases musicales respetando el tempo y ritmo de una música de fondo. Se utilizan para crear una banda sonoara dinámica que reacciona a cómo el jugador interactúa con el entorno.

Sumario

En esta tercera parte, hemos visto los cuatro tipos de Game Syncs y algunos de los containers que llevan asociados. 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 esta tercera parte. !Hasta la próxima!

  • Game Syncs: Objeto que nos permite recibir información del juego y cambiar cómo nuestros sonidos se comportan en tiempo real.

  • Game Parameter o RTPC: Tipo de Game Sync con la que el juego nos puede comunicar una variable que toma un valor numérico en un rango determinado. Por ejemplo la salud del personaje, la velocidad de un vehículo o los segundos restantes de partido.

  • Blend Container: Tipo de objeto que nos permite combinar distintas proporciones de varios sonidos según cambie el valor de un RTPC.

  • Blend Track: Pistas especiales que podemos crear en cada Blend Container y nos permitirán personalizar cómo se comportarán nuestros sonidos según cambien determinados parámetros.

  • Switches: Tipo de Game Sync que en vez de usar un rango de valores numéricos, usan unos determinados estados pre definidos como si se tratara de distintos posibles valores en un interruptor. Se ajustan a determinados sonidos de manera local.

  • Switch Group: Conjunto de Switches.

  • Switch Container: Tipo de objeto que lee los valores que el juego manda para así determinar qué grupo de sonidos lanzar.

  • States: Tipo de Game Sync que usa valores cualitativos como los Switches pero se utiliza para eventos globales que pueden afectar a varios sonidos a la vez.

  • State Group: Conjunto de States.

  • Triggers: Tipo de Game Sync que se utiliza para implementar elementos musicales que se pueden disparar respetando el tempo musical.