ブラウザで作ったゲームを、 ネイティブアプリへコンパイル
プロジェクトがタブを離れる準備が整うと、Engineはそれをエクスポートし、Rust製のBevyプロジェクトを生成します——そしてWindows、macOS、Linux、Androidいずれかのビルドへとコンパイルします。
対象
Bevy 0.19
ライセンス
MIT / Apache 2.0
言語
Rust (rustc ≥ 1.95)
レンダラー
wgpu
Bevyとは
BevyはRustで書かれたゲームエンジンで、MIT / Apache 2.0のデュアルライセンスの下、無料かつオープンソースで提供されています。エンティティ・コンポーネント・システム(ECS)アーキテクチャを中核に据え、WebGPUの基盤ともなっているグラフィックス抽象化レイヤーwgpuを通じて描画します。ブラウザもランタイムの同梱も必要ない、正真正銘のネイティブバイナリへとコンパイルされます。
なぜ2つ目のエンジンが必要なのか
Babylon.jsは、URLひとつで開ける3Dアプリケーションというaukimiの前提そのものを支えています。しかし完成したゲームは、多くの場合ファイルでなければなりません——ストアページに掲載したり、プレイヤーに渡したり、タブなしで実行したりするために。Engineは、プロジェクトをどこか別の場所で作り直せと言う代わりに、それを変換します。ブラウザで作成したシーンは、デスクトップやモバイルアプリケーションへとコンパイルされるBevyプロジェクトになります。
実際にエクスポートされるもの
ビルドはシーンをスクリーンショットのように写し取るのではなく、抽出します。ジオメトリとマテリアルは標準的なGLBとして書き出され、glTFでは扱えないもの(地形、植生、空、ポストプロセッシング、エンティティデータ、シーン設定)のうちエンジンが把握している情報はすべて、それに付随する構造化JSONとして書き出されます。そしてこの2つのファイルから完全なRustプロジェクトが生成されます。それは普通のCargoプロジェクトなので、中身を読むことができます。
- scene.glb — ジオメトリ、マテリアル、アニメーション
- scene.json — 地形、植生、ライト、設定
- Bevy 0.19を対象に生成されたCargoプロジェクト
あなたのスクリプトもそのまま持ち込まれる
Engineで書かれたゲームプレイスクリプトは、手作業でRustに書き直されることも、切り捨てられることもありません。生成されたプロジェクトにはJavaScriptランタイム(QuickJS)が組み込まれ、同じスクリプティングAPIがバインドされているため、ブラウザで書いたスクリプトはそのままネイティブビルドの中で動きます。この2つのAPIを揃え続けることは、後付けの配慮ではなく、コードベースの恒常的なルールです。
4つの対象と、1つの正直な「未対応」
現在ビルドパネルが提供する対象は、Windowsの実行ファイル、macOSのアプリバンドル、LinuxのAppImage、AndroidのAPKです。iOSは項目として表示されていますが無効化されています——必要なツールチェーンは、読み込み中の表示の裏に隠せるようなものではないからです。ビルドサーバーが対象に対応できない場合は、失敗メッセージの代わりに、自分でコンパイルできる生成済みのRustプロジェクトが渡されます。
- Windows 10/11 実行ファイル
- macOSアプリバンドル
- Linux AppImage
- Android APK(Android 8以降)
移行できないものは、そう明記される
2つのレンダラーは、あくまで2つの別物です。ブラウザプレビューにできることの中には、まだBevy側に対応するものがないものもあります——ベイクされたライトマップやローカライズされたライトプローブなどです。エクスポーターは、持ち越せなかったものを黙って切り捨てて完成ビルドで違いに気づかせるのではなく、正確にリストアップした変換レポートを書き出します。目に見えるギャップなら、計画に織り込むことができます。