No se lo que hice – Postmortem

Durante el último fin de semana se llevó a cabo la gamejam de GranadaJam en la que tuve la suerte de participar con un equipo magnífico y me divertí muchísimo. Quiero compartir con vosotros el postmortem del juego que logramos entregar: “No se lo que hice el Último Verano“.

El equipo y la presentación del tema

Tuve la tremenda suerte de tener un equipo lleno de talento y que se compenetraba a la perfección.

A los dos programadores, Laura y Sergio, se unieron una excelente artista 2D, Elena y un productor de audio muy experimentado, Elior. En la parte final del post os acompaño enlaces a sus páginas y portfolios para que podáis contactar con ellos en el futuro.

La presentación del tema vino a cargo del Fernando Ruíz L_draven, cuyo canal de youtube es famoso por sus tutoriales sobre iniciación en el desarrollo de juegos y las herramientas más usadas el mismo. De entre los temas propuestos, Fernando se decantó por “¿Quién soy yo?”.

Casi todos los participantes coincidimos en que era un tema muy interesante por la flexibilidad que nos otorgaba a la hora de generar mecánicas e historias.

El brainstorming

Sentados a la mesa y con la “orden” estricta de no censurar ninguna idea de primeras, comenzamos a tomar nota de todo lo que se nos ocurría para ilustrar el tema.

Los temas más comunes fueron los primeros en salir, como hacer un simple “Quién es quién” o el juego del personaje misterioso. Las ideas giraron desde los juegos más mecánicos hasta otros más basados en la narrativa (identidad de género, disociación, generación de comportamientos…) que se fueron descartando por una u otra razón.

Las limitaciones autoimpuestas (podéis consultar mi artículo sobre generar ideas en el que hablo sobre ellas) que más permitieron acotar las ideas e ir afinando el concepto que surgió al final venían de la propia composición del equipo. El tener una excepcional artista 2D nos hizo abandonar los conceptos relacionados con el 3D o las perspectivas en primera persona. Además su deseo de probar con el pixel-art nos animó a buscar estéticas que encajaran bien con ese estilo. El contar con dos programadores hizo que también tendiésemos más hacia mecánicas propias que a la narrativa o juegos utilizando librerías públicas (aunque alguna usamos).

Finalmente el concepto cristalizó. Buscamos un poco el humor y desarrollamos un juego en el que las últimas personas conscientes en una fiesta pasada de rosca dan tumbos etílicos por una casa llena de obstáculos con el potencial de dejarles en ridículo. El último en pie conseguirá grabar a todos los demás y subir el vídeo a youtube donde se hará viral. La integración con el tema, por tanto, era la respuesta a la pregunta “¿Quién era yo anoche? ¿El que se puso en ridículo o el que grababa el vídeo?”

Y recordad: ¡Bebed siempre con moderación!

El concepto

postmortem noseloquehice

El juego requería de una IA basada en necesidades. Cada personaje deambularía por la casa buscando satisfacer una serie de necesidades que irían modificándose en el tiempo y les haría buscar la habitación que les permitiera satisfacerlas. El personaje que representaba al jugador estaría marcado con una flecha y sólo podría intercambiarse por otro personaje presionando la barra espaciadora cuando se cruzase con otro personaje. El jugador recibiría feedback de hacia dónde se dirige cada personaje mediante las frases que los mismos irían diciendo cuando las necesidades cambiaran y de esta manera podría “saltar” al personaje que más le conviniera en cada momento, esquivando así los obstáculos que periódicamente iban apareciendo por la casa.

Una mecánica relativamente simple (el salto entre personajes) que tenía muchas posibilidades de generar momentos de tensión, al ver como tu personaje va irremediablemente hacia la perdición mientras rezas para que otro de ellos se cruce en tu camino y así saltar y evitarlo.

Para darle a todo un punto cómico, los nombres de los personajes salían de la lista de participantes de la jam. Las frases que cada uno decía también estaban escogidas para hacer escapar una sonrisa o hasta una carcajada al jugador. Incluso los sprites y las animaciones buscaban este sentimiento.

La realización

Con un sistema de control de tareas tan simple como efectivo (post-its que se ibancontrol de tareas rompiendo al terminar cada una), comenzamos montando el entorno principal. Sergio trabajaba en la programación gráfica mientras Laura se ponía con la IA y la mecánica básica. Elena dibujaba sprites y más sprites sin parar (¡¡Realizó más de 200 en 48 horas!!), mientras yo montaba las animaciones y los prefabs e iba redactando todo el texto. Sergio fue el encargado también de integrar los temas musicales que Elior iba creando para la ocasión.

Todo funcionó a las mil maravillas salvo algunos problemas con la IA que se empeñaba en hacer cosas que no estaban en los planes, pero Laura la fue domesticando poco a poco. Los ajustes de la cámara para que respetasen el “pixel perfect” funcionaron también maravillosamente bien salvo algunos momentos puntuales.

Algunas animaciones costaron un poco, pero el feedback constante entre Elena y yo creo que dio un resultado final bastante decente. Ella tuvo una paciencia infinita conmigo y eso es algo que le agradezco mucho.

Elior no sólo desarrolló varias melodías de fiesta para que fueran apareciendo y entremezclándose, sino que trabajó con sonidos del exterior para dar una sensación de profundidad que simulaban muy bien el entorno de la casa.

El mayor problema nos vino originado por el control de versiones de Unity: Collab.

Durante el fin de semana estuvimos trabajando prácticamente en tiempo real, llegando casi a un centenar de commits. No teníamos que detenernos dado que trabajábamos en escenas distintas y siempre con prefabs, por lo que al hacer cualquier cambio en uno de ellos sólo teníamos que recargar la escena para que los cambios se aplicaran automáticamente.

El problema vino cuando la animación que preparé para uno de los prefabs rompía la IA del personaje. Cuando al fin detectamos el problema decidimos que daríamos a revertir ese commit, de manera que el prefab volviera al estado anterior. Lo que no sabíamos es que el revert iba a descartar los cambios que Laura llevaba haciendo en el script de la IA toda la mañana y que sólo tenía guardados en local. Un control de versiones normal (como git) te avisa cuando hay cambios en local sin guardar en la nube que pueden sufrir daño si se hace cualquier acción. Pero Unity no nos avisó de esto. El resultado fue que Laura perdió todo lo que había hecho esa mañana. Un juego que estaba casi terminado y preparado para el testeo pasó a estar roto.

Laura se autosometió a un crunch brutal que le valió para reconstruir el trabajo perdido en un tiempo record, pero el debug que hizo falta para poder montar el build que íbamos a presentar nos dejó sin casi tiempo para testear adecuadamente el juego. Esto ha hecho que el juego haya quedado considerablemente flojo. Si bien es algo que podremos corregir más adelante.

Que funcionó

  • El brainstorming: Todos los miembros del equipo participaron en el proceso de generación de ideas, lo que permitió que surgiesen muchas posibilidades entre las que elegir. Ésto nos permitió también desechar muchas ideas más comunes y que sabíamos que el resto de equipos iban a tocar en sus juegos.
  • El concepto: Creemos que el concepto de juego elegido fue un acierto. Para empezar encajaba bastante bien con el tema, que además abordábamos de una manera distinta a la que elegieron los demas equipos. El centrarnos en el 2D nos hacía movernos en un territorio que todos conocíamos bien y el pixel-art le daba un aspecto muy vistoso y divertido al juego. De no haber cometido el error catastrófico que tanto tiempo nos hizo perder, hubiéramos podido trabajar más el equilibrio del juego que fue su punto más débil. Esto nos indica que el alcance y extensión del juego estuvieron aceptablemente bien calculados.
  • La colaboración: El reparto de tareas y los mecanismos que definimos para la gestión de las mismas funcionó tremendamente bien y prácticamente no provocó colisiones durante toda la jam.

Qué falló

  • Unity Collaborate: Si bien soy un gran defensor de esta herramienta de trabajo colaborativo, he de decir que su comportamiento en el único conflicto de importancia dejó mucho que desear. Curiosamente dos días después de terminar la jam, Unity lanzó una nueva versión en la que el control de versiones está mejorado y corrige en gran medida el problema que nos dio.
  • Equilibro de mecánicas: Como ya he comentado más arriba, el fallo que tuvimos el domingo nos dejó sin tiempo para testear adecuadamente el juego y equilibrarlo para hacerlo más divertido y justo. Al no disponer de ese tiempo el juego adolece de problemas en su funcionamiento que hacen que sea difícil de controlar y que las decisiones sean confusas para el jugador.

Conclusión

Una nueva gamejam, un nuevo juego publicado (aunque hay trabajo por delante para equilibrarlo) y un nuevo equipo del que pude aprender mucho. Queda mucho por hacer y practicar, pero poco a poco me voy sintiendo más cómodo.

El equipo

Arte: Elena García

Programación: Laura del Pino, Sergio Linares

Música: Elior Dumont

Soporte y GameDesign: Yo mismo.postmortem el equipo

Please follow and like us:

1 comentario

  1. Tiene muy buena pinta el juego, intentare probarlo luego más tarde.
    Se ve que habéis tenido un fin de semana muy productivo y que la parte del diseño inicial os ha quedado perfecta, ya que no siempre es fácil acotar todo lo que se debe incluir en el juego para realizarlo en el plazo de dos días. Y el formar un equipo de trabajo que en dos días llegue a esa armonía de trabajo, es idílico.
    Enhorabuena por el trabajo!

Deja un comentario

Tu dirección de correo electrónico no será publicada.

*