Ampliar los flujos de trabajo de Unity: Lecciones aprendidas de proyectos de tamaño medio a grande

Esta entrada de blog es la primera de una serie de Mega Cat Studios, en la que comparten sus conocimientos sobre Unity y sus soluciones para los retos reales del desarrollo de videojuegos comerciales. ¡Esperamos que te sirvan de ayuda estos TiPs!

Tienes una idea genial, y el código sale volando tan rápido como lo escribes. Con cada commit, va tomando forma una nueva función. Pero es precisamente la rapidez con la que surgen tus ideas lo que pronto podría llevarte a encontrarte con un gran lío lleno de errores.

En Mega Cat Studios, abordamos todos nuestros proyectos con pasión, por lo que comprendemos el atractivo de ir a toda velocidad y hacer las cosas lo antes posible. Para un prototipo, este enfoque está bien y, de hecho, ¡lo recomendamos! Un desarrollador con experiencia sabe cuándo dar prioridad a la velocidad de iteración y cuándo a la estabilidad. Porque, una vez superada la fase de prototipo, ese enfoque «rápido y poco riguroso» se convierte en un lastre.

En Mega Cat Studios hemos superado esta transición muchas veces y, con cada Projecto, aprendemos algo nuevo. Nos gustaría compartir algunas de las lecciones que hemos aprendido al preparar nuestro proyecto más reciente, Backyard Baseball, para su lanzamiento.

Lección 1: Estructura para la escala

Los problemas de escalabilidad rara vez se deben a un código defectuoso; por el contrario, suelen deberse a una arquitectura mal planificada. Si un desarrollador o un artista no encuentra un recurso en 10 segundos, hay que cambiar el flujo de trabajo. Algunos TiPs para configurar tu proyecto a escala son:

• Organizar por tipo y finalidad: Los agrupamos por tipo y, a continuación, por finalidad. El tipo incluye categorías como arte, código y audio. La finalidad es el uso que se les da. Una organización intuitiva reduce las dificultades de incorporación; un artista nuevo debería saber exactamente dónde va cada sprite de «personaje en reposo» sin tener que preguntar.
• Mantén las escenas simples: Hemos descartado la «megascena» y, en su lugar, hemos optado por escenas más pequeñas, como una escena principal que contiene los datos guardados y los sistemas críticos, junto con una pantalla de título y escenas del campo de béisbol que se cargan de forma adicional dependiendo de si el jugador se encuentra en un partido. Del mismo modo, utilizamos prefabs para elementos independientes, por lo que es menos probable que los cambios se serialicen en el archivo de escena que los contiene. Esto permite que un artista trabaje en el entorno mientras un diseñador ajusta la jugabilidad en el mismo «nivel» sin que se produzcan conflictos entre archivos (más adelante se profundizará en este tema).
• Configurar el sistema Addressables: En lugar de las carpetas de recursos tradicionales, utilizamos el sistema Addressables para cargar los recursos solo cuando es necesario, lo que permite mantener un consumo de memoria reducido. Además, cargar un recurso utilizando su clave Addressable resulta más claro y menos propenso a fallar que cargarlo VIA una ruta de archivo que apunta a una ubicación específica dentro de la carpeta «Resources».

Lo difícil no es entender estas buenas prácticas. Se trata de comprometerse con ellos desde el principio y mantener esa disciplina incluso años después.

Averigua en qué fase de desarrollo te encuentras y cuáles son tus prioridades en esa etapa.

«En la fase de creación de prototipos, dado que apenas hay código, está bien que primero se haga funcional antes de modularlo», afirma Paolo Roxas, desarrollador de Backyard Baseball. «Queremos ver cómo evoluciona el Project antes de complicarlo más».

Lección 2: Trabaja con Unity, no en su contra

«No hay nada más eficaz que crear elementos básicos —ya sean componentes, objetos programables o clases personalizadas— que sean específicos, concisos y autónomos», afirma David Chávez Armenteros, director de ingeniería de Mega Cat Studios. La modularidad es un elemento fundamental de Unity. Para mantener nuestra flexibilidad, seguimos tres principios clásicos:

1. Responsabilidad única: Cada script o clase debe tener una función bien definida.

2. Acoplamiento flexible: Los sistemas deben interactuar a través de interfaces o eventos, en lugar de referencias directas, y solo cuando sea pertinente. Recomendamos representar gráficamente las dependencias entre los sistemas antes de implementarlas en el código, para evitar una arquitectura cíclica o enredada.

3. Plug and Play: Combina unidades pequeñas y específicas para crear comportamientos complejos, en lugar de escribir scripts «omnipotentes» de gran envergadura.

Lección 3: Utiliza las limitaciones para liberarte

Las definiciones de ensamblado (AsmDefs) son construcciones de C# que agrupan el código. Su ventaja principal es la reducción de los tiempos de compilación, pero su verdadero punto fuerte es garantizar la modularidad.

Nico Gaudenzi, desarrollador jefe y enemigo acérrimo del código espagueti, confía plenamente en ellos.

«En Backyard Baseball, la capa de entrada y la capa de juego se encuentran en DLL diferentes. «La mecánica del juego es totalmente independiente de los detalles de la entrada».

Esto evita que los ingenieros se vean en apuros, ya que convierte cada dependencia en una decisión meditada. Si fuera realmente necesario, podríamos reescribir todo el sistema de entrada —desde el manejo del mando hasta el código de red— sin correr el riesgo de alterar la física de los personajes ni el comportamiento de la IA. Lo más probable es que permita a un ingeniero trabajar en un único ámbito del código sin que los cambios se propaguen accidentalmente a otro sistema, y que reduzca la cantidad de código que un desarrollador debe tener en cuenta para la implementación de nuevas funciones y la corrección de errores.

Lección 4: Estudia de forma SMART, no más intensa

A medida que los proyectos crecen, puede producirse el «efecto dominó»: Un pequeño cambio aquí provoca un problema allá. Una buena arquitectura es muy útil, pero no es la panacea.

Antes de que los cambios en las funciones lleguen a las garras de nuestros estimados gatos del departamento de control de calidad para someterse a pruebas manuales, el juego se analiza rigurosamente mediante una serie de pruebas unitarias automatizadas.

«Las pruebas funcionan como una lista de requisitos», afirma Nico. «Describen lo que se espera y ofrecen ejemplos de uso clave».

Cuando un personaje de Backyard Baseball lanza una bola rápida, roba una base o batea un jonrón, queremos conseguir unos resultados específicos en el juego, como garantizar que la bola viaje a una velocidad que resulte realista para el lanzamiento, que la sincronización del corredor se ajuste a la mecánica de robo de bases o que los defensores reaccionen correctamente ante un golpe. El personaje debe chocar correctamente contra el suelo, la pelota debe moverse a la velocidad adecuada y deben funcionar sistemas más detallados, como los indicadores del controlador del jugador que registran acciones como el lanzamiento, el swing o el sprint entre bases.

Cuando modificamos la potencia de Pablo Sánchez o, lo que es aún más importante, ajustamos el código común que controla los movimientos del bate, debemos asegurarnos de que todas las interacciones, desde el momento del contacto hasta la trayectoria de la pelota, se comporten de manera coherente a lo largo de todo el juego.

A menudo, lo que falla es algo que uno no se esperaría, y esa es precisamente la razón por la que las pruebas son tan importantes.

Al integrar este sistema en nuestro flujo de trabajo, nos damos cuenta en el momento en que se produce un fallo en un requisito concreto, lo que reduce las sesiones de pruebas y resolución de problemas, que requieren tanto tiempo como buscar una aguja en un pajar.

El Test Runner de Unity funciona con mayor eficacia cuando los sistemas son modulares, lo cual es otra razón por la que utilizamos definiciones de ensamblaje.

Lección 5: Get your assets in gear

«Errar es humano; perdonar, divino».

Pero implantar sistemas para evitar los errores humanos desde el principio es sencillamente legendario.

Después de horas programando y depurando, es inevitable que algún desarrollador con los ojos cansados haga algún clic erróneo o envíe accidentalmente al repo cambios que solo estaban pensados para ser temporales. Aunque es comprensible (lo digo como alguien que a veces se levanta con sueño), un activo con una configuración de importación deficiente podría tener graves consecuencias. Y dado que muchos desarrolladores trabajan con equipos potentes, la peor pesadilla es que el problema de rendimiento pase desapercibido hasta más adelante, por ejemplo, cuando una escena en un estadio con personajes, animaciones y efectos empiece a provocar ralentizaciones o inestabilidad en hardware de gama baja.

Para mitigar este riesgo, se podría limitar el acceso a los activos, pero esto provoca un cuello de botella debido a las numerosas razones por las que es necesario ajustar el contenido del juego:

• La modelo es demasiado alta para caber en el encuadre de la cámara.
• Este clip de audio tiene poco volumen, por lo que necesita un efecto específico.
• Ahora que se ha cambiado el sombreador, hay que ajustar todas las texturas.

En un juego como Backyard Baseball, donde la identidad visual es premium, los modelos y los efectos visuales se someten a cientos de ajustes hasta conseguir el aspecto y la sensación perfectos antes del lanzamiento.

«Por muchas especificaciones técnicas que haya, no se puede ignorar el hecho de que contar con una variedad de contenidos implica lidiar con diferencias sutiles, pero de importancia, entre los distintos recursos», afirma Nico.

La Automation también ayuda en este caso:

• AssetPostprocessor: Desarrollamos lógica de importación personalizada que garantiza el cumplimiento de las Project Standards.
• OnValidate: Utilizamos el método OnValidate para señalar las referencias que faltan en el Editor, ya que este método siempre se ejecuta antes de la compilación.

Por último, sin embargo, no dejes que todo este debate sobre la Automation te haga pasar por alto las soluciones manuales simples cuando estas sean más rápidas.

«Nunca dediques diez días a automatizar una tarea que se hace en diez minutos de forma manual», advierte David.

Lección 6: Domina el factor humano (la colaboración)

Los sistemas de Version Control como Git son de lo primero que se nos viene a la mente a la hora de coordinar cientos de cambios realizados por decenas de desarrolladores cada día. David recomienda estas metodologías de probada eficacia para todos nuestros proyectos en Mega Cat:

• Pequeños cambios atómicos: Evita los «mega commits» que afectan a muchos sistemas a la vez. Aísla el trabajo en ramas de características individuales hasta que estén estables y hayan sido revisadas. Guarda los cambios individuales en commits individuales para mantener un historial de versiones bien documentado que, además, facilite la selección selectiva y otras funciones avanzadas de Git cuando sea necesario.
• Fusiones diarias desde «main»: Mantén las ramas de funciones, de departamentos y de larga duración actualizadas con respecto a la rama principal, ya que esto puede reducir el tamaño y la complejidad de las fusiones finales, lo que ayuda a evitar conflictos a gran escala.
• Revisar las solicitudes de fusión: Esta es la primera línea de control de calidad, donde se detectan errores, se aplican las Project Standards y se garantiza la coherencia con el sistema en su conjunto.

«En los proyectos grandes de Unity, las revisiones de código no son solo una formalidad», aconseja David. «Son un elemento clave para la prevención de conflictos y para la calidad general del proyecto».

Solo hay que asegurarse de que las personas que revisan el código tengan experiencia en el ámbito en cuestión y conozcan las mejores prácticas de programación, para que puedan evaluar con precisión la corrección y la facilidad de mantenimiento del código.

Hay TiPs y trucos específicos para que el Version Control en Unity funcione de la forma más fluida posible. Las escenas y los prefabs constituyen la base de tu Project, así que optimízalos no solo para mejorar el rendimiento de la CPU, sino también para facilitar la colaboración entre desarrolladores.

Siempre preferimos componentes más pequeños, complementarios y anidados a una escena grande o a un prefabricado monolítico. De esta forma, los desarrolladores pueden trabajar en paralelo sin que se produzcan conflictos.

Esto es importante, ya que los conflictos de fusión en escenas y prefabs son los más difíciles de resolver, ya que los desarrolladores no pueden leer fácilmente sus datos. Para facilitar este proceso, serializamos estos archivos como texto, en lugar de como binario, y activamos la función de fusión automática de nuestra configuración de Git para archivos YAML. Esto hace que Git tenga más posibilidades de resolver por sí mismo los conflictos de fusión y permite que los desarrolladores dediquen su tiempo a la importante tarea de crear nuevas funciones.

Pero a pesar de todo eso:

«Prevenir los conflictos suele ser una estrategia mejor que intentar resolverlos», afirma Nico.

Una titularidad clara de los activos puede ser de gran ayuda en este sentido.

«Define quién puede modificar escenas o prefabs concretos», dice David. «Entonces, los miembros del equipo solicitan cambios fuera de su ámbito de responsabilidad en lugar de editar los activos directamente».

Nico describe un procedimiento similar como un «sistema de semáforos». Se trata, básicamente, de una hoja de cálculo en la que los desarrolladores registran cuándo modifican un recurso, «bloqueándolo» de hecho. Si otro desarrollador necesita realizar cambios en ese archivo, deberá esperar a que el desarrollador que lo ha bloqueado envíe sus cambios al repo y lo «desbloquee».

Como siempre, busca el procedimiento que mejor se adapte a tu equipo.

Construyendo el futuro

En Mega Cat Studios, hemos aprendido que escalar un proyecto de Unity no consiste tanto en «programar más» como en aplicar una arquitectura rigurosa. Al respetar la naturaleza basada en componentes de Unity, establecer límites mediante definiciones de ensamblaje y organizar los recursos pensando en el futuro, conservamos gran parte del flujo creativo de la fase de prototipo sin que el proyecto se vea abrumado por la deuda técnica antes del lanzamiento.

Aunque estas lecciones son importantes, recuerda que no hay código perfecto. El desarrollo de software es una batalla épica en la que los patrones de programación recomendados y las consideraciones prácticas se enfrentan a diario. Si seguir uno de estos principios frena el desarrollo sin aportar ninguna ventaja a cambio, es una señal de que debes prestar más atención a las particularidades de tu propio equipo y no a las recomendaciones de los manuales. Al fin y al cabo, cada proyecto, cada equipo y cada persona es diferente.

En Mega Cat Studio intentamos encontrar ese equilibrio cada día. Con cada nuevo proyecto, a medida que nuestra biblioteca de juegos sigue creciendo, esperamos convertirnos en mejores desarrolladores de Unity y en mejores colaboradores.