La venganza de MotoGT (parte 2/2)

Les comenté hace poco que llegué a la inevitable conclusión de que tengo que reescribir MotoGT. A pesar de algunas ideas nuevas que mencioné para el diseño del juego, lo más importante es que en realidad ya no puedo seguir trabajando sobre el mismo proyecto. Y esto se debe a cuestiones técnicas, cuestiones de programación. Y como programar es lo que me gusta, muy probablemente me divierta más re-escribiendo el juego que jugandolo una vez "terminado".

El primer motivo para esta reescritura es el paso de SFML 1 a SFML 2, en combinación con mi falta de criterio al implementar el MotoGT original. Recuerden que nació como un simple experimento, y tomen esto como excusa válida para justificar un código verdaderamente horrible, muy poco flexible, lleno de copy-paste, 100% atado a la API de SFML 1, y que, como todo buen espagueti, se come con salsa. Al comenzar el proyecto, como siempre, ni sabía que iba a ser un proyecto largo, ni para dónde quería ir, ni cuanto más iba a querer construir sobre el mismo. El resultado es el de siempre. El código que gestiona la parte gráfica está directamente atado al que simula la parte física, del cual a su vez depende fuertemente la inteligencia artificial, que está pegada a las rutinas que gestionan los controles del usuario, y todo eso cableado directamente a la lógica del juego (perfiles, campeonatos, etapas de una carrera, etc), y hasta en la gestión de recursos (memoria y archivos). Sencillamente insostenible.

Y esta verdad, aunque bien disimulada en el resultado final, se hace insoportablemente evidente con el cambio de versión de SFML. Desde hace ya un buen tiempo está disponible la segunda versión de esta biblioteca, versión que no presenta compatibilidad hacia atrás en algunos aspectos. Es decir, ya no sirve directamente lo hecho para la primera, cambia tanto internamente como a nivel de interfáz. Cambian hasta las convenciones utilizadas para nombrar métodos y funciones. Y creo que el cambio es para bien, la biblioteca aporta ahora más flexibilidad y algo adicional de eficiencia sin sacrificar demasiado su facilidad de uso. Pero nos obliga a "portar" nuestros juegos a la nueva versión para no quedar atados a una vieja versión ya deprecada.

Intenté primero acomodar mi código SFML 1 para separa allí un poco mejor la parte que se encarga de gestionar las imágenes y los sprites, pensando en que luego eso facilitaría la migración. Es decir, había código repetido por todos lados. Intenté acomodar un poco las cosas para que todo dependa de unas pocas clases base, para luego tener que migrar solo esas pocas clases. Algo similar hice con los menúes. Pero no lo logré. Había avanzado bastante en ese sentido en un tirón inicial que hice hace ya varios meses, pero recientemente concluí que terminar esa tarea sería más costoso y menos provechoso que empezar de nuevo. Considerando que soy de los que disfrutan haciendo sus propios motores y bibliotecas, será un ejercicio muy interesante con el que también espero aprender bastante y replantear la arquitectura del juego, para separar bien las capas, para que no me vuelva a pasar los mismo cuando salga SFML 3 (o se me ocurra portarlo a cualquier otra cosa).

Además, recuerden que no soy un game-designer, sino solo un programador. Para llegar a algo decente en cuanto de game-design, el nuevo motor debe permitirme modificar muy fácilmente aspectos del diseño del juego, como la lógica de los campeonatos, los modos de carrera, los elementos desbloqueables, algunos detalles de presentación, variantes de la física, etc. Esto es esencial para que pueda experimentar libremente con el mismo (con este game-design), para que luego de mucho ensayo y error encuentre finalmente un balance adecuado entre diversión, dificultad y demás condimentos del juego. Además un diseño sólido (bien pensado y documentado) y flexible (que permita probar cosas nuevas fácilmente) me facilitará el desarrollo en el futuro y contribuirá a que el juego no se vuelva a estancar otros 3 o 4 años.

Finalmente, la nueva versión de SFML también agrega características interesantes que me permitirán agregar a mi juego nuevas funcionalidades que antes eran imposibles o muy difíciles de implementar, como las carreras multijugador con pantalla dividida, nuevos modos para la cámara, y otros detalles. En conclusión, cuando retome el proyecto (esto será largo, aunque algunas ideas ya estás marchando) voy a tener mucho trabajo, pero me va a resultar muy divertido y también muy productivo, y espero que el resultado esté a la altura de las circunstancias. Si todo sale bien, MotoGT 2 podría ser un lindo juego.