Postmortem de “Chromaturgia”

“Chromaturgia es un juego de puzles en 2D, diseñado por cuatro estudiantes para su proyecto de primer año”
Estoy seguro de que los que leáis esto y hayáis estado antes en nuestras presentaciones estaréis hartos de esa frase, o al menos de las miles variaciones que hemos usado a lo largo de estos cuatro meses de desarrollo para presentároslo.
Pero Chromaturgia no es solo un juego de puzles en 2D, no es solo “un juego”. Chromaturgia es, al menos para mí (aunque estoy seguro de que no soy el único), un logro. Es la prueba de que estos cuatro meses, con todos sus problemas y sus buenos momentos, han servido para algo. Y no solo eso, también es una lección: una lección de cómo mejorar de cara al año que viene.

Chromaturgia nació de cuatro personas que se quedaron solos cuando tocaba hacer grupos para el proyecto. Al principio ninguno nos poníamos de acuerdo (había ideas de un juego de música, de un Metroidvania…), pero poco a poco fuimos apilando ideas y tuvimos una base: un juego de puzles en el que uses los tres colores primarios. Esto nos lo llevamos a casa, y una semana después… ¡BAM! Surgió RGB Color Quest, o a veces “RBG” Color Quest (según nos diera el día). Belén trajo inmediatamente un prototipo, y Arturo ya tenía un montón de concept art en el bolsillo. Yo y Tony nos habíamos dedicado ya a ir pensando en qué clase de puzles hacer, qué obstáculos meter…
Decidimos que el conflicto del juego sería una especie de enfermedad que le quitaba el color a las cosas y los volvía completamente negro, además de volverlos malignos, seres corrompidos y ansiosos de infectar todo a su alrededor. Así surgió que el objetivo del jugador fuese el de devolver la luz a todo aquello que lo ha perdido. Sabíamos que no queríamos tener un boss final o un personaje malo al que temer, y que buscábamos que fuese un juego que te hiciera pensar, que te sintieses solo en un lugar desconocido pero al mismo tiempo en un ambiente acogedor y agradable.
Al final pulimos todas esas ideas, escribimos el GDD… y tres meses después, gracias a Unity, esto es lo que tenemos.

Y mentiría si dijera que me esperaba un juego así de (en mi opinión) pulido, al menos en nuestro primer año. O que la producción fue siempre fantástica y maravillosa (entre el estrés y las noches sin dormir, me duermo en Junio y despierto en Septiembre). Pero por eso mismo digo que esto es una lección: porque ahora sabemos qué hay que cambiar en nuestra forma de trabajar.

Pero ya basta de introducciones. La gracia del postmortem es hacer una lista de qué ha ido bien y qué ha ido mal, y con tal de ser positivos empezaré por lo primero.

Lo que ha ido bien

---

1: Hacer el juego bonito lo antes posible

Lo cual fue, en su mayoría, gracias a Arturo (que se empeñó en ello). Al darle importancia a la parte artística pronto, pudimos recibir feedback de esta, además de que nuestro juego resultaba mucho más impresionante. Y eso que yo le decía que no hacía falta...

2: Especializarnos en lo que se nos da mejor

Obviamente, por cómo se califica la asignatura no pudimos especializarnos totalmente, y creo que es buena idea: la gracia es que todos trabajemos por igual en esto y que todos aprendamos. Pero sí nos fue de mucha ayuda que Arturo, por ejemplo, se centrara más en lo que era el spriting y buscar música, ya que tenía mejor mano. O que, a la hora de compaginar este proyecto con el de Dibujo, Belén y Tony se encargaran de ese último mientras Arturo y yo acabábamos el juego.

3: No poner una historia extensa/profunda

Centrarnos más en lo que es el juego que en darle una narrativa profunda nos quitó mucho trabajo de encima, y nos dio más libertad a la hora de diseñarlo. Pudimos dirigir atención al propio juego, y una vez estuvo acabado fue cosa de cerrar la pequeña trama que habíamos creado como base.

4: Hacer el código muy modular

Lo cual es bastante estándar, sí, pero fue de gran ayuda tener muchos scripts pequeños en vez de pocos grandes. Al principio quizá no tanto, pero cuando llegó la hora de arreglar fallos se hizo mucho más llevadero gracias a esto. Además, tener scripts pequeños nos permitía reciclarlos para varias cosas.

5: Adherirnos lo máximo posible al GDD

Es cierto que hemos derivado un poco del GDD, que hemos eliminado ciertas cosas y añadido otras… pero en lo que es la base, nos hemos tratado de adherir lo máximo, y fue especialmente útil a la hora de aclarar malentendidos acerca de distintos aspectos del juego, o crear nuevos.

Lo que no ha ido tan bien

---

1: La comunicación

Esto fue un gran obstáculo, que por desgracia no logramos resolver del todo hasta el último hito. Discusiones, enfados, cambios que nunca se mencionaban, ideas que no se aceptaban… Tuvimos muchos momentos en los que encontramos que dos personas habían hecho código para la misma cosa, o que alguien había borrado algo porque pensaba que era inútil.

2: Olvidarnos de los dailies/las retrospectivas semanales

Porque en clase suenan como que son un coñazo, pero al final son extremadamente útiles para aliviar el problema de arriba, la comunicación. Forzarnos a hablar un poco cada día y a discutir qué tenemos que arreglar habría agilizado muchísimo el proyecto, y nos habríamos ahorrado un montón de problemas por falta de coordinación (especialmente cuando aún no podíamos usar GitHub)

3: No limpiar el código

El código del juego está hecho una completa mierda, y lo digo así porque es algo de lo que me arrepiento muchísimo. Hay métodos que nunca borramos, comentarios que mezclan español e inglés, una amalgama extraña de estilos de programación, variables redundantes… Por fortuna es un juego pequeño, y podremos aprender de ello para la próxima

4: Dejar las cosas que podemos hacer hoy para mañana

Lo típico. Piensas que te dará tiempo mañana, así que lo haces mañana. Y quizá es cierto que te da tiempo, pero al final del día lo que has hecho es perder tiempo por pura pereza. Y no digo que sea buena idea matarse a trabajar, pero sí que es buena idea ir haciendo las cosas poco a poco y quitártelas antes de encima que hacerlo todo en un día y no te dé tiempo a probar que todo funciona al 100%.

5: No dedicarle tiempo a diseñar puzles

El puzle más popular, el 1-1, es el primer puzle que diseñamos y al que más tiempo le dedicamos. Y si juegas, se nota qué puzles tienen tiempo puesto en ellos y qué puzles no lo tienen. Y es una verdadera pena, sobre todo considerando que es un juego de puzles… De tener que hacer otro juego así, dedicaría muchísimo más tiempo a hacer y probar todos los puzles, aunque me llevase tiempo de más.