Os jogos nativos do navegador estão cada vez mais sérios: o que revelam os projetos de combate de código aberto

Comecei esta investigação à espera de encontrar apenas algumas experiências interessantes de combate no navegador. Em vez disso, encontrei um ecossistema muito mais amplo: verdadeiros protótipos de ação na terceira pessoa com fixação de alvo, árvores de combos ramificadas, parries perfeitos, invulnerabilidade durante a evasão, sistemas de postura, ataques aéreos, sinalização prévia de ataques de chefes, motion warping, hit-stop, choques físicos entre armas, suporte a gamepad, comandos táteis e simulação determinista.

Esse é o resultado importante. Já não se trata apenas de pequenos jogos que, por acaso, são renderizados dentro de uma página web. Alguns estão a resolver os mesmos problemas de engenharia que os jogos de ação convencionais, mas são distribuídos através de uma URL e podem ser jogados imediatamente.

Para mim, como profissional de desenvolvimento web, essa é a parte fascinante. O antigo modelo mental dos jogos era dominado por instaladores, grandes downloads, atualizadores, launchers e por um intervalo entre descobrir um jogo e conseguir realmente experimentá-lo. O navegador reduz drasticamente esse percurso: abrir um link, carregar os recursos e começar a jogar.

Esta investigação concentrou-se em projetos com uma versão jogável no navegador e código-fonte público. As exportações Unity WebGL foram excluídas de propósito porque eu queria estudar jogos construídos em torno de tecnologias web, e não jogos simplesmente exportados para a web.

Os projetos mais sólidos que encontrei

As descobertas mais úteis não se destacavam todas pela mesma razão. Algumas tinham os sistemas de combos mais profundos. Outras ofereciam melhor arquitetura na terceira pessoa, uma simulação de combate mais limpa ou impactos físicos mais convincentes.

Porque os resultados me surpreenderam

O surpreendente não foi simplesmente a qualidade visual dos gráficos. Renderizar uma cena polida é apenas uma parte do desenvolvimento de jogos. Os projetos que mais se destacaram implementavam sistemas difíceis de simular de forma convincente: buffering de entrada, transições de estado de combate, seleção de alvos, movimento durante ataques, temporização de animações, deteção de impactos, reações de inimigos, janelas defensivas, comportamento da camera e feedback de impacto.

Isto cria uma distinção útil:

• a temporização da animação não é a temporização do combate;
• a taxa de renderização não é a taxa de simulação;
• uma colisão não é automaticamente um impacto válido;
• a animação não é necessariamente a autoridade sobre o movimento;
• o contacto visual não é a mesma coisa que o impacto percebido.

Estas distinções apareceram repetidamente nos projetos mais sólidos e são mais importantes do que o logótipo do renderer no README.

Voxel Musou: o combate no navegador pode ter uma verdadeira gramática de movimentos

Voxel Musou foi um dos exemplos mais claros de que o combate no navegador já não precisa de significar uma animação de ataque associada a um único botão. O código-fonte está disponível em mike007jd/voxel-musou.

O projeto utiliza longas cadeias de ataques normais e ramificações de ataques carregados, em vez de um combo puramente linear. Isto é importante do ponto de vista da arquitetura porque o sistema pode ser modelado assim:

current move + buffered input + combat state -> next move

Esta é uma base muito melhor para um jogo de ação centrado em personagens do que uma coleção crescente de condicionais para casos especiais. Também demonstra ataques aéreos, sequências especiais, vários kits de personagens, comportamento de chefes, hit-stop e combate contra grandes grupos de inimigos.

A lição de engenharia mais geral é que os movimentos devem tornar-se dados e as transições devem tornar-se explícitas. Quando isso acontece, adicionar outra personagem deixa de exigir a reescrita de todo o controlador de combate.

Long Wind: a referência mais próxima de um jogo de ação moderno no navegador

Long Wind foi uma das referências mais completas porque combina movimento na terceira pessoa com ataques leves e pesados, fixação de alvo, guarda, parry perfeito, invulnerabilidade durante a evasão, pressão de postura, execuções, reações de lançamento e derrube, projéteis, chefes e vários arquétipos de inimigos. O código-fonte está disponível em jbang2004/long-wind.

O seu valor não vem de cada funcionalidade individual ser inédita, mas de todas coexistirem num único protótipo de ação nativo do navegador. Isso torna-o uma referência útil para seguir todo o percurso desde a entrada e a seleção de alvo até ao estado de ataque, animação, contacto, reação, hit-stop e feedback da camera.

O motion warping resolve um problema que as demos web muitas vezes ignoram

Samurai Third-Person Template ThreeJS é particularmente interessante porque aborda um problema clássico do combate corpo a corpo na terceira pessoa. O código-fonte está disponível em achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

Uma animação de ataque criada previamente pressupõe que o alvo estará a uma determinada distância quando o golpe chegar ao fotograma de contacto. Num jogo real, o alvo quase nunca está perfeitamente posicionado. Se a personagem simplesmente reproduzir a animação no mesmo lugar, a espada pode falhar visualmente mesmo que o jogo aplique dano. Se a personagem for teletransportada para a posição correta, o ataque parece artificial.

O motion warping oferece uma resposta melhor: ajustar a rotação e a translação durante o ataque para que a personagem chegue à posição de contacto esperada no momento correto.

A distinção importante é:

animation intent != movement authority

Uma personagem pode preservar a intenção visual de uma animação criada previamente enquanto o controlador de jogo continua a ter autoridade sobre o local para onde a personagem realmente se desloca.

A deteção de colisões e a validação de impactos são problemas diferentes

Stick & Steel explora um modelo de combate muito diferente. O código-fonte está disponível em Rabneba/stick-steel.

Em vez de tratar a espada principalmente como uma animação com um volume de dano, o projeto dá presença física às armas. A velocidade de contacto, a orientação da arma, a região do corpo, as guardas, os choques, os derrubes e os desarmes são todos relevantes.

A lição mais transferível não é que todos os jogos de ação devam utilizar armas totalmente físicas. É esta:

Uma colisão indica que duas coisas se tocaram. Não indica se ocorreu um impacto significativo.

Um sistema de combate convincente precisa muitas vezes de uma segunda camada que decida se o contacto teve velocidade suficiente, a direção correta, a região correta da arma, o momento correto e um estado válido do alvo para contar como dano.

A resolução centralizada do combate facilita o raciocínio sobre defesas complexas

Hollowmere, com código-fonte em euuuuuuan/hollowmere-public, destacou-se menos pelo espetáculo visual e mais pela arquitetura de software.

A sua simulação de combate está separada da renderização e a resolução defensiva é centralizada. Isto evita um modo de falha comum em jogos de ação, no qual o sistema de evasão, o sistema de parry, o sistema de reação a impactos e a camada de animação podem discordar de forma independente sobre se o mesmo ataque acertou.

Um modelo mental mais limpo é:

incoming attack -> evade | parry | hit

O renderer deve mostrar o resultado, e não inventar uma segunda versão da verdade do combate.

Esta distinção torna-se cada vez mais importante à medida que o combate cresce. A simulação determinista e as transições de estado explícitas não são funcionalidades vistosas, mas tornam sistemas de combate complexos mais fáceis de testar, depurar e ampliar.

A sensação de jogo é um sistema de engenharia, não decoração

Fabled Revolutions, com código-fonte em ericrius1/FabledRevolutions, é útil precisamente porque isola os efeitos que fazem os impactos parecerem substanciais.

Um sistema de combate logicamente correto pode continuar a parecer fraco. A colisão pode ser precisa, o dano pode ser aplicado no fotograma correto e, mesmo assim, o resultado pode parecer dois modelos a atravessarem-se.

O impacto percebido surge muitas vezes de uma combinação de efeitos de curta duração:

• hit-stop;
• movimento brusco ou impulso da camera;
• rastos das armas;
• partículas de impacto;
• clarão ao sofrer dano;
• recuo;
• reação de animação;
• som bem sincronizado.

Isto sugere outra distinção útil: a correção do combate não é a mesma coisa que a sensação do combate. Um jogo no navegador precisa das duas.

O renderer não foi o principal indicador da qualidade do combate

Um dos padrões mais interessantes da investigação foi que o melhor combate não era determinado pelo uso da API de renderização mais recente.

Three.js apareceu repetidamente. Alguns projetos utilizavam tecnologia de renderização relacionada com WebGPU; outros utilizavam stacks convencionais baseados em WebGL. Ao longo da investigação apareceram motores de física, TypeScript, JavaScript, Vite, WebAssembly e diferentes abordagens de renderização.

Mas o combate sofisticado dependia de forma mais consistente da arquitetura: simulação com passo fixo, estados explícitos, seleção de alvo fiável, autoridade de animação bem definida, movimentos orientados por dados, resolução de dano centralizada e bom feedback de impacto.

Isto é encorajador para quem desenvolve para a web. Não é necessário esperar que todas as pessoas tenham o stack gráfico mais recente antes de experimentar um design de combate sério.

Porque a distribuição pelo navegador muda a equação

O navegador tem uma vantagem que pouco tem a ver com gráficos: uma fricção de distribuição extremamente baixa.

Os jogos tradicionais colocam muitas vezes vários passos entre a descoberta e a interação: encontrar a página da loja, fazer o download de um pacote grande, instalá-lo, iniciá-lo, esperar por atualizações e, por vezes, criar uma conta antes de chegar a uma experiência de jogo significativa.

Um jogo no navegador pode reduzir esse percurso a um link.

Isto muda a forma como os protótipos podem ser disponibilizados e testados. É possível publicar uma build, enviar uma URL, colocar outra pessoa imediatamente na mesma versão, obter feedback e fazer deploy de outra iteração sem pedir a quem testa que instale manualmente um novo pacote.

Esta vantagem torna-se particularmente importante para jogos experimentais e desenvolvimento independente. O navegador não é apenas um ambiente de execução; é também um sistema de distribuição.

Onde o navegador ainda fica atrás

A investigação não me convenceu de que os navegadores tenham substituído as plataformas de jogos nativas. Não substituíram.

Continuam a existir várias limitações importantes:

• Grandes volumes de recursos. O acesso imediato deixa de parecer imediato quando um jogo exige um download inicial muito grande.
• Pressão de memória. Os navegadores têm de coexistir com outras páginas abertas e com o sistema operativo, e o comportamento da memória é menos previsível do que num processo nativo dedicado.
• Limites térmicos em dispositivos móveis. Um jogo 3D tecnicamente funcional pode ainda sofrer uma redução acentuada de desempenho durante uma sessão mais longa.
• Diferenças entre navegadores. Gráficos, áudio, pointer lock, fullscreen, gamepads e características de desempenho não são perfeitamente uniformes.
• Preparação de shaders e recursos. O trabalho de compilação ou upload ainda pode provocar pausas visíveis se o pipeline não for concebido com cuidado.
• Limitações de uso offline e persistência local. As aplicações nativas mantêm uma gestão mais direta de grandes instalações locais e arquivos.
• Segurança competitiva. Um sistema anti-cheat sério e pressupostos de cliente hostil tornam-se muito mais difíceis quando o cliente é uma aplicação web.

Estas limitações importam porque definem onde os jogos no navegador são hoje mais fortes: jogos que beneficiam de acesso imediato, iteração rápida, distribuição multiplataforma e orçamentos de recursos e execução que se mantêm geríveis.

A IA encurta muito o ciclo entre protótipo e URL

A IA é relevante aqui, mas não porque transforme magicamente uma frase num jogo acabado e de alta qualidade. A vantagem mais realista é a velocidade de iteração.

O desenvolvimento moderno de jogos contém muitas tarefas pequenas que, no conjunto, são dispendiosas: configurar máquinas de estados, criar vistas de depuração, escrever testes, experimentar comportamentos de inimigos, criar formatos de dados para movimentos, refatorar código de entrada, prototipar shaders, analisar erros de física e ligar conteúdo temporário.

A IA pode encurtar muitos desses ciclos. Combinada com a distribuição web, o fluxo de trabalho torna-se invulgarmente direto:

idea -> prototype -> deploy -> open URL -> test -> iterate

O navegador já torna o deploy rápido. A IA também pode acelerar a parte de implementação do mesmo ciclo.

A ressalva importante é que a geração rápida não substitui o critério nem a validação. Um controlador de combate gerado pode estar estruturalmente errado. A temporização da animação continua a exigir julgamento humano. A física continua a precisar de depuração. O desempenho continua a precisar de medição. A IA reduz o custo de experimentar ideias; não elimina a necessidade de decidir quais são boas.

O que isto significa para quem desenvolve para a web

A fronteira entre desenvolvimento web e desenvolvimento de jogos está a tornar-se menos rígida.

Um jogo sério no navegador pode agora utilizar ferramentas web familiares e, ao mesmo tempo, exigir conceitos clássicos de engenharia de jogos:

• passos fixos de simulação;
• máquinas de estados;
• buffering de entrada;
• grafos de animação;
• consultas espaciais;
• física;
• orçamentos por fotograma;
• gestão de recursos da GPU;
• temporização de áudio;
• sistemas deterministas.

Ao mesmo tempo, quem desenvolve jogos para o navegador ganha coisas em que a web já é excecionalmente boa: URLs, deploy imediato, distribuição por CDN, atualizações rápidas, telemetria, sistemas de contas, interfaces responsivas e partilha sem fricção.

A investigação mudou o meu próprio modelo mental. Já não vejo os jogos no navegador principalmente como versões simplificadas de jogos nativos. Vejo o navegador como uma plataforma de jogos cada vez mais capaz, com um conjunto diferente de vantagens: distribuição imediata, iteração rápida, capacidades 3D cada vez mais sérias e um enorme ecossistema de desenvolvimento já existente.

A web não está apenas a melhorar na apresentação de jogos criados noutros ambientes. Está cada vez mais a tornar-se um lugar onde sistemas de jogo sérios podem ser concebidos, implementados, testados, distribuídos e jogados diretamente.