Arrancando Vessel

En este post hablaré del arranque del proyecto. Aunque gran parte de las estrategias y conceptos que nombraré son técnicos, voy a intentar que el texto sea lo más ligero posible. Primero hablaré de las herramientas que usaremos para desarrollar este juego y el porque las hemos elegido. Después profundizaré un poco sobre la filosofía del desarrollo y las estrategias que hemos elegido para implementarlo. Esto nos llevará un ratito, así que: ¡Al turrón!

Sobre las herramientas

Antes de profundizar en la preparación técnica de Vessel y las herramientas que usaremos, quiero matizar mi punto de vista sobre las herramientas digitales. Alto y claro, una herramienta no es más que una herramienta. La elección debe basarse en la adecuación de la misma al trabajo que vamos a realizar. Sé que suena obvio, pero en las industrias tecnológicas mucha gente es “fan” de ciertas herramientas y basa su elección no en esta premisa tan simple sino en si su herramienta favorita puede hacer el trabajo o no. Si no eres alguien muy metido en la industria de los videojuegos puedes pensar que “si todos son motores de juego deben de ser parecidos”. Bueno, en parte es cierto. Todos se parecen del mismo modo que una motosierra, un bisturí, y unas tijeras son herramientas que cortan. Todas buscan el mismo objetivo pero difieren mucho en su caso de uso.  

Así pues, antes de elegir las herramientas que vamos a usar debemos entender que necesita el proyecto: 

• Desde el punto de vista de arte, Vessel es un juego en 3D con modelos de muy baja poligonización e iluminación en tiempo real. Como apuntamos a un estilo artístico retro (PS1, o PS2), cualquier motor de juegos moderno como Godot, Unity, o Unreal Engine deberían renderizarlo sin problema. 

• En cuanto a animación, apuntamos a un estilo realista de baja fidelidad. Esta es una de las áreas del juego más complicadas dado que no hay animadores en el equipo (de momento). Nuestro objetivo es utilizar, reutilizar, y elevar tanto como podamos packs de assets. De modo que nuestra herramienta ideal debería ser muy flexible y reducir esta problemática.

• Para código y diseño, el mayor reto es lograr una IA de compañero útil. De base esto ya suele ser un ejercicio complicado y es de los pocos puntos del juego en los que el equipo es inexperimentado. Así pues la herramienta ideal debería tener un soporte para la implementación de IAs amplio.

• Es importante mencionar que en este pequeño análisis no estamos valorando las necesidades de sonorización y música. Esto se debe a que tenemos intención de subcontratar estos servicios y usar un middleware como FMod  o WWise y estos están soportados en casi todos los motores modernos.  

Teniendo todo esto en cuenta, hemos decidido desarrollar Vessel usando como herramienta principal Unreal Engine 5. Principalmente por sus herramientas de animación, el soporte integrado para árboles de comportamiento y herramientas de inteligencia artificial, herramientas de efectos visuales, y soporte de edición de cinemáticas. Además, es el motor donde el equipo está más experimentado y eso siempre hay que tenerlo en cuenta.

Este motor se distribuye de dos formas: por un lado existe la versión compilada (la distribuida por el lanzador de Epic), o el código fuente (distribuido vía repositorio). Hemos optado por la primera versión por tres motivos. En primer lugar, reduce la fricción con la herramienta. Usar una versión compilada nos quita ciertas libertades pero nos ahorra mantener la herramienta. En segundo lugar nos permite preparar a los nuevos miembros mucho más rápido y simplifica mantener al equipo en la misma versión del motor. Finalmente, reduce mucho los costes. Esto se debe a que el código fuente del motor es gigante. Bueno, GIGANTE en mayúsculas. Decantarnos por esta opción implicaría añadirlo a nuestro repositorio para poder distribuirlo entre el equipo, y dado que no tenemos la infraestructura para alojar el repositorio en un servidor propio, tendríamos que pagar por hacerlo. 

Esto nos lleva a las siguientes herramientas, vamos a usar git y git LFS para el control de versiones. De nuevo, el principal motivo detrás de esta decisión es la reducción de costes. Unreal serializa los assets en binario y git no es especialmente bueno lidiando con este tipo de ficheros así que hay opciones mejores (como P4). Sin embargo, las opciones para alojar un repositorio basado en git son bastante más baratas y fáciles de preparar que con otras herramientas. En concreto, hemos elegido GitHub como proveedor de hosting porque es muy barato y nos provee de varias herramientas integradas y clientes visuales.

Respecto a la edición de código, en general se suelen considerar dos opciones para trabajar con Unreal Engine: Visual Studio (en este caso podríamos usar el community al ser un equipo pequeño), o Rider. Personalmente, uso Rider. A mi parecer es más rápido y funciona mejor con este motor. 

Como filosofía general, nuestro objetivo es reducir toda la fricción posible que se genere con las herramientas y reducir los costes al mínimo. Esto, por desgracia, no es una elección sino una obligación si queremos que el proyecto sea viable económicamente. Esta filosofía se ve reflejada en decisiones como la de usar la versión compilada del editor, o priorizar el uso de paquetes de animaciones en lugar de contratar a alguien. 

Estrategias de código

Desde la perspectiva de código este desarrollo está muy influenciado por dos grandes restricciones: 

• La ausencia de QA durante el desarrollo.

• Los tiempos son justos para hacer el proyecto viable.

El objetivo es implementar el código del juego de forma que sea modular, reutilizable, testeable, y fácil de mantener de modo que evitemos problemas y una fase de corrección eterna al final del desarrollo. Para conseguirlo vamos a aplicar varias estrategias basadas en la programación defensiva.

La primera es bastante estándar, favorecer la composición sobre la herencia cuando diseñamos sistemas y designar “puntos de rotura”. En esencia, toda la funcionalidad se encapsula en componentes (siguiendo el principio de responsabilidad única). Estos componentes estarán completamente aislados entre sí y usarán la inyección de dependencias para evitar relacionarse directamente. Estas dependencias se establecen a nivel de actor, creando así un “punto débil” dentro de la arquitectura. Facilitando que los componentes sean unidades cerradas y perfectamente testeables. Esto significa que las podemos tratar como un programa al que pasamos una serie de valores de entrada y analizar los parámetros de salida. De esta forma podemos comprobar que la funcionalidad, que no la implementación, es correcta. De modo que si podemos validar estas funcionalidades y tenemos un problema, este estará en los “puntos débiles” permitiéndonos gestionar mejor los esfuerzos y simplificando la búsqueda de errores. 

La segunda estrategia (también bastante estándar) consiste en provocar un crash del juego tan pronto como sea posible. De modo que si detectamos que algo va mal en cualquier punto de la ejecución esta se pare, haciendo obvio el problema y facilitando su corrección. Esto lo acompañamos con feature flags de modo que estos crashes no interrumpan el trabajo de los miembros del equipo que no programan en caso de que el error sea difícil de corregir.

La tercera estrategia es usar una variante de git flow como modo de trabajo en el repositorio usando una rama por tarea. Esto simplifica la gestión y mantenimiento del mismo a la vez que reduce el esfuerzo necesario para revisar el código.

Reflexiones finales

¡Esto ha sido más largo de lo que esperaba! Como podéis ver nuestra principal restricción es el presupuesto. Esto nos ha llevado a tomar una serie de decisiones clave para mantener la viabilidad del proyecto. Algunas de ellas aunque han sido necesarias tendrán un coste a futuro, pero ya lo veremos cuando llegue el momento. 

Espero que os haya parecido interesante, como siempre dejad un comentario diciendo qué os ha parecido el post, darle like y uniros al Discord :D!