#2 Devlog : Refactor de Arquitectura

Siempre llega ese momento. TIenes una idea, empiezas un proyecto, quizás hiciste un prototipo rápido y viste que puede funcionar. Tu cabeza hierve de ideas e imagina cómo podría ser ese videojuego , cómo se vería, qué mecánicas tendría.

Es una sensación única de ilusión y motivación difícil de explicar que solo los apasionados de una materia tenemos, es puro fuego creativo, tienes que, al menos, intentarlo o sacar esa creatividad que te quema por dentro.
Creas el proyecto y te pones manos a la obra, vas añadiendo contenido, quizás un menú, un personaje, un sistema de interacción. El proyecto va flaman, avanza rápido y encima, estás teniendo cuidado de seguir hasta cierto punto, buenas prácticas de programación.

Y siempre llega ese otro momento, el videojuego crece, ese bug que no sabes de dónde sale, esa feature que no sabes en qué contexto tendría que estar, si debería estar en el jugador, en la cámara, en un singleton… y sobre todo, ese nuevo bug que aparece cuando intentas incluir algo nuevo, ese bug que arreglas y hay otro detrás , que te lleva a otro bug que estaba esperando.
Pierdes la perspectiva, ese fuego creativo se va convirtiendo en frustración y esas primeras ideas de abandonar el proyecto recorren tu cabeza, lo estabas haciendo de puta madre, pero a cómputo global, es un caos.

En mi caso, he estado ahí muchas veces, pero esta vez, abandonar no es una opción en absoluto. Aunque tuve en cuenta muchas buenas prácticas, intentando «decouplar» todo lo máximo que pudiera, siempre había alguna hard reference que me llevaba de un lado a otro en un plato de «Espaguetis a la dependencia». Todo esto seguramente fruto de las prisas o de simplemente, llevar muchas horas programando, no pensar con claridad y aún así seguir hacia adelante.

Era el momento de replantear la estructura del proyecto, pensar de manera global, ya que, es prácticamente imposible crear una arquitectura adecuada a la primera, considerando que «la arquitectura perfecta» es de facto inexistente. He de confesar que todo esto, me parece de largo, lo más complicado a la hora de desarrollar un proyecto de este tipo.

Era hora de ahondar quizás más en patrones de programación, y , aunque me leí el clásico https://gameprogrammingpatterns.com/ hace unos cuantos años, la verdad es que no suelo seguir ninguna guía ni me ciño estrictamente a ningún patrón, uno va aplicando esos patrones automáticamente sin pensar mucho según sus necesidades.

Noto que hoy en día hay una nueva tendencia sobre no usar patrones ni buenas prácticas, de ir al meollo directo, escribir código cerdo pero que funcione. Una idea que me encuentro en muchos lados, e incluso con sorna hacia muchos devs que se ríen de los devs que implementan prácticas correctas y código ‘limpio’.

-» JAJAJAJA qué flipaos, mira a ese pringado haciendo buenas prácticas»

A ver, ni tanto ni tan calvo, hay que buscar un equilibrio y avanzar, o es pan para hoy y hambre para mañana, ese código caótico te dará en la frente en algún momento, garantizado.
En ese preciso momento tuve el placer de tener a un desarrollador de primer nivel ( https://www.nosolopau.com/ ) en mi casa. No se dedica al gamedev , pero creedme que de estas cosas sabe. Tras enseñarle el proyecto le expuse la duda que tenía: seguir el desarrollo hasta mucho más adelante, luchando contra los bugs, o empezar un refactor importante inmediatamente.
Lo cierto es que me dio un consejo en el que realmente tenía razón, ir al grano de lo más indispensable y básico, pegándome con lo que tuviera, y encontrándome con nuevas cosas que potencialmente tendría que refactorizar más tarde.

Y así fue, avanzo entre un lodazal de bugs e incongruencias hasta el loop básico de turnos, matar, morir, renacer, etc. Una vez tocada esa pared, al fin, pude ponerme a repensar la estructura del proyecto y el orden de ejecución de las cosas, implementando más fuertemente un EventBus ,un sistema de carga asíncrona, un sistema de generación (Factory Pattern) , y un sistema de comandos (Command Pattern) , que sin duda, mantiene diferentes áreas del proyecto separadas.
Me ha llevado bastante tiempo, pero ahora todo tiene más sentido y el desarrollo va bastante más fluido y mucho más libre de bugs y potenciales bugs.
Ha sido un ejercicio de paciencia a mitad de desarrollo pero ha merecido la pena.
Seguimos!