¿Cómo es el trabajo de un Game Designer?

Javier Mombiela estudió el Grado en Animación y el Máster en Game Design de U-tad, y actualmente trabaja como diseñador de videojuegos en Ubisoft Reflections. Asegura que a veces cuesta hacerse a la idea de cuál va a ser el trabajo de un diseñador de videojuegos, y especialmente es difícil explicárselo a quienes tienes más cerca (pero no trabajan en este sector). “Tus padres te preguntan: ¿diseñador? ¿y qué haces? ¿dibujar?”.

Para explicar su labor profesional suele hacer referencia a la definición que da la diseñadora Liz England valiéndose del ‘problema de la puerta’. “Ella lo que dice es que si está haciendo un videojuego le van a surgir preguntas como: ¿queremos que haya puertas en el juego? ¿sí o no?; y seguirá preguntándose: ¿el jugador va a poder abrir esas puertas? ¿se abren todas las puertas? (porque hay puertas que son decorativas, hay puertas que son funcionales…) ¿Si soy un jugador cómo sé qué puertas puedo o no puedo abrir? ¿Puede pasar un enemigo por la puerta? Y, en caso de que pueda, ¿el enemigo puede abrirla? ¿Puede cerrarla?”.

Mombiela nos explica que su trabajo se centra especialmente en resolver esas preguntas, una detrás de otra, según van surgiendo. “Al final tenemos que resolver los problemas de cualquier mecánica, siendo una mecánica la acción que se quiere meter en un juego. Y cuando resuelves las primeras preguntas, aparecen más, y luego muchas más. Por eso me gusta utilizar el ejemplo de la puerta. Es claro, mundano y significativo”, añade.

Evidentemente el trabajo del Game Designer va más allá. Nos sumergimos en sus profundidades con los siguientes pasos que se convierten en el día a día de quien se dedica profesionalmente a este ámbito. ¡Toma nota!

 

• Siguiendo el ejemplo de la puerta, en mi trabajo – dependiendo del rango – tienes mayor o menor capacidad de entrar en el concepto del juego (lo que sería el alto nivel). En mi caso, como junior, mi trabajo empieza cuando me piden desarrollar una mecánica, un sistema, un objeto del juego como una puerta o un enemigo, el sistema de salto de un personaje, una progresión, una mejora, etc… Mi trabajo empieza cuando se me pide resolver algo.

 

• Lo siguiente que se suele hacer es buscar referencias. Juegas a otros juegos, buscas en sitios donde se haya podido hacer algo que pueda servir. Lo importante es buscar para construir algo de biblioteca en tu cabeza y saber qué han hecho ya otros para resolver tu mismo problema.

 

• Mientras se hace esto, en paralelo – aunque se puede considerar el siguiente paso – hay que hacer un primer documento de diseño de la mecánica, sistema, o del elemento que te hayan pedido. En él detallaremos cómo funcionaría lo que se nos han pedido, y que en cuanto tengamos los primeros bocetos tenemos que compartir con el resto del equipo. Al final, un programador – por ejemplo – va a necesitar ciertos detalles que se cubren en tu documento.

 

• Muchas veces mi rol o mi trabajo en el día a día es estar en el centro de todos. No quiere decir que mi trabajo sea más importante, pero estás en un sitio en el que todos los demás puestos y departamentos te pueden preguntar, y tienes que darles una respuesta. Nuestro objetivo es resolver una funcionalidad. No solo se trata de la funcionalidad en sí misma, sino de la funcionalidad en el juego. Es necesario ver dentro del conjunto. A veces pasa que te pones a diseñar y dejas de ver, pero hay que mirar alrededor para entender cómo encajarlo todo para que funcione.

 

• Dependiendo del estudio, se funciona de una manera u otra. Algunos lo hacen de forma más directa, comienzan a hacer implementaciones muy pronto. Nosotros tardamos un poquito más, solemos contar con un documento de diseño un poco más trabajado antes de empezar a implementar. Sea en el momento que sea, hay que hacer un prototipo sobre lo que estés desarrollando y, una vez esté implementado, se prueba. Le vas a encontrar mil fallos, saldrán mil preguntas nuevas, y toca resolverlas, así como los fallos. Hay cosas que en papel funcionan (el papel lo aguanta todo), el prototipo a veces no tanto. Aquí empieza ya el proceso iterativo.

 

• La mitad de tu jornada son reuniones. Hay que poner al día a los diferentes departamentos, pasas muchas horas compartiendo procesos, porque es muy importante estar al tanto sobre lo que se está haciendo. Cuando tenemos algo un poco más cerrado y funcional es cuando intervienen el resto de los departamentos afectados (un programador tendrá que pensar cómo hacer para que un enemigo entre por la puerta. Un diseñador de niveles tendrá que ver dónde va a colocar esa puerta, etc.). En este momento van a ir surgiendo más preguntas, y hay que resolverlas consultando a diferentes departamentos. En el tiempo que tienes tienes que tratar de que lo que estés haciendo cubra todas las necesidades que vayan surgiendo.

 

• Después, cuando parece que las cosas funcionan, hay algo muy importante: hay que probarlas con gente que no esté todo el día jugando al juego. A veces estás mucho tiempo con algo, parece que todo el mundo está contento, pero después lo testeas y no se entiende, nadie sabe qué hacer con algo concreto que has implementado. El feedback es muy útil. Te das cuenta de que quien está jugando no está entendiendo lo que está ocurriendo, por lo que tratas de averiguar por qué, para saber dónde está el problema. Es un proceso de darle vueltas, de decir: tengo esto, entra más gente, lo tratas de mejorar, lo pruebas con más personas, y se sigue tratando de mejorar. Cuando se te acaba el tiempo todo debe estar lo mejor posible.

 

—-