@cireja, inicialmente lo sacaremos para Android, y luego probablemente lo publicaremos en iOS y PC/Mac. Como estamos utilizando libGDX para el desarrollo y es un framework multiplataforma dudo que tengamos muchos problemas en hacerlo.
Relacionado con eso os dejamos con un 'articulillo' que hemos publicado en
nuestra web, en el que explicamos porqué decidimos utilizar nuestro propio motor en lugar de Unity3D, AGS o cualquier otra herramienta. ¡Si tenéis algún comentario o duda no dudéis en decirlo!
Reinventando la rueda
Dicen que reinventar la rueda es una estupidez. Yo particularmente, y teniendo en cuenta ciertos matices, veo por lo menos dos situaciones en las que estaría justificado. La primera, en la que se necesita una rueda cuyo diseño expone una serie de requerimientos que no cubre ninguna de las alternativas existentes. Si el diseño (o el diseñador) no es flexible no queda otra que crear una nueva rueda, la rueda innovadora. La segunda, en la que el diseño no presenta ninguna variación insalvable respecto a las que ya existen. En este caso, conocer los detalles que hay detrás de su elaboración y exponerse a problemas que otros ya resolvieron antes puede suponer un reto lo suficientemente atractivo como para llevar a cabo la reinvención de la rueda, la rueda didáctica.
En Mango Protocol hemos creado nuestro propio motor de aventuras gráficas, básicamente a partir de la motivación generada por las dos situaciones comentadas. Por un lado, tras una fase de análisis en las que estudiamos varias de las opciones disponibles, llegamos a la conclusión de que, o no proporcionaban todo lo que necesitábamos, o no estaban lo suficientemente bien documentadas, ya sea por falta de documentación pura y dura o porque no encontramos muestras de trabajos similares a nuestra idea. Por otro lado, a mí, como programador del estudio, me apetecía arremangarme y crear nuestro propio motor para la aventura gráfica que estábamos diseñando y así enfrentarme a un nuevo reto.
Nuestro juego, MechaNika, tampoco es que vaya a suponer una revolución en el mundo de las aventuras gráficas en cuanto a las bases del género. Tiene diálogos, inventario, se sustenta en el clásico point and click, y se interactúa con el escenario y las entidades que por ahí pululan para resolver puzles. Pero teníamos algunas ideas de diseño que no queríamos sacrificar por elegir un motor con ciertas limitaciones. Algunos ejemplos son nuestro sistema de diálogos, la gestión de la interacción del jugador durante la resolución de ciertos puzles, o la posibilidad de ofrecer el juego en varias plataformas.
Así pues, tras estudiar mínimamente varias alternativas, incluyendo herramientas específicas para aventuras gráficas como Visionaire Studio, Adventure Game Studio y Wintermute Engine, otras más generalistas como Unity3D, Construct 2 y Stencyl, y frameworks como cocos2d-x y libGDX, nos decantamos por esta última opción. Las principales razones de dicha elección vienen dadas por la propia definición de libGDX: es un framework para el desarrollo de videojuegos multiplataforma utilizando Java como lenguaje de programación. Al ser un framework en lugar de un motor no proporciona entidades que se puedan usar directamente en un videojuego, sino que ofrece un conjunto de subentidades que, juntas como atributos, permiten crear cualquier entidad que el desarrollador necesite, además de poder atacar al sistema de gráficos o de sonido de manera sencilla gracias a la capa de abstracción proporcionada. Esto otorga una mayor libertad aunque también hace necesaria la elaboración de un diseño a nivel de programación más detallado. Al ser multiplataforma, concretamente para Windows, Linux, Mac, iOS, Android, Blackberry y HTML5, se amplían claramente las posibilidades de llevar el juego a cualquiera de esas plataformas, además de manera muy sencilla. Por último, al utilizar Java como lenguaje de programación, con el que estoy bastante familiarizado y he podido compartir varias experiencias agradables durante mi labor como ingeniero software (no es coña), prometía una curva de aprendizaje favorable.
Una vez confirmada la herramienta a utilizar para mover MechaNika tocaba diseñar el motor. Aunque a priori iba a ser utilizado únicamente para un juego concreto y se iba a diseñar en base a las necesidades del proyecto, se planteó la idea de que el motor fuera independiente de ciertos elementos con el objetivo de que en el futuro fuera posible crear nuevas aventuras a partir de un conjunto de ficheros externos de configuración. Es decir, crear un motor que implementara la gestión del juego a nivel de gráficos, sonido, navegación, entidades, inventario, acciones y poco más. Los personajes, los objetos, los escenarios y sus interconexiones, las variables de mundo, los puzles y el árbol de diálogos se definirían en ficheros JSON que alimentarían el motor, donde todo cobraría vida. Incluso sería posible crear un editor gráfico para facilitar la generación de esos ficheros, pudiendo asignar atributos a las diferentes entidades, las cadenas de dependencias para la resolución de puzles y dibujar las celdas y nodos de un escenario para la navegación, por ejemplo, para luego exportar toda esta información a los ficheros correspondientes. Es más que posible que nunca se cree dicho editor ni se utilice el motor para un nuevo juego, dado que tenemos muchas otras ideas para juegos que no son aventuras gráficas, pero la premisa de diseñar una caja negra que genere videojuegos de este tipo a partir de ficheros de configuración es igualmente válida para la creación de un motor modular y extensible, lo que garantiza un desarrollo menos tortuoso.
Tras varios meses de desarrollo, en un estado muy avanzado y cerca de la finalización del juego, el motor es muy modular, permite ser extendido con facilidad, y, aunque la documentación brilla por su ausencia, se ha hecho un esfuerzo para que revisar un método un año después no suponga un trauma. No es tan bonito como me hubiera gustado que fuera, pero la vida es así y existen esas cosas que se llaman prioridades y restricciones, que siempre deben tenerse en cuenta para no perder el rumbo. No obstante, la experiencia ha sido muy enriquecedora y es gratificante ver lo fácil que es ahora añadir escenarios, personajes, objetos y definir los puzles y las interacciones entre ellos, únicamente siguiendo una nomenclatura específica para los recursos y añadiendo pequeños bloques de parámetros en los ficheros adecuados.
Es mi rueda. Innovadora y didáctica.
