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

Toolchains alternativos en ZinjaI

Wikipedia en inglés empieza la definición de toolchain con algo que traducido sería más o menos "el conjunto de herramientas de programación que se utilizan para crear un producto...". Esta definición involucra compilador, editor, depurador, etc. Pero en la práctica he visto usar este término para referirse mayormente al conjunto de herramientas que verdaderamente producen el ejecutable; es decir el compilador en sentido general, que incluye preprocesador, compilador, ensamblador, enlazador, y cualquier otra cosa que pueda ser necesaria para pasar del fuente al ejecutable. Mi compilador amigo es el archiconocido gcc en GNU/Linux (y su port para Windows de 32 bits, mingw32), pero existen muchos otros. Entre las alternativas puedo mencionar al compilador de intel (que nunca probé, pero que tiene muy buena fama en el ambiente científico porque logra ejecutables más rápidos en ciertas configuraciones y un set interesante de herramientas auxiliares), o al flamante conjunto LLVM+Clang. LLVM es un conjunto de herramientas que forman parte de un toolchain propio modular y flexible. Clang es el módulo que le falta para completar un conjunto enteramente basado en llvm que compile de principio a fin código C++. Su creciente popularidad y su rápida evolución, junto con otras ventajas que forman parte de su concepto me hacen pensar en integrarlo en ZinjaI. Y ya que voy a estar en el baile, pretendo hacer esta integración de una forma más o menos genérica para que al final ZinjaI permita configurar fácilmente toolchains alternativos, o incluso diferentes formas de construir un proyecto independientemente del toolchain.

Emparchar vs Reescribir: ¿qué hacer con un diseño limitado?

Rara vez, al comenzar un proyecto personal, el diseñador/programador sabe exactamente a donde va a llegar. Puede tener una idea bastante aproximada de hacia donde quiere ir, y hasta de qué podría llegar a cambiar, pero inevitablemente algo va a pasar que lo va a obligar a plantearse la posibilidad de rediseñar medio programa. Solo un experto iluminado con gran experiencia puede proponer desde el comienzo el diseño adecuado en un proyecto más o menos complejo. En general, el programa muta, el programador madura, y las cosas cambian. La mayoría de los mortales, empezamos con un diseño que por alguna razón en algún momento pareció correcto (o tal vez no pareció del todo correcto, pero si pareció ser la mejor de las posibles opciones), y luego vemos como el proyecto, si sobrevive al embate inicial, va cambiando lenta O dolorosamente: lentamente cuando las cosas se hacen bien, dolorosamente cuando se hacen rápido.

Es decir, a la hora de implementar algo no previsto en el diseño inicial de un sistema, podemos tomarnos todo el tiempo necesario replantear el diseño inicial para hacerlo más flexible, recodificar lo que sea necesario recodificar para cumplir con el nuevo diseño, actualizar la documentación, etc. y luego agregar pacíficamente la nueva funcionalidad; o bien podemos empezar a parchear el código poco flexible que escribimos en un primer momento para tener rápidamente al menos un prototipo andando. Por lo general, cuando el cambio no es tan grande, voy por la segunda alternativa, hasta que llega un día en que mi código es 90% parches y 10% del pobre diseño original, y se hace imposible seguir añadiendo cosas (o al menos hacerlo sin romper lo que ya estaba andando).

Las mil y una distribuciones

Sabido es que hay cientos de distribuciones de GNU/Linux dando vueltas, y que de cada una conviven varias versiones al mismo tiempo. Es decir, unos usuarios tienen Fedora, otros Ubuntu, otros Arch, algunos Mint, unos pocos Slackware, aquel usa Gentoo, un amigo OpenSuse, etc, etc, etc. Y además, supongamos que solo existiera Ubuntu, alguno usará la de 32 bits, otro la de 64, alguno seguirá con la 10.04 porque es LTS, otro tendrá la 12.04 porque le gusta tener siempre lo último, el más pacífico tal vez corra la 11.10 porque aún no aplicó las actualizaciones, y hasta uno por alla con un hardware viejo y raro se quedó en la 9.10 porque es la única que le reconoce todo y le anda rápido con su poca memoria.

Tanta variedad trae problemas (y ventajas, pero vengo a plantear algunos problemas). Para empezar, los programas de terceros de los que dependen ZinjaI o PSeInt varían enormemente. Por ejemplo, si quiero correr algo en una terminal gráfica, ¿uso xterm? o ¿konsole? o ¿gnome-terminal? ¿o qué?. Supongamos que uso konsole, los argumentos que recibía en kde3 eran unos, pero en kde4 son otros, y hasta varían entre versiones de kde4. O supongamos que uso gnome-terminal. Hasta cierta versión de gnome uno lanzaba un proceso en esta terminal y esperaba a que termine, pero a partir de no se cuando empezó a lanzar el proceso algo así como en segundo plano, entonces el comando que hace la llamada finaliza enseguida, aunque el proceso que quería ver tal vez ni siquiera alcanzó a comenzar. Otros casos podrían ser instalar íconos y asociar tipos de archivos con los muchos exploradores de archivos (soluciones como xdg empiezan a parecer estándar pero aún no están en todos lados), o lanzar un comando como administrador (gksudo es lo más común, pero tampoco está en todos lados).