Como Hologryph construiu SAND: Raiders of Sophie para uma cadência sustentável de operações ao vivo

Para Hologryph, em desenvolvimento AREIA: Os Caçadores de Sophie Significava transformar um deserto desértico de história alternativa de 1910 em um jogo de extração que pudesse continuar crescendo muito tempo depois do lançamento. Os jogadores comandam e pilotam Tramplers – máquinas gigantescas que funcionam como base, depósito de tesouros e armas, tudo ao mesmo tempo – e as utilizam para atravessar um mundo aberto gerado proceduralmente em busca de recursos e uns dos outros.

Para proporcionar essa experiência, foi necessário um sistema rígido de separação entre servidor e cliente, geração procedural do mundo que funciona de forma idêntica em ambos os lados, sincronização das centenas de entidades que compõem um único Trampler e streaming do mundo suficientemente fluido para transmitir a sensação de estar pilotando um. A equipe também precisava de um fluxo de conteúdo rápido o suficiente para lançar novos compartimentos, armas, efeitos e ambientes sazonais em uma cadência regular, sem comprometer o desempenho.

Conversamos com Serhiy Grinets, CTO e diretor de jogos da Hologryph, sobre a arquitetura do jogo a longo prazo, a manutenção do fluxo de conteúdo e o que é necessário para operar um jogo tão ambicioso tecnicamente.

Como é o seu modelo de operações em tempo real e o que está incluído em uma atualização típica?

Serhiy Grinets: Nosso modelo de operações ao vivo para SAND tem como foco manter o jogo em constante evolução, em conjunto com nossa apaixonada comunidade. Nossa prioridade é manter um ritmo regular de atualizações que combinem novos conteúdos, melhorias na jogabilidade, balanceamento, correções de bugs e alterações na qualidade de vida do jogador. Nosso objetivo final é construir um modelo de operações ao vivo sustentável que dê suporte ao título a longo prazo.

Quais eram seus principais objetivos técnicos iniciais e como eles moldaram sua abordagem para criar um jogo projetado para existir e evoluir a longo prazo?

Tínhamos três grandes objetivos:

• Uma separação estrita entre um servidor autoritativo e um cliente, com geração procedural do mundo que funciona de forma idêntica em ambos os lados.
• Sincronizar um número enorme de entidades – um único Trampler é composto por centenas delas.
• Transmissão suave pelo mundo todo – o mundo é realmente grande, e para vender a sensação de andar em um Trampler, você precisa de um lugar para andar.

Os pisoteadores são essenciais para a identidade do jogo. Como você construiu o sistema de personalização para poder lançar novas peças, itens cosméticos e variantes como conteúdo contínuo para operações ao vivo?

Todo o sistema é construído em torno de compartimentos. Um compartimento é uma seção de um Trampler – um convés, uma cabine, uma estrutura de suporte, uma sala de equipamentos – e cada compartimento é projetado para se encaixar com os outros.

Os jogadores montam seu Trampler a partir destes blocos: Eles escolhem o layout, organizam as cartas, posicionam os equipamentos e acabam com uma máquina que é verdadeiramente deles – sua base, seu cofre e sua arma, tudo ao mesmo tempo.

Para nós, desenvolvedores, isso também faz parte do fluxo de conteúdo. Para adicionar um novo compartimento, nós o modelamos e configuramos sem código. Ele se integra ao sistema de construção como qualquer outro bloco, e os jogadores podem usá-lo imediatamente em seus projetos. Um programador só entra em cena quando uma peça precisa de um novo mecanismo, e mesmo assim é um trabalho pequeno e isolado.

É isso que torna os compartimentos perfeitos para conteúdo de operações ao vivo: Cada nova unidade multiplica o número de configurações possíveis do Trampler, e elas são baratas para nós produzirmos.

Qual é a arquitetura subjacente ao sistema de compartimentos e como ela permite prototipar novas mecânicas rapidamente?

Utilizamos uma abordagem modular que nos permite iterar rapidamente sobre os protótipos. Nos bastidores, temos um contêiner de inversão de controle personalizado para integrar novas funcionalidades, e ele se encaixa muito bem ao nosso Sistema de Componentes de Entidade (ECS). Além disso, nosso mecanismo de rede personalizado significa que quase nunca precisamos nos preocupar com a rede ao criar novas mecânicas. A replicação é tratada em uma camada abaixo do código de jogabilidade.

Como o sistema de tarefas C# e o compilador Burst do Unity proporcionaram a margem de desempenho necessária para continuar adicionando conteúdo de operações ao vivo sem regressões?

Nossa simulação é executada em nossa própria versão modificada do Entitas, um framework ECS de código aberto, em vez do Unity Entities, mas o Job System em C# e o compilador Burst são essenciais para nossos caminhos críticos. A geração procedural de terreno, incluindo tarefas de amostragem de mapas de altura e biomas, matemática de movimento do Trampler e nossa eliminação de oclusão personalizada, são executadas como cadeias de tarefas compiladas pelo Burst. Esse trabalho fica fora da thread principal, então um mundo mais denso não nos custa frames.

Qual foi o papel do VFX Graph em permitir que sua equipe iterasse rapidamente nos efeitos para eventos ao vivo, momentos sazonais ou marcos importantes?

Todos os nossos efeitos – poeira de areia, fumaça, escudos, efeitos de armas – são construídos no VFX Graph, mas o ponto principal é como o utilizamos. Além disso, construímos sistemas de efeitos configuráveis, como o clarão do disparo ou o impacto da bala, que existem como um gráfico flexível com um grande conjunto de parâmetros expostos, incluindo tamanho, cor, tempo, detritos e fumaça.

Assim, quando uma nova arma é lançada, um artista simplesmente ajusta esses parâmetros e obtém um efeito único – não há nenhum artista técnico envolvido ou um novo gráfico construído do zero. O tempo dos artistas técnicos é dedicado a aprimorar esses sistemas, em vez de criar manualmente cada efeito individual para aquela arma.

É isso que mantém a produção rápida o suficiente para garantir um fluxo constante de conteúdo. Novas armas e eventos recebem efeitos de qualidade à custa de configuração, não de desenvolvimento.

De que forma o Unity Profiler moldou seu fluxo de trabalho de otimização à medida que seu pipeline de conteúdo de operações ao vivo foi escalado?

Medimos regularmente o desempenho tanto no cliente quanto no servidor para encontrar e otimizar os pontos fracos. A análise por sistema no Unity Profiler mostra exatamente para onde o tempo está indo, o que torna nosso ECS muito conveniente para análise de desempenho.

Também contamos com testes automatizados que medem o desempenho em cenários fixos, o que nos permite acompanhar a tendência diariamente e reagir às mudanças imediatamente.

Como você está usando o Addressables para enviar atualizações de conteúdo ao vivo, correções de bugs e lançamentos sazonais sem exigir uma atualização completa do cliente?

Os Addressables são a espinha dorsal do nosso gerenciamento de memória. O mundo é transmitido via streaming: Enquanto os jogadores cavalgam pelo deserto, o conteúdo é constantemente carregado e descarregado atrás deles. Tudo isso passa por Addressables, então a memória permanece estável, não importa o quão longe os jogadores viajem.

Uma segunda função, menos óbvia, é que temos dois projetos separados, o projeto principal do cliente e o projeto do servidor, e criamos uma solução personalizada que transfere recursos de um para o outro. Isso mantém ambos os ambientes consistentes: O servidor vê os mesmos dados que o cliente, construídos através do mesmo pipeline, então bugs de conteúdo do tipo "funciona no cliente, mas não funciona no servidor" são estruturalmente impossíveis, em vez de algo que precisamos testar.

Houve alguma ferramenta da Asset Store que ajudou você a criar ou manter seu pipeline de operações em produção mais rapidamente?

A partir da Unity Asset Store, o GPU Instacer Pro renderiza toda a nossa dispersão no deserto, o que é essencial para o mundo aberto, e o Amplify Impostors lida com objetos distantes. O Odin Inspector alimenta nossas ferramentas voltadas para designers, que são essenciais para um fluxo de trabalho de conteúdo orientado a dados, e o Rewired lida com a entrada de dados em PC e consoles. Easy Save , DOTween e I2 Localization nos pouparam tempo de verdade.

De que forma o Cinemachine contribuiu para capturar momentos compartilháveis ​​e memoráveis ​​– batalhas de mechas, grandes jogadas – que impulsionam sua estratégia de conteúdo?

Nossa utilização do Cinemachine é propositalmente simples. Ele gerencia nossas câmeras e alterna entre elas – a câmera de jogo, a câmera do hangar e a visão do espectador. Não fazemos nenhuma encenação extra ou cinematografia roteirizada por cima, e essa é uma escolha consciente. AREIA: Os Caçadores de Sophie É um jogo em primeira pessoa, altamente competitivo, e a função da câmera é ser confiável, não artística.

A qualidade cinematográfica provém do próprio jogo. Quando duas fortalezas ambulantes gigantescas estão trocando tiros de canhão, e você está no convés de uma delas recarregando uma arma, nenhuma sequência de câmera roteirizada consegue superar isso. A grandiosidade da simulação reside na cinematografia. O Cinemachine garante que a câmera nunca atrapalhe.

Você configurou um sistema Vivox de dois canais – bate-papo da tripulação e bate-papo por proximidade espacial. O que foi necessário para projetar e implementar isso?

Cada jogador está em dois canais Vivox simultaneamente: o canal normal da tripulação, que é o "rádio" onde sua tripulação sempre o ouve, e um canal posicional via voz de proximidade 3D , para que você ouça jogadores próximos de outras tripulações ao redor do mundo.

O canal posicional utiliza as propriedades 3D da Vivox – alcance, atenuação, modelo de fade – ajustadas em uma configuração. Nosso sistema ECS envia as posições do alto-falante e do ouvinte para o Vivox a uma taxa limitada, cerca de 20 vezes por segundo e somente quando o reprodutor se move. A autenticação é feita através do nosso próprio serviço de tokens de backend.

Além da gestão de voz, como a Vivox se integrou à sua estratégia mais ampla de operações ao vivo e como ela contribuiu para impulsionar o engajamento e a retenção nas redes sociais?

A voz por proximidade é um recurso de jogabilidade para nós, não apenas para comunicação. Os jogos de extração se baseiam em momentos sociais espontâneos, onde equipes que se encontram no deserto podem conversar, negociar, formar alianças ou trair umas às outras, e ouvir a voz real de um estranho por perto cria uma tensão que nenhum sistema roteirizado consegue proporcionar. O rádio da equipe mantém os times coordenados.

Qual é a sua principal dica para desenvolvedores que desejam criar um jogo orientado a operações em tempo real?

Desenvolver um jogo com operações ao vivo é uma jornada desafiadora, portanto, certifique-se de que sua equipe tenha a resiliência necessária para levá-la adiante e que você conte com parceiros e ferramentas confiáveis. Mantenha-se próximo da sua comunidade – ouça seus jogadores, aprenda com o feedback deles e deixe que isso ajude a moldar a evolução do jogo ao longo do tempo.

Para saber mais sobre projetos criados com Unity, visite a página de Recursos .