¿Cómo empiezan ZinjaI, PSeInt y MotoGT el 2017?

Finalmente termina el año, y con él un cuatrimestre de trabajo, y llega un período de pseudo-descanso. El cuatrimestre que acaba de terminar, como todos, fue especialmente difícil: esta vez porque se me juntaron varias materias y terminé dando entre teorías y prácticas 6 clases por semana! Eso me dejo sin tiempo para mis proyectos libres... hasta hace unas semanas. Cuando terminó pude de a poco retomar los desarrollos. Ya leyeron las primeras novedades. Pero hay más en camino, y algunas muy importantes.

...se encienden las ilusiones

Si realmente te gustan las carreras de motos, ya sabías cómo se iba a titular este segundo post. Se nos pone la piel de gallina cada vez que Martín Urruty pronuncia estas palabras un domingo a la mañana. Pero más allá del pequeño homenaje al relator (y extiendo mi simpatía también a su genial compañero Gustavo Morea), la idea es seguir hablando de cómo avanza MotoGT 2. En el post anterior comentaba que la escena principal (la carrera) ya empezaba a tomar forma, con varios cambios en el Game, y ya casi sin trabajo del lado del Engine y su Bridge. Sin embargo, sí hubo otro pequeño trabajo en el Engine, y queda por hacer uno más grande en el bridge. Hoy les cuento de qué se trata y de paso les traigo otro video.

Se apaga el semáforo...

Hoy toca otra actualización del estado de MotoGT2 (video incluido!). Está avanzando relativamente rápido. El tiempo inicial invertido en el diseño del motor está pagando y con creces. La base ya está sólida, todo lo que tenga que ver con gestión de recursos, despliegue de gráficos, gestión de escenas, lógica interna del juego, y entradas ya está modelado y tiene al menos una primer implementación funcional. El único sistema grande en el cual aún no avancé nada es el de sonido, pero habiendo resuelto los otros, no es algo que me preocupe.

"Compilando" circuitos en MotoGT

Los que hayan jugado MotoGT sabrán que la primera vez corren en un circuito deben esperar buen rato hasta que cargue. Luego, las siguientes veces carga mucho mucho más rápido. Esto se debe a que cuando descargan MotoGT no descargan todas las imágenes que necesita para montar el circuito en pantalla. En su lugar, descargan otro conjunto de imágenes, a partir de las cuales se puede obtener el primero. Digamos que serían como los "fuentes" de los gráficos del circuito. Esto es así por varios motivos interesantes que vengo a comentar. Y como en estos días estuve reimplementando todo ese sistema para MotoGT2, también traigo novedades y algunas capturas para que vean cómo está mejorando el juego.

El control del tiempo en MotoGT2 (parte 2)

Hace unos días hablaba de qué es esto del "framerate" en un juego, cómo se puede relacionar con la física del mismo, y cuál era la solución simple que había usado en MotoGT 1. Si ya entendieron eso, ahora toca mostrar la solución un poco más complicada que estoy usando en MotoGT 2.

El control del tiempo en MotoGT2 (parte 1)

La gestión de los FPS en un juego es mucho más compleja de lo que parece a primera vista. Para MotoGT 1 usé la técnica más simple y menos elegante: framerate constante. Para MotoGT 2 empezé tratando de independizar la velocidad de la física de la del rendering, usando para lo primero un velocidad constante, pero implementando el código de forma tal que esa constante pudiera ser ajustada luego. Pero ahora la cosa mutó, y resulta que al final el framerate ya no es constante, para ninguna de las dos. Hubo que resolver algunos conflictos, pero la inversión pagó, la diferencia se nota mucho más de lo que había imaginado.

std::function: Ya tengo mi (nuevo) martillo

Todos conocen la frase "si solo tienes un martillo, todo te parece un clavo" o alguna variación con la misma idea. A mi, con la programación me pasa algo curioso. Tengo una caja repleta de herramientas de todo tipo, pero cada vez que agrego a la caja un martillo nuevo, todo lo demás se me convierte en clavo. Mi caja está mayormente llena de C++. Diría que casi todo C++03 está en la caja, y que gradualmente he ido agregando herramientas de C++11/14. En algún punto me pasó con eso de SFINAE y los trucos que se podían hacer, y los apliqué por todos lados. En otro momento, agregé a la caja las maravillosas "Variadic Templates" y grité "I have a hammer!", y variadic templates para todos.

Ahora, la funcionalidad de C++11 que se está tornando increíblemente "martillosa", es la aparición de las funciones lambda, y como yapa de la clase auxiliar std::function. Es decir, la posibilidad de crear funciones y clausuras "al vuelo", sin siquiera ponerles tipo ni nombre, y la facilidad que provee la clase std::function para apuntarle a esos pequeños monstruitos sin que nos importen ni preocupen sus especies. En MotoGT 2 están martillando cuanto clavo (y tornillo) se les cruza. Y el resultado es una delicia. Un buen motor puede dar muchas más libertades sin agregar ruido cuando hace uso de estas cosas, y permite al programador ser mucho más productivo.

Las bases de MotoGT 2: overview

Hace un tiempo les comenté que pienso reescribir MotoGT desde cero. Llamo a este proyecto MotoGT 2. Aunque por fuera, al principio será un clon del primer MotoGT con apenas unos pocos detalles nuevos visibles, por dentro la historia es totalmente diferente. El objetivo es obtener una base de código más sólida con la cual experimentar fácilmente agregando y quitando cosas al juego, para que lo que limite su desarrollo sea mi creatividad y mi poca idea de game-design, y no un código complicado y difícil de modificar o mantener.

Entonces, tengo que escribir un pequeño motor de juego. Lo suficientemente general como para que me provea esa flexibilidad. No tan general como para renegar con cosas que no necesito. Con una interfaz de alto nivel para no lidiar con detalles finos de implementación al concetrarme en la lógica del juego. Con capas o subsistemas desacoplados para que, por ejemplo, la biblioteca que use para gráficos y sonido no me condicione la forma de programar esa lógica del juego. Y más, como para que un imprevisto no tire abajo el proyecto.

Variables globales otra vez

Ya comenté que pensaba reescribir desde cero MotoGT. También que el no poder predecir/controlar el orden en que se construyen y destruyen las variables globales me trajo serios problemas. Pues bien, dado que en el nuevo MotoGT voy a volver a usar una buena cantidad de variables globales, me vi forzado a repensar el problema. Y finalmente, encontré una buena solución, con la que puedo tener mis queridas y odiadas variables globales, pero puedo además asegurarme de que se creen y destruyan en un orden correcto.

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".

La venganza de MotoGT (parte 1/2)

Hace unos días, cuando tuve algo más de tiempo libre de lo habitual, gracias a un fin de semana largo, intenté retomar algunas viejas cuestiones pendientes de MotoGT. Mi principal problema era (y es) migrar todo a SFML 2.x. Además, de eso, el juego estaba incompleto, y tenía algunas pocas ideas para mejorarlo. Pero al final no llegué a migrar ni implementar nada nuevo, sino que "solamente" (no es poca cosa) llegué a algunas conclusiones importantes al respecto. Resumiendo: tengo que escribir MotoGT 2, de cero. Los motivos son mayormente técnicos, pero en el medio de todo esto, hay lugar para muchas mejoras en el diseño del juego.

¿Quien es quien? Hoy: MotoGT

Para terminar con las presentaciones formales, voy a contarles sobre el tercer y último proyecto: MotoGT. En resumidas cuentas, es un juego de carreras de motos 2D de vista superior. Los gráficos son bastante feos ya que no soy un gran dibujante ni diseñador, y la mecánica del juego es por ahora muy básica ya que escribí todo el "engine" (va entre comillas porque no puedo llamarle engine a eso) de cero y sin muchas ambiciones. La verdad es que empezó como una, digamos, prueba de concepto, y después me entusiasme y terminé publicándolo.

Lo primero que hay que saber es que me encanta ese tipo de juego. Como referencia obligada, puedo recordar horas y horas de un verdadero grande del género como fue Death Rally (el original, que pueden bajar legalmente para Windows desde aqui, y que en GNU/Linux corre perfectamente con wine). Lo que mejor lograba este juego según mi criterio era un balance perfecto en la dificultad y el sistema de premios (mejores autos, más armas, la posibilidad de competir en carreras más difíciles, trampas, sabotajes, premios inesperados, un adversario final, etc). Con gráficos impecables para la época, una combinación excelente de carrera y combate, y un sinfín de agregados y personajes, hacían que uno no se cansara de ver y hacer siempre lo mismo como puede ocurrir fácilmente en un juego aparentemente tan simple. Desde chico intenté programar juegos de carrera de vista superior (además porque es relativamente fácil para empezar). Por otra parte, hay otra historia más personal sobre una deuda pendiente que será develada en otro post, y que me lleva a tener un especial cariño con estos juegos y a querer experimentar en el género.