inmensia

En estos últimos días ha terminado de liberarse el código fuente de una serie de juegos "indies" bastantes populares: Aquaria, Gish, Penumbra Overture y Lugaru. Todo esto dentro de una iniciativa (ya finalizada) llamada "The Humble Indie Bundle (pay what you want)" que permitía a los usuarios pagar el precio que quisieran por estos juegos, además de World of Goo, para el que no se va a liberar los fuentes. Una campaña que si bien puede parecer arriesgada, ha conseguido recaudar 1.273.613 dólares, de los cuales el 30,85% (392.953 dólares) han sido destinados a Electronic Frontier Foundation y Child's Play Charity.

Cada proyecto ha puesto los fuentes en un sitio distinto y con una licencia distinta. Aquaria lo ha colgado en un repositorio público con Mercurial y licencia GNU, Gish en un simple zip con licencia GPL, Penumbra Overture en un repositorio con git y licencia GNU, y Lugaru en otro repositorio también con Mercurial pero con licencia GPL2. Mucho que cotillear ahí dentro.

Lo bueno que tienen estos proyectos es que funcionan para las tres plataformas más extendidas actualmente: PC, Mac y Linux. Además de que son juegos de tipos completamente distintos. En 2D y 3D. Aunque naturalmente la idea no es que se compile el código y se haga el mismo juego con gráficos o sonidos distintos. Eso no tiene ningún sentido. Al menos no más allá de un homenaje al juego original. Lo que si puede servir es para que algunos programadores se fijen en como están resueltos algunos problemas que les impiden avanzar en sus proyectos. O tomar decisiones acerca de cuales librerías multiplataforma utilizar. Sobre todo cuanto se está empezando y no se tiene criterio para tomar este tipo de decisiones.

En cuanto al código en si mismo, me ha llamado la atención que Gish esté hecho en C, y no en C++ como el resto. Pero por lo demás no hay muchas sorpresas, ya que lógicamente usan SDL, OpenGL y OpenAL. Y sin ninguna capa de abstracción, o muy sencillas, en la mayoría de los casos, como era de esperar. Los ficheros de mayor peso son los que hacen la mayor parte del trabajo, y contienen en algunos casos métodos de bastantes cientos líneas de código, de miles en algunos casos. También hay código comentado, obsoleto, o con indicaciones del autor acerca de su propósito, normalmente para activar algunos procesos de depuración específicos. Para compilar contra una plataforma u otra se usan directivas #ifdef embebidas dentro de las clases en los puntos en los que fueron necesarios ponerlos. Penumbra tiene un motor separado, ya que es un proyecto más técnico que surgió a partir de unas demos tecnológicas, pero el resto son más programas "de una pieza" a los que se han ido añadido clases a medida que hacían falta.

Curiosamente, o no, el comentario de todos los programadores que han liberado su código es "ahí lo tenéis, pero no esperéis gran cosa". La mayoría se muestra orgullosa de que funcione y que fuera un éxito, pero a la hora de mostrar el código lo ven de otra forma. Que si es un lío. Que si es una mezcla de varios proyectos anteriores. Que si se hizo después de un par de copas. En fin ... Supongo que esto pone el desarrollo de este tipo de software al nivel de la "artesanía" que sigue siendo hoy en la mayoría de los casos. Crear diseños sólidos, módulos debilmente acoplados, interfaces claras, y todo ese tipo de características que propugna la ingeniería del software es algo deseable, pero también muy dificil y costoso. Un programador trabajando por su cuenta en un proyecto personal puede permitirse el lujo de empezar la casa por el tejado y luego ir uniendo el resto de las partes. No sé a qué vienen tantos reparos. La mayoría del código que se produce hoy en día, y se produce una barbaridad, tiene que ser por fuerza mediocre. Ya es hora de que nos permitan sentirnos orgullosos de nuestro trabajo.

Hace tres meses ya de mi último juego, así que va siendo hora de que me ponga manos a la obra con el siguiente. Esta vez me gustaría pasar más tiempo trabajando el apartado gráfico. Algo complicado, ya que normalmente mis objetivos/preferencias son de carácter técnico y no artístico.

Tenía pensado hacer algo de tipo "tuberías", como los populares "Candy Train" (no encuentro el link, supongo que ya lo habrán descatalogado) o Rocket Mania de PopCap. Siempre me ha gustado la simplicidad, en lo referente a su jugabilidad, de esos dos programas. Acerca del primero de ellos, recuerdo que es una idea que incluso a mi se me ocurrió una día que viajaba en tren. Cuando llegué a casa busqué por Internet para ver si existía algo parecido. Después de seguir un par de enlaces pude comprobar que no era precisamente el colmo de la originalidad lo que se me había ocurrido.

Para mi juego, tengo apuntadas varias ambientaciones distintas sobre las que poder trabajar. La primera es bastante obvia, la he llamado "One Way!", y consistiría en construir una carretera por la que circule un coche. E incluso mejor, un taxis, e incluso un autobús, ya que entonces se podría jugar (nunca mejor dicho) con conceptos como "parada" o "viajero" para establecer objetivos fáciles de identificar por los jugadores. Las señales de tráfico o los semáforos también podrían estar bien, sobre todo porque son señalizaciones con un significado conocido por todos y que no requerirían mayor explicación. La mayor dificultad para mi reside en el dibujado de un vehículo desde una perspectiva aérea, sobre todo con diversos ángulos de giro.

Otra alternativa que se me ocurrió, a la que llamo "Jungle Path", consistiría en sustituir la carretera por una especie de liana, y el autobús por un mono que se moviera por ella. Los objetivos serían probablemente la recolección de comida, algún de tipo de fruta, y evitar a otros animales salvajes. Naturalmente con este diseño se me plantea el mismo problema que antes, ya que la creación de los gráficos se me hace aún más complicada que con la opción anterior. Para simplificar creo que me bastaría con algún tipo de representación simbólica, como una especie de token con las cabezas de los animales por ejemplo.

El tercer diseño, por nombre "Cheese Maze", utilizaría un laberinto clásico como escenario, con ratones blancos a modo de cobayas como protagonistas y trozos de queso como objetivos. Curiosamente, aunque no acabo de concretarla, esta es la única opción para la que me he atrevido a hacer algo. Por una parte el laberinto, generado aleatoriamente, que se puede ver en la primera imagen de este post, tal y cual lo dibuja el prototipo actualmente. Teniendo en cuenta que está hecho en JavaScript no me puedo quejar del resultado, sobre todo por la continuidad de las paredas y las sombras, aunque hay mucho que pulir todavía. También he intentado dibujar un ratón, segunda imagen de este post, aunque el resultado no acaba de convencerme.

Tengo algunas otras ideas sobre el asunto, pero es bastante probable que opte por una solución mucho más sencilla y acabe utilizando unas simples tuberías o mangueras para hacer pasar agua de un lado a otro del tablero, desde un grifo hasta una boca de riego o algo parecido. No me siento muy positivo hoy, creo que esto va ir para largo.

Trabajar todos estos gráficos píxel a píxel suele llevarme mucho tiempo, y no pocos ajustes, hasta llegar a obtener un resultado que acabe de gustarme. El proceso que sigo es bastante básico y es el que siempre sugieren todos los tutoriales. Primero busco imágenes de referencia, después dibujo el contorno con las formas básicas (line-art), a continuación escojo la paleta de colores, los aplico prestando atención a la posición de las luces, y por último remato los detalles. Suena sencillo, pero me cuesta un mundo, será cuestión de practicar más a menudo. A escala tan pequeña todos y cada uno de los pixeles individualmente cuentan por si solos una barbaridad. Un simple píxel fuera de su sitio puede estropear el suave curso que se supone debería seguir una línea de contorno, por no mencionar como un simple cambio de tonalidad puede suponer el éxito o fracaso de un gráfico. Siempre he pensado que para apreciar mejor estas pequeñas obras de arte hay que ampliarlas de tamaño, para ver detalles que con sus dimensiones normales lucen fantásticas, y comprobar que se han resuelto con tan solo cuatro o cinco pixeles de distinto color. Hay mucho material increíble que puede encontrarse por Internet. Y es que parece que la masificación en el uso de dispositivos móviles ha hecho resurgir este noble arte del píxel-art que parecía destinado a quedar relegado a un segundo plano por el hoy omnipresente 3D.

Loover publicó ayer un post en el foro de Stratos anunciando la salida de Indielib, un motor pensado para ayudar a los desarrolladores a programar juegos 2D muy rápidamente. Totalmente gratuíto, incluso para aplicaciones comerciales. Está escrito en C++, se entrega en forma de dos librerías para Microsoft Visual C++ 6 y 2008, y viene acompañado con un manual con toda la documentación en formatos HTML y PDF. El SDK contiene como bonus los ejecutables y fuentes de 19 tutoriales completos.

Técnicamente comentar que se apoya en SDL, DevIL y Direct3D. Esto último hace que sólo funcione bajo Windows, pero aporta la ventaja de que se utiliza la aceleración por hardware para realizar todas las operaciones gráficas. Gracias a ello también permite cargar modelos 3D para mostrarlos sobre fondos bidimensionales, algo habitual en algunas aventuras gráficas por ejemplo. En general tiene una lista bastante importante de características soportadas (features): interfaz sencillo, traslaciones, rotaciones, escalados, efectos, animaciones, colisiones, scrolls, varios tipos de cámaras, varios viewports simultáneos, ... y así un largo etcétera. En los ejecutables de las demos que vienen ya precompiladas pueden verse muchas de estas características en funcionamiento, aunque se echa en falta un jueguecillo.

En el post del anuncio pedía algo de promoción en el ciberespacio, así que sirva este post para la causa.

La "estadística del pollo" dice que desarrollo un juego nuevo cada tres meses, una productividad que más que quisiera para sí más de uno, incluido yo mismo. El problema de esa estadística es que también dice que si tú te comes dos pollos y yo no me como ninguno, entonces "de media" nos comemos un pollo cada uno, aunque la realidad es que uno se harta y otro se queda a dos velas.

De los últimos 9 juegos que he publicado en la web en estos últimos 27 meses, hay algunos que me llevaron un par de días de desarrollo y otros que los he ido dilantando durante semanas, tomando horas sueltas de aquí y de allá. Lo interesante desde mi punto de vista es que puedo hacer un repaso desde la distancia y observar mi evolución como programador de videojuegos amateur.

Para los juegos de la web decidí usar JavaScript, así que para ir familarizándome con el lenguaje empecé con lo básico, un Arkanoid del cual llegué a hacer tres versiones. Comenzar escribiendo un clon de algún juego sencillo (Adivinar un Número, Ahorcado, Tetris, ...) es lo que siempre se recomienda cuando se está empezando, y no creo que sea un mal consejo, aunque yo creo que llevo demasiado tiempo siguiéndolo.

Después de ese primer juego fueron cayendo otros. Un Mahjong donde empezaba a usar gráficos estáticos, aunque no tenía ningún tipo de variación sobre lo básico, ni puntuación, ni tiempo. Colors, un juego de emparejamiento de colores que hacía uso de un algoritmo recursivo fundamental dentro del género. Un Solitario donde tuve que lidiar con el drag and drop, y empezar a pelearme con las incompatibilidades entre distintas plataformas y navegadores. Un Sudoku donde puse a prueba el rendimiento del backtracing en un navegador. Discovery, un punto de inflexión en el que me reafirmé en mi condición de "coder" prácticamente nulo como "designer". Buscaminas, un entrenimiento como cualquier otro para pasar un frío fin de semana. Videopoker, un juego hecho para reaprovechar material gráfico y buscar formas sencillas de encontrar la mejor jugada posible. Y por último Confetti, posiblemente el más elaborado de todos ellos, tanto interna como externamente.

En mi último juego me he esmerado un poco más que de costumbre en el acabado y he tratado de ser un poco más original que de costumbre. Dos detalles:

- El marcador con la puntuación originalmente iba a ser un simple y discreto texto estático, pero a medida que trabajaba en el código me dí cuenta que el único objetivo del juego era conseguir sumar más puntos que en la partida anterior, así que decidí darle más protagonismo. El resultado fue un marcador bastante grande, visible de un sólo y fugaz vistazo. Para mejorarlo un poco y hacerlo más atractivo visualmente decidí que cada número apareciera desplazado verticalmente de forma aleatoria uno o dos pixels. Un cambio pequeño pero que queda muy bien, ya que le quita rigidez a la puntuación y le da un poco de vida. No contento con eso decidí que debía tener algún tipo animación, así que hice que la puntuación fuera subiendo gradualmente en vez de de un sólo golpe. Queda muy bien cuando termina la partida y se puede ver la puntuación subiendo todavía.

- El contador de tiempo en un principio tenía que haber sido la clásica barra que fuera subiendo hasta alcanzar su tope, pero después de echar un vistazo a algunos juegos comerciales (en plan "casual") me fijé que normalmente tenían algún tipo de detalle diferenciador y decidí cambiarlo. En un principio pensé en un termómetro, pero luego me pregunté si podría implementar un sistema de partículas y simular un reloj de arena. Después de muchas pruebas lo conseguí. Incluso llegué a hacer uno con varios colores, pero era tan espectacular que distraía la atención sobre el juego y decidí no ponerlo. Curiosamente al final esto me llevó tanto tiempo que casi me hace abandonar la idea de hacer el juego completo, uno de los de los problemas de no tener diseño ni planificación previa (¿o debería decir "ventajas" cuando uno se es amateur?)

A partir de aquí no tengo muy claro hacía donde mirar y qué camino seguir, y es que creo que siempre trabajaré mejor por encargo que por iniciativa propia. En mi trabajo siempre me he encontrado cómodo con esa presión, buscando soluciones a problemas ajenos en un tiempo adecuado y con la calidad necesaria.

A partir de ahora Confetti estará también disponible como un gadget de Google.