Como a Coatsink reduziu o tempo de carregamento da web para Ready, Set, Cook! em 25%

Pronto, Preparar, Cozinhar! é um jogo cooperativo de gerenciamento de restaurante para o Messenger desenvolvido pela Coatsink, o estúdio por trás de Jurassic World Aftermath e Transformers: Campos de batalha. Aqui está o que eles aprenderam durante sua primeira incursão no desenvolvimento web móvel.

Como um estúdio traz um jogo destinado ao Messenger Rooms do desktop para o celular?

Pronto, Preparar, Cozinhar! foi originalmente criado como um jogo web para desktop, onde os jogadores participam de chamadas de vídeo de seus PCs ou laptops. Enquanto a Coatsink estava mudando o desenvolvimento para focar em dispositivos móveis, eles colaboraram com a Meta e Unity, que já tinham uma parceria estratégica existente para fazer o runtime funcionar em dispositivos móveis. Esta é uma das principais atualizações do Unity Web na próxima versão do Unity 6, que também inclui suporte adicional para WebAssembly 2023, acesso antecipado ao WebGPU e a adição da ferramenta Emscripten 3.1.38. No próximo ano, os desenvolvedores de jogos poderão aproveitar o enorme ecossistema de jogos da Meta com o suporte da plataforma Instant Games da Unity.

Testando uma nova plataforma

Minha coisa favorita sobre Ready, Set, Cook! é o tempo mínimo de clique para jogar. Você está em uma chamada de vídeo no Messenger e, com o apertar de um botão, todos estão no Lobby e depois direto para o jogo. Não há configuração”, diz Ross Furmidge, chefe de programação da Coatsink.

Como era a primeira vez da Coatsink desenvolvendo um jogo para a web, o objetivo era tentar tirar o máximo proveito do fluxo de trabalho da plataforma. Eles trataram isso como um projeto de P&D para analisar a viabilidade da plataforma e sua força no desenvolvimento web móvel.

A equipe construiu principalmente sobre a funcionalidade existente. Eles pegaram blocos de construção prontos, incluindo Prefabs que abordavam HUD, gerentes de jogo, rede, interativos, Lobby e instruções de jogo, e adicionaram recursos aprimorados para melhor indicar o que o usuário deve fazer. Eles também incorporaram novas adições de recursos, como pausa, randomização de cosméticos, ajustes no Lobby e mensagens, mudanças no HUD, suporte a proporções de aspecto flexíveis e balanceamento de dificuldade, entre outros.

“Nós construímos e equilibramos o jogo em torno do aspecto multiplayer e nos divertimos com friends em uma videochamada”, explica Furmidge. "Quando nos aprofundamos no projeto, encontramos desafios comuns para jogos que vão do desktop para o celular." Tivemos que focar na interface do usuário e, para a web em particular, tivemos que considerar os tempos de download sobre dados móveis, já que não é garantido que um jogador esteja conectado ao Wi-Fi."

Os resultados

• Reduziu o tempo de carregamento do jogo em 25%
• Reduziu o tamanho do arquivo WebAssembly (Wasm) em 2,5%
• Reduziu os tempos de transferência e descompactação do jogo em 10%

Criando uma orientação de interface dinâmica

À medida que a equipe da Coatsink começou o projeto, eles rapidamente perceberam que havia muito a considerar para a interface do usuário. No início, eles estavam preocupados em garantir que tanto os jogadores quanto os usuários de videochamada que não estavam jogando pudessem participar. Eles precisavam refinar a funcionalidade de espectador existente que mantém consistentemente os jogadores online enquanto oferece aos outros usuários uma experiência de visualização positiva.

“A experiência de espectador sempre foi uma prioridade para nós ao projetar outros aspectos do jogo”, explica Kamil Bazydlo, um designer júnior da Coatsink. “Não é uma característica comum em todos os gêneros de jogos em outras plataformas, mas como os jogadores estão em uma chamada de vídeo, era importante enfatizar a participação inclusiva dos usuários ao longo do jogo.”

Eles também começaram a observar a orientação da tela desde cedo. Como o jogo foi inicialmente criado para desktop, foi construído com uma orientação horizontal. Quando eles mudaram para o celular, tiveram que suportar tanto as perspectivas de paisagem quanto de retrato. No Messenger, os jogadores seguram suas telas como um telefone, já que estão em uma videochamada, então se o telefone for girado, a câmera fica de lado, o que não é ideal. “Esta foi uma grande consideração quando projetamos os ambientes para apoiar isso”, diz Furmidge.

Repensando os controles do jogo

Pronto, Preparar, Cozinhar! pode ser jogado em uma ampla variedade de dispositivos com diferentes tamanhos de tela e proporções, mas a janela de visualização do jogo não se estende por toda a tela, pois aloca espaço para elementos como o feed de vídeo da Meta e os controles da plataforma. Estes não fazem parte do próprio aplicativo do jogo, então eles não aparecem no Editor do Unity quando os desenvolvedores estão trabalhando no jogo.

"Tivemos que levar isso em consideração ao colocar qualquer elemento da interface do usuário na tela", diz Bazydlo. "Obtivemos a faixa aproximada de quanto espaço de tela é ocupado por esses elementos da plataforma e trabalhamos com nossa equipe de QA para identificar qual seria a proporção de aspecto mais estreita a ser alvo."

Em dispositivos móveis, os controles específicos do dispositivo estão na parte inferior da tela. Como o jogo foi desenvolvido com a orientação paisagem em mente, a equipe usou a parte inferior da tela para exibir alguns elementos do HUD em vez de para entradas críticas de jogabilidade.

Quando o título foi lançado suavemente nos EUA, a equipe incorporou Analytics diretamente no aplicativo, o que foi fundamental para identificar quando os jogadores saíam do jogo. No início, eles perceberam que os usuários estavam desistindo antes mesmo do jogo carregar.

“Vimos que quando o menu estava um pouco mais ocupado e seu fluxo para o jogo era muito longo para os usuários no Lobby, eles desistiam rapidamente.” Assim que entraram no jogo, a maioria dos jogadores continuou a jogá-lo na íntegra”, diz Furmidge. “Isso foi um dado instrumental para nós, e o Analytics foi um grande fator em muitas de nossas tomadas de decisão.”

Otimizando o tempo de carregamento

Os analytics da Coatsink mostraram que, se os tamanhos dos arquivos do jogo fossem muito grandes e demorassem muito para carregar, os usuários desistiriam antes de chegarem ao menu principal ou à jogabilidade.

O desenvolvedor da Coatsink, Andrei M., concentrou-se em reduzir o tamanho do arquivo usando opções dentro das Configurações de Build do Unity. Por exemplo, ele definiu a configuração de otimização de código para tamanho de disco com LTO, usou o formato de compressão Brotli, definiu a geração de código IL2CPP para compilações mais rápidas (menores), ajustou o nível de remoção gerenciada para alto, e mais. Com essas otimizações para a web, a equipe conseguiu reduzir significativamente o tempo de carregamento.

Eles então usaram a ferramenta WebAssembly (Wasm) do Unity, que remove partes não utilizadas do Unity Engine e gera um arquivo .wasm otimizado. Ao reduzir o tamanho deste arquivo, havia menos para comprimir, transferir e descompactar no dispositivo em tempo de execução. “Dessa forma, o usuário entra diretamente no jogo assim que termina de baixar as informações”, explica Furmidge.

Essas práticas de otimização de jogos levaram a uma redução de 4 MB, o que corresponde a uma redução de 2,5% no arquivo Wasm. Isso se traduziu em uma economia de 10% tanto no tempo de transferência quanto no tempo de desempacotamento. Embora 4 MB possa parecer pequeno, no grande esquema das coisas teve um grande impacto para um jogo rodando em navegadores móveis.

Reduzindo o tamanho do arquivo

Para reduzir o tamanho do arquivo, a equipe da Coatsink usou AssetBundles, um arquivo de arquivamento que contém ativos não-código específicos da plataforma. Eles os hospedaram em um servidor externo e depois os baixaram quando a compilação foi executada para ajudar os usuários a entrar no lobby do jogo o mais rápido possível.

Eles também usaram o Addressable Asset System para carregar ativos sob demanda. Isso os ajudou a dividir os pacotes nos grupos necessários para diferentes partes do jogo e contribuiu significativamente para a redução de 25% no tempo de carregamento.

“Dessa forma, temos a quantidade mínima de ativos para lobbies para ajudar os jogadores a entrarem cedo, a quantidade mínima para cada nível e alguns pacotes comuns com ativos comuns para diferentes níveis”, explica Andrei M. "O objetivo é ter o menor número possível de arquivos para baixar, já que o HTTP/2 não está em todos os lugares, e queremos o menor número possível de ativos não necessários dentro."

A equipe criou um fluxo de trabalho que os ajudou a detectar se um usuário estava em um dispositivo móvel ou desktop quando iniciavam o jogo. Em um modelo web, durante o carregamento, eles poderiam determinar se o dispositivo era móvel e, se fosse, mudariam os diretórios de dados e ativos para usar ativos otimizados para a plataforma.

"Criamos nosso próprio sistema de construção dupla, que produziu duas versões que não eram completamente diferentes." Refere-se a diferentes atlas e altera tanto o tipo de compressão quanto o tamanho. São duas visões diferentes de ativos baseadas no mesmo código-fonte", diz Andrei M.

Enfrentando desafios únicos de teste e depuração

Quando se tratou de testar e depurar o jogo, a equipe enfrentou algumas dificuldades devido à circunstância única de executar o jogo dentro do aplicativo Messenger em vez de um navegador web tradicional. Embora tivessem compilações que podiam rodar em navegadores usando jogadores fictícios, ainda assim acabaram tendo que se aprofundar mais para encontrar os bugs que só apareciam dentro do Messenger.

"Para esses bugs, criamos um sistema que faz upload dos logs para nossos servidores AWS em builds de desenvolvimento, que então poderíamos ler", explica Furmidge.

A equipe também usou ferramentas de desenvolvimento de navegadores web para capturar erros no console e rastrear chamadas de API. Como programador, isso foi fundamental para Furmidge.

"No console do navegador, você pode digitar os comandos e tentar executá-los manualmente", ele diz. “Como tínhamos uma biblioteca externa de JavaScript que construímos para fazer a ponte entre JavaScript e Unity, um plug-in nativo, podíamos acessá-la quando necessário.” Isso foi usado para encapsular o SDK JavaScript da Meta para poder se comunicar com seu servidor multiplayer de nó, um recurso que a Unity está trabalhando para lançar como um pacote em lançamentos futuros.

Para ajudar a acelerar o desenvolvimento, Andrei M. também criou seu próprio wrapper local para imitar as chamadas da API do Meta que ele precisava. Ele explica: "Eu me concentrei em chamadas de API que lidavam com configuração de servidor local, respostas programáveis e latência."

Tornando-se uma extensão natural da plataforma

A equipe da Coatsink queria que a Ready, Set, Cook! experiência fosse perfeita para os usuários do Messenger. De permitir que os jogadores entrem rapidamente em sessões de jogo a tempos de carregamento curtos, seu objetivo final era agir como uma extensão orgânica da plataforma.

Parte disso é fornecer uma jogabilidade intuitiva onde os jogadores podem avançar sem interrupções, jogar em vários dispositivos e torcer por seus Friends à distância. Para fazer isso, a equipe incorporou dicas roláveis sobre os recursos do jogo durante o carregamento, animações convenientes de como jogar e elementos interativos. Esses recursos ajudam os jogadores a encontrar a diversão com Friends enquanto gerenciam o caos na cozinha.

“Queríamos naturalmente aproveitar as pessoas que já estavam usando o Messenger e adicionar às suas experiências de chamadas de vídeo”, diz Nick Taylor, um produtor sênior da Coatsink. “Trabalhar com a Meta e a Unity foi realmente colaborativo e nos deu a oportunidade de fazer isso em abundância.”

Possibilidades ampliadas com Unity 6

O Unity 6 visa colocar a criação de jogos rápida e fácil diretamente em suas mãos, não importa onde seus jogadores estejam. Baixe o Unity 6 no Unity Hub.