Gravituz
Ha pasado tiempo desde nuestra última publicación, pero estamos deseosos de volver a escribir nuestras experiencias y vivencias en el mundo del desarrollo.
Hoy queremos compartir, un epítome sobre nuestro primer videojuego Gravituz.
Aunque es en apariencia sencillo, detrás de él hay un compendio de técnicas y tecnologías tan diferentes pero con una sinergia única, y cada una de ellas es todo un mundo en sí; desde el modelado 3D, que es muy distinto al modelo tradicional para otro fines como arquitectura o impresión 3D, hasta la exportación y portabilidad del mismo para diferentes plataformas.
Lo cierto es que nos hubiese gustado que Gravituz tuviese un poco más de popularidad, pero entendemos el porqué y sus carencias. Sin embargo, cumplió con su objetivo que era el de romper el cascarón para este tipo de proyectos, que a diferencia de cualquier otra pieza de software; los videojuegos van más allá, y ese tramo extra es su estrecha relación con el arte.
El desarrollo tomó aproximadamente 6 meses, y como somos únicamente dos personas, una diseñadora y un programador; decidimos tomarlo con calma e ir alternando el proyecto con nuestras responsabilidades habituales en la empresa, y para ese entonces desconocíamos mucho más de lo que desconocemos ahora sobre el desarrollo de videojuegos.
El primer paso, como siempre fue evaluar qué herramientas usar para llevar a cabo el proyecto, que si bien es cierto, existe una vasta gama de éstas, decidimos elegir primero que todo el motor, queríamos uno que fuese muy flexible y nos permitiera calar de proyectos indies muy pequeños a proyectos de mayor envergadura, por lo tanto estábamos entre Godot, Cryengine, Unity y UE4.
Para esa época Godot estaba mucho más verde, y su principal lenguaje de programación era uno propio llamado GDScript (cabe destacar que ha evolucionado bastante bien, ahora soporta 4 o más lenguajes), que en ese momento era muy amigable, se parecía a Python. Pero como somos fans de los lenguajes de tipado estático; queríamos usar C# o C++ sin tener que dar tantas vueltas, razón por la cual Godot quedó descartado. Restando así Unity, Cryengine y UE4.
De esos tres candidatos, nos encantaba Cryengine por diferentes razones; interfaz amigable, usaba C++ como API, y su sistema de luces naturales y vegetación eran, y siguen siendo realmente sorprendentes. A pesar de ello, su documentación era algo escasa, no tenía una licencia gratuita y su compilación para producción era bastante escabrosa, debíamos enviar todo el proyecto a los servidores de EA para su compilación final y no se podían hacer proyectos para móviles, pero su mayor problema y que aún persiste es que, tiene muy poco apoyo para proyectos indies, además hasta donde sabemos aún no soporta juegos 2D. Aunque, en la actualidad ya cuenta con una licencia gratuita y su sistema de compilación es totalmente local.
Siendo eliminado Cryengine, ya sólo nos quedaba elegir entre Unity y UE4, ya en el pasado habíamos coqueteado con ambos motores, con Unity por allí en el 2011 recién llegado a PC, ya que venía de ser exclusivo de Mac por esos días. Y con Unreal Engine cuando se llamaba UDK, por allí en el 2009 con una versión liberada, este último usaba como lenguaje de programación UnrealScript, mientras Unity soportaba C#, Javascript y algún otro lenguaje.
Sin embargo, ya para la época del desarrollo de nuestro videojuego, ambos motores habían evolucionado, y se estaban adaptado a los nuevos tiempos. Justo allí, fue cuando Unity decidió otorgar una licencia gratuita y al poco tiempo Epic le siguió, liberando también su motor UE4 yendo aún más allá, ya que compartió el código fuente del mismo, mientras que con Unity se otorgaba, y aún se otorga esa opción; sólo con la membresía Pro.
UE4 había dejado atrás el UnrealScript y ahora se podía usar una API de C++ junto con un sistema de scripting visual llamado blueprints, perfecto para la sinergia entre programadores y artistas. Unity estaba evolucionando rápidamente y compitiendo directamente con el motor de Epic a pesar que éste le llevaba casi una década de ventaja.
La estrategia de Epic era simple, ellos con su motor ya estaban consagrados en la industria, pero aún sabiendo esto; supieron reconocer los aromas de cambio en la brisas venideras y sus políticas en poco tiempo fueron cambiando, dando más apoyo a esos espacios donde no tenían presencia y era en el desarrollo indie. Por el contrario, Unity nació en los entornos indies, mas su objetivo es hacerse un puesto en las grandes compañías AAA aunque ha sabido mantener a su comunidad unidad (*platillos).
Observando estos movimientos y tratando de dilucidar un poco el futuro como si de piezas de ajedrez se tratara, finalmente decidimos tener lo mejor de los dos mundos y elegimos a UE4, además que su soporte para C++ es nativo y con Unity es a través de dll. Y como ya podrán entrever, nuestro lenguaje favorito es precisamente C++.
Ya teniendo definida la herramienta principal, lo demás fue un poco más sencillo, para los modelados y esculpidos sin duda Blender, teníamos cierta experiencia con otros softwares similares, pero Blender era la mejor opción (seguramente, ya les estaremos contando el porqué de esa decisión). Con todo y ello, aún nos faltaban otros detalles, por ejemplo un programa dedicado para realizar texturas de modo sencillo y que fuese potente; nos decantamos por la gama de Substance ya que disponía de una licencia permanente (claro antes que Adobe la adquiriera). Otros softwares que decidimos utilizar fueron DaVinci Resolve para la edición de vídeos, Audacity para el audio y Aseprite para Pixel art, cada una de ellos con características excepcionales. Poco a poco, fuimos aprendiendo a manejar estas herramientas, y empezamos a convertir una simple idea en un videojuego.
A pesar que UE4 permite realizar proyectos totalmente en blueprints, lo cierto es que Gravituz está desarrollado casi en su totalidad en C++ esto porque aunque los blueprints son “más sencillos de usar” pueden tardar hasta diez veces más que un código bien escrito en C++ (cuando nos referimos a un buen código es porque, si no sigues las buenas prácticas de programación a la final los blueprints podrán trans-compilar código más eficiente) por lo que, sólo los usamos para abstraer nuestras clases del código, es decir, llamar o conectar los nodos de modo visual pero todo el peso de cómputo está escrito en código.
Después de una cantidad ingente de café y de buena música, pudimos tener la primera versión de Gravituz, pero ahora tocaba el jefe final y era publicarlo. Publicarlo para Windows x86/64 era relativamente sencillo, pero queríamos publicarlo en la Microsoft Store (MS), algunos dirán ¿por qué? Si esa tienda es horrible, honestamente hasta esta fecha la MS no es de lo mejor, pero estamos seguros que va a mejorar y además presenta una opción sencilla para instalar y actualizar nuestro juego ya que viene integrada con Windows 8/10.
Lo cierto es que no nos arrepentimos, estamos muy contentos con nuestro juego publicado allí, lo único es que, a partir de la versión 4.15 o cercanas de UE4, ya este no daba la opción de exportar para UWP que es el formato requerido para publica en la MS, sino que debíamos solicitar acceso a un repositorio privado en Github mantenido por Microsoft para recompilar todo el motor (UE4 4.19.2) y poder exportar en dicho formato, por lo que deducirán no fue labor de un día ni de tres, además de toda la configuración requerida para adaptarlo a la tienda. Actualmente Microsoft no ha actualizado más ese repositorio por lo que la única versión oficial de UE4 para UWP se quedó en el 4.19.2, sin embargo, Microsoft ha habilitado una herramienta para convertir exe a UWP, lo hemos probado y funciona hasta el momento muy bien.
En resumen, y en base a nuestra experiencia, hoy podemos decir con propiedad:
Antes de realizar cualquier cosa, un videojuego es una pieza de software como cualquier otra, pero con algunas particularidades; y es que, la concepción de su desarrollo requiere de establecer varios cimientos desde el día 0, que en otro tipo de desarrollos no son necesarios o simplemente no aplican.
La particularidad del desarrollo de un videojuego, es que tanto lo artístico como lo técnico, tienen la misma importancia. Y un buen producto dependerá del correcto equilibrio de estos. Para ello, es muy habitual antes de nada, la creación de un documento matriz, que es el GDD (Documento de diseño de videojuegos) allí, se plasmará todo, absolutamente todo y servirá de brújula durante todo el desarrollo.
Actualmente nos encontramos, porteando Gravituz a Android y trabajando en un par de proyectos, que seguramente compartiremos pronto con todos ustedes.
Enlaces de descarga:
Microsoft store
Itch.io