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.

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.

Screen Shot 2019-12-19 at 15.05.00 1.png

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.

Blog

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