Diario de desarrollo #4: Elección de herramientas de desarrollo

Para desarrollar un videojuego tenemos que decidir que herramientas de desarrollo vamos a utilizar tanto para programarlo como para generar todo tipo de recursos necesarios para componer el resultado final.

Es por esto que una vez que ya hemos estudiado que tipo de recursos vamos a necesitar, tenemos que buscar las herramientas más adecuadas para generarlos, y esto implica buscar herramientas que posean las características necesarias y que cumplan con otras cuestiones como la facilidad de uso, una curva de aprendizaje asumible, un coste asequible, la cantidad de documentación disponible y si existe una comunidad de usuarios a la que acudir para resolver posibles dudas, y también influirá en ello la experiencia previa de las personas que utilizarán las herramientas, ya que siempre es más fácil usar herramientas ya conocidas que no una herramienta nueva que haya que aprender a usarla desde cero.

Cómo entusiasta del software libre que soy, siempre abogo por utilizar herramientas de software libre para cualquier tarea, aunque soy consciente de que no siempre puede ser así.

Las ventajas de utilizar software libre en general son obvias pero vamos a enumerar algunas de ellas:

• Libertad: Por lo general, el software libre permite a su usuario acceder a su código fuente y usarlo, modificarlo y distribuirlo con total libertad. Por ejemplo, podríamos añadir una funcionalidad que el software no tiene, y podríamos distribuir dicha modificación si pensamos que puede ser de utilidad para otros usuarios.
• Comunidad: Normalmente el software libre se desarrolla en comunidades de muchos usuarios alrededor del mundo que se coordinan entre ellos para implementar las funcionalidades del software, mantenerlo y dirigir el desarrollo de forma conjunta. Eso implica que es muy probable que haya mucha gente que pueda ayudar en caso necesario si hay problemas con el software, e incluso podríamos contribuir a arreglar esos problemas nosotros mismos.
• Ahorro en costes de licencias: Al poder acceder al código fuente, el software libre no suele incluir costes de licencias, como si ocurre con el software privativo. Aunque no es para mí el rasgo más importante, si es algo a tener en cuenta, sobretodo si eres parte de un estudio de nueva creación como nosotros que contamos con unos recursos muy limitados.

Dicho esto, entremos en materia.

Una de las primeras decisiones que tenemos que tomar es si vamos a utilizar un motor genérico de desarrollo de videojuegos, un motor específico para novelas visuales o si vamos a programar todo desde cero.

Motores específicos

Inicialmente evaluamos la opción de utilizar motores específicos para desarrollo de novelas visuales. El más conocido es RenPy: un motor de novelas visuales programado en Python que utiliza su propio lenguaje de descripción de escenas para programar las historias. Lo utilicé algún tiempo para hacer algunas pruebas y es una herramienta muy especializada que te da ya todo lo que se espera de un juego de novela visual. Sólo tienes que añadir los gráficos, escribir la historia y ya tenemos una novela visual muy básica.

Si queremos personalizar cualquier aspecto como efectos gráficos, animaciones y otras cuestiones, se puede utilizar Python para programar pequeños módulos o modificar el propio RenPy para que haga lo que necesitamos.

A pesar de todo esto, nos parecía una herramienta muy simple, ya que queríamos tener más control sobre aspectos de la representación del juego en pantalla. RenPy permite personalizarlo, pero el coste de aprender a hacerlo aprendiendo sus entresijos es algo costosa.

Motores genéricos

Aunque técnicamente nos sería posible programarnos nuestro propio motor a medida, existen en el mercado opciones muy profesionales que nos facilitarían mucho el desarrollo, evitándonos tener que programar todo desde cero. Las más conocidas son Unity y Unreal Engine, pero ambas son soluciones privativas, que aunque no tienen unos costes de licencia elevados (al menos al principio), tienen limitaciones por su modelo de licencias y porque no se puede acceder a su código para modificarlo o mejorarlo en caso necesario.

Hace ya unos años, en la conferencia FOSDEM de 2016, descubrí una joya llamada Godot Engine. Un motor de desarrollo de videojuegos completamente libre, multiplataforma y que ya en ese momento en su versión 2.x era muy potente. Actualmente, en su versión 4.x este motor está entre los más valorados por los desarrolladores de videojuegos indie, y el número de usuarios de su comunidad crece día a día.

Teniendo en cuenta que es un motor libre, sin costes de licencia, multiplataforma, y que además llevo usándolo desde que lo descubrí para pequeños proyectos y pruebas (ya he pasado la parte más complicada de la curva de aprendizaje), la decisión es muy simple: Godot es la opción lógica para desarrollar nuestro juego.

Soluciones existentes en Godot

Godot es un motor general. Es decir, nos da un conjunto de herramientas para manipular gráficos en 2D y 3D, sonido, elementos en pantalla, físicas y un montón de cosas más, pero no dejan de ser herramientas simples.

Para conseguir comportamientos complejos, hay que programar esos comportamientos, y para eso cada herramienta tiene su sistema de programación: para que definamos comportamientos y funciones complejas que darán forma a nuestro juego.

Por suerte a veces existen soluciones prediseñadas por otras personas que pueden facilitarnos la vida. En Godot existen lo que llamamos “addons” o “plugins”. Son módulos que se pueden cargar en el programa para expandir su funcionalidad.

En el caso de Godot, hay dos addons interesantes para el desarrollo de juegos tipo novela visual. Uno de ellos, llamado “Escoria” está orientado más bien a aventuras tipo point and click (aventuras gráficas), pero podría utilizarse fácilmente para novelas visuales. Por otro lado, existe un addon específico para desarrollar novelas visuales llamado Dialogic que nos da muchas de las herramientas para gestionar personajes y diálogos.

Ambas herramientas están programadas sobre Godot, y pueden personalizarse muchísimo. Sin embargo, después de probarlas, leer su documentación y evaluarlas, vimos que tenían un nivel de complejidad muy alto para lo que nosotros necesitábamos.

Además, la forma en la que están desarrollados hace que añadir características personalizadas y mantenerlas en el tiempo a medida que se actualizaban las herramientas y avanzaba nuestro proyecto iba a ser un proceso que consumiría mucho tiempo, así que en este punto, decidimos que valía más la pena trabajar un poco más al principio en hacer nuestro propio motor de novelas visuales basado en Godot que tuviera las características específicas que necesitamos sin añadir mayor complejidad innecesaria y que nos permitiera tener un control total sobre nuestro juego.

Otra ventaja de hacer nuestro propio motor es que durante su desarrollo identificaremos necesidades que podremos cubrir nosotros mismos y que además serán oportunidades para innovar haciendo nuestras propias funcionalidades a medida.

Siguientes pasos

Ahora que ya tenemos seleccionadas las herramientas es hora de ponerse manos a la obra y diseñar nuestro motor de novelas visuales. Pero eso, es una historia que iremos contando en los siguientes DevLogs.