Editor de juegos estilo Unity que corre en WASM puro

 (raverie-us.github.io)
2 puntos por GN⁺ 2023-09-27 | 1 comentarios | Compartir por WhatsApp
  • Motor de juegos ligero que busca revivir la experiencia del antiguo Macromedia/Adobe Flash
  • Diseñado para funcionar en todas las plataformas, con WASM puro como único objetivo de salida
  • La salida no incluye ejecutables ni código glue, y no usa Emscripten
  • La lista de imports y exports está claramente definida en PlatformCommunication.hpp
  • Estructura fácil de implementar en cualquier plataforma, incluido el navegador

Descripción general

  • Motor de juegos ligero (light-weight) cuyo objetivo es recrear la experiencia del antiguo Macromedia/Adobe Flash

Arquitectura

  • Fue creado para ejecutarse en cualquier plataforma y tiene como único objetivo de salida WASM puro
  • La salida no incluye ejecutables ni código glue, y no utiliza Emscripten
  • La lista de imports y exports está definida de forma clara en PlatformCommunication.hpp, lo que permite implementarlo fácilmente en cualquier plataforma, incluido el navegador

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-27
Opiniones en Hacker News

  • ¡Wow, son quienes hicieron Zero Engine! Lo usé hace mucho en un campamento de verano de DigiPen, y programar en Zilch era realmente divertido.
    También hice una IA que jugaba un clon de Galaga. Con todo este asunto de Unity me preguntaba qué habría pasado con Zero, y me emociona mucho que parezca que va a revivir.

    • ¡Qué bueno! Zilch era algo que desarrollé con mucho cariño, así que me alegra muchísimo que digas eso :D

  • Como dato adicional: en una laptop claramente de gama baja con gráficos integrados, funciona como otra gran presentación de diapositivas.
    También lo probé en un viejo Mate 20 Pro y parecía quedarse trabado en “Downloading runtime”. No creo que fuera por el 4G inestable, así que abrí chrome://inspect en la laptop por USB para revisar la pestaña, y apareció el error Uncaught (in promise) Error: Needs OES_texture_float_linear to function. Aunque termina siendo una pregunta filosófica si vale la pena crear una pantalla de error solo para mostrar el mensaje de que, de todos modos, no vas a poder jugar con eso.

  • Me gusta el concepto. Pero mi GPU y mi navegador están llorando por la latencia, y se ve como una presentación de diapositivas impresionante.
    Después de varios intentos, apenas pude seleccionar la esfera inicial. Al principio ni siquiera estaba seguro de si ya había terminado de cargar. Claro que estoy usando Firefox en un Celeron de 1.8 GHz, GPU integrada y 8 GB de RAM, así que estoy lejos de tener una máquina potente.

    • Me pregunto si en Chrome funciona mejor. Parece que bastante gente está teniendo problemas con Firefox. En adelante también vamos a probar Firefox de forma regular.
    • Si puedes intentarlo de nuevo, acaban de desplegar una corrección que mejora mucho el rendimiento en algunas máquinas.
      Como es un motor de juegos nativo portado a WASM, el problema estaba en el código de limitación de tasa de cuadros, que no encajaba bien con las API de temporización del navegador: https://raverie-us.github.io/raverie-engine/
    • Tuve exactamente la misma experiencia en un M2 Pro, y yo también estaba usando Firefox.
    • ¿Todavía fabrican Celeron?

  • La parte de “nuestro motor tenía una función única llamada Spaces, y podía instanciar mundos/niveles separados” me parece exactamente lo mismo que hace el motor Godot[1].
    Ese motor también tiene un target para navegador (WASM). [1]: https://godotengine.org/

    • No solo tiene target WASM, también tiene versión web: https://editor.godotengine.org/
      No parece ser una prioridad alta para el proyecto. Lo probé un poco y parece funcionar :), aunque es más lento que ejecutarlo de forma nativa.
    • Tampoco tengo muy claro en qué se diferencia de las escenas de Unity.

  • Me pregunto si existe un flujo de desarrollo WASM que permita que las Web API del navegador y WASM puro interactúen sin una capa de JS, o con bajo costo.
    A veces miro https://github.com/WebAssembly/proposals y es muy confuso. La propuesta de importación de tipos parece estar a años de distancia, y la propuesta de GC, que está casi lista, parece ser para lenguajes con GC, no para navegador↔WASM. El modelo de componentes parece estar lejos de los casos de uso del navegador, y JS String Builtins acelera las cadenas de JS, pero no el DOM. La integración con módulos ECMAScript convierte los módulos WASM en módulos ES, pero las Web API no son módulos ES, así que no ayuda. Al ver las conversaciones de los contribuidores, a veces parece que ofrecer esta capacidad no es una prioridad ni está en los planes, y para la mayoría parecen ser más importantes WASI y el modelo de componentes para usos como la nube y la criptografía.

    • Yo también quiero mucho esto. Me gustaría ver un navegador wasm puro donde la página sea simplemente WASM y el “navegador” proporcione imports de plataforma como WASI.
      Pero, como dices, no parece ser una prioridad para ellos. Ojalá algún día sea posible.
    • Gracias a los tipos de referencia (reference types), técnicamente ya se pueden llamar directamente las API del navegador. Eso es porque WASM puede enviar y recibir objetos de JavaScript.
      Si se importan todas las Web API relevantes, podrías pasar objetos JS tal cual entre llamadas individuales de API, con muy poco JS intermedio. En la práctica, el JS solo sería necesario más o menos al inicializar el módulo WASM por primera vez.
    • El problema de WASM puro es que puede llevar a una web cerrada con anuncios imposibles de bloquear.
    • Creo que, al menos en parte, esa es la dirección a la que apunta la propuesta de GC.

  • Gran proyecto. ¿Hay alguna forma de ampliar la UI en pantallas de alta resolución?
    En una pantalla 2:1, la fuente se ve pixelada. Si pongo el zoom del navegador en 50%, la UI se ve nítida, pero todo queda demasiado pequeño y es difícil de usar.

    • Para el OP: la forma de arreglarlo es establecer el ancho del canvas en window.innerWidth * window.devicePixelRatio y el alto en window.innerHeight * window.devicePixelRatio.
      Después, con CSS, maximizas el canvas en la pantalla.
    • No entiendo por qué no usan el motor de renderizado nativo del navegador para la UI, o al menos SVG.
      Sería más barato en recursos (memoria, red, CPU), más fácil de hacer accesible y también más fácil de renderizar.

  • ¡Trevor! Me encantaba la optativa de CS en DigiPen donde veíamos diseño de lenguajes de programación a través de la gramática.
    Muchos de los estudiantes a los que enseñaste ahora trabajan en Minecraft. Mientras diseño la API de scripting de Minecraft, estoy usando las bases que aprendí entonces y muchas cosas de mi época en DigiPen. Me alegra ver que sigues haciendo cosas geniales.

    • ¡Me alegra mucho saber que te sirvió! Algún día volveré a dar clases ;)
      También me encantaría ver la interfaz de scripting en la que estás trabajando. Antes hice muchísimos mods de Minecraft, y siempre quise alguna forma de scripting dinámico.

  • Realmente genial. Me alegra ver un producto basado en WASM puro en este campo. Aunque en mi M1 Mac Pro va bastante entrecortado.

  • Tengo una pregunta: ¿esto también corre en un NES? Es un modelo frontal reacondicionado, con la mayoría de las piezas originales, pero le agregué un poco más de RAM.
    La pegué arriba con silicón caliente, pinté la carcasa de rojo y le puse unos soldaditos de juguete.

    • ¿Por qué hacer un convertidor de WASM > NES suena como algo que de verdad sería divertido…?

  • Incluso mostrando solo la escena básica de la pelota, golpea durísimo la GPU en una Radeon Pro 560X y un entorno casi 4K.
    Solo rotar la cámara hace que la tasa de cuadros baje muchísimo. ¿Alguien sabe si puede haber un problema de optimización de WebGL?

    • En mi Intel HD Graphics 620 funciona muy fluido. Es una gráfica integrada Intel de 7.ª generación, así que es vieja y lenta, pero me sorprendió lo bien que va en el sistema solo con la escena básica de la pelota. Estoy usando Chrome.
    • Si puedes intentarlo de nuevo, acaban de desplegar una corrección que mejora mucho el rendimiento en algunas máquinas.
      Como es un motor de juegos nativo portado a WASM, el problema estaba en el código de limitación de tasa de cuadros, que no encajaba bien con las API de temporización del navegador: https://raverie-us.github.io/raverie-engine/
    • También suena a que quizá no está usando la tarjeta gráfica dedicada. ¿Otras demos de WebGL funcionan normalmente?