Por dentro da infraestrutura da rede Multiplayer da Survival Kids

Neste verão, a Survival Kids foi lançada como lançamento do primeiro dia para o Nintendo SwitchTM 2. O jogo foi desenvolvido inteiramente no Unity 6, o primeiro projeto de desenvolvimento completo da Unity, em estreita colaboração com a KONAMI, parceira de publicação.

Desenvolver para uma nova plataforma no primeiro dia é um grande desafio, mas a pequena equipe interna que desenvolveu esse projeto incluía desenvolvedores experientes da Unity, muitos dos quais trabalham na Unity e nos jogos há décadas. Este blog faz parte de uma série contínua sobre como o jogo foi feito, como esse trabalho impulsionou o compromisso da Unity com a verificação de produção, além de lições que outros desenvolvedores de jogos da Unity podem tirar e aplicar em seus próprios projetos.

Este é o primeiro jogo de uma série em andamento nos bastidores que mergulha nas lições de equipe do trabalho em Survival Kids.

A Nintendo Switch é uma marca registrada da Nintendo.

O Survival Kids foi desenvolvido por uma equipe muito pequena dentro da Unity. O grupo principal era composto por cerca de 10 desenvolvedores de várias disciplinas (artistas, engenheiros e designers). No nosso pico, éramos cerca de 20 anos quando pessoas de outras equipes da Unity entraram. Por exemplo, Steven, nosso engenheiro de renderização, trabalhou muito conosco, mas nem sempre esteve no projeto.

Como uma equipe pequena, tivemos algumas vantagens. Os engenheiros eram muito experientes — a maioria de nós escreveu jogos há cerca de 20 anos, principalmente no espaço AAA, então aprendemos muitas lições e cometemos muitos erros. E, claro, temos experiência em Unity pois a maioria de nós está aqui há algum tempo.

Alguns de nós também trabalharam em projetos de clientes como parte das equipes de suporte da Unity, como Professional Services/Accelerate Solutions, agora Unity Studio Productions. Nós aconselhamos os clientes sobre como otimizar seus projetos e até mesmo integrar com as equipes de projeto para trabalhar ao lado deles e ajudar a resolver problemas técnicos difíceis, portanto, somos bastante experientes nos erros que os estúdios geralmente cometem e como corrigi-los. Trabalhando na Survival Kids, conseguimos arquitetar o projeto e colocá-lo no caminho certo desde o início pois sabíamos onde todos os problemas estavam, e isso nos economizou muito tempo e recursos.

Hoje, quero mergulhar na arquitetura de rede do jogo. Usamos o Unity para impulsionar a rede Multiplayer, e o Survival Kids oferece aos jogadores diversas maneiras diferentes de jogar, tudo na mesma base de rede. Então, vamos mergulhar em como isso veio em conjunto, e espero que algumas delas possam ajudar você em seus projetos também.

Survival Kids pode ser jogado de várias maneiras: jogador único, cooperativa local e online com amigos. No Nintendo SwitchTM 2, os jogadores também podem usar o GameShare para transmitir o vídeo para outro Nintendo Switch 2 ou até mesmo um Switch original, depois jogar Multiplayer com alguém na TV ou em um dispositivo, o que é muito legal.

Queríamos que a nossa configuração impulsionasse todas essas e outras combinações. Por exemplo, você pode ter dois jogadores jogando tela dividida em uma televisão conectada e outros dois jogadores jogando tela dividida em uma televisão diferente — então, quatro jogadores usando dois dispositivos. Essa flexibilidade foi algo que queríamos realmente projetar na arquitetura para possibilitar a jogabilidade de várias maneiras diferentes.

Para isso, decidimos sobre Netcode for Entities. Depois de apresentarmos o conceito de Survival Kids para a KONAMI, entramos na prototipagem para encontrar a diversão para o nosso jogo Multiplayer. Usamos um projeto existente como ponto de lançamento, um que eu tinha escrito anteriormente como prova de conceito para como podemos usar Netcode for Entities como uma rede de backend, depois escrever uma camada de GameObject sobre ela para aproveitar os Prefabs e animações. Nem todos da equipe tinham experiência em trabalhar com Entities, então decidimos usar GameObjects e MonoBehaviour juntos.

Também queríamos manter a lógica de jogabilidade em GameObjects e MonoBehaviours pois facilitam a prototipagem – essa configuração permite que você junte as coisas e escreva scripts e baixe scripts da internet ou use pacotes da Asset Store para prototipagem. Queríamos essa iteração rápida e liberdade, mas também gostamos que a NetCode for Entities nos proporcionasse uma camada de rede de alto desempenho. Eu já usei em alguns projetos de clientes e projetos pessoais de pesquisa, então eu sabia que seu nível de qualidade poderia impulsionar o nível de jogabilidade que queríamos.

Quando começamos, há cerca de três anos, existia o Netcode for GameObjects, mas ainda não tinha alguns dos recursos que queríamos, principalmente a previsão do lado do cliente. Com a previsão do lado do cliente, se alguma vez houver um atraso entre o servidor e o cliente, o cliente prevê o que o servidor fará e faz de maneira instantânea — para que os controles dos jogadores sejam responsivos mesmo quando houver atraso. Você não precisa esperar que o servidor diga que um jogador se moviu ou o que você tem, já está fazendo. Isso é algo que a Netcode for Entities tinha desde o início.

Para prototipagem, basicamente pegamos um projeto que já tínhamos e entramos. Começamos com coisas simples — pegar objetos, cortar árvores — e, gradualmente, começamos a concretizar o que seria uma parte da jogabilidade. Ainda estávamos desenvolvendo protótipos, então não nos preocupamos muito com a qualidade do código. Estávamos tentando encontrar a diversão e analisando nossos pilares de jogo, incluindo “sobrevivência para todos”. Queríamos um jogo de sobrevivência, mas não queríamos que fosse super difícil ou punitivo, tentávamos descobrir o que é realmente divertido e emocionante nesse gênero.

Perguntamos-nos: O que as pessoas adoram em criar e reunir recursos? Do que eles não se importam? Isso nos ajudou a definir como os jogadores obtêm recursos, como os movem de um lugar para outro, como criam. Nós descobrimos tudo isso desenvolvendo protótipos e iterando rapidamente usando GameObjects e MonoBehaviours.

Como começamos com essa pequena demonstração de comprovação de conceito, conseguimos nos conectar pelo endereço da Internet, imediatamente. Foi possível conectar-se usando uma IP de computador, mas também usamos o serviço Unity Relay, que permite hospedar um jogo em um servidor Relay na nuvem. Com o Relay, qualquer pessoa pode participar desse jogo usando um código de participação, e as pessoas podem se conectar em casa ou no escritório sem uma VPN ou IP conhecida. Isso significou que pudemos entrar em um ritmo de testes de jogo semanais, que estávamos fazendo no trabalho e em nossas redes domésticas, o que nos permitiu testar a arquitetura de nossa rede junto com a jogabilidade com todos os tipos de velocidades de conexão diferentes. No final, mantivemos o Relay em produção.

Tentamos ficar o mais próximo possível dos pacotes publicamente lançados. Se encontrássemos um bug em um dos pacotes, identificá-lo-íamos, trouxemos o pacote localmente e tentaríamos corrigir. Às vezes, entramos no Slack depois e mandamos uma mensagem para a equipe de NetCode da Unity explicando o problema e nossa correção para que pudessem levar isso e fazer os PRs – e, às vezes, colocá-lo na versão final. Não estávamos necessariamente envolvidos na correção, mas ao trabalhar em um ambiente de produção, descobrimos alguns problemas que eles ainda não tinham (embora às vezes já tivessem uma correção melhor do que qualquer coisa que imaginássemos, ou falassem que estávamos usando errado).

Como desenvolvemos deste jeito, remotamente por meio do Relay, não adicionamos um modo offline até mais tarde, próximo do lançamento. O modo offline não abre nenhum soquete de rede e usa algo chamado de driver em processo. Ele se comporta como se fosse uma rede, com um servidor e um cliente, mas eles executam no mesmo processo e se comunicam entre si. Em vez de enviá-lo pela rede, eles enviam diretamente para o cliente. É chamada de conexão em processo e é muito rápida pois você não precisa esperar que os bytes reais viajem pela rede, mas passa pelo mesmo fluxo que a nossa jogabilidade.

Para trabalhar dessa maneira, não precisávamos programar uma versão diferente, é o nosso modo de jogador único e o nosso modo Multiplayer. Jogador único e offline ainda são um jogo de rede, basta não usar a rede, tudo acontece internamente.

Isso significou que tivemos uma arquitetura de código única que podia ser usada em qualquer lugar. O custo disso, no entanto, é que quando você hospeda ou jogador único, simula o servidor e o cliente, criando um desafio de desempenho para executar ambos ao mesmo tempo. Com servidores dedicados, um servidor pode sair e viver em um farm de servidores em algum lugar, para que você só precise do que é chamado de cliente, o que faz com que tudo pareça bom e responda a qualquer coisa que o servidor está comunicando. Mas para jogador único, já que estamos simulando, o jogo tem que fazer ambos e não pode ficar em um servidor dedicado em algum lugar.

Isso acabou sendo um dos maiores desafios de desempenho, otimizar para que o servidor e o cliente pudessem ficar no mesmo jogo, no mesmo quadro, e ainda atingir nossa meta de 60 quadros por segundo em uma boa resolução. Esse objetivo era muito importante para nós.

Confira as outras séries da nossa série de blogs aprofundando na produção de Survival Kids:
- "Dicas de gráficos e renderização de Survival Kids"
- "Layout de níveis e fluxos de trabalho de terreno em Survival Kids"

Mantenha-se ligado na quarta e última publicação da série, parte 2 de nossa história Multiplayer, que mergulha em como desenvolvemos essa arquitetura de rede para habilitar a jogabilidade em tela dividida e o GameShare no Nintendo Switch 2.

Para saber mais sobre projetos Made with Unity, acesse a página de recursos.