Dimensionando 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 cobrem entrada, design de níveis e de ambiente:

• Batendo um bolão: Como o Input System orientado a eventos da 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íveis, construção de mundo e efeitos visuais
• Renderização em escala: Estratégias eficientes para contagens massivas de objetos

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 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.

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 escalabilidade 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: Nós 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. Uma 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: Nós 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, não tem problema fazer funcionar primeiro antes de tornar modular", diz Paolo Roxas, um desenvolvedor de Backyard Baseball. “Queremos ver como o projeto se desenrola antes de torná-lo mais complexo.”

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

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

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

2. Baixo acoplamento: 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 confusa.

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

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

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

"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 gamepad 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 faz 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, balançar o bastão ou correr entre as bases, precisam funcionar.

Quando fazemos um ajuste no poder de Pablo Sanchez, ou, 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.

Frequentemente, 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 cientes 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 é outra razão pela 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 cometa alguns cliques errados ou envie acidentalmente alterações para o repositório 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 é premium, modelos e VFX recebem centenas de ajustes à medida que acertamos o visual e a sensação 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 os padrões do 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 simples e manuais 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)

Sistemas de Version Control 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 testadas e true para todos os nossos projetos na Mega Cat:

• Pequenas alterações 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 grande 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, então otimize-os não apenas para o desempenho da CPU, mas também para a colaboração dos desenvolvedores.

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

Isso é importante, já que conflitos de merge em cenas e prefabs são os mais difíceis de resolver, porque 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 auto-merge da nossa configuração do Git para arquivos YAML. Isso torna mais provável que o Git resolva os conflitos de merge por conta própria e protege o tempo do desenvolvedor 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 de 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 precisa 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 “codificar mais” e mais sobre disciplina arquitetural. Ao respeitar a natureza baseada em componentes do Unity, reforçar limites com Assembly Definitions e organizar ativos pensando na preparação para o 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 colidem diariamente. Se seguir um desses princípios travar 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. Com cada novo projeto, à medida que nossa biblioteca de jogos continua a crescer, esperamos nos tornar melhores desenvolvedores Unity e melhores colaboradores.