Como a Ares Interactive executa operações ao vivo sem esperar por atualizações do cliente

Executar um jogo ao vivo significa construir para mudança constante. As equipes precisam manter os jogadores engajados com novos eventos, atualizações de equilíbrio, ofertas e conteúdo, enquanto mantêm o desempenho e a estabilidade intactos.

Ares Interactive executa dois jogos ao vivo muito diferentes: Rebatidas de Beisebol 26, desenvolvido pela sua equipe do 7º Inning, e The Walking Dead: Aftermath, desenvolvido pelo seu estúdio Swift Games. Rebatidas de Beisebol 26 acompanha de perto o calendário real do beisebol. Os Mortos Caminhando: Aftermath constrói seu serviço ao vivo em torno de uma fundação roguelite que pode se expandir sem interromper o loop principal.

Conversamos com Andre Taube, chefe de estúdio na 7th Inning, e Carsten Granig, diretor administrativo da Swift Games Germany. Eles nos contaram como estruturam sistemas de serviço ao vivo, gerenciam conteúdo e configuração remotos, encurtam os ciclos de iteração e mantêm os lançamentos móveis estáveis enquanto os jogos continuam a evoluir.

Construindo operações ao vivo em torno de dados em vez de lançamentos de clientes

Baseball Hits 26 foi construído para dar aos fãs e jogadores de beisebol uma experiência de beisebol essencial que é fácil de começar a qualquer hora, em qualquer lugar, em curtos períodos ou em jogadas estratégicas mais longas. Essa acessibilidade está ao lado de decisões de beisebol do mundo real, progressão, eventos ao vivo, clubes sociais e recursos de comunicação. Manter esses sistemas atualizados significa tratar o jogo como algo que está sempre mudando, em vez de algo que simplesmente foi lançado.

Por exemplo, se um jogador licenciado pela MLBPA tiver um desempenho particularmente bom em um jogo ou série, o time pode apresentar esse jogador em eventos ao vivo na semana seguinte.

"Esse nível de relevância é possível graças às nossas atualizações de servidor ágeis e orientadas por dados e à capacidade da nossa equipe de operações ao vivo de encaixar rapidamente os confrontos certos", diz Taube.

A equipe construiu seu próprio backend e pipeline de operações ao vivo para poder alterar eventos, armazenar vendas, ofertas, recompensas e ajuste de matchmaking sem esperar por um lançamento do cliente ou Deployment do servidor.

Na base, há um sistema personalizado de entrega de conteúdo e configuração remota com mais de 50 domínios de configuração cobrindo jogadores, eventos, itens da loja, caixas de recompensa, passes de batalha e outros sistemas. A equipe gerencia as mudanças através de um painel de administração. O sistema valida as alterações antes de aceitá-las, e os servidores as captam em segundos sem reinicialização.

Tudo é versionado e registrado. A equipe pode revisar ou reverter para qualquer estado anterior e pode preparar alterações contra contas de teste internas antes de promovê-las para produção.

O agendamento de eventos se apoia nessa mesma fundação. Eventos, torneios e vendas por tempo limitado têm Windows de início e fim definidas. Um motor de segmentação gerencia o direcionamento e potencializa os testes A/B, para que a equipe possa testar novas ofertas ou formatos de eventos com uma fração do público antes de um lançamento mais amplo.

Na prática, isso permite que a equipe realize até quatro eventos em uma única semana, como eventos Prime Club e Tower Club, cada um com seus próprios jogadores bônus e ofertas em destaque vinculadas a ele.

"Possuir toda a pilha compensa mais quando algo dá errado no meio de um evento", diz Taube. "A equipe pode diagnosticar o problema, corrigir a configuração, compensar os jogadores afetados e enviar a atualização [config] aos clientes, tudo em minutos e tudo de um só lugar."

Mantendo a entrega de conteúdo e os lançamentos móveis previsíveis

A equipe usa Addressables especificamente para pacotes de estádio. Um estádio padrão vem pré-instalado no aplicativo, então os jogadores de primeira viagem não precisam de um download extra. A equipe empacota cada outro estádio como um pacote, enviado para o servidor da equipe e baixado sob demanda quando um jogador o seleciona.

A equipe realiza testes de estresse em cada pacote de estádio em seus dispositivos de menor desempenho para garantir que permaneça dentro de orçamentos rigorosos de tamanho e memória. Um pacote comum compartilhado armazena recursos reutilizados em todos os estádios, de modo que os mesmos dados não são duplicados em cada download.

A mesma ênfase na previsibilidade se aplica aos lançamentos do iOS e Android. A equipe mantém o código específico da plataforma no mínimo absoluto, e ambas as plataformas compartilham prazos de marcos e submissão. A equipe cria e testa builds do Android e iOS diariamente.

Como a maior parte do conteúdo é orientada por dados, o calendário ao vivo não precisa estar rigidamente acoplado ao cronograma de análise da loja de aplicativos.

O cliente também é projetado com a premissa de que cada chamada de servidor pode falhar.

"Para jogos ao vivo especificamente, trate cada chamada de servidor como não confiável por padrão", diz Taube. "Estruture o cliente de modo que um servidor lento, que cai ou que não responde nunca quebre a experiência do jogador."

Esse princípio se aplica ao suporte de dispositivos. A equipe usa o Simulador de Dispositivo para verificar a cobertura da interface do usuário em toda a gama de tamanhos e resoluções de tela que ele suporta. O Unity Profiler é usado extensivamente para encontrar soluços de desempenho durante o jogo. A equipe também testa regressões de desempenho em uma ampla gama de dispositivos físicos Android e iOS, tanto com quanto sem Wi-Fi.

Para a Taube, as equipes móveis devem definir sua estratégia de dispositivos cedo.

"Invista cedo em um plano arquitetural sólido para suporte a dispositivos, especialmente no Android, onde a fragmentação entre hardware e versões do OS é o risco real."

Construindo The Walking Dead: Consequências para que os sistemas vivos possam evoluir independentemente

Rebatidas de Beisebol 26 é construído para refletir um calendário esportivo do mundo real. Os Mortos Caminhantes: Aftermath tem um desafio de serviço ao vivo diferente: adicionar novas formas de jogar sem perturbar sua experiência roguelite subjacente.

O RPG de ação roguelite coloca os jogadores no mundo de The Walking Dead. Eles constroem equipes de Sobreviventes, incluindo Rick Grimes, Daryl Dixon e Michonne, e lutam contra hordas de Andarilhos e outros inimigos em combate em tempo real. Entre as rodadas, os jogadores desbloqueiam Sobreviventes e Equipamentos, os aprimoram, desbloqueiam habilidades e constroem sua base.

"Em sua essência, queríamos criar algo que capture o perigo constante e as escolhas difíceis de The Walking Dead enquanto oferece a rejogabilidade e progressão que você espera de um roguelite," diz Granig.

O serviço ao vivo se baseia nesse fundamento com desafios e restrições, além de sistemas sociais como Alianças, eventos cooperativos e Leaderboards.

Do ponto de vista do desenvolvimento, construímos o jogo para que esses sistemas possam evoluir de forma independente. Isso nos dá a flexibilidade para continuar expandindo a experiência ao vivo sem interromper o loop roguelite principal.

Tornando o décimo recurso ao vivo tão barato de enviar quanto o primeiro

A Swift Games não reconstruiu sua fundação de serviço ao vivo do zero. Começou com seu título anterior, Heroes vs Hordes. Sistemas de armazenamento, Economy, Authentication, Analytics, configuração remota e salvamento em nuvem pareceram tecnologia comprovada, enquanto o núcleo roguelite novo foi prototipado separadamente e depois integrado a essa base.

Qualquer coisa esperada para mudar semanalmente foi projetada para mudar sem um lançamento de cliente. Os designers criam conteúdo e balanceiam em planilhas e os publicam como pacotes remotos, com cada pacote carimbado com as versões do cliente que suporta.

Os dados salvos são versionados com uma cadeia de migração, para que uma atualização ao vivo nunca deixe um jogador de longa data órfão. O tempo vem do servidor em vez do dispositivo, porque eventos e ofertas cronometradas dependem dele.

O compromisso é que os recursos ao vivo precisam ser projetados não apenas para ligar, mas para desligar com segurança.

"É isso que mantém o décimo recurso ao vivo tão barato de enviar quanto o primeiro", diz Granig.

O jogo usa primariamente GameObjects e NVIDIA PhysX. Entities e Burst são reservados para o sistema de busca de caminho A* que move inimigos.

Mais importante para o desenvolvimento de vida é a injeção de dependência com escopo. O jogo tem quatro contextos aninhados: raiz, salvar jogo, tela principal e jogabilidade. Cada contexto é responsável pelo que cria e por limpá-lo.

Isso significa que um evento ao vivo pode ser estruturado como um instalador mais um arquivo de configuração conectado a um contexto. Quando aquele contexto fechar, seus ativos e assinaturas vão com ele.

A equipe também separa a interface do usuário da lógica. Uma loja ou oferta pode existir como uma classe C# simples que pode ser testada sem iniciar o Motor, enquanto os designers trabalham diretamente com ativos de configuração.

Traçar uma linha clara entre dados ao vivo e ativos do jogo

Em The Walking Dead: Aftermath, Addressables gerenciam o gerenciamento de memória e o carregamento em vez da entrega de conteúdo remoto. Vinte e nove grupos correspondem a recursos individuais e eles carregam e descarregam de maneira muito semelhante aos contextos do jogo.

O conteúdo ao vivo segue um pipeline separado construído diretamente na API AssetBundles em vez de Addressables. Os pacotes são construídos por plataforma, enviados e buscados pelo jogo em tempo de execução. Cada um inclui um hash, um checksum e a versão mais antiga de cliente compatível.

A regra da equipe é simples: "Se os designers querem mudar isso toda semana, deve estar em um pacote." Se for arte ou código, pertence à construção.

Dentro desse limite, a equipe ainda pode mover eventos, reequilibrar recompensas, ajustar ofertas, ativar ou desativar recursos ou comportamento de compra e executar testes A/B sem voltar às lojas. Nova arte e novo código exigem uma compilação.

"Nós definimos esse limite intencionalmente para que a superfície viva permaneça pequena o suficiente para que, quando algo quebrar, possamos identificar o que mudou", diz Granig.

A variedade visual segue uma abordagem igualmente controlada. Arenas são construídas à mão em vez de serem geradas proceduralmente. Em vez de duplicar ambientes, a equipe muda a aparência através de materiais, iluminação e shaders na geometria existente. Cerca de 35 gráficos de shader e 10 shaders escritos à mão compõem esse sistema.

"Como as arenas são construídas à mão, podemos contabilizar tudo o que um jogador pode ver e medir tudo isso, em vez de amostrar e torcer."

Encurtando o caminho da planilha ao jogo ao vivo

Grande parte da velocidade das operações ao vivo da equipe vem das ferramentas.

Os designers editam a configuração sozinhos. Importadores internos puxam capítulos, texto e tabelas de recompensa diretamente de planilhas, e a planilha permanece como a fonte da verdade.

O resultado: Se a equipe identificar um problema de operações ao vivo ou de balanceamento, pode aplicar uma correção em cerca de 15 minutos, em vez de passar por um processo de lançamento completo.

O pipeline de construção também é projetado para encurtar o tempo de iteração. O perfilamento profundo é um switch de compilação em vez de um branch dedicado, então os desenvolvedores podem solicitar uma compilação de perfilamento do que quer que estejam trabalhando quando suspeitam de uma regressão. Trabalhar com cache e tempos de compilação também ajuda a equipe a lidar com o grande número de compilações que produz todos os dias.

Como as mudanças na interface do usuário são lançadas semanalmente, a equipe depende do Simulador de Dispositivos para verificações de entalhe e área segura em diferentes formatos de tela. Não substitui os testes de dispositivo físico, mas detecta problemas de layout mais cedo.

O problema operacional mais difícil veio da separação dos ambientes de desenvolvimento e de produção. A configuração do Firebase está embutida nos arquivos de build, e as chaves do Firebase, Play Services, configuração do Facebook, IDs de pacote, nomes e ícones devem corresponder.

A equipe eventualmente moveu a responsabilidade por esses ambientes para a integração contínua (CI). Desenvolvimento e builds ao vivo usam IDs de pacote, nomes e ícones diferentes, para que possam coexistir no mesmo dispositivo. Se uma compilação de desenvolvimento se conectar ao servidor ao vivo, um aviso no jogo aparece. Os uploads falham quando a configuração está ausente, em vez de mirar silenciosamente no ambiente errado.

"Nós transferimos a responsabilidade para o CI em vez de deixá-la para as pessoas", diz Granig.

Comece pequeno, teste cedo

Ambas as equipes chegam à mesma lição de direções diferentes: O desenvolvimento de vida sustentável depende de decidir cedo o que precisa mudar, isolá-lo do que deve permanecer estável e construir sistemas que assumam que algo acabará dando errado.

Para Baseball Hits 26, isso significa um backend orientado a dados que pode reagir rapidamente à temporada real de beisebol, mantendo as liberações de clientes, dispositivos e falhas de servidor sem interromper o jogo.

Para The Walking Dead: Consequências, isso significa sistemas vivos modulares, configuração rigidamente controlada e um limite deliberado: O conteúdo pode mudar remotamente, enquanto o código e a arte são enviados na compilação.

O conselho de Granig para equipes que estão se aproximando de seu primeiro jogo móvel ao vivo é provar a experiência central antes de construir a maquinaria de serviço ao vivo em torno dela.

"Monte de um a três dias de conteúdo e lance antes de trabalhar em qualquer outra coisa." Então veja quantos jogadores voltam no dia seguinte. Se eles não voltarem, nenhum conteúdo de final de jogo vai salvar isso," ele explica.

Então faça de novo. Adicione conteúdo, olhe para o dia três e repita. Comece pequeno, teste cedo e deixe os números dizerem se o jogo está funcionando. A parte difícil é dizer não a tudo o que você quer construir até que o loop principal se prove.

Rebatidas de Beisebol 26 e The Walking Dead: Aftermath estão disponíveis agora na App Store e Google Play. Confira mais histórias de desenvolvedores da Unity no Blog da Unity e no Resource Hub.