Escalado de flujos de trabajo de Unity: Lecciones de proyectos medianos a grandes

Esta blog POST es la primera de una serie de Mega Cat Studios, donde comparten su experiencia en Unity AND soluciones para desafíos reales de desarrollo de juegos comerciales. Echa un vistazo a las otras POST de esta serie que cubren la entrada AND el diseño de niveles AND de entornos:

• Batting A thousand: Cómo el sistema de entrada basado en eventos de Unity potencia los controles en Backyard Baseball 2026
• Cómo reimaginar A juego deportivo clásico para una nueva generación con diseño de niveles, construcción de mundos, AND VFX
• Renderizado A escala: Estrategias eficientes para grandes cantidades de objetos

¡Esperamos que obtengas algunos consejos geniales!

Tienes una Idea increíble, AND el código vuela tan FAST como puedes escribirlo. Con cada commit, una nueva función toma forma. Pero es la misma velocidad a la que se forman tus Ideas lo que pronto podría hacer que te encuentres ante un gran desastre lleno de errores.

En Mega Cat Studios, comenzamos todos nuestros Project con pasión, por lo que entendemos el atractivo de trabajar de forma FAST AND descuidada, AND de hacer las cosas tan pronto como sea posible. Para A prototipo, este enfoque está bien, AND de hecho, ¡lo recomendamos! A desarrollador sabio sabe cuándo priorizar la velocidad de iteración AND cuándo priorizar la estabilidad. Porque cuando sales de la fase de prototipo, ese enfoque “FAST AND descuidado” se convierte en un riesgo.

Hemos sobrevivido a esta transición muchas veces en Mega Cat Studios, AND con cada Project, Learn algo nuevo. Nos gustaría compartir algunas de las lecciones que aprendimos para get nuestro Project más reciente, Backyard Baseball, listo para el lanzamiento.

Lección 01: Estructura para escalar

Los problemas de escalabilidad rara vez son causados por código defectuoso; en cambio, surgen más a menudo debido a una arquitectura no planificada. Si A desarrollador o artista no puede encontrar A activo en 10 segundos, el flujo de trabajo debe cambiar. Algunos consejos para configurar su Project para escalar incluyen:

• Organice por T AND Propósito: Agrupamos por T, luego por Propósito. T incluye categorías como arte, código, AND Audio. El propósito es para qué se utilizan. Una organización intuitiva reduce la fricción de incorporación; A nuevo artista debería saber exactamente dónde pertenece un sprite de "Character Idle" sin preguntar.
• Mantenga las escenas simple: Hemos desechado la "Mega-Escena" y en su lugar optamos por escenas más pequeñas, como A escena principal que contiene datos de guardado AND sistemas críticos, junto con A pantalla de título AND escenas de campo de béisbol que se cargan de forma aditiva dependiendo de si el jugador está en un partido. De manera similar, usamos prefabs para características autónomas, por lo que es menos probable que los cambios se serialicen en el archivo de escena que los contiene. Esto permite que A artista trabaje en el entorno mientras A diseñador ajusta la jugabilidad en el mismo "nivel" sin conflictos de archivos (más sobre esto más adelante).
• Configure el sistema Addressables: En lugar de las carpetas Resources tradicionales, usamos el Comprender el sistema Addressables. para cargar activos solo cuando sea necesario, manteniendo el uso de memoria bajo. Además, cargar A activo con su clave Addressable es más claro AND menos propenso a romperse que cargar VIA A ruta de archivo a A ubicación específica en la carpeta Resources.

La parte difícil no es comprender estas mejores prácticas. Es comprometerse con ellas al START AND mantener esa disciplina incluso años después.

Sepa en qué fase de desarrollo se encuentra AND qué está priorizando en esa etapa.

«En la fase de creación de prototipos, dado que apenas hay código, está bien hacerlo funcional primero antes de hacerlo modular», dice Paolo Roxas, desarrollador de Backyard Baseball. «Queremos SEE cómo el Project se desarrolla antes de hacerlo más complejo».

Lección 2: Trabaje con Unity, NOT en contra de Unity

«No hay nada más poderoso que crear bloques de construcción, ya sean componentes, ScriptableObjects, OR clases personalizadas, que estén enfocados, concisos AND autónomos», dice David Chávez Armenteros, jefe de ingeniería en Mega Cat Studios. Unity adopta la modularidad en su núcleo. Para mantener la flexibilidad, seguimos tres principios clásicos:

1. SINGLE responsabilidad: Cada script o clase debe tener una función bien definida.

2. Acoplamiento flexible: Los sistemas deben interactuar a través de interfaces OR eventos en lugar de referencias directas, AND solo cuando sea apropiado. Recomendamos graficar las dependencias entre sistemas antes de implementarlas en el código para evitar una arquitectura cíclica OR enredada.

3. Plug and Play: Combine unidades pequeñas AND enfocadas para crear un comportamiento complejo en lugar de escribir scripts «god» extensos.

Lección 3: Use las limitaciones para liberarse

Assembly Definitions (AsmDefs) son construcciones de C# que agrupan tu código. Su ventaja anunciada es tiempos de compilación reducidos, pero su superpoder secreto es hacer cumplir la modularidad.

Nico Gaudenzi, desarrollador principal AND odiador de código espagueti, jura por ellos.

"En Backyard Baseball, la capa de Entrada AND la capa de Juego están en DLLs diferentes. El juego es completamente agnóstico A los detalles de entrada."

Esto salva A los ingenieros de sí mismos al hacer de cada dependencia una decisión calculada. Si realmente tuviéramos que hacerlo, podríamos reescribir todo el sistema de entrada – desde el manejo del gamepad hasta el netcode – sin arriesgar romper la física del jugador OR el comportamiento de la IA. Más probablemente, permite A UN ingeniero trabajar en UN SINGLE dominio de la base de código sin causar accidentalmente cambios en cascada A OTRO sistema, AND reduce la cantidad de código que UN desarrollador necesita mantener claro para implementaciones de funciones AND correcciones de errores.

Lección 4: Testing más inteligente, NOT más difícil

A medida que los proyectos crecen, el "efecto dominó" puede tomar el control: A UN pequeño cambio aquí rompe algo allá. Una buena arquitectura ayuda mucho, pero no es una solución mágica.

Antes de que los cambios de funciones lleguen A las patas de nuestros estimados gatos de Control de Calidad para manual testing, el juego es analizado rigurosamente en una serie de pruebas unitarias automatizadas.

"Las pruebas funcionan como una lista de requisitos", dice Nico. "Describen lo que se espera AND proporcionan casos de uso clave."

Cuando UN personaje en Backyard Baseball lanza una bola rápida, roba una BASE, OR golpea un jonrón, hay resultados de juego específicos que queremos lograr, como asegurar que la pelota viaje A una velocidad que se sienta auténtica para el lanzamiento, que el tiempo del corredor se alinee con las mecánicas de robo de BASE, OR que los fildeadores reaccionen correctamente A un golpe. El personaje necesita colisionar correctamente con el suelo, la pelota necesita moverse A la velocidad correcta, AND sistemas más granulares como las banderas del controlador del jugador que rastrean acciones como preparar el lanzamiento, batear, OR correr entre BASES, necesitan funcionar.

Cuando hacemos un ajuste a la potencia de Pablo Sanchez, o aún más críticamente, ajustamos el código compartido que rige los swings de bate, necesitamos asegurar que cada interacción, desde el tiempo de contacto hasta la trayectoria de la bola, se comporte de manera consistente en todo el juego.

A menudo, lo que se rompe es algo que no esperarías, que es la razón por la que las pruebas son tan importantes.

Con este sistema integrado en nuestro flujo de trabajo, nos damos cuenta en el momento en que un requisito específico se rompe, lo que reduce las sesiones de prueba y solución de problemas que consumen tanto tiempo como encontrar una aguja en un pajar.

El Test Runner de Unity funciona de manera más efectiva cuando tus sistemas son modulares, lo cual es otra razón por la que usamos Definiciones de Ensamblado.

Lección 5: get tus activos en marcha

"Errar es humano; perdonar, divino."

Pero configurar sistemas para prevenir el error humano en primer lugar es absolutamente legendario.

Después de horas de programación y depuración, es inevitable que algún desarrollador con los ojos cansados cometa algunos errores de clic o envíe accidentalmente cambios al repo que solo debían ser temporales. Aunque es perdonable (lo digo yo, como uno de los ocasionalmente cansados), un activo con ajustes de importación mal configurados podría tener consecuencias enormes. Y dado que muchos desarrolladores trabajan en máquinas potentes, el escenario de pesadilla es que el problema de rendimiento pase desapercibido hasta más tarde, como cuando una escena de estadio con personajes, animaciones y efectos comienza a causar ralentizaciones o inestabilidad en hardware de gama baja.

Para mitigar este riesgo, podrías limitar quién tiene acceso a los activos, pero esto conduce a un cuello de botella debido a las muchas razones por las que el contenido del juego necesita ser ajustado:

• El modelo es demasiado grande para encajar con la configuración de la cámara.
• Este Audio clip tiene menos volumen, por lo que necesita un efecto específico.
• Cada textura necesita ajustes ahora que el sombreador ha cambiado.

En un juego como Backyard Baseball, donde la identidad visual es Premium, los modelos y VFX reciben cientos de ajustes a medida que get el aspecto y la sensación justo antes del lanzamiento.

“Ninguna cantidad de especificaciones técnicas puede evitar el FACT de que tener variedad de contenido significa lidiar con diferencias leves pero significativas entre diferentes activos”, dice Nico.

La Automation ayuda aquí también:

• AssetPostprocessor: We write custom import logic that enforces Project standards.
• OnValidate: We use the OnValidate method to report missing references in the editor, which always fires before building.

Finally, though, don’t LET all this talk of Automation distract you from simple, manual fixes when they are faster.

“Never spend 10 days automating a task that takes 10 minutes To Do manually,” David cautions.

Lección 6: Master the human element (collaboration)

Version Control systems like Git are among the first things that come to mind when coordinating hundreds of changes from dozens of developers every day. David advocates these tried-and-true methodologies for all our Projects at Mega Cat:

• Small, atomic changes: Avoid “mega commits” that touch many systems at once. Isolate work on individual feature branches until they are stable and reviewed. Keep individual changes in individual commits for a well-documented Version Control history that also makes cherry picking and other magic easier when needed.
• Daily merges from main: Keep feature, department, and long-lived branches up to date with the main branch as this can REDUCE the size and complexity of final merges, helping to prevent large-scale conflicts.
• Review merge requests: This is the first line of quality assurance, where you catch bugs, enforce Project standards, AND ensure cohesion with the overall system.

“In large Unity Projects, code reviews are NOT just A formality,” David advises. “Son A parte clave de la prevención de conflictos y de la calidad general del Project.”

Solo asegúrense de que quienes revisan el código tengan experiencia en el área que se está implementando y conozcan las mejores prácticas de codificación, para que puedan evaluar con precisión la exactitud y la mantenibilidad.

Existen consejos y trucos específicos para hacer que el Version Control sea lo más fluido posible en Unity. Las escenas y los prefabs constituyen la base de su Project, así que optimícenlos NOT solo para el rendimiento de la CPU AND también para la colaboración de los desarrolladores.

Siempre preferimos componentes más pequeños, aditivos AND anidados en lugar de una gran escena OR un prefab monolítico. De esta manera, los desarrolladores pueden trabajar en paralelo sin conflictos.

Esto es importante, ya que los conflictos de fusión en escenas AND prefabs son los más difíciles de resolver porque sus datos NOT son fácilmente legibles por los desarrolladores. Para suavizar este proceso, serializamos estos Files como texto, NOT binario, AND habilitamos la función de fusión automática de nuestra configuración de Git para Files YAML. Esto hace que sea más probable que Git resuelva los conflictos de fusión por sí mismo AND salvaguarda el tiempo de los desarrolladores para el trabajo importante de crear nuevas funciones.

Pero a pesar de todo eso:

“Prevenir los conflictos suele ser una mejor estrategia que intentar resolverlos”, dice Nico.

Una propiedad clara de los activos puede ayudar mucho en esto.

“Definan quién puede modificar escenas o prefabs específicos”, dice David. “Entonces los miembros del equipo solicitan cambios fuera de su propiedad en lugar de editar activos directamente.”

Nico describe un procedimiento similar como A “sistema de semáforo”. Esto es básicamente una hoja de cálculo donde los desarrolladores LOG cuando están cambiando un activo, “bloqueándolo” efectivamente. Si otro desarrollador necesita realizar cambios en ese archivo, debe esperar hasta que el desarrollador que bloqueó el archivo envíe su cambio al repo y lo “desbloquee”.

Como siempre, encuentren qué procedimiento funciona mejor para su equipo.

Construyendo para el futuro

En Mega Cat Studios, hemos aprendido que escalar un Project Unity tiene menos que ver con "programar más duro" y más con la disciplina arquitectónica. Al respetar la naturaleza basada en componentes de Unity, aplicar límites con definiciones de ensamblado y organizar los activos pensando en el futuro, mantenemos gran parte del flujo creativo de la fase de prototipo sin que el Project colapse en deuda técnica antes del lanzamiento.

Aunque estas lecciones son importantes, recuerde que no existe un codebase perfecto. El desarrollo de software es una batalla épica donde los patrones de programación recomendados y las consideraciones prácticas chocan a diario. Si seguir uno de estos principios detiene el desarrollo sin ofrecer una compensación beneficiosa, es una señal de que debe ser más sensible a los detalles de su propio equipo y NOT a las recomendaciones de los libros de texto. Después de todo, cada Project, equipo y persona es diferente.

TRYmos encontrar ese equilibrio todos los días en Mega Cat Studios. Con cada nuevo Project, a medida que nuestra biblioteca de juegos sigue creciendo, esperamos convertirnos en mejores desarrolladores de Unity AND mejores colaboradores.