純粋な WASM で動作する Unity 風ゲームエディタ

 (raverie-us.github.io)
2 ポイント 投稿者 GN⁺ 2023-09-27 | 1件のコメント | WhatsAppで共有
  • かつての Macromedia/Adobe Flash の体験をよみがえらせることを目指す軽量ゲームエンジン
  • あらゆるプラットフォームで動作するよう設計されており、唯一の出力ターゲットは 純粋な WASM
  • 出力物に実行ファイルやグルーコードなどは含まれず、Emscripten は未使用
  • import と export の一覧が PlatformCommunication.hpp に明確に定義されている
  • ブラウザを含むどのプラットフォームでも容易に実装できる構造

概要

  • **軽量（light-weight）**ゲームエンジンで、かつての Macromedia/Adobe Flash の体験を再現することを目指す

アーキテクチャ

  • どのプラットフォームでも実行できるよう作られており、唯一の出力ターゲットとして 純粋な WASM を目指す
  • 出力物に実行ファイルやグルーコードなどは含まれず、Emscripten を使用しない
  • import と export の一覧が PlatformCommunication.hpp にきれいに定義されており、ブラウザを含むどのプラットフォームでも簡単に実装可能

関連記事

1件のコメント

 
GN⁺ 2023-09-27
Hacker Newsのコメント

  • わあ、Zero Engineを作った方々なんですね？ ずいぶん前にDigiPenのサマーキャンプで使ったことがあり、Zilchでプログラミングするのが本当に楽しかったです
    GalagaクローンをプレイするAIも作りました。今回のUnity騒動でZeroはどうなったのか気になっていましたが、また復活しそうで本当に楽しみです

    • いいですね！ Zilchは私が大事に作っていたものなので、そう言ってもらえると本当にうれしいです :D

  • 参考までに付け加えると、内蔵グラフィックス搭載の明らかな低スペックノートPCでは、また別の見事なスライドショーのように動きます
    古いMate 20 Proでも試しましたが、「Downloading runtime」で止まったように見えました。不安定な4Gのせいではなさそうだったので、USBでノートPCからchrome://inspectを開いてタブを確認したところ、Uncaught (in promise) Error: Needs OES_texture_float_linear to functionというエラーが出ていました。どうせ遊べないというメッセージを表示するためにエラー画面を作る価値があるのか、という哲学的な問いにはなります

  • コンセプトは気に入っています。ただ、私のGPUとブラウザが遅延で泣いていて、印象的なスライドショーのように見えます
    何度か試した末に、ようやく開始時の球体を選択できました。最初はロードが終わったのかどうかも確信できませんでした。もちろん、Firefox上で1.8GHz Celeron、内蔵GPU、8GB RAMを使っているので、高スペックとはほど遠いのですが

    • Chromeではもう少しうまく動くのか気になります。かなり多くの人がFirefoxの問題を経験しているようです。今後はFirefoxも定期的にテストしてみます
    • もう一度試せるなら、一部のマシンで性能を大きく改善する修正が先ほどデプロイされました
      ネイティブのゲームエンジンをWASMに移植したものなので、問題はブラウザのタイミングAPIとうまく合っていなかったフレームレート制限コードにありました: https://raverie-us.github.io/raverie-engine/
    • M2 Proでもまったく同じ体験をしましたし、私もFirefoxでした
    • まだCeleronって作っているんですね？

  • 「私たちのエンジンにはSpacesという独自機能があり、別々のワールド／レベルをインスタンス化できた」という部分は、私にはGodotエンジンがやっていることとまったく同じに見えます[1]
    そのエンジンにもブラウザ（WASM）ターゲットがあります。 [1]: https://godotengine.org/

    • WASMターゲットがあるだけでなく、Web版もあります: https://editor.godotengine.org/
      プロジェクト内で優先度は高くなさそうです。少しテストしたところ動作はするようですが :)、ネイティブ実行より遅いです
    • Unityのシーンとどう違うのかもよく分かりません

  • ブラウザのWeb APIと純粋なWASMが、JSレイヤーなし、または低コストで相互作用できるようにするWASM開発フローがあるのか気になります
    ときどき https://github.com/WebAssembly/proposals を見ますが、非常に混乱します。型インポート提案は何年も先に見えますし、ほぼ完了しているGC提案はGC言語向けであって、ブラウザ↔WASM向けではなさそうです。コンポーネントモデルはブラウザ用途からは遠く見えますし、JS String BuiltinsはJS文字列を高速化しますがDOMではありません。ECMAScriptモジュール統合はWASMモジュールをESモジュールにしますが、Web APIはESモジュールではないので役に立ちません。貢献者たちの会話を見ると、こうした機能の提供は優先事項でも計画にも入っていないように見えることがあり、大多数にとってはクラウドや暗号化のような用途のWASIとコンポーネントモデルの方が重要なようです

    • 私もこれを本当に望んでいます。ページはただのWASMで、「ブラウザ」はWASIのようにプラットフォームインポートを提供する純粋なwasmブラウザ、というものを見てみたいです
      ただ、おっしゃるように彼らにとって優先度は高くなさそうです。いつか可能になることを願っています
    • **参照型（reference types）**のおかげで、技術的にはすでにブラウザAPIを直接呼び出せます。WASMがJavaScriptオブジェクトを受け渡しできるためです
      関連するWeb APIをすべてインポートすれば、個々のAPI呼び出しの間でJSオブジェクトをそのまま渡せるので、中間のJSはほとんど不要になる可能性があります。実際にJSが必要なのは、最初にWASMモジュールを初期化するときくらいです
    • 純粋なWASMの問題は、ブロックできない広告がある閉鎖的なWebにつながりかねないことです
    • 少なくとも一部は、GC提案が目指している方向だと思います

  • 素晴らしいプロジェクトです。高解像度ディスプレイでUIを拡大する方法はありますか？
    2:1ディスプレイではフォントにジャギーが見えます。ブラウザのズームを50%に設定するとUIはシャープになりますが、すべてが小さすぎて使いにくくなります

    • OPへ: 修正方法は、キャンバス幅をwindow.innerWidth * window.devicePixelRatio、高さをwindow.innerHeight * window.devicePixelRatioに設定することです
      そのうえでCSSでキャンバスを画面いっぱいにすればよいです
    • なぜUIにブラウザネイティブのレンダリングエンジンを使わないのか、少なくともSVGでも使わないのか理解できません
      リソース（メモリ、ネットワーク、CPU）の面でより安く、アクセシビリティ対応もしやすく、レンダリングも簡単なはずなのに

  • Trevor！ DigiPenで文法を通じてプログラミング言語設計を扱うCS選択科目が本当に好きでした
    教えていた学生のかなり多くが、今はMinecraftで働いています。現在MinecraftのスクリプティングAPIを設計しながら、あのとき学んだ基礎とDigiPen時代の多くの内容を活用しています。今もかっこよく活動している姿を見られてうれしいです

    • 役に立ったなら本当にうれしいです！ いつかまた講義をすることになるでしょう ;)
      取り組んでいるスクリプティングインターフェースもぜひ見てみたいです。昔MinecraftのModを本当にたくさん作っていて、常に何らかの形の動的スクリプティングを望んでいたんです

  • 本当に素晴らしいです。この分野で純粋なWASMベースのプロダクトを見られてうれしいです。ただ、私のM1 Mac Proではかなりカクつきます

  • ひとつ質問なのですが、これはNESでも動きますか？ リファービッシュした前面ローディングモデルで、部品はほとんどオリジナルですが、RAMを少し増設しています
    上にグルーガンで貼り付けて、ケースも赤く塗ったうえで兵隊のおもちゃをいくつか付けてあります

    • WASM > NES変換器を作ることが、なぜ実際に面白そうに見えるのでしょうか…

  • デフォルトのボールシーンを表示しただけでも、Radeon Pro 560Xとほぼ4K環境でGPUをかなり強く叩きます
    カメラを回転するだけでもフレームレートが非常に低くなります。WebGLの最適化問題があり得るのか分かる方はいますか？

    • 私のIntel HD Graphics 620では非常になめらかに動きます。第7世代Intel内蔵グラフィックスなので古くて遅い方ですが、デフォルトのボールシーンだけを見たとき、システム上で非常にスムーズだったので驚きました。Chromeを使っています
    • もう一度試せるなら、一部のマシンで性能を大きく改善する修正が先ほどデプロイされました
      ネイティブのゲームエンジンをWASMに移植したものなので、問題はブラウザのタイミングAPIとうまく合っていなかったフレームレート制限コードにありました: https://raverie-us.github.io/raverie-engine/
    • 専用グラフィックカードを使っていないようにも聞こえます。他のWebGLデモは正常に動きますか？