Rede de tela dividida e GameShare em Survival Kids

Neste verão, a Unity lançou seu primeiro jogo, criado em estreita colaboração com o parceiro editor KONAMI. Survival Kids é uma atualização cheia de diversão do clássico jogo infantil que foi lançado como um título de dia um Nintendo Switch™ 2.

O jogo foi construído inteiramente na Unity 6, então a equipe de desenvolvimento estava trabalhando com um novo software para lançar o jogo em uma nova plataforma – um grande desafio. Além disso, o jogo pode ser aproveitado em uma variedade de configurações de rede, então a pequena equipe da Unity que trabalhava no projeto teve que construir uma arquitetura multiplayer robusta que suportasse essas opções.

Confira a primeira parte da história de rede multiplayer para Survival Kids, onde compartilhamos como os fundamentos por trás da arquitetura de rede do jogo se juntaram. Este post expande essa base para mostrar como a equipe construiu a tela dividida do jogo e as capacidades GameShare do Nintendo Switch 2.

A Nintendo Switch é uma marca registrada da Nintendo.

Depois de resolver muitos dos problemas na arquitetura de rede do jogo, começamos a pensar sobre como faríamos a tela dividida, que não é fornecida de forma padrão no Netcode for Entities. Esse foi um desafio diferente. Com a tela dividida, deve haver mais de um jogador, mas esses jogadores pertencem a um cliente.

O Netcode for Entities assume que há um jogador por cliente – se houver um jogo separado, com um console separado se conectando a ele, então ele tem um jogador. Quando isso muda e há na verdade dois ou três jogadores, não há como enviar a entrada para cada jogador individualmente. Elas têm que ser enviadas como uma só.

Nós efetivamente criamos um jogador de entrada virtual que ninguém pode ver. É totalmente invisível, mas coleta toda a entrada de todos os jogadores locais, até quatro deles (embora no final não tenhamos feito tela dividida para quatro jogadores). Ele gerencia toda a entrada que chega e, em seguida, envia toda essa entrada para o servidor a cada quadro.

No jogo, os jogadores não gerenciam sua própria entrada. O jogador de entrada virtual imaginário lhes diz qual é a entrada para um quadro. Anteriormente, o Netcode for Entities assume que um jogador é responsável por obter sua entrada e usar sua entrada para fazer todo o seu movimento, mas aqui há esse outro jogador que não faz nenhum movimento, mas mantém toda a entrada para tudo o mais.

A tela dividida foi o principal desafio do ponto de vista da rede. Para evitar ter um problema de múltiplas câmeras, começamos tendo um segundo jogador que correria enquanto a câmera ficava com o primeiro jogador. Isso se juntou rapidamente, mas então encontramos outros problemas, como como configurar uma segunda câmera? Como manter uma câmera à esquerda da tela e a outra à direita da tela? Tivemos que resolver problemas de interface do usuário também, porque há bastante interface que apenas um jogador pode ver. Por exemplo, se um jogador está na frente de um tronco, ele veria um pequeno botão de prompt que diz: "Ei, pressione X para pegar este tronco", mas é claro que você não quer que o outro jogador veja isso.

Tivemos que descobrir como esconder a interface do usuário para que, se o outro jogador estiver por perto, ele não a veja. Usamos camadas para isso, mas nossa solução estava mais relacionada à interface do usuário do que à rede. Decidimos que, no final das contas, queríamos bloquear o jogo para dois jogadores em tela dividida para uma melhor experiência de jogo - mesmo que seja em uma tela grande, só pode haver dois jogadores locais. Poderíamos fazer quatro em uma tela dividida internamente, e mantivemos isso por um bom tempo porque era uma ótima maneira de testar o desempenho, já que cada jogador adiciona um pouco mais de processamento, um pouco mais de renderização, outro jogador para simular.

Uma das características durante o desenvolvimento para o Nintendo Switch 2 é o GameShare. Você está efetivamente enviando um feed de vídeo para outro console - na verdade, é apenas tela dividida do ponto de vista da rede - exceto que o sistema envia uma câmera para outro console em vez de renderizá-la em uma tela.

Nossa tela dividida para quatro jogadores foi a base de como abordamos o modo GameShare. Poderíamos conectar quantos jogadores quiséssemos, desde que o desempenho estivesse ok e pudéssemos transmitir vídeo para aquele console. A principal razão pela qual não queríamos fazer tela dividida para quatro jogadores era apenas sobre o tamanho da tela, na verdade. A menos que você tenha uma TV enorme, é realmente difícil ver as janelas - mas se você tiver seu próprio console, o vídeo pode ser transmitido para isso.

Nos esforçamos muito para nos diferenciar do nosso modo de tela dividida para dois jogadores para que pudéssemos suportar um terceiro jogador extra no GameShare. Você pode ter um anfitrião e dois convidados enquanto ainda oferece aos jogadores uma ótima experiência e desempenho suave. Não estávamos dispostos a baixar nossos padrões nisso, mas ainda conseguimos usar a arquitetura de tela dividida para alimentar o GameShare.

Um recurso realmente útil que adicionamos foi um comando de depuração. Temos um menu de desenvolvedor, então você pode pressionar um botão, chamar o menu e, em seguida, digitar comandos nele. Isso foi útil porque nos permitiu executar várias coisas de depuração – tudo isso é compilado fora do jogo final, então, é claro, ninguém poderia fazer isso no jogo final que as pessoas compram e jogam. Mas um dos modos que tínhamos na tela dividida era que você poderia duplicar o jogador principal – isso permitia que você tivesse uma tela dividida onde um controle controla ambos os jogadores. Foi uma ótima maneira de testar a tela dividida sem precisar ter muitos controles por perto, e isso facilitou os testes.

A configuração da tela dividida também executou efetivamente todo o código de rede normal que fizemos. Como os jogadores estavam separados uns dos outros, o servidor enviaria informações para mostrar como o jogo online funciona. Mas também é possível testar se o código funcionou no modo multiplayer sem conectar um jogador a outro cliente, iniciando o modo de tela dividida com outro controle no Editor para jogar lá. Não há necessidade de fazer uma nova compilação, já que é possível testar o código na tela dividida como um proxy para um jogo online normal.

Havia mais duas ferramentas do Unity que achamos realmente úteis, embora não as usássemos até bem no final do projeto. O Unity 6 inclui novas ferramentas de Modo de Jogo Multiplayer, que nos permite testar sem uma compilação de jogador separada.

Abrindo o Editor, leva mais de uma hora para fazer uma compilação limpa de jogador porque há muita arte e outras informações, então testar o código com um jogador remoto significa esperar pelo menos esse tempo. Não é particularmente bom para iteração. Mas o Modo de Jogo Multiplayer permite que você efetivamente abra outra janela, como outra versão virtual do Editor, e se conecte assim.

O Netcode for Entities também possui ferramentas de Modo de Jogo para simular conexões de rede ruins. Você pode especificar e simular um nível específico de ping – digamos, um ping de 300 milissegundos, uma viagem de ida e volta realmente horrível para simular como seria jogar com um amigo que conectou seu telefone ao laptop em um aeroporto e se conectou ao jogo dessa forma. Então você pode testar isso no Editor para descobrir quão lento ou instável é. Às vezes isso não funciona em uma conexão de rede que está perdendo dados e descartando pacotes, e poderíamos simular isso facilmente.

Esse teste aconteceu o tempo todo. Por um tempo, tivemos uma regra de que ninguém poderia jogar no Editor com o simulador desligado – todos tinham que jogar com algum tipo de lag simulado, já que nenhum dos nossos jogadores jogaria em uma conexão perfeita. Dessa forma, nunca poderíamos nos enganar acreditando que uma banda larga de escritório super rápida era representativa.

No final, todos esses testes valeram a pena – conseguimos entregar um jogo suave e performático a 60 fps em redes e configurações multiplayer realmente diferentes. Desde o lançamento do jogo há algumas semanas, vimos jogadores continuando a se engajar online através do Lobby e Relay, esperamos que estejam desfrutando de uma experiência de jogo contínua e robusta, independentemente das condições de rede em casa.

Confira as outras edições da nossa série de blog que mergulha em Survival Kids produção:
- "Dicas de gráficos e renderização de Survival Kids"
- "Layout de nível e fluxos de trabalho de terreno em Survival Kids"
- "Dentro da infraestrutura de rede multiplayer de Survival Kids"

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