Escalonando fluxos de trabalho do Unity: Lições de projetos de médio a grande porte

Esta postagem de blog é a primeira de uma série da Mega Cat Studios, onde eles compartilham sua experiência com Unity e soluções para desafios reais de desenvolvimento de jogos comerciais. Confira as outras postagens desta série que abordam entrada, design de nível e de ambiente:

• Acertando em cheio: Como o Input System orientado a eventos do Unity impulsiona os controles em Backyard Baseball 2026
• Como reimaginar um jogo de esportes clássico para uma nova geração com design de nível, construção de mundo e VFX

Esperamos que você aproveite ótimas dicas!

Você tem uma ideia incrível, e o código flui tão rápido quanto você consegue digitá-lo. A cada commit, um novo recurso ganha forma. Mas é justamente a velocidade com que suas ideias se formam que pode resultar, em breve, em você olhando para uma grande bagunça cheia de bugs.

Na Mega Cat Studios, começamos todos os nossos projetos com paixão, por isso entendemos o fascínio de trabalhar de forma rápida e descompromissada, e de terminar as coisas o mais rápido possível. Para um protótipo, essa abordagem é aceitável e, na verdade, nós a recomendamos! Um desenvolvedor experiente sabe quando priorizar a velocidade de iteração e quando priorizar a estabilidade. Porque, quando você sai da fase de protótipo, essa abordagem “rápida e descompromissada” se torna um passivo.

Nós sobrevivemos a essa transição muitas vezes na Mega Cat Studios e, a cada projeto, aprendemos algo novo. Gostaríamos de compartilhar algumas das lições que aprendemos para preparar nosso projeto mais recente, Backyard Baseball, para o lançamento.

Lição 1: Estrutura para escala

Problemas de escala raramente são causados por código ruim; em vez disso, eles surgem mais frequentemente devido a uma arquitetura não planejada. Se um desenvolvedor ou artista não consegue encontrar um ativo em 10 segundos, o fluxo de trabalho precisa mudar. Algumas dicas para configurar seu projeto para escalar incluem:

• Organize por Tipo e Propósito: Agrupamos por Tipo, depois por Propósito. Tipo inclui categorias como arte, código e áudio. Propósito é para o que eles são usados. A organização intuitiva reduz o atrito de integração; um novo artista deve saber exatamente onde um sprite de "Character Idle" pertence sem precisar perguntar.
• Mantenha as cenas simples: Descartamos a "Mega-Cena" e, em vez disso, optamos por cenas menores, como uma cena principal que contém dados de salvamento e sistemas críticos, juntamente com uma tela de título e cenas de campo de beisebol que carregam aditivamente dependendo se o jogador está em uma partida. Da mesma forma, usamos prefabs para recursos autônomos, para que as alterações tenham menos probabilidade de serem serializadas no arquivo de cena que as contém. Isso permite que um artista trabalhe no ambiente enquanto um designer ajusta a jogabilidade no mesmo "nível" sem conflitos de arquivo (mais sobre isso depois).
• Configure o sistema Addressables: Em vez de pastas Resources tradicionais, usamos o sistema Addressables para carregar ativos apenas quando necessário, mantendo o uso de memória reduzido. Além disso, carregar um ativo com sua chave Addressable é mais claro e menos propenso a falhas do que carregar via caminho de arquivo para um local específico na pasta Resources.

A parte difícil não é entender essas melhores práticas. É comprometer-se com elas desde o início e manter essa disciplina mesmo anos depois.

Saiba em qual fase de desenvolvimento você está e o que está priorizando nesse estágio.

“Na fase de prototipagem, como quase não há código, tudo bem torná-lo funcional primeiro antes de torná-lo modular”, diz Paolo Roxas, desenvolvedor de Backyard Baseball. “Queremos ver como o projeto se desenrola antes de torná-lo mais complexo.”

Lição 2: Trabalhe com a Unity, não contra ela

"Não há nada mais poderoso do que criar blocos de construção – sejam Componentes, ScriptableObjects ou classes personalizadas – que sejam focados, concisos e autônomos", diz David Chávez Armenteros, Chefe de Engenharia na Mega Cat Studios. A Unity adota a modularidade em seu núcleo. Para permanecer flexível, seguimos três princípios clássicos:

1. Responsabilidade única: Cada script ou classe deve ter uma função bem definida.

2. Acoplamento fraco: Os sistemas devem interagir por meio de interfaces ou eventos em vez de referências diretas, e apenas quando apropriado. Recomendamos mapear as dependências entre os sistemas antes de implementá-los no código para evitar uma arquitetura cíclica ou emaranhada.

3. Plug and play: Combine unidades pequenas e focadas para criar comportamentos complexos em vez de escrever scripts "deus" extensos.

Lição 3: Use limitações para se libertar

Definições de Assembly (AsmDefs) são construções C# que agrupam seu código. A vantagem anunciada deles é a redução do tempo de compilação, mas seu superpoder secreto é a imposição da modularidade.

Nico Gaudenzi, desenvolvedor líder e odiador de código espaguete, confia neles cegamente.

"Em Backyard Baseball, a camada de Input System e a camada de Gameplay estão em DLLs diferentes. A jogabilidade é completamente agnóstica aos detalhes de entrada."

Isso salva os engenheiros deles mesmos, tornando cada dependência uma decisão calculada. Se realmente precisássemos, poderíamos reescrever todo o Input System – desde o manuseio do controle até o Netcode – sem arriscar quebrar a física do jogador ou o comportamento da IA. Mais provavelmente, isso permite que um engenheiro trabalhe em um único domínio da base de código sem acidentalmente propagar mudanças para outro sistema, e reduz a quantidade de código que um desenvolvedor precisa manter organizada para implementações de recursos e correções de bugs.

Lição 4: Teste de forma mais inteligente, não mais difícil

À medida que os projetos crescem, o "efeito dominó" pode assumir o controle: Uma pequena mudança aqui quebra algo ali. Uma boa arquitetura ajuda muito, mas não é uma solução mágica.

Antes que as mudanças de recursos cheguem às patas de nossos estimados gatos de Garantia de Qualidade para testes manuais, o jogo é rigorosamente analisado em uma série de testes unitários automatizados.

"Os testes funcionam como uma lista de requisitos", diz Nico. "Eles descrevem o que é esperado e fornecem casos de uso principais."

Quando um personagem em Backyard Baseball lança uma bola rápida, rouba uma base ou rebate um home run, há resultados de jogabilidade específicos que queremos alcançar, como garantir que a bola viaje a uma velocidade que pareça autêntica para o arremesso, que o tempo do corredor se alinhe com as mecânicas de roubo de base ou que os defensores reajam corretamente a uma rebatida. O personagem precisa colidir corretamente com o chão, a bola precisa se mover na velocidade certa e sistemas mais granulares, como sinalizadores de controle do jogador que rastreiam ações como preparar o arremesso, rebater ou correr entre as bases, precisam funcionar.

Quando fazemos um ajuste na força de Pablo Sanchez, ou, ainda mais criticamente, ajustamos o código compartilhado que rege as rebatidas, precisamos garantir que cada interação, desde o tempo de contato até a trajetória da bola, se comporte de forma consistente em todo o jogo.

Muitas vezes, o que quebra é algo que você não esperaria, que é a razão pela qual os testes são tão importantes.

Com este sistema integrado ao nosso fluxo de trabalho, ficamos sabendo no momento em que um requisito específico quebra, o que reduz as sessões de teste e solução de problemas que são tão demoradas quanto encontrar uma agulha no palheiro.

O Test Runner do Unity funciona de forma mais eficaz quando seus sistemas são modulares, o que é outro motivo pelo qual usamos Assembly Definitions.

Lição 5: Prepare seus ativos

"Errar é humano; perdoar, é divino."

Mas configurar sistemas para evitar o erro humano em primeiro lugar é algo lendário.

Após horas de codificação e depuração, é inevitável que algum desenvolvedor com olhos cansados faça alguns cliques errados ou envie acidentalmente para o repositório alterações que deveriam ser apenas temporárias. Embora perdoável (digo eu, como um dos ocasionalmente cansados), um ativo com configurações de importação mal configuradas pode ter consequências enormes. E como muitos desenvolvedores trabalham em máquinas potentes, o cenário de pesadelo é que o problema de desempenho passe despercebido até mais tarde, como quando uma cena de estádio com personagens, animações e efeitos começa a causar lentidão ou instabilidade em hardware de nível inferior.

Para mitigar esse risco, você poderia limitar quem tem acesso aos ativos, mas isso leva a um gargalo devido aos muitos motivos pelos quais o conteúdo do jogo precisa ser ajustado:

• O modelo é grande demais para caber na configuração da câmera.
• Este clipe de áudio tem menos volume, então ele precisa de um efeito específico.
• Cada textura precisa de ajuste agora que o shader mudou.

Em um jogo como Backyard Baseball, onde a identidade visual é fundamental, modelos e VFX recebem centenas de ajustes à medida que deixamos o visual e a sensação perfeitos antes do lançamento.

“Nenhuma quantidade de especificações técnicas pode evitar o fato de que ter variedade de conteúdo significa lidar com diferenças pequenas, mas significativas, entre diferentes ativos”, diz Nico.

A automação ajuda aqui também:

• AssetPostprocessor: Escrevemos uma lógica de importação personalizada que impõe padrões de projeto.
• OnValidate: Usamos o método OnValidate para relatar referências ausentes no Editor, que sempre é disparado antes da compilação.

Finalmente, no entanto, não deixe que toda essa conversa sobre automação o distraia de correções manuais simples quando elas forem mais rápidas.

“Nunca gaste 10 dias automatizando uma tarefa que leva 10 minutos para ser feita manualmente”, alerta David.

Lição 6: Domine o elemento humano (colaboração)

Version Control sistemas como o Git estão entre as primeiras coisas que vêm à mente ao coordenar centenas de alterações de dezenas de desenvolvedores todos os dias. David defende estas metodologias true e comprovadas para todos os nossos projetos na Mega Cat:

• Alterações pequenas e atômicas: Evite “mega commits” que afetam muitos sistemas de uma só vez. Isole o trabalho em branches de recursos individuais até que estejam estáveis e revisados. Mantenha alterações individuais em commits individuais para um histórico de Version Control bem documentado, o que também facilita o cherry picking e outras mágicas do Git quando necessário.
• Mesclagens diárias da main: Mantenha branches de recursos, de departamento e de longa duração atualizados com a branch principal, pois isso pode reduzir o tamanho e a complexidade das mesclagens finais, ajudando a evitar conflitos em larga escala.
• Revisar solicitações de mesclagem: Esta é a primeira linha de garantia de qualidade, onde você detecta bugs, impõe padrões de projeto e garante a coesão com o sistema geral.

“Em grandes projetos Unity, as revisões de código não são apenas uma formalidade”, aconselha David. “Elas são uma parte fundamental da prevenção de conflitos e da qualidade geral do projeto.”

Apenas certifique-se de que aqueles que revisam o código tenham experiência na área que está sendo implementada e estejam cientes das melhores práticas de codificação, para que possam avaliar com precisão a correção e a manutenibilidade.

Existem dicas e truques específicos para tornar o Version Control o mais tranquilo possível no Unity. Cenas e prefabs formam a base do seu projeto, portanto, otimize-os não apenas para o desempenho da CPU, mas também para a colaboração entre desenvolvedores.

Sempre preferimos componentes menores, aditivos e aninhados a uma cena grande ou prefab monolítico. Dessa forma, os desenvolvedores podem trabalhar em paralelo sem conflitos.

Isso é importante, já que conflitos de mesclagem em cenas e prefabs são os mais difíceis de resolver, pois seus dados não são facilmente legíveis pelos desenvolvedores. Para suavizar esse processo, serializamos esses arquivos como texto, não binário, e habilitamos o recurso de mesclagem automática da nossa configuração do Git para arquivos YAML. Isso torna mais provável que o Git resolva os conflitos de mesclagem por conta própria e economiza o tempo dos desenvolvedores para o trabalho importante de criar novos recursos.

Mas, apesar de tudo isso:

“Prevenir os conflitos geralmente é uma estratégia melhor do que tentar resolvê-los”, diz Nico.

Uma propriedade clara dos ativos pode ajudar muito nisso.

“Defina quem pode modificar cenas ou prefabs específicos”, diz David. “Então, os membros da equipe solicitam alterações fora de sua propriedade em vez de editar os ativos diretamente.”

Nico descreve um procedimento semelhante como um “sistema de semáforo”. Isso é basicamente uma planilha onde os desenvolvedores registram quando estão alterando um ativo, efetivamente “bloqueando-o”. Se outro desenvolvedor precisar fazer alterações nesse arquivo, ele precisará esperar até que o desenvolvedor que bloqueou o arquivo envie sua alteração para o repositório e o “desbloqueie”.

Como sempre, descubra qual procedimento funciona melhor para sua equipe.

Construindo para o Futuro

Na Mega Cat Studios, aprendemos que escalar um projeto Unity é menos sobre “programar mais” e mais sobre disciplina arquitetônica. Ao respeitar a natureza baseada em componentes do Unity, impor limites com Assembly Definitions e organizar ativos pensando no futuro, mantemos grande parte do fluxo criativo da fase de protótipo sem colapsar o projeto em dívida técnica antes do lançamento.

Embora essas lições sejam importantes, lembre-se de que nenhuma base de código é perfeita. O desenvolvimento de software é uma batalha épica onde padrões de programação recomendados e considerações práticas se chocam diariamente. Se seguir um desses princípios atrasar o desenvolvimento sem gerar uma compensação benéfica, é um sinal de que você precisa ser mais sensível às especificidades da sua própria equipe e não às recomendações de livros didáticos. Afinal, cada projeto, equipe e pessoa é diferente.

Tentamos encontrar esse equilíbrio todos os dias no Mega Cat Studios. A cada novo projeto, à medida que nossa biblioteca de jogos continua a crescer, esperamos nos tornar melhores desenvolvedores Unity e melhores colaboradores.