Bevy 0.19のBSNは今使えるか。実装済み範囲と将来エディターを分ける導入判断
Rust製ゲームのUIや再利用シーンにはbsn!を限定採用できる。一方、公式.bsnローダー、BSN経由のglTFスポーン、完成した公式エディターは未提供。現在の導入範囲を整理する。
Bevy 0.19のBSN（Bevy Scene Notation）は、Rustコード内でUIや複合エンティティーを組み立てる用途なら、今から小さく採用できる。一方、シーンを.bsnファイルとして編集・保存する公式ワークフローや、完成したBevy Editorを前提に制作工程を組む段階ではない。小規模チームの現実的な判断は、既存のシーン／保存系を全面移行せず、新しいメニュー、HUD、開発ツールなど一つのコード駆動領域でbsn!を試すことだ。
Bevy 0.19.0は2026年6月19日に公開された。公式発表はBSNを次世代シーンシステムとして紹介する一方、この版はコード駆動の利用に焦点を置き、公式の.bsnアセットローダーはまだ同梱していないと明記している。エディター向けの部品が増えたことと、エディター製品が利用可能になったことを分けて読む必要がある。
先に分ける三つの状態
- 実装済み：
bsn!／bsn_list!、シーンの合成とパッチ、関係を持つエンティティー、コードからのスポーン。 - 併存中：旧シーン系を改名した
bevy_world_serialization。ワールドの往復保存とglTFシーンのスポーンには引き続き必要。 - 将来計画：公式の
.bsn読み書き、glTFの新シーン系対応、統合されたエンティティーインスペクター、完成したBevy Editor。
0.19で使えるBSNは「コードで書く再利用可能な差分」
BSNは、あるエンティティーへ追加するコンポーネントと、その子や独自RelationshipをRustに近い記法でまとめる。すべてのフィールドを書かずに既定値を使い、シーン関数を別のシーンへ合成し、後から特定フィールドだけを上書きできる。公式はこれを「完全な値の複製」ではなくパッチとして説明している。幅だけを定めた共通ボタンへ、高さや色だけを加えるような派生を作りやすい。
Bevy 0.19.0のscene API文書には、即時スポーンと依存物を待つキュースポーン、階層、名前付きエンティティー参照、合成、キャッシュ、オブザーバーまで現在のAPIとして整理されている。公式BSNサンプルでも、ボタン関数を再利用し、子テキストとポインターイベントを一つの宣言へまとめるコードが動作例として提供されている。したがってBSNそのものは構想だけではない。
小規模チームに効くのは、シーンが将来エディターで開けるかどうかより、同じ構造を複数箇所へ手作業で展開しなくてよくなる点だ。ポーズメニュー、設定画面、デバッグパネル、敵の基本構成など、「構造は共通で一部だけ違う」対象に絞れば、合成とパッチの価値を現在の0.19だけで評価できる。
未提供の部分を制作基盤として数えない
| 機能 | 0.19.0での状態 | 制作上の扱い |
|---|---|---|
コード内のbsn! |
提供済み。合成、パッチ、階層、シーン関数を利用可能 | 新規の限定領域で試せる |
| Feathersのツール向けUI | BSNへ移行し、機能フラグ名からexperimentalが外れた。ただし不完全で破壊的変更の可能性がある | 内部ツールや試作で評価し、製品UIは必要機能を個別確認する |
公式の.bsnファイルローダー |
未提供。将来版向けの設計と基盤はある | レベルやPrefabのファイル形式として依存しない |
| ワールドの往復シリアライズ | BSNへ書き出せないため旧系が必要 | セーブデータやスナップショットをBSNへ置き換えない |
| glTFシーンのBSN統合 | 未移行。0.19では旧系のWorldAssetRootを使ってスポーンする |
DCCからの現行経路を維持する |
| Bevy Editor | 部品を段階的に実装中。完成版の提供日なし | 非プログラマー中心の編集工程をまだ前提にしない |
0.18から0.19の公式移行ガイドは、新BSNが旧シーン系の全機能を置き換えていないため、旧bevy_sceneをbevy_world_serializationへ改名したと説明する。従来のSceneRootもWorldAssetRootへ変わる。glTFを読み込んでいる既存作品は、BSNを使わなくてもこの名前変更の影響を受けるため、「BSNを採用するか」と「0.19へ更新するか」は別々に見積もるべきだ。
エディターの実在状態
0.19にはFeathersウィジェット、基本的なテキスト入力、アプリ設定、変形ギズモ、無限グリッド、アセット保存など、エディターにも使える機能が含まれる。しかし公式発表自身が、それらを「エディターそのもの」ではなく、将来のシーンエディターに必要な部品として区別している。2026年7月18日時点で、公式記事からリンクされた動的.bsn実装のPull Request #23576もDraft表示であり、公開版への採用時期は確定できない。
どのチームなら今採用できるか
| チームの状態 | 判断 | 理由 |
|---|---|---|
| 新規試作で、Rustコード中心 | 限定採用 | 一つのUIや複合エンティティーなら、既存資産を壊さず現在の利点を測れる |
| 0.18でUIのspawnコードが重複している | 移行ブランチで比較 | 行数ではなく、派生パターン、レビュー性、変更時の修正箇所を比べる |
| glTFとDynamicScene、ワールド保存へ強く依存 | 既存系を維持 | 新BSNだけでは0.19時点の必要機能を満たさない |
| レベルデザイナーがGUIで大量のシーンを制作する | 待つか別ツールを維持 | 公式.bsnファイル工程と完成したエディターがまだない |
| リリース直前で0.18が安定している | 次の開発区切りへ送る | 0.19にはBSN以外にも広い破壊的変更があり、見た目の置換だけでは済まない |
半日で試す最小検証
- 対象を一つ選ぶ。共通ボタン、設定行、敵の装備階層など、現在重複しているが保存データには関係しない構造を選ぶ。
- 共通シーンと派生を作る。シーン関数で共通部分を定義し、二つの派生で別フィールドだけをパッチする。
- 現行実装と同じ試験を通す。スポーン結果、イベント、アセット依存、despawn、対象プラットフォームでのビルドを比較する。
- 変更しやすさを測る。共通項目を一つ変更し、差分の読みやすさ、コンパイルエラーの位置、レビューで追うファイル数を記録する。
- 境界を固定する。
.bsnファイル、glTF、セーブ／ロードへ範囲を広げず、採用するコード領域と0.20以降に再確認する項目を残す。
合格条件は「短く書けた」だけでは足りない。共通構造の変更が一箇所で済み、派生差分が読み取れ、イベントとアセット依存を既存テストで確認できたときに採用する。マクロ内の診断やツール補完がチームの開発環境で扱いにくい場合は、公式が経験の粗さを認めている現段階で無理に広げる理由はない。
導入判断の要点
- Bevy 0.19のBSNは実在し、コード内のシーン合成とパッチに利用できる。
- 公式の
.bsnファイル工程、glTFの新系移行、完成したBevy Editorはまだ利用条件に入れない。 - 既存作品では、0.19へのAPI移行とBSN採用を分け、旧シーン／保存系を残したまま一領域だけ比較する。
- エディターを待つチームより、RustコードでUIや複合エンティティーを管理するチームの方が、現在の価値を先に得やすい。
参照した情報源
一次情報、補助報道、コミュニティ観測を役割別に表示しています。
Bevy 0.19.0の公開日、BSNのコード駆動ワークフロー、合成・パッチ・Relationship・シーン関数・依存認識、FeathersのBSN移行、テキスト入力、App Settingsなどを確認。公式の.bsnアセットローダーが未提供で、glTF移行、エンティティーインスペクター、完成したエディターが将来項目であることも確認した。
新BSNが0.19で旧シーン系を全面置換していないことを確認。ワールドからBSNへの書き出しとglTFシーンのスポーンには旧系が必要で、旧bevy_sceneがbevy_world_serializationへ、SceneRootがWorldAssetRootへ改名された範囲を確認。Feathersは広いツール利用が可能な段階へ進んだ一方、不完全で破壊的変更の可能性があるという公式の注意も確認した。
Bevy公式crateから生成された0.19.0 API文書を確認。bsn!、即時／キュースポーン、階層とRelationship、合成、パッチ、キャッシュ、アセット依存、オブザーバーの現在APIを確認した。.bsnファイルは未対応で、現時点ではbsn!、既存形式、またはコミュニティ実装を使うという記載を確認した。
Bevy 0.19公式記事が参照する.bsnアセット形式実装のPull Requestを確認。2026年7月18日時点でDraft表示であり、公式のファイルローダーを0.19の実装済み機能として扱えないことを再確認した。議論中の設計やマイルストーンから公開時期は推定していない。
0.19向けの公式実行例を確認。bsn!とbsn_list!でUI階層、再利用可能なボタン関数、子テキスト、ポインターイベントをコード内で構成する現在の利用形を確認した。ファイルベースのシーン編集やエディター提供の根拠には使っていない。