Unity-artiger Spiele-Editor, der in reinem WASM läuft

 (raverie-us.github.io)
2 Punkte von GN⁺ 2023-09-27 | 1 Kommentare | Auf WhatsApp teilen
  • Eine leichtgewichtige Game-Engine, die darauf abzielt, das frühere Erlebnis von Macromedia/Adobe Flash wieder aufleben zu lassen
  • Entwickelt für den Betrieb auf allen Plattformen; einziges Ausgabeziel ist reines WASM
  • Die Ausgabe enthält keine ausführbare Datei, keinen Glue Code o. Ä.; Emscripten wird nicht verwendet
  • Die Liste der Imports und Exports ist klar in PlatformCommunication.hpp definiert
  • Eine Struktur, die sich auf jeder Plattform, einschließlich Browsern, einfach implementieren lässt

Überblick

  • Eine leichtgewichtige (light-weight) Game-Engine, die darauf abzielt, das frühere Erlebnis von Macromedia/Adobe Flash nachzubilden

Architektur

  • Entwickelt für die Ausführung auf jeder Plattform; als einziges Ausgabeziel ist reines WASM vorgesehen
  • Die Ausgabe enthält keine ausführbare Datei, keinen Glue Code o. Ä.; Emscripten wird nicht verwendet
  • Die Liste der Imports und Exports ist sauber in PlatformCommunication.hpp definiert und lässt sich dadurch auf jeder Plattform, einschließlich Browsern, leicht implementieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-27
Hacker-News-Kommentare

  • Wow, das sind doch die Leute, die Zero Engine gemacht haben? Ich habe sie vor langer Zeit in einem DigiPen-Sommercamp benutzt, und das Programmieren mit Zilch hat wirklich Spaß gemacht.
    Ich habe sogar eine KI gebaut, die einen Galaga-Klon spielt. Wegen der aktuellen Unity-Sache habe ich mich gefragt, was wohl aus Zero geworden ist, und freue mich sehr darauf, dass es offenbar wiederbelebt wird.

    • Cool! Zilch war etwas, das ich mit viel Herzblut gebaut habe, daher freut es mich wirklich, das zu hören :D

  • Nur als Zusatzinfo: Auf einem eindeutig schwachen Notebook mit integrierter Grafik läuft es wie eine weitere tolle Diashow.
    Ich habe es auch auf einem alten Mate 20 Pro ausprobiert, dort sah es so aus, als bliebe es bei „Downloading runtime“ hängen. Es schien nicht am wackligen 4G zu liegen; ich habe per USB auf dem Notebook chrome://inspect geöffnet und den Tab überprüft, dort kam der Fehler Uncaught (in promise) Error: Needs OES_texture_float_linear to function. Das wird dann zur philosophischen Frage, ob es sich lohnt, einen Fehlerbildschirm zu bauen, nur um anzuzeigen, dass man ohnehin nicht damit herumspielen kann.

  • Das Konzept gefällt mir. Allerdings weinen meine GPU und mein Browser wegen der Latenz, und es sieht aus wie eine beeindruckende Diashow.
    Nach ein paar Versuchen konnte ich endlich die Startkugel auswählen. Anfangs war ich mir nicht einmal sicher, ob das Laden abgeschlossen war. Natürlich nutze ich Firefox auf einem 1,8-GHz-Celeron mit integrierter GPU und 8 GB RAM, also weit weg von High-End.

    • Ich frage mich, ob es in Chrome besser läuft. Offenbar haben ziemlich viele Leute Firefox-Probleme. Ich werde Firefox künftig auch regelmäßig testen.
    • Falls du es noch einmal versuchen kannst: Es wurde gerade ein Fix ausgerollt, der die Performance auf manchen Maschinen deutlich verbessert.
      Da es sich um eine Portierung einer nativen Game Engine nach WASM handelt, lag das Problem im Code zur Begrenzung der Framerate, der nicht gut zu den Timing-APIs des Browsers passte: https://raverie-us.github.io/raverie-engine/
    • Ich hatte auf einem M2 Pro exakt dieselbe Erfahrung, und bei mir war es auch Firefox.
    • Wird Celeron immer noch hergestellt?

  • Die Stelle „Unsere Engine hatte ein einzigartiges Feature namens Spaces, mit dem man separate Welten/Level instanziieren konnte“ wirkt für mich exakt wie das, was die Godot-Engine macht[1].
    Diese Engine hat ebenfalls ein Browser-Ziel (WASM). [1]: https://godotengine.org/

    • Sie hat nicht nur ein WASM-Target, sondern auch eine Web-Version: https://editor.godotengine.org/
      Im Projekt scheint das keine hohe Priorität zu haben. Nach kurzem Testen scheint es zu funktionieren :), ist aber langsamer als die native Ausführung.
    • Mir ist auch nicht ganz klar, wie sich das von Unitys Scenes unterscheidet.

  • Ich frage mich, ob es einen WASM-Entwicklungsflow gibt, der es den Web APIs des Browsers und purem WASM erlaubt, ohne JS-Schicht oder mit geringen Kosten zu interagieren.
    Ich schaue gelegentlich auf https://github.com/WebAssembly/proposals und finde es sehr verwirrend. Der Type-Imports-Vorschlag scheint noch Jahre entfernt zu sein, und der fast abgeschlossene GC-Vorschlag ist wohl eher für GC-Sprachen gedacht, nicht für Browser↔WASM. Das Component Model wirkt weit von Browser-Use-Cases entfernt, und JS String Builtins machen JS-Strings schneller, aber nicht das DOM. Die ECMAScript-Modulintegration macht WASM-Module zu ES-Modulen, aber Web APIs sind keine ES-Module, daher hilft das nicht. Wenn man die Gespräche der Mitwirkenden verfolgt, wirkt es manchmal so, als sei die Bereitstellung solcher Funktionen weder priorisiert noch geplant; für die meisten scheinen WASI und das Component Model für Dinge wie Cloud und Kryptografie wichtiger zu sein.

    • Das wünsche ich mir auch wirklich. Ich würde gern einen reinen wasm-Browser sehen, bei dem die Seite einfach WASM ist und der „Browser“ Plattform-Imports wie WASI bereitstellt.
      Aber wie gesagt, für sie scheint das keine Priorität zu haben. Hoffentlich wird es irgendwann möglich.
    • Dank Reference Types kann man Browser-APIs technisch gesehen schon direkt aufrufen, weil WASM JavaScript-Objekte übergeben und empfangen kann.
      Wenn man alle relevanten Web APIs importiert, kann man JS-Objekte zwischen einzelnen API-Aufrufen unverändert weiterreichen, sodass kaum Zwischen-JS nötig wäre. Wirklich gebraucht wird JS im Grunde nur beim initialen Starten des WASM-Moduls.
    • Das Problem mit purem WASM ist, dass es zu einem geschlossenen Web mit nicht blockierbarer Werbung führen könnte.
    • Zumindest ein Teil davon ist meiner Ansicht nach die Richtung, in die der GC-Vorschlag zielt.

  • Tolles Projekt. Gibt es eine Möglichkeit, die UI auf einem hochauflösenden Display zu skalieren?
    Auf einem 2:1-Display wirkt die Schrift kantig. Wenn ich den Browser-Zoom auf 50 % setze, wird die UI scharf, aber alles ist dann viel zu klein, um sie gut zu benutzen.

    • An OP: Der Fix besteht darin, die Canvas-Breite auf window.innerWidth * window.devicePixelRatio und die Höhe auf window.innerHeight * window.devicePixelRatio zu setzen.
      Danach kann man das Canvas per CSS auf den Bildschirm maximieren.
    • Ich verstehe nicht, warum für die UI nicht die native Rendering-Engine des Browsers genutzt wird, oder zumindest SVG.
      Das wäre bei Ressourcen (Speicher, Netzwerk, CPU) günstiger, Barrierefreiheit ließe sich leichter umsetzen, und das Rendering wäre ebenfalls einfacher.

  • Trevor! Ich habe das CS-Wahlfach bei DigiPen, in dem es anhand von Grammatik um Programmiersprachen-Design ging, wirklich geliebt.
    Viele der Studierenden, die du unterrichtet hast, arbeiten heute an Minecraft. Beim Entwurf der aktuellen Minecraft Scripting API nutze ich die Grundlagen von damals und vieles aus meiner DigiPen-Zeit. Schön zu sehen, dass du immer noch so coole Sachen machst.

    • Es freut mich sehr, dass es hilfreich war! Irgendwann werde ich sicher wieder unterrichten ;)
      Die Scripting-Schnittstelle, an der du arbeitest, würde ich unbedingt gern sehen. Früher habe ich wirklich viele Minecraft-Mods gebaut und wollte immer irgendeine Form von dynamischem Scripting haben.

  • Wirklich cool. Schön, in diesem Bereich ein Produkt auf Basis von purem WASM zu sehen. Auf meinem M1 Mac Pro ruckelt es allerdings ziemlich.

  • Eine Frage: Läuft das auch auf dem NES? Es ist ein refurbishtes Frontloader-Modell, die Teile sind größtenteils original, aber ich habe etwas mehr RAM angebaut.
    Den habe ich oben mit Heißkleber befestigt, außerdem das Gehäuse rot lackiert und ein paar Spielzeugsoldaten drangemacht.

    • Warum klingt es eigentlich tatsächlich spaßig, einen WASM-zu-NES-Transpiler zu bauen …

  • Schon die Standard-Kugel-Szene belastet meine Radeon Pro 560X in einer Umgebung nahe 4K extrem stark.
    Allein das Drehen der Kamera senkt die Framerate stark. Weiß jemand, ob es hier ein WebGL-Optimierungsproblem geben könnte?

    • Auf meiner Intel HD Graphics 620 läuft es sehr flüssig. Das ist integrierte Intel-Grafik der 7. Generation, also alt und eher langsam, aber allein mit der Standard-Kugel-Szene lief es auf meinem System überraschend geschmeidig. Ich nutze Chrome.
    • Falls du es noch einmal versuchen kannst: Es wurde gerade ein Fix ausgerollt, der die Performance auf manchen Maschinen deutlich verbessert.
      Da es sich um eine Portierung einer nativen Game Engine nach WASM handelt, lag das Problem im Code zur Begrenzung der Framerate, der nicht gut zu den Timing-APIs des Browsers passte: https://raverie-us.github.io/raverie-engine/
    • Es klingt auch so, als würde die dedizierte Grafikkarte nicht genutzt. Laufen andere WebGL-Demos normal?