Comunidad orientada al desarrollo de videojuegos

Desarrollo de Dictator’s Inferno

@theHansel, el ganador del Reto GameDev 2013, ha accedido a contarnos como ha sido su experiencia en la participación en el concurso y el desarrollo de Dictator’s Inferno. ¡Muchas gracias y enhorabuena!

 

Captura de pantalla 6

Tras lanzar Starzzle (posiblemente nuestro mejor juego hasta el momento) y después de 6 meses de desvaríos, desajustes y mil cambios absurdos no programados en el desarrollo, por fin, hace ya dos años, conseguimos publicar Plugemons: Part 1 (y última, de momento) en el servicio online Xbox Live Indie Games para la consola Xbox 360. Desarrollado en XNA mediante C# el juego conllevó mucho más esfuerzo del previsto, convirtiéndose en una fuente de auténtica frustración para lo que acabó siendo. Ni siquiera llegamos a subir una versión totalmente acabada (sólo hay que ver el nombre), al menos no teniendo cuenta lo que habíamos pensado inicialmente que sería. Basta decir que la idea original que manejaba el reducido grupo de compañeros con el que trabajo era algo muy similar (por no decir prácticamente igual) al que poco después se convertiría en uno de los mayores éxitos del servicio: Cute Things Dying Violently. Un juego simple de jugar, de mecánica sencilla y apto para consola y móviles. Hecho por otros, por supuesto, nosotros siempre hemos sido especialistas en llegar tarde a los sitios. Por contra, con Plugemons acabamos creando un plataformas cooperativo de control tosco y niveles pensados de un día para otro, incluso de una hora para otra. Y encima pocos. Un desastre, tarde y mal. Al menos conseguimos clasificarnos para la final de Dream Build Play de ese año, seguramente porque el montaje gráfico y las ideas del juego tampoco eran tan malas a fin de cuentas. Supongo que de todo se aprende.

Captura de pantalla 2

    Aunque nuestras pretensiones de futuro siempre han sido y son ambiciosas la realidad es que nosotros veníamos de desarrollar juegos relativamente simples estilo Avatar Street Basketball o Avatar Insane Race 3D porque pensábamos que lo simple era lo más fácil de vender en relación a lo que costaba de crear, sobre todo para un equipo tan pequeño como era el nuestro. Y la verdad es que siguiendo esa filosofía nos había ido bastante bien. Además habíamos tenido una mala experiencia con nuestro primer juego, Ectoplasmic Wars (el desarrollo se estiró demasiado), y no estábamos dispuestos de nuevo a tirar nuestro tiempo de manera tan infructuosa. Es cierto que no podíamos estar demasiado orgullosos pero tampoco era nuestro plan, preferíamos ganar experiencia haciendo cosas pequeñas e ir hacia arriba poco a poco. Más o menos sabíamos dónde estábamos. Pero cuando hay demasiadas cabezas pensando sobre un proyecto siempre parece que se pueda ir más allá de tus posibilidades y todo el mundo tiene una gran idea que quiere ver convertida en realidad. Si bien con Starzzle dimos un paso en la buena dirección la verdad es que sus ventas fueron vergonzosas. Cuatro meses para crearlo y una miserable recaudación fueron una patada considerable en las gónadas. Lo de Plugemons ya fue la puntilla. Por suerte de todo aquello salió algo bueno y es que conseguimos desarrollar un mini-motor lo suficientemente válido como para crear cosas mejores de cara al futuro partiendo, eso sí, de lo que ya había usado antes en Starzzle. Usando el editor Gleed2D y manteniendo el framework teníamos una herramienta muy potente para poder evolucionar hacia cosas mejores. Pero como suele pasar aparecieron otros proyectos que requerían de mucha más atención (no nos dedicamos en exclusiva a videojuegos) y el tiempo usable fue desvaneciéndose hasta convertir en un lujo poder lanzar algo nuevo (aunque conseguimos sacar adelante varios proyectos pequeños como Avatar Thunder Cars o Starzzle Seassons). Tampoco estábamos demasiado ilusionados, la verdad.

Captura de pantalla 3

    Sin embargo de todo aquel mal momento empezó a crecer un proyecto que nos llamó poderosamente la atención desde el primer instante: Adolf Must die!. En un principio iba a ser un “salto-me-agacho” simplón de los que hace un par de años abundaban, una mezcla entre Tiny Wings y Jetpack Joyride, donde un dictador llamado Adolf recién llegado al infierno intentaba llegar lo más lejos posible antes de su inevitable y horrible muerte. Creo que la idea era muy llamativa, casaba muy con el contexto de crisis actual en el que estamos sumergidos, y el personaje principal era lo suficientemente interesante y polémico como para haber llegado a triunfar, aunque fuera sólo un poquito. Pero volvimos a las andadas y lo que iba a ser algo simple y rápido empezó a complicarse y llegados a ese punto todo se detuvo durante un tiempo. Y entonces llegó el Dream Build Play de ese año y por tradición nos tuvimos que presentar. Para ello terminamos el prototipo del juego y creamos 30 niveles bastante potables donde Adolf tenía que morir una y otra vez para así descubrir el camino a base de mancharlo con su propia sangre. Suena mucho más macabro de lo que realmente acabó siendo. El objetivo era siempre el mismo: encontrar un disfraz de piña para poder meterse de esa guisa en su propio culo para poder acceder al siguiente nivel, en un claro homenaje a la película Little Nicky. Un ensayo-error continuo que requería de mucha habilidad y que se hacía casi imposible según se avanzaba por la cantidad de trampas y enemigos que impedían el paso. Para hacerlo compatible con las normas de DBP pensamos que sería mejor eliminar toda la simbología del juego, convertimos a Adolf en un dictador más genérico (en realidad apenas lleva una barba y un sombrero para disimular), añadimos CENSORED encima de cada elemento susceptible de ser irrespetuoso para el jurado (véase culos) y lo pasamos todo al blanco y negro, excepto la sangre, que mantuvo su rojo intenso. Por último cambiamos el nombre a Dictator’s Inferno para eliminar cualquier referencia al líder alemán. No conseguimos clasificarnos ni para la final, ni lo llegamos a sacar a la venta (ni para WP7, que también tenía su respectiva versión) pero es de las pocas creaciones de las que es difícil arrepentirse. Era algo personal que queríamos hacer y que hicimos por gusto, prácticamente como entretenimiento. Y con eso teníamos suficiente.

Captura de pantalla 4

     Hará un año empezamos a tantear Unity3D debido a un proyecto que surgió en paralelo con otra empresa, también Valenciana. En teoría sólo se iban a involucrar los dos grafistas, modelando y animando todos los assets del juego. La realidad es que en la otra empresa no tenían demasiada experiencia (por no decir ninguna) y no sabían por dónde tirar en casi ningún aspecto. Empezaron con Mermalade pero era demasiado complicado y ahí es donde nosotros mismos entramos a buscar una solución a ese respecto, aunque no era nuestra competencia. Y pensamos en Unity. Tras trastear un rato y ver lo sencillo que era su uso hicimos una primera demo usando los assets que estaban hechos hasta ese momento. Viendo el resultado la otra empresa no dudó en elegirlo para sus propios fines. Mi trabajo durante los últimos 8 años se había  centrado en OpenGL, Ogre3D (gran motor gratuito con una gran comunidad detrás) y C++. Por otro lado creábamos juegos para la consola y WP7 con XNA y C#. Unity me ofrecía algo muy diferente a lo que estaba acostumbrado y la verdad es que nos supuso un paseo en comparación. Todas las complicaciones derivadas de tener que crear uno mismo casi todo desaparecían de golpe, todo parecía estar pensando para que el programador hiciera lo mínimo posible y para que el grafista no tuviera el más mínimo quebradero de cabeza a la hora de representar lo que quería. El editor era potente, se podía elegir entre C# y JavaScript para el scripting, enlazar elementos era tan simple como un click’n drag y para ver el resultado bastaba con darle a play, pudiendo encima editar en tiempo real todo aquello que quisiéramos. Sólo el hecho de arrastrar un fbx y ver su animación al momento ya era la leche. Es obvio que con el tiempo sí le hemos encontrado taras y muchas cosas que mejorar, aspectos que seguro que los propios creadores del motor tienen en mente para futuras versiones, pero la realidad es que a nivel práctico ha sido un verdadero soplo de aire fresco. No hay comparación posible en cuanto a facilidades. En cierta manera nos ha devuelto la ilusión al evitarnos trabajo que de otra manera sería demasiado costoso para tan pocas personas. Por desgracia no sirve para todo ni es la solución óptima siempre, así que hemos seguido desarrollando en C++, Java o Javascript todo lo que ha sido necesario. Cada lenguaje y cada herramienta tienen su lugar. La de Unity es crear videojuegos y eso se nota.

Captura de pantalla 1

Para aprender a manejar en condiciones el motor pensamos en retomar Dictator’s Inferno y darle una vuelta al concepto, así no había que rehacer los assets. Ya no sería sólo en 2D, también contendría algo de 3D, aunque de primeras no teníamos claro sí sólo sería a nivel gráfico o si afectaría al plano jugable. Sintiéndome más cómodo con C# (por cercanía con XNA) empecé a investigar. Hoy día Unity cuenta con herramientas para crear juegos 2D que en su momento no pudimos usar y, aunque, tengo entendido que tampoco son ninguna maravilla, seguramente hubiéramos hecho uso de ellas. Como programador muchas veces tengo que tomar decisiones que pueden gustar más o menos pero siempre intento facilitar la vida del equipo. El ejemplo más claro es el uso de spritesheets. Un spritesheet es algo muy cómodo para empaquetar texturas, a nivel de rendimiento reduce los accesos a memoria una barbaridad y bien usados también minizan el tamaño al limitarlo todo a un desplazamiento sobre la textura. Pero son muy complejos de usar para una grafista y les hace la vida imposible a la larga, sobre todo si no use tienen programas específicos para empaquetarlos. Por la naturaleza de nuestro trabajo principal usar spritesheets hubiera sido un infierno al requerir de cambios en texturas de manera continua y cuando empezamos con esta versión de Dictator’s tampoco quise recorrer ese camino. Mi alternativa: un diccionario de texturas previamente precargadas. Penaliza el rendimiento pero cuando buscando el equilibrio siempre me ha parecido. Curiosamente en la Xbox original no me quedó más remedio debido a que múltiples texturas multiplicaban los tiempo de carga desde disco hasta 20 veces mientras que en WP7 era al revés, los spritesheets convertían la carga en una eternidad.

Captura de pantalla 8

    Por lo demás, y teniendo en cuenta que casi todo lo complicado ya viene fabricado con el motor, lo más complejo de todo el framework que acabé montando fue el manejo de escenas. A nivel técnico Unity es simple en ese sentido, puedes cargar y descargar sin problema en cualquier momento. El desafío  viene cuando necesitas mantener coherencia entre ellas y poner algo encima que se dedique a controlarlas y mantener el estado global del juego. Para ello nada como escribir DontDestroyOnLoad en el Awake del objeto que quieres mantener inalterable. Seguramente haya otras soluciones mejores. En cuanto al juego en un arrebato de lucidez decidimos rescatar los portales de Plugemons y los extendimos en el eje Z, ampliando de paso la jugabilidad. También eliminamos el ensayo y error para convertirlo en una mezcla entre plataformas, puzzle y laberintos. Intentando darle un toque de variedad añadimos fases en el espacio, situando la acción en planetas circulares donde la gravedad se altera de uno a otro. La acción se desarrollaba en el infierno, el lienzo permitía casi cualquier escenario. Y una cosa llevó a otra y el haber ampliado el nivel gráfico por un lado nos demostró que aquel gracioso personaje en 2D podía cohesionarse con casi cualquier tipo de lugar, aunque fuera realista, buscando la coherencia del conjunto precisamente en la total falta de la misma. Para ello tuvimos que ampliar mucho el nivel gráfico respecto al original. En cuanto a la jugabilidad lo peor vino con las colisiones y los saltos. Usar un motor 3D limitado a 2D para detectar correctamente todo se hizo un poco cuesta arriba y el tema de los planetas y su gravedad no hizo más que aumentar los problemas. Lo peor fue dar con la manera de que el personaje no tuviera fricción alguna al saltar contra una pared, cosa que limitaba mucho el salto. Al final optamos por una solución ligeramente extraña, poner al propio personaje un material sin ninguna fricción en su interacción, y limitar su velocidad y movimientos completamente por código. Con todos los problemas de física aparentemente solucionados sólo nos quedaba ir creando niveles.

Captura de pantalla 9

    Casualidades de la vida coincidiendo con el desarrollo surgió el Reto Gamedev ,así que aprovechamos para lanzarnos a una plataforma nueva como era Windows 8.1, a la espera de que se libere la versión de Unity que permite publicar en Xbox One.Y aquí estamos, a la espera mientras seguimos desarrollando nuestro próximo proyecto, que esta vez sí será algo más grande de lo habitual (en todos los sentidos).

, ,

Leave a Reply