Escalando fluxos de trabalho do Unity: Lições de projetos médios a grandes

Este post no blog é o primeiro de uma série do Mega Cat Studios, onde eles compartilham sua experiência e soluções em Unity para desafios reais de desenvolvimento de jogos comerciais. Esperamos que você aproveite algumas dicas ótimas!

Você tem uma ideia incrível, e o código voa tão rápido quanto você consegue digitá-lo. A cada commit, uma nova funcionalidade ganha forma. Mas é a velocidade com que suas ideias se formam que pode resultar em um grande e problemático emaranhado em breve.

No Mega Cat Studios, começamos todos os nossos projetos com paixão, então entendemos a atração de trabalhar rápido e solto, e de fazer as coisas o mais rápido possível. Para um protótipo, essa abordagem é boa, e na verdade, nós a recomendamos! Um desenvolvedor sábio 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ápido e solto" se torna uma responsabilidade.

Sobrevivemos a essa transição muitas vezes no 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 escalar

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:

• Organizar por Tipo e Propósito: Agrupamos por Tipo, depois por Propósito. O tipo inclui categorias como arte, código e áudio. O propósito é para o que eles são usados. Uma organização intuitiva reduz a fricção na integração; um novo artista deve saber exatamente onde um sprite "Character Idle" pertence sem perguntar.
• Mantenha as cenas simples: Descartamos a "Mega-Cena" e optamos por cenas menores, como uma cena principal que contém dados de salvamento e sistemas críticos, junto com uma tela de título e cenas de campo de beisebol que são carregadas aditivamente dependendo se o jogador está em uma partida. Da mesma forma, usamos prefabs para recursos autossuficientes, assim as mudanças têm 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 mais tarde).
• Configure o sistema Addressables: Em vez de pastas de Recursos tradicionais, usamos o sistema Addressables para carregar ativos apenas quando necessário, mantendo o uso de memória enxuto. Além disso, carregar um ativo com sua chave Addressable é mais claro e menos propenso a falhas do que carregar via um caminho de arquivo para um local específico na pasta de Recursos.

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 do desenvolvimento você está e o que está priorizando nesse estágio.

“Na fase de prototipagem, como há quase nenhum código, é aceitável torná-lo funcional primeiro antes de torná-lo 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 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 autossuficientes," diz David Chávez Armenteros, Chefe de Engenharia da Mega Cat Studios. Unity abraça a modularidade em seu núcleo. Para manter a flexibilidade, seguimos três princípios clássicos:

1. Responsabilidade única: Cada script ou classe deve ter um papel bem definido.

2. Acoplamento solto: 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 arquiteturas cíclicas ou emaranhadas.

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

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

Definições de Montagem (AsmDefs) são construções em C# que agrupam seu código. Sua vantagem anunciada é a redução dos tempos de compilação, mas seu superpoder secreto é impor a modularidade.

Nico Gaudenzi, desenvolvedor principal e odiador de código espaguete, jura por elas.

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

Isso salva os engenheiros de si mesmos, tornando cada dependência uma decisão calculada. Se realmente precisássemos, poderíamos reescrever todo o sistema de entrada – desde o manuseio de gamepads até o netcode – sem arriscar quebrar a física dos jogadores 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 causar mudanças em outro sistema, e reduz a quantidade de código que um desenvolvedor precisa manter em ordem 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: Uma pequena mudança aqui quebra algo ali. Uma boa arquitetura vai longe, 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 chave."

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

Quando fazemos um ajuste no poder de Pablo Sanchez, ou ainda mais criticamente, ajustamos o código compartilhado que governa os swings de bastão, precisamos garantir que cada interação, desde o tempo de contato até a trajetória da bola, se comporte de maneira consistente em todo o jogo.

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

Com este sistema integrado ao nosso fluxo de trabalho, nos tornamos 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 em um palheiro.

O Test Runner da Unity funciona de forma mais eficaz quando seus sistemas são modulares, que é mais uma razão pela qual usamos Definições de Assembly.

Lição 5: Coloque seus ativos em ordem

"Errar é humano; perdoar é divino."

Mas estabelecer sistemas para prevenir erros humanos desde o início é verdadeiramente lendário.

Após horas de codificação e depuração, é inevitável que algum desenvolvedor com os olhos cansados cometa alguns cliques errados ou acidentalmente envie alterações para o repositório que eram apenas temporárias. Embora seja perdoável (digo isso como um dos que às vezes têm os olhos cansados), um ativo com configurações de importação mal configuradas pode ter enormes consequências. E como muitos desenvolvedores trabalham em máquinas poderosas, 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 baixo desempenho.

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 se encaixar na configuração da câmera.
• Este clipe de áudio tem menos volume, então precisa de um efeito específico.
• Cada textura precisa de ajustes agora que o shader mudou.

Em um jogo como Backyard Baseball, onde a identidade visual é primordial, modelos e VFX recebem centenas de ajustes enquanto acertamos a aparência 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 sutis, mas significativas, entre diferentes ativos,” diz Nico.

A automação ajuda aqui também:

• AssetPostprocessor: Escrevemos 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 é acionado antes da construção.

Finalmente, no entanto, não deixe toda essa conversa sobre automação distraí-lo de correções manuais simples quando elas são mais rápidas.

"Nunca passe 10 dias automatizando uma tarefa que leva 10 minutos para fazer manualmente,” alerta David.

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

Sistemas de Controle de Versão como Git estão entre as primeiras coisas que vêm à mente ao coordenar centenas de mudanças de dezenas de desenvolvedores todos os dias. David defende essas metodologias testadas e comprovadas para todos os nossos projetos na Mega Cat:

• Pequenas mudanças atômicas: Evite "mega commits" que tocam em muitos sistemas ao mesmo tempo. Isolar o trabalho em branches de recursos individuais até que estejam estáveis e revisados. Mantenha mudanças individuais em commits individuais para um histórico de versão bem documentado que também facilita o cherry picking e outras magias do git quando necessário.
• Mesclagens diárias do principal: Mantenha branches de recursos, departamentos e de longa duração atualizados com a branch principal, pois isso pode reduzir o tamanho e a complexidade das mesclagens finais, ajudando a prevenir conflitos em larga escala.
• Revisar solicitações de mesclagem: Esta é a primeira linha de garantia de qualidade, onde você encontra bugs, impõe padrões de projeto e garante coesão com o sistema geral.

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

Apenas certifique-se de que aqueles que revisam o código tenham expertise na área 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 controle de versão o mais suave possível no Unity. Cenas e prefabs constituem a base do seu projeto, então otimize-os não apenas para desempenho da CPU, mas também para colaboração entre desenvolvedores.

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

Isso é importante, pois conflitos de mesclagem 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 ativamos o recurso de mesclagem automática da nossa configuração do Git para arquivos YAML. Isso torna o Git mais propenso a resolver conflitos de mesclagem por conta própria e protege 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 clara propriedade de ativos pode ajudar muito nisso.

“Defina quem pode modificar cenas ou prefabs específicos”, diz David. “Então, os membros da equipe solicitam mudanças 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 mudando 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 “desbloqueie-o.”

Como sempre, encontre 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 Definições de Assemblies e organizar ativos com a proteção do futuro em mente, mantemos grande parte do fluxo criativo da fase de protótipo sem colapsar o projeto em dívidas técnicas 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 atrasar o desenvolvimento sem gerar um trade-off benéfico, é um sinal de que você precisa ser mais sensível às especificidades de 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 na 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.