Nós descobrimos com nosso líder de tecnologia
Para o projeto educacional do Banco da Rússia, criamos um jogo da web impressionante "O Mistério do Cofrinho Perdido" . Ela chama a atenção dos alunos para o tema da educação financeira, apresenta os termos, ensina-os a administrar o dinheiro com sabedoria. O jogo agradou não apenas às crianças, mas também aos adultos de diferentes cidades da Rússia - foi jogado por mais de 30.000 pessoas.
Há muito tempo que pedimos ao nosso líder de tecnologia que nos falasse sobre o desenvolvimento do jogo para web. Ele não apenas contou, mas também escreveu um artigo ardente sobre nossa experiência neste projeto, sobre as dificuldades que surgiram, e também compartilhou hacks de vida no desenvolvimento de jogos de navegador. O resultado é um material cheio de utilidade. Leia.
Um jogo da web é fundamentalmente diferente de um jogo de computador normal e de um site normal em um navegador. Em um jogo normal, todos os recursos do jogo estão disponíveis offline, o mecanismo de jogo conhece informações sobre o processador, a memória e a placa de vídeo do computador. Um site normal requer poucos recursos do computador e, em caso de problemas, você pode simplesmente recarregar a página.
Tínhamos suposições sobre os recursos de um jogo de navegador - restrições significativas no tamanho de RAM disponível e usado (por exemplo, está declarado no TOR que 1 GB de RAM deve ser suficiente para dispositivos móveis), o equilíbrio entre a qualidade dos recursos do jogo (imagens, texturas, sprites, sons, vídeos) e sua velocidade de download.
Somados a isso estavam os requisitos do cliente - o jogo deve rodar e funcionar em todos os navegadores declarados para dispositivos móveis e desktop (incluindo o IE 11), com as especificações de hardware mais baixas possíveis. Esses requisitos baseavam-se no fato de que o jogo deveria ser exibido em qualquer oportunidade conveniente, em qualquer dispositivo que estivesse à mão - por exemplo, na escola.
Como o motor foi escolhido
Já tínhamos experiência em desenvolvimento de jogos, então as direções para a escolha de um motor foram imediatamente indicadas:
- Phaser — /.
- Unity Web — .
- LibGDX, Godot, PlayCanvas.
Opções desconhecidas caíram por um motivo óbvio - precisavam ser dominadas e estudadas, o que, de alguma forma, assustava, embora não parecesse impossível. A opção Unity caiu porque o motor e as restrições de exportação não permitiam, por exemplo, o uso de áudio no IE 11. E também porque o Javascript exportado do Unity era muito grande, e o IE 11 é muito mais lento na análise e execução de código do que os modernos. navegadores.
Assim, decidiu-se por uma nova versão do motor Phaser (na época do desenvolvimento, era a versão Phaser 3.11). Escolhemos este motor também porque toda a lógica e renderização são software, o que significa que poderíamos controlar absolutamente qualquer aspecto do futuro jogo no código.
Como eles escreveram
No início, não tínhamos nenhuma mecânica elaborada, mas sabíamos que seria definitivamente um jogo de plataformas. Portanto, decidimos montar pelo menos algum protótipo para atualizar nosso conhecimento do motor, bem como fazer medições aproximadas dos recursos consumidos e da carga no navegador.
Pegamos nos exemplos “movimento do personagem” e “mapa de blocos” prontos na documentação, montados, lançados - funciona: o personagem anda, pula, se move em plataformas. Lançado em todos os dispositivos disponíveis - ainda funciona. Adicionados botões de controle virtual a partir do exemplo "botões virtuais" e iniciados no celular - ainda funciona. Adicionado um pouco de mecânica - bater, inimigo, lidar e receber danos, coletar moedas - foi o suficiente para o protótipo.
No protótipo, havia até um pouco mais do que o necessário. Por exemplo, a mecânica de controlar dois personagens foi implementada, entre os quais você pode alternar a qualquer momento.
Depois de um protótipo bem-sucedido, entendemos como a arquitetura seria implementada e o código organizado. Se falamos da parte de infraestrutura, então é trabalhar com o motor em termos de carregamento de recursos, criação de objetos de jogo, troca de telas. Quanto à própria lógica do jogo, esta é a implementação dos personagens, a implementação da mecânica de interação com presas, armadilhas, inimigos.
A pilha de desenvolvimento foi considerada típica para um projeto semelhante - webpack, webpack-dev-server, babel, babel / preset-typescript.
Quais dificuldades foram
Foram encontradas dificuldades no cumprimento dos requisitos de desempenho e na comunicação da equipe. Tive que trabalhar com novas ferramentas e transferir materiais uns para os outros em novos formatos, então nem sempre tudo funcionou bem na primeira vez.
Por exemplo, foi estipulado no TOR que o jogo tenta determinar o desempenho do dispositivo na inicialização, sendo exibida uma notificação correspondente em caso de baixo desempenho. Nesta fase, enfrentamos dois problemas. Em primeiro lugar, o navegador não dá praticamente nenhuma informação sobre este assunto. Em segundo lugar, o desempenho de uma guia específica do navegador em um determinado momento depende muito de fatores externos - quantas guias estão abertas, se há sites pesados em outras guias, se o navegador está minimizado.
Foram testadas várias hipóteses teóricas e práticas, das quais nasceu a solução final. A solução é a seguinte:
- Na tela de carregamento do jogo, onde há uma evolução de 0 a 100%, o carregamento real dos recursos termina em 92%.
- Depois disso, uma cena é criada fora da tela, na qual animações pesadas e um pouco de física são colocadas.
- Então, em 5 segundos, o tempo médio de renderização de um quadro é medido.
- Depois disso, é tomada uma decisão sobre o desempenho do aparelho e o progresso chega a 100%.
Muito importante era a exigência de que o jogo funcionasse totalmente no IE 11, o que também causava transtornos. Descobriu-se que, com as ferramentas do desenvolvedor em execução, a já lenta execução do Javascript neste navegador ficou ainda mais lenta.
Ou seja, você se depara com os freios do jogo, abre as ferramentas do desenvolvedor para descobrir o motivo e o jogo fica ainda mais lento.
Mecânica de jogo
A própria mecânica do jogo é descomplicada, amplamente inspirada nos jogos existentes.
O personagem principal, por exemplo, é um sprite de animação de uma peça junto com uma arma. Esta solução foi escolhida para evitar a fora de sincronia das animações de swing e armas. Portanto, o dano infligido é verificado da seguinte forma - no momento de certos quadros da animação de impacto (quadro do terceiro aproximadamente), calculamos a área de intersecção, que é válida para vários outros quadros de animação. É assim que conseguimos atingir o funcionamento realista da arma.
A desvantagem dessa decisão na animação do personagem principal é que para cada gênero em cada um dos níveis, você precisa de um conjunto separado de animações preparadas com armas. E no segundo nível, outro conjunto adicional era necessário - tênis de crédito. No total, temos quatro conjuntos completos de animações para cada personagem.
Outra coisa engraçada aqui é que quando você escolhe uma arma para a batalha final, na verdade você escolhe o personagem inteiro do nível correspondente. Portanto, todos os heróis com uma espada usarão tênis normais.
A mecânica de pegar as chaves do baú era interessante. Para a chave que precisava ser capturada, a área de gatilho foi diminuída do que o sprite visual da chave, e também ligeiramente deslocada para o lado aleatoriamente. Isso levou ao efeito desejado “minha chave não vai ser montada na primeira vez” - às vezes você precisa tentar recolher a chave várias vezes para chegar à área de atuação. Caso contrário, era muito fácil, embora na versão final a área de gatilho fosse ligeiramente aumentada para reduzir a porcentagem de tentativas malsucedidas.
Todas as outras mecânicas são realmente as mesmas - acionando a abordagem e a interseção do personagem e dos objetos do jogo em determinados pontos no tempo e na animação.
A mecânica com o Dragão de Seguros, o vôo sobre o abismo e a batalha final foram um pouco mais complicados. As técnicas eram as mesmas, mas as pausas e a inatividade eram adicionalmente orquestradas para reproduzir as animações de outros personagens dessa época.
Conclusões e conselhos
Decida um gênero desde o início.
Os jogos na web são um fenômeno real, com público próprio e regras próprias. Esses jogos não requerem instalação, eles permitem que você organize sessões de jogo curtas, eles atraem mais mecânica do que aparência.
Dica - trate o desenvolvimento de jogos da web como um jogo real, não apenas mais um "script na página". Teste, analise e evite vazamentos de memória e sobrecarga de CPU. Os jogadores e as baterias de seus dispositivos ficarão felizes.