¿Qué archivos debemos incluir en Git para un proyecto de Unity?

Si aún no tienes tu proyecto de Unity a buen recaudo, en un repositorio de Git como GitHub, deberías hacerlo cuanto antes. 

Las principales razones para añadir un repositorio de versiones a tu rutina de trabajo son:

• Tener tu proyecto en un repositorio remoto (como GitHub, GitLab o Bitbucket) asegura que no pierdas tu trabajo si algo le pasa a tu ordenador.
• Git te permite rastrear cambios en tu proyecto, revertir a versiones anteriores si algo sale mal y entender qué modificaciones se hicieron y cuándo.
• Si trabajas en equipo, Git facilita que múltiples personas trabajen en el mismo proyecto sin conflictos, usando ramas y merges.
• Puedes usar ramas para experimentar con nuevas funciones o correcciones sin afectar la versión principal, manteniendo el proyecto ordenado.
• Muchas plataformas de CI/CD y herramientas de desarrollo se integran con Git, lo que agiliza flujos de trabajo como pruebas automáticas o despliegues.
• Usar Git es un estándar en la industria, y dominarlo te prepara para trabajar en entornos profesionales.

Sin embargo, no debes subir todos tus ficheros a un repositorio Git. Por ejemplo, no tiene sentido subir los compilados porque cualquiera los puede generar si cuentan con el código fuente. Subir los compilados sólo incrementaría innecesariamente el tamaño del repositorio, haciéndolo más caro de mantener e incrementando los tiempos de sincronización del resto del equipo de desarrolladores.

Por eso, para proyectos de Unity, asegúrate de incluir un archivo .gitignore adecuado para evitar subir archivos innecesarios. Git espera encontrar este fichero en la raíz del proyecto (al mismo nivel que la carpeta Assets). Su contenido enumera el listado de nombres de fichero y carpetas que Git debe evitar incluir en el repositorio para mantenerlo limpio. En internet, puedes encontrar abundantes ejemplos de ficheros .gitignore adecuados para Unity. Si usas Rider, JetBrains tiene un plugin oficial (denominado .ignore) que te ofrece un wizard para generar un .gitignore adecuado al proyecto que te traigas entre manos (incluido Unity). Otra fuente puede ser GitHub, que tienen un repositorio oficial con archivos .gitignore para los frameworks de desarrollo más populares, y tampoco falta el de Unity. 

Qué debes dejar fuera del repositorio

Si optas por construirte un fichero .gitignore a mano, debes excluir lo siguiente:

• Carpetas de Unity: Excluye Library, Temp, Obj, Build, Logs y UserSettings, ya que son generadas automáticamente por Unity y no deben versionarse.
• Archivos de compilación: Archivos como .csproj, .sln y otros generados por Visual Studio o Rider no son necesarios en el repositorio.
• Caché y assets: Excluye caché de Addressables, StreamingAssets y paquetes para reducir el tamaño del repositorio.
• Archivos del sistema operativo: Ignora .DS_Store (macOS) y Thumbs.db (Windows).
• Editores y herramientas: Excluye configuraciones específicas de editores como VS Code o Rider, pero permite incluir configuraciones compartibles (como .vscode/settings.json).
• Archivos grandes: Si no usas Git LFS, excluye archivos comprimidos o pesados como .unitypackage.

Qué debes incluir en el repositorio

Eliminado lo anterior, tu repositorio debería contener sólo las siguientes carpetas:

• Assets
• Packages
• Project Settings

La más crítica de las carpetas anteriores es la de Assets ya que contiene todo el código del proyecto, así como los modelos, texturas, música, sonidos, y todos los elementos con los que está construido nuestro proyecto. 

La pregunta de siempre: ¿Qué hago con los ficheros .meta?

Si usas el explorador de ficheros para examinar la carpeta Assets, verás que cada uno de los elementos anteriores lleva asociado un fichero con extensión .meta. Dado que Unity se encarga de generar automáticamente esos ficheros .meta, mucha gente se pregunta si deberían incluirse en el repositorio. Para responder a esa pregunta, primero hay que entender para qué sirven.

Unity asocia un fichero .meta a cada uno de los ficheros assets que se incluyan en el proyecto. En los ficheros .meta se guardan los parámetros para importar cada asset en el proyecto. Esto es especialmente importante con assets como las texturas o los sonidos ya que, si no incluimos los ficheros .meta en el versionado, otros desarrolladores del equipo pueden importar los mismos recursos con diferentes parámetros, lo que puede darnos problemas.

Dado que Unity tiende a generarlos automáticamente si no los encuentra, es muy importante insistirle a todo el equipo en que, cuando creen un nuevo asset, lo incluyan en el repositorio junto con su respectivo archivo .meta. Si alguno se le pasase incluir en el repositorio el fichero .meta del recién creado asset, los próximos desarrolladores que se lo bajasen generarían un fichero .meta para él (lo haría el editor de Unity de manera automática al echarlo en falta) por lo que tendríamos un potencial conflicto al hacer los merges, dado que tendríamos diferentes ficheros .meta (uno por desarrollador) para un mismo asset. Es una situación fea que da para recurrentes preguntas en reddit. 

Moraleja: bajo ningún concepto te olvides de incluir los ficheros .meta en el repositorio de versiones.

Conclusión

Con lo anterior, ya tienes lo básico para saber si te falta algo importante en tu repositorio. Luego, operar con ese repositorio es un capítulo aparte que da para muchísimo. Usar un repositorio de Git es fácil, pero hacerlo de manera efectiva, y sin liarla, tiene mucha más miga.

Si quieres profundizar en este tema, le dedico el capítulo 15 de mi libro "Reconstrucción de un juego mítico con Unity".

Game Engines basados en Blender

Blender se ha erigido, por derecho propio, como una de las grandes herramientas de modelado, animación y rendering del mercado. Su calidad, unida a su carácter open-source y gratuito, ha disparado su popularidad aupándola a una posición en la que puede mirar de tú a tú a grandes "monstruos" comerciales como Maya o 3D Studio.

Lo que no sabe tanta gente es que Blender también fue un engine para construir juegos. Se llamaba Blender Game Engine (BGE), y estuvo integrado con Blender desde comienzo de la década de los 2000. Permitía la creación de aplicaciones interactivas directamente desde Blender, sin necesidad de herramientas externas. Para la lógica, permitía no sólo programar en Python sino también emplear un lenguaje visual, muy similar a los actuales Blueprints de Unreal Engine.

El engine permitía crear juegos tanto 3D como 2D, con física en tiempo real (usando la librería Bullet Physics). También permitía crear shaders básicos y animaciones. Como estaba integrado en Blender, ya no hacía falta exportar los modelos a otros motores.

Para demostrar las capacidades del engine, la fundación Blender desarrolló el juego "Yo Frankie!" en 2008. El juego era vistoso, pero pronto quedó claro que que se quedaba atrás respecto a lo que podían ofrecer otros engines como Unity o Unreal. Frente a estos, el BGE no podía ofrecer más que un rendimiento limitado en proyectos complejos, adolecía de falta de soporte para plataformas móviles modernas y su interfaz de desarrollo estaba menos pulido.

Al final, la fundación Blender tuvo que tomar una decisión. Para mantenerse a la par que otros engines, el BGE requería en exclusiva de un equipo de desarrolladores que la fundación no podía dedicar. Además, la comunidad de desarrolladores de BGE, ajenos a la fundación, era muy pequeña y eso hacía que el ritmo de actualizaciones fuera muy lento. BGE se iba quedando atrás a ojos vista e iba lastrando al resto del proyecto de Blender. Al final se optó por abandonar el BGE, para poder concentrar los recursos de desarrollo en aquello que mejor se le daba a Blender: las herramientas de modelado, animación y renderizado (como Cycles).

La eliminación formal del BGE tuvo lugar en 2019, con la versión 2.80 de Blender. A partir de ahí, la fundación recomendó usar Blender como herramienta de modelado y exportar desde allí los assets a motores más avanzados.

Afortunadamente, como suele pasar en el mundo open-source, el cierre de un proyecto no suele ser tal, sino más bien su traspaso. Otros desarrolladores, interesados en continuar con el proyecto, recogieron el código fuente de BGE y lo hicieron evolucionar a partir de ahí. Gracias a eso, dónde antes teníamos un engine (BGE) ahora tenemos dos descendientes de aquel y uno fuertemente inspirado en él. Vamos a analizarlos:

UPBGE (Uchronia Project Blender Game Engine)

Este engine fue creado, junto con otros colaboradores, por Porteries Tristan, uno de los desarrolladores del BGE original 

Inicialmente, UPBGE pretendía ser una bifurcación que mejorase el código de BGE, limpiando su base y experimentando con nuevas características, pero con vistas a acabar incorporándose en el código principal de BGE. Sin embargo, la eliminación de BGE en la versión 2.80 de Blender llevó a UPBGE a adquirir identidad propia e independiente. A partir de entonces, UPBGE ha continuado su desarrollo asegurándose de sincronizar su código con el de Blender, para mantener la compatibilidad.

UPBGE está completamente integrado con Blender, permitiendo modelado, animación y desarrollo de juegos en un solo entorno sin necesidad de exportar assets.

Utiliza el motor EEVEE de Blender para renderizado en tiempo real, con soporte para sombreado PBR, reflejos SSR, oclusión ambiental GTAO, bloom, sombras suaves y volumétricos.

Usa la biblioteca Bullet Physics para simulaciones en tiempo real, incluyendo cuerpos rígidos, simulación de obstáculos y búsqueda de caminos.

Además, incluye un motor de audio basado en OpenAL y Audaspace, con soporte para sonido 3D

Para la lógica de los juegos, mantiene el sistema de "logic bricks" del BGE original y añade Logic Nodes, facilitando la creación de comportamientos interactivos sin programar. También soporta scripting en Python para los que prefieran programar a golpe de teclado.

A la hora de importar y exportar elementos, permite los mismos formatos que Blender, principalmente FBX, Collada, glTF, OBJ y STL.

Se trata de un proyecto muy activo, con un equipo pequeño pero muy implicado de desarrolladores, que sacan actualizaciones regulares cada pocos meses y mantienen el engine sincronizado con las evoluciones de Blender.

A nivel de funcionalidades, los desarrolladores planean añadir características modernas como SSAO, profundidad de campo (DoF), herramientas para modo en línea o luces de área.

Por tanto, se trata de un proyecto muy interesante y prometedor, al que sólo se puede poner un pero y es que el rendimiento que se puede esperar en escenas complejas, con muchos polígonos o riqueza de efectos, puede ser más limitado que el que se puede conseguir con engines como Unity o Unreal.

También hay que tener en cuenta que hereda la licencia GPL de BGE. Los juegos desarrollados con UPBGE no están obligados a ser de código abierto si solo usan los datos del proyecto (modelos, texturas, scripts, etc.) y no distribuyen el ejecutable de UPBGE (blenderplayer). Sin embargo, si un juego incluye el blenderplayer o partes del código de UPBGE, debe cumplir con la GPL y ser distribuido con el código fuente.

Range Engine

Este engine no es un fork del BGE original, sino de UPBGE. Se originó en 2022, como consecuencia de determinadas decisiones de diseño que se tomaron para UPBGE 3.0. Algunos desarrolladores entendieron que dichas decisiones alejaban a UPBGE del espíritu del BGE original y por eso decidieron escindirse a través de un fork.

Por ese motivo, Range Engine conserva un interfaz mucho más cercano al que había en el BGE original. Frente a UPBGE, Range Engine prima la sencillez de uso.

Range Engine prioriza la compatibilidad con proyectos antiguos de BGE y la sencillez en el flujo de trabajo de los desarrolladores.

Su juventud, y su relativamente menor base de desarrolladores, explican que sus funcionalidades y ritmo de actualizaciones sean menores que los de UPBGE. 

Aun así, parece que han conseguido optimizar el apartado de animaciones frente a UPBGE. Por otro lado, también se han observado limitaciones de rendimiento cuando se utiliza este engine con grandes escenarios abiertos. 

Al igual que UPBGE, está licenciado con GPL. Sin embargo, incluye Range Armor, un formato proxy que permite empaquetar datos de juego separadamente del ejecutable blenderplayer, posibilitando la creación de juegos bajo licencias más flexibles como MIT, lo que facilita la distribución comercial sin restricciones estrictas.

Armory 3D

A diferencia de los dos anteriores, no se trata de un fork directo de BGE, sino de engine de juegos independiente que usa a Blender como complemento para el modelado, texturizado, animación y composición de escenas. Además, enriquece lo anterior con herramientas relacionadas como ArmorPaint (para pintura de texturas PBR) y ArmorLab (para creación de texturas con IA), ambas integradas con el motor Armory.

Basa su editor de lógica en scripts de lenguaje Haxe. Algunos dicen que este lenguajes es más flexible que el Python utilizado en BGE. También ofrece un editor visual basado en nodos, a los que recientemente se han añadido uevos nodos para interpolación (tweening) de valores, vectores y rotaciones, nodos de dibujo de cámara, nodos de pulso para controlar tasas de disparo, y mejoras en la jerarquía de nodos lógicos.

A nivel multimedia, este engine se apoya en el framework Kha. Utiliza un renderizador físicamente basado, compatible con pipelines HDR, sombreado PBR y efectos de posprocesamiento, todo ello de forma muy personalizable.

Al igual que BGE, utiliza Bullet Physics, como motor de físicas, y soporta cuerpos rígidos, colisiones y físicas blandas. También permite configurar el motor de físicas Oimo como alternativa. Además, ofrece soporte para sistemas de partículas (emisor y cabello) con instanciación por GPU para mejorar el rendimiento

Armory 3D tiene mayor compatibilidad para exportar tu juego a diferentes plataformas y ofrecer un rendimiento optimizado de las animaciones. Actualmente soporta Windows, macOS, Linux, Web, Android, iOS y consolas (con configuraciones específicas).

A diferencia de los anteriores, Armory 3D está impulsado principalmente por un único desarrollador (Lubos Lenco) y eso se nota en que las actualizaciones llegan con cuenta gotas. Aun así, poco a poco se van incrementando las colaboraciones y aportaciones externas conformando un primigenio núcleo de desarrolladores.

En cuanto a la licencia, una ventaja respecto a los herederos directos de BGE es que Armory 3D usa la licencia Zlib, más permisiva que la GPL de Blender, permitiendo mayor flexibilidad para proyectos comerciales.

Conclusiones

Como puedes ver, el desarrollo de juegos con Blender está muy vivo, y no sólo usándolo como herramienta complementaria de modelado y animación, sino como un engine en si mismo.

A día de hoy no ofrece un rendimiento equiparable al que se puede obtener con engines dedicados como Unity, Unreal o Godot Engine, pero la posibilidad de poder concentrar en una misma herramienta tanto la programación como el modelado, texturizado y rigging de assets, puede simplificarle mucho la vida a los que quieran iniciarse en el mundo de los videojuegos. Sin contar con que lenguajes como Python o Haxe son realmente sencillos para aprender a implementar los algoritmos típicos de un juego.

Mi consejo, si quieres iniciarte en este tipo de engines, es que empieces con UPBGE y luego pruebes los otros dos, a ver qué valor diferencial te pueden ofrecer.