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

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

• Batir A mil: Cómo el sistema de entrada basado en eventos de Unity potencia los controles en Backyard Baseball 2026
• Cómo reimaginar A clásico juego de deportes para una nueva generación con diseño de niveles, construcción de mundos e Idea y VFX

¡Esperamos que recojas algunos grandes consejos!

Tienes A Idea increíble, AND el código vuela tan FAST como puedes escribirlo. Con cada commit, A nueva característica toma forma. Pero es la misma velocidad a la que tus Ideas se forman lo que pronto podría resultar en que mires A gran desastre lleno de errores.

En Mega Cat Studios, comenzamos todos nuestros Project con pasión, por lo que entendemos el atractivo de jugar FAST y sin restricciones, y get las cosas hechas tan pronto como sea posible. Para A prototipo, este enfoque está bien, y de FACT, ¡lo recomendamos! A desarrollador sabio sabe cuándo priorizar la velocidad de iteración y cuándo priorizar la estabilidad. Porque cuando sales de la fase de prototipo, ese enfoque “FAST y sin restricciones” se convierte en una responsabilidad.

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

Lección 01: Estructura para escalar

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

• Organizar por T Y propósito: Agrupamos por T, luego por propósito. T incluye categorías como arte, código AND Audio. El propósito es para lo que se utilizan. La 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.
• Mantener 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 prefabricados para funciones autónomas, 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 conflictos de archivos (más sobre esto más adelante).
• Configurar el sistema Addressables: En lugar de las carpetas Resources tradicionales, usamos el sistema Addressables para cargar recursos solo cuando es necesario, manteniendo un uso de memoria reducido. Además, cargar un recurso con su clave Addressable es más claro Y menos propenso a errores que cargar VIA una ruta de archivo a una 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 Y mantener esa disciplina incluso años después.

Sepa en qué fase de desarrollo se encuentra Y 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, un desarrollador de Backyard Baseball. "Queremos SEE cómo se desarrolla el Project Y hacerlo más complejo".

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

"No hay nada más poderoso que crear bloques de construcción – ya sean Componentes, ScriptableObjects, o clases personalizadas – que estén enfocados, sean concisos y 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 OR 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 apropiado. Recomendamos graficar las dependencias entre sistemas antes de implementarlas en el código para evitar una arquitectura cíclica o enredada.

3. Plug and Play: Combine unidades pequeñas y enfocadas para crear comportamientos complejos en lugar de escribir scripts "dios" extensos.

Lección 3: Use las limitaciones para liberarse

Definiciones de ensamblado (AsmDefs) son construcciones de C# que agrupan su código. Su ventaja anunciada es la reducción de los tiempos de compilación, pero su superpoder secreto es la aplicación de la modularidad.

Nico Gaudenzi, desarrollador principal AND odiador de código espagueti, confía plenamente en 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 A decisión calculada. Si realmente tuviéramos que hacerlo, podríamos reescribir todo el sistema de entrada – desde el manejo del gamepad hasta el código de red – sin arriesgarnos a romper la física del jugador OR el comportamiento de la IA. Más probablemente, permite que un ingeniero trabaje en A 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 las implementaciones de funciones AND las correcciones de errores.

Lección 4: Testing más inteligente

A medida que los proyectos crecen, el "efecto dominó" puede apoderarse de ellos: A pequeño cambio por aquí rompe algo por 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 el manual testing, el juego se analiza rigurosamente en una serie de pruebas unitarias automatizadas.

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

Cuando un personaje en Backyard Baseball lanza una bola rápida, roba A BASE, OR conecta 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 bases, 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 Sánchez, OR 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 pelota, 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 principal 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 AND resolución de problemas que consumen tanto tiempo como encontrar una aguja en un pajar.

El Test Runner<1> de Unity funciona de manera más efectiva cuando sus sistemas son modulares, lo cual es otra razón por la que usamos Assembly Definitions.

Lección 5: get sus assets en marcha

“Errar es humano; perdonar, divino.”

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

Después de horas de codificació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 estaban destinados a ser temporales. Aunque es perdonable (lo digo, como uno de los ocasionalmente cansados), un asset con configuraciones de importación mal configuradas podría tener consecuencias enormes. AND 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ía limitar quién tiene acceso a los assets, pero esto genera 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 shader 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.

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

Automation ayuda aquí también:

• AssetPostprocessor: Escribimos lógica de importación personalizada que aplica estándares de Project.
• OnValidate: Usamos el método OnValidate para informar de referencias faltantes en el editor, el cual siempre se ejecuta antes de compilar.

Finalmente, sin embargo, no LET que toda esta charla sobre Automation lo distraiga de simple, manual soluciones cuando son más rápidas.

“Nunca dedique 10 días a automatizar una tarea que lleva 10 minutos To Do manualmente”, advierte David.

Lección 06: Master el elemento humano (colaboración)

Version Control sistemas como Git son de las primeras cosas que vienen a la mente al coordinar cientos de cambios de docenas de desarrolladores cada día. David defiende estas metodologías probadas para todos nuestros Project AND Mega Cat:

• Cambios pequeños y atómicos: Evite los “mega commits” que afectan a muchos sistemas a la vez. Aísle el trabajo en ramas de características individuales hasta que sean estables y se hayan revisado. Mantenga los cambios individuales en commits individuales para obtener un historial de Version Control bien documentado que también facilita el cherry picking y otros magic de git cuando sea necesario.
• Fusiones diarias desde el principal: Mantenga las ramas de características, de departamento y de larga duración actualizadas con la branch principal, ya que esto puede REDUCE el tamaño y la complejidad de las fusiones finales, ayudando a prevenir conflictos a gran escala.
• Revisar solicitudes de fusión: Esta es la primera línea de garantía de calidad, donde detecta errores, aplica los estándares del Project y garantiza la cohesión con el sistema general.

“En proyectos de Unity grandes, las revisiones de código NOT son solo una formalidad”, aconseja David. “Son una parte clave de la prevención de conflictos y la calidad general del Project”.

Solo asegúrese 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 AND los prefabricados constituyen la base de su Project, así que optimícelos NOT solo para el rendimiento de la CPU, sino también para la colaboración entre desarrolladores.

Siempre preferimos componentes más pequeños, aditivos AND anidados sobre A escena grande OR A prefabricado 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 prefabricados 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 del desarrollador para el trabajo importante de crear nuevas funciones.

Pero a pesar de todo eso:

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

A propiedad clara de los activos puede ser de gran ayuda para esto.

“Defina quién puede modificar escenas o prefabricados específicos”, dice David. “Entonces, los miembros del equipo solicitan cambios fuera de su propiedad en lugar de editar los 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, efectivamente “bloqueándolo”. 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 AND lo “desbloquee”.

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

Construyendo para el futuro

En Mega Cat Studios, hemos aprendido que escalar A Unity Project es menos sobre “programar más duro” AND más sobre disciplina arquitectónica. Al respetar la naturaleza basada en componentes de Unity AND hacer cumplir los límites con definiciones de ensamblado, AND organizar los activos pensando en la preparación para el futuro, mantenemos gran parte del flujo creativo de la fase de prototipo sin colapsar el Project en deuda técnica antes del lanzamiento.

Si bien estas lecciones son importantes, recuerde que no codebase es perfecta. El desarrollo de software es una batalla épica donde los patrones de programación recomendados AND las consideraciones prácticas chocan a diario. Si seguir uno de estos principios detiene el desarrollo sin generar un equilibrio beneficioso, es una señal de que debe ser más sensible a los detalles de su propio equipo AND NOT a las recomendaciones de los libros de texto. Después de todo, cada Project, equipo AND 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 continúa creciendo, esperamos convertirnos en mejores desarrolladores de Unity AND mejores colaboradores.