Compartir
Trabajar en un desarrollo formado por diferentes equipos de por si es difícil, pero con un equipo de audio hay una complejidad añadida. La base de esta complejidad es educativa y cultural. Por una parte es educativa porque en los centros de formación no se educa de la mejor manera en la importancia de esta rama dentro de un desarrollo: en qué consiste, qué opciones hay, cómo conseguir un acabado sonoro profesional, cómo trabajar con gente formada en este apartado, etc. Y por otra parte es cultural porque, por lo general, el tema del sonido es algo considerado no tan importante por el desarrollador. Tener a una o varias personas de sonido dentro de un desarrollo es algo en lo que en estos momentos la industria española no está avanzada (salvo excepciones que confirman la regla). En este post voy a hablar un poco de las experiencias que he tenido y voy a dar los consejos que pueden ser útiles (o no) para que el trabajo con un equipo de audio termine satisfactoriamente.
Por una parte el problema más habitual y extendido que existe es la desconfianza del desarrollador hacia la persona encargada del sonido. Realmente es demasiado complicado convencer a un equipo para usar middleware en el proyecto. El middleware de audio es una herramienta fantástica, con unas opciones totalmente profesionales que correctamente usadas van a conseguir que el juego tenga un acabado sonoro profesional y de calidad.
Pero por lo general el equipo de audio no es quien decide las tecnologías que se deberían usar. Normalmente el equipo de programación es quien decide las herramientas que hay que usar para sonido, y hay que destacar que en todos los casos que esto me ha pasado no ha sido porque el equipo de programación conozca esas herramientas, sino que suele venir por una desconfianza desarrollada a partir del desconocimiento por esta tecnología.
Un ejemplo, hace poco me ha ocurrido que un equipo de programadores insistían en que no podía usar Wwise en el proyecto, “no sea que tocara algo que no debiese” (palabras textuales). Los programadores, por supuesto, era la primera vez que escuchaban hablar de Wwise. Un símil parecido (no es exactamente lo mismo, pero si puede servir para poner en situación) sería como si yo, un compositor musical y diseñador de efectos de sonido, le digo al artista que no puede usar Photoshop ni Illustrator y que debe usar Painter, por ejemplo, sin importar lo que el artista opine. Algo absurdo.
El middleware es una maravilla de tecnología, que en desarrollos independientes se puede usar de forma gratuita y que deja al equipo de sonido sacar lo mejor de sí, y lo que también es importante, crecer profesionalmente. Mi consejo en este tema es que si un equipo de desarrollo decide trabajar con una o varias personas encargadas del sonido, escuchen sus propuestas y sepan tenerlas en cuenta por encima de sus opiniones personales (que suelen venir desde el desconocimiento en el 99% de los casos), porque van a conseguir ahorrarse trabajo de programación en sonido (la implementación la hará la persona de sonido correspondiente), van a propiciar que el diseñador y/o compositor trabajen en un ambiente de confianza hacia sus posibilidades y van a poder crecer profesionalmente, porque aprenderán cosas nuevas en cada desarrollo.
Por desgracia, en España es muy fácil tocar techo -técnicamente hablando- en los desarrollos, porque solemos estar privados de muchas opciones de trabajo. Si tienes a una persona (o varias personas) con experiencia en sonido, formación y conocedores de las herramientas que podrían dar un salto de calidad al producto, lo mejor que se puede hacer es darles la confianza necesaria y las riendas del apartado sonoro del desarrollo. O al menos escucharles, no decidir por ellos lo que pueden hacer.
Esto sirve para enlazar con el siguiente problema añadido que suele haber en los desarrollos con equipos de sonido. El estudio por lo general no sabe de donde sale un profesional de sonido, no sabe que ha estudiado, como sabe lo que sabe y si realmente pueden fiarse de él. Hay casos en los que incluso da igual la experiencia que la persona de sonido pueda tener, siguen desconfiando. Tengo compañeros que han tenido que modificar cosas por obligación, porque el programador tenía un amigo que decía que sonaba alto, otro incluso que preguntaba si el diseñador había usado compresores. Y les obligaban a cambiarlo siguiendo los consejos (tóxicos, muy tóxicos) de esas terceras personas. Y así ocurrió.
Si en un desarrollo estás trabajando con una persona de sonido es debido a que nadie más del equipo está capacitado para hacerlo con una calidad final positiva y a la altura del proyecto.
Llegados a este punto carece de todo sentido quitarle importancia a lo que piense el encargado de sonido por dársela a un amigo, un familiar u otro desarrollador. Tan solo son opiniones, y como bien dijo Clint Eastwood “Las opiniones son como los culos: Todo el mundo tiene uno”. Recibir feedback es esencial en un desarrollo, pero no se puede dar más importancia de la que se debe frente a las decisiones que tome el equipo de sonido, y mucho menos sin consultarlas con ellos antes. Recientemente me he visto en la situación dentro de un desarrollo en la que el equipo había estado hablando con desarrolladores y otras personas sobre sonido (de los cuales 9,5 de cada 10 no se dedican a ello) y habían tomado una serie de decisiones totalmente perjudiciales para su desarrollo en el apartado sonoro sin antes habernos consultado si quiera al equipo de sonido.
Como conclusión os recomiendo intentar trabajar siempre que os sea posible con gente especializada en sonido. No solo por el enriquecimiento personal que supone compartir un tramo del camino con otra gente, sino por el enriquecimiento a nivel profesional que también va a suponer. Si trabajáis con una persona dedicada al sonido (o varias) lo mejor que podéis hacer es tenerle en cuenta para tomar todas las decisiones desde un principio, escuchar y valorar su opinión como una más. Generalmente se tratará de una persona con experiencia que sabrá que es lo mejor para el proyecto en su campo. Y si no tiene experiencia da igual, dejadle que la adquiera, todos queremos mejorar.
Por otro lado, no penséis que el encargado del sonido es alguien que debe mantenerse al margen del desarrollo, por favor incluidle en el proceso desde el día cero: que se familiarice con el equipo, con la tecnología, que vea el proceso que va siguiendo y participe en ello. Si por ejemplo tenéis 5 meses para trabajar en una demo no dejéis el apartado sonoro para las dos últimas semanas, porque si no todo va a ir mal. Muy mal. Terriblemente mal.
Tampoco decidáis por él lo que será mejor para su trabajo y para la calidad final. Duele mucho trabajar en un diseño de sonido elaborado y ver que la implementación no es la adecuada. La persona que hace el sonido debe ser quien lo implemente, porque esa persona es quien tiene en su cabeza como debería sonar en el juego y por qué hace ese sonido en particular, no un programador. Y si os pide usar middleware por favor dejadle usarlo, porque no solo le facilitará el trabajo a él y al resto del equipo, si no que se conseguirá un acabado final bastante superior. Un juego es una obra artística que generalmente se compone de un conjunto de aportes de diferentes personas. Dejar que cada uno ofrezca lo mejor de sí es fundamental.
Autor
Compositor musical y diseñador de efectos de sonido para videojuegos.
