Editor de jogos estilo Unity executado em WASM puro

 (raverie-us.github.io)
2 pontos por GN⁺ 2023-09-27 | 1 comentários | Compartilhar no WhatsApp
  • Motor de jogos leve com o objetivo de reviver a experiência do antigo Macromedia/Adobe Flash
  • Projetado para funcionar em todas as plataformas, tendo WASM puro como único alvo de saída
  • O resultado gerado não inclui executáveis nem código glue, e não usa Emscripten
  • A lista de imports e exports está claramente definida em PlatformCommunication.hpp
  • Estrutura fácil de implementar em qualquer plataforma, incluindo navegadores

Visão geral

  • Um motor de jogos leve (light-weight) que busca recriar a experiência do antigo Macromedia/Adobe Flash

Arquitetura

  • Foi criado para rodar em qualquer plataforma e tem WASM puro como único alvo de saída
  • O resultado gerado não inclui executáveis nem código glue, e não utiliza Emscripten
  • A lista de imports e exports está organizada de forma clara em PlatformCommunication.hpp, permitindo implementação fácil em qualquer plataforma, incluindo navegadores

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-27
Comentários no Hacker News

  • Uau, são as pessoas que criaram o Zero Engine? Usei há muito tempo em um acampamento de verão da DigiPen, e programar em Zilch era muito divertido
    Também criei uma IA que jogava um clone de Galaga. Com essa situação toda da Unity, eu estava curioso para saber o que tinha acontecido com o Zero, então estou bem animado com a possibilidade de ele voltar

    • Que legal! Zilch era algo que eu criava com muito carinho, então fico muito feliz em ouvir isso :D

  • Só para acrescentar uma observação: em um notebook definitivamente de baixo desempenho com gráficos integrados, ele se comporta como mais uma bela apresentação de slides
    Também testei em um Mate 20 Pro antigo e parecia travado em “Downloading runtime”. Não acho que fosse culpa do 4G instável, então conectei por USB ao notebook, abri chrome://inspect e verifiquei a aba; apareceu o erro Uncaught (in promise) Error: Needs OES_texture_float_linear to function. Acaba virando uma questão filosófica se vale a pena criar uma tela de erro só para mostrar a mensagem de que, de todo modo, você não vai conseguir brincar com isso

  • Gosto do conceito. Mas minha GPU e meu navegador estão chorando por causa da latência, e parece uma apresentação de slides impressionante
    Depois de algumas tentativas, finalmente consegui selecionar a esfera inicial. No começo, eu nem tinha certeza se o carregamento tinha terminado. Claro que estou usando Firefox em um Celeron de 1,8 GHz, GPU integrada e 8 GB de RAM, então está longe de ser uma máquina potente

    • Fico curioso para saber se roda melhor no Chrome. Parece que bastante gente está tendo problemas no Firefox. Daqui para frente, vou testar regularmente no Firefox também
    • Se você puder tentar de novo, uma correção que melhora bastante o desempenho em algumas máquinas acabou de ser publicada
      Como se trata de um porte de um motor de jogo nativo para WASM, o problema estava no código de limitação de taxa de quadros, que não se dava bem com as APIs de temporização do navegador: https://raverie-us.github.io/raverie-engine/
    • Tive exatamente a mesma experiência em um M2 Pro, e eu também estava no Firefox
    • Ainda fabricam Celeron?

  • A parte “nosso engine tinha um recurso único chamado Spaces, que permitia instanciar mundos/níveis separados” me parece exatamente o que o engine Godot faz[1]
    Esse engine também tem um alvo para navegador (WASM). [1]: https://godotengine.org/

    • Além de ter um alvo WASM, também há uma versão web: https://editor.godotengine.org/
      Não parece ser uma prioridade alta no projeto. Testei um pouco e parece funcionar :), mas é mais lento do que rodar nativamente
    • Também não entendo muito bem como isso difere das cenas da Unity

  • Fico me perguntando se existe um fluxo de desenvolvimento WASM que permita que as Web APIs do navegador e o WASM puro interajam sem uma camada JS, ou com baixo custo
    Às vezes olho https://github.com/WebAssembly/proposals e é muito confuso. A proposta de importação de tipos parece estar a anos de distância; a proposta de GC, quase concluída, parece ser para linguagens com GC, não para navegador↔WASM. O modelo de componentes parece distante dos casos de uso no navegador, e JS String Builtins acelera strings JS, mas não o DOM. A integração com módulos ECMAScript transforma módulos WASM em módulos ES, mas as Web APIs não são módulos ES, então isso não ajuda. Ao acompanhar conversas dos contribuidores, às vezes parece que fornecer esse tipo de recurso não é prioridade nem está nos planos; para a maioria, WASI e o modelo de componentes para usos como nuvem e criptografia parecem mais importantes

    • Eu também quero muito isso. Gostaria de ver um navegador wasm puro em que a página fosse simplesmente WASM e o “navegador” fornecesse imports de plataforma como o WASI
      Mas, como você disse, isso não parece ser prioridade para eles. Espero que um dia seja possível
    • Graças aos tipos de referência (reference types), tecnicamente já é possível chamar APIs do navegador diretamente. Isso porque o WASM consegue passar objetos JavaScript de um lado para o outro
      Se você importar todas as Web APIs relevantes, pode passar objetos JS diretamente entre chamadas individuais de API, então talvez quase não precise de JS intermediário. Na prática, JS só é necessário mais ou menos na hora de inicializar o módulo WASM pela primeira vez
    • O problema do WASM puro é que ele pode levar a uma web fechada com anúncios impossíveis de bloquear
    • Acho que ao menos parte disso é a direção para a qual a proposta de GC aponta

  • Projeto excelente. Há alguma forma de ampliar a UI em telas de alta resolução?
    Em uma tela 2:1, as fontes ficam serrilhadas. Se eu ajusto o zoom do navegador para 50%, a UI fica nítida, mas tudo fica pequeno demais para usar

    • Para o OP: a forma de corrigir é definir a largura do canvas como window.innerWidth * window.devicePixelRatio e a altura como window.innerHeight * window.devicePixelRatio
      Depois é só maximizar o canvas na tela via CSS
    • Não entendo por que não usar o motor de renderização nativo do navegador para a UI, ou pelo menos SVG
      Seria mais barato em termos de recursos (memória, rede, CPU), mais fácil de tornar acessível e mais fácil de renderizar

  • Trevor! Eu adorava a optativa de CS na DigiPen que tratava de design de linguagens de programação por meio de gramáticas
    Muitos dos alunos que você ensinou agora trabalham no Minecraft. Ao projetar a API de scripting do Minecraft hoje, estou usando os fundamentos que aprendi naquela época e muita coisa do período na DigiPen. Fico feliz em ver que você ainda está fazendo coisas legais

    • Fico muito feliz que tenha sido útil! Algum dia vou voltar a dar aulas ;)
      Também adoraria ver a interface de scripting em que você está trabalhando. Antigamente eu criava muitos mods para Minecraft e sempre quis algum tipo de scripting dinâmico

  • Muito legal. É bom ver um produto baseado em WASM puro nessa área. Dito isso, no meu M1 Mac Pro ele engasga bastante

  • Tenho uma pergunta: isso roda em um NES? É um modelo front-loader recondicionado, com a maioria das peças originais, mas adicionei um pouco mais de RAM
    Colei por cima com cola quente, pintei o gabinete de vermelho e prendi alguns bonequinhos de soldados nele

    • Por que fazer um conversor de WASM > NES parece algo realmente divertido…

  • Mesmo abrindo só a cena padrão da bola, ele força muito a GPU em um ambiente quase 4K com uma Radeon Pro 560X
    Só de girar a câmera, a taxa de quadros fica muito baixa. Alguém sabe se pode haver algum problema de otimização em WebGL?

    • Na minha Intel HD Graphics 620, roda muito suavemente. É uma GPU integrada Intel de 7ª geração, então é antiga e meio lenta, mas fiquei surpreso com o quanto ficou fluido no meu sistema só com a cena padrão da bola. Estou usando Chrome
    • Se você puder tentar de novo, uma correção que melhora bastante o desempenho em algumas máquinas acabou de ser publicada
      Como se trata de um porte de um motor de jogo nativo para WASM, o problema estava no código de limitação de taxa de quadros, que não se dava bem com as APIs de temporização do navegador: https://raverie-us.github.io/raverie-engine/
    • Também soa como se você não estivesse usando a placa de vídeo dedicada. Outras demos WebGL rodam normalmente?