--- title: "Bevy ECSとは？Rust製ゲームエンジンの仕組みと書き方を0.20で実行検証" url: "https://www.issoh.co.jp/tech/details/7874/" published: 2025-07-25 updated: 2026-10-24 categories: ["Rust"] publisher: "株式会社一創" --- # Bevy ECSとは？Rust製ゲームエンジンの仕組みと書き方を0.20で実行検証 Bevyは、Rustで書かれたオープンソースのゲームエンジンです。ゲームの状態をすべてECS（Entity Component System）で扱うのが最大の特徴で、キャラクターも画面遷移の状態も、0.19からはリソースまで「エンティティに付いたコンポーネント」として管理します。 この記事では、2026年10月時点の最新安定版**Bevy 0.20.0**で、ECSの基本・Queryの書き方・Commandsの反映タイミング・Stateによる画面遷移・Pluginでの分割をコードで示します。掲載したコード（抜粋を含む）はすべてRust 1.99.1で実行し、出力をそのまま載せています。0.19以前の解説記事のコードが0.20でどこから動かなくなるかも、実際のコンパイルエラーで示します。 ## まとめ：Bevy ECSを書き始める前に押さえる要点 - 最新安定版は0.20.0（2026年10月8日）で、Rust 1.97.1以上が必要です。1.0前で、マイナー版の更新には破壊的変更が含まれます。0.14から0.20までの公開間隔は約3か月半〜5か月半ですが、今後の公開間隔が保証されているわけではありません。 - データはコンポーネント、処理はシステム（普通のRust関数）に分けます。システムは引数の型（`Query`・`Res`・`Commands`）で何を読み書きするかを宣言します。 - 0.20ではオブザーバーの引数が`On`から`On>`に変わり、旧い書き方はコンパイルエラーになります。`NextState::set_if_neq`も`set_if_different`に改称されました。 - `Commands`によるエンティティ生成は、その場では反映されません。`.chain()`や0.20の`.chain_weak()`で順序を付けると間に同期点が入り、後続のシステムから見えるようになります。 - 格納方式は既定のTableと、付け外しが速いSparseSetの2種類です。0.20.0の実測では付け外しがSparseSetで約3倍速く、走査はTableが1〜2割速い結果でした。 - 公式エディタと組み込みの物理エンジンはまだありません。コードだけで組むことを受け入れられるかが、採用の分かれ目です。 ## Bevyの位置づけ：名前の意味・最新版・注目される理由 英単語の「bevy」は「似たもの同士の大きな集まり」「鳥の群れ」を指し、発音記号は/ˈbev.i/です（[Cambridge Dictionaryの語釈](https://dictionary.cambridge.org/dictionary/english/bevy)）。 ### Bevy 0.20.0の公開日・要求Rustと破壊的変更 Bevyは2020年8月に0.1が公開されて以来、0.x系のまま開発が続いています。0.14以降のマイナー版の間隔は3か月半〜5か月半で、そのたびに移行ガイドが公開されます。公式のセットアップガイドはRustの最低対応版（MSRV）を「最新の安定版」と定めており、[crates.ioのbevy 0.20.0](https://crates.io/crates/bevy/0.20.0)はRust 1.97.1を要求します。 | 版 | 公開日 | 要求Rust | ECSまわりの主な変更 | | ---- | ---------- | ------ | ------------------------ | | 0.14 | 2024-07-04 | 1.79.0 | フック・Observers | | 0.15 | 2024-11-29 | 1.82.0 | Required Components | | 0.16 | 2025-04-24 | 1.85.0 | Relationships | | 0.17 | 2025-09-30 | 1.88.0 | EventをMessageへ改称 | | 0.18 | 2026-01-13 | 1.89.0 | 同一ステートへの遷移 | | 0.19 | 2026-06-19 | 1.95.0 | リソースのコンポーネント化 | | 0.20 | 2026-10-08 | 1.97.1 | Observerの型引数・chain\_weak | 公開日と要求Rustはcrates.ioの登録値（UTC）です。依存に書く版は`bevy = "0.20"`とマイナー版まで固定し、上げるときは移行ガイドを読みながら1版ずつ進めるのが安全です。 ### 「Rust Bevyはえぐい」と言われる理由と、その裏返し Bevyが評価される根拠は、設計・開発規模・ライセンスにあります。まず、ゲームのロジックが普通のRust関数で書け、引数の型から読み書きの競合をエンジンが判定して、ぶつからないシステムを自動で並列実行します。次に、開発の勢いです。[Bevy 0.20のリリースノート](https://bevy.org/news/bevy-0-20/)によれば、0.20は227人のコントリビューターによる817件のプルリクエストで作られました。そして、ライセンスが`MIT OR Apache-2.0`のデュアルライセンスで、商用ゲームにもロイヤリティなしで使えます。 裏返すと、この勢いは「数か月ごとに書き方が変わる」ことを意味します。検索で見つかる日本語の入門記事は0.6〜0.17を前提に書かれたものが多く、0.20ではそのまま動かないコードが混じります。学ぶ側にとってはこれが最大の障害です。 ## ECSの基本：Entity・Component・System・Resourceの役割 ECSは、ゲーム内のモノを「IDだけの入れ物」と「データの部品」と「部品を処理する関数」に分ける設計です。Bevyではこれにグローバルな単一データのResourceが加わります。 | 要素 | Bevyでの実体 | 例 | | --------- | -------------------------- | -------- | | Entity | インデックスと世代を持つID | `4v0` | | Component | `#[derive(Component)]`の構造体 | 位置・速度・目印 | | System | 引数でデータを宣言する関数 | 移動・重力 | | Resource | 1つだけ存在するデータ | 重力値・スコア | オブジェクト指向の継承では「動く敵」「動かない敵」のようにクラス階層で振る舞いを決めますが、ECSでは`Velocity`コンポーネントを付けるか外すかで決めます。振る舞いを後から足し引きできるので、継承の階層が深くなる問題が起きません。Rustの所有権や借用の基本は[Rust入門の環境構築と所有権の解説](/tech/details/15373/)にまとめています。 ### 最小コード：コンポーネント定義からシステム実行まで この例を試すには、`cargo new ecs_example`で作成したプロジェクトへ移動し、`cargo add bevy_ecs@=0.20.0`で依存を追加します。次のコードを`src/main.rs`へ保存し、`cargo run`で実行します。 次のコードは、ウィンドウを開かない`bevy_ecs`クレート単体（0.20.0）で動く最小例です。重力で速度を減らし、位置を動かし、位置のY座標が0になっている各フレームでメッセージを送ります。この例では、着地した瞬間だけに送信を限定していません。 ``` use bevy_ecs::prelude::*; #[derive(Component, Debug, Default)] struct Position(f32, f32); // Velocity を付けると Position も自動で付く（Required Components） #[derive(Component, Debug)] #[require(Position)] struct Velocity(f32, f32); #[derive(Component)] struct Player; #[derive(Resource)] struct Gravity(f32); #[derive(Message)] struct Landed(Entity); fn apply_gravity(g: Res, mut q: Query<&mut Velocity>) { for mut v in &mut q { v.1 -= g.0; } } fn movement(mut q: Query<(Entity, &mut Position, &Velocity)>, mut w: MessageWriter) { for (e, mut p, v) in &mut q { p.0 += v.0; p.1 = (p.1 + v.1).max(0.0); if p.1 == 0.0 { w.write(Landed(e)); } } } fn on_landed(mut r: MessageReader, q: Query<&Position>) { for m in r.read() { println!(" landed: {} at {:?}", m.0, q.get(m.0).unwrap()); } } fn main() { let mut world = World::new(); world.insert_resource(Gravity(1.0)); world.init_resource::>(); // 0.20 の書き方。0.19 までは On world.add_observer(|add: On>| println!("observer: Player -> {}", add.entity)); let a = world.spawn((Velocity(1.0, 0.0), Player)).id(); println!("a has Position: {}", world.get::(a).is_some()); world.spawn((Position(0.0, 2.0), Velocity(0.0, 0.0))); let mut schedule = Schedule::default(); schedule.add_systems((apply_gravity, movement, on_landed).chain()); for frame in 1..=2 { println!("frame {frame}"); schedule.run(&mut world); world.resource_mut::>().update(); } } ``` 実行結果は次のとおりです。 ``` observer: Player -> 4v0 a has Position: true frame 1 landed: 4v0 at Position(1.0, 0.0) frame 2 landed: 4v0 at Position(2.0, 0.0) landed: 5v0 at Position(0.0, 0.0) ``` 読み取れることは3点あります。`Velocity`だけを渡したエンティティにも`Position`が付いている（Required Components）こと、`Player`が付いた瞬間にオブザーバーが呼ばれていること、そしてエンティティ番号が0から始まっていないことです。3点目は、0.19からリソースもエンティティ上のコンポーネントとして保存されるためです。オブザーバーも1つのエンティティとして登録されるので、この例ではリソース2つとオブザーバー1つの後の`4v0`から始まっています。 ### AppとPluginによるシステム登録と機能分割 ゲーム全体は`App`に組み立てます。`add_systems`の第1引数がスケジュールで、起動時に1回だけ動く`Startup`と毎フレーム動く`Update`をよく使います。機能が増えたら、関連するシステムを`Plugin`にまとめて`add_plugins`で差し込みます。次の例はウィンドウを出さない`MinimalPlugins`で実行しました。 ``` use bevy::prelude::*; #[derive(Component)] struct Enemy; pub struct EnemyPlugin; impl Plugin for EnemyPlugin { fn build(&self, app: &mut App) { app.add_systems(Startup, spawn_enemies) .add_systems(Update, (count_enemies, quit).chain()); } } fn spawn_enemies(mut c: Commands) { c.spawn_batch((0..3).map(|_| Enemy)); } fn count_enemies(q: Query<(), With>) { println!("enemies: {}", q.iter().count()); } fn quit(mut exit: MessageWriter) { exit.write(AppExit::Success); } fn main() { App::new() .add_plugins((MinimalPlugins, EnemyPlugin)) .run(); } ``` 出力は`enemies: 3`の1行です。`Startup`で積んだ生成コマンドは`Update`より前に適用されるので、最初のフレームから3体見えています。ウィンドウ付きのゲームにするときは`MinimalPlugins`を`DefaultPlugins`に替えます。 ## Queryの書き方：フィルタと変更検知の落とし穴 システムが扱うエンティティは`Query<取得するデータ, フィルタ>`で指定します。`&T`は読み取り、`&mut T`は書き込み、`Entity`はIDの取得です。フィルタには`With`・`Without`（データは取らずに有無で絞る）、`Added`・`Changed`（前回の実行以降に付いた・変わったものだけ）、複数条件の`Or<(...)>`があります。1体しかいない前提のプレイヤーには`Single<&Transform, With>`が使え、該当が0体か2体以上ならシステム自体がスキップされます。 同じ型を`&T`と`&mut T`で2つのQueryから取ると、システムの初期化時にパニックします。`Without`で対象が重ならないことを型で示すか、`ParamSet`でまとめるのが定石です。 ### Changedの検知条件とset\_if\_neqによる更新抑制 `Changed`で「位置が変わった敵だけ当たり判定する」と書いたのに、毎フレーム全件が引っかかる。原因は変更検知の仕組みにあります。100体の`Position`を地面より下に行かないよう補正するシステムの後ろで、`Changed`に一致した件数を数えました。どの個体も地面より上にいるので、値は一度も変わりません。 ``` // set_if_neq には PartialEq が必要 #[derive(Component, PartialEq)] struct Position(f32, f32); // A: 可変参照で書き戻す fn clamp_naive(mut q: Query<&mut Position>) { for mut p in &mut q { p.1 = p.1.max(0.0); } } // B: 値が違うときだけ書き込む fn clamp_neq(mut q: Query<&mut Position>) { for mut p in &mut q { let y = p.1.max(0.0); p.set_if_neq(Position(p.0, y)); } } ``` | 書き方 | 1回目 | 2回目 | | -------------- | ---- | ---- | | A：`p.1 = ...` | 100件 | 100件 | | B：`set_if_neq` | 100件 | 0件 | Aは値が同じでも、可変参照を通して書き込んだ時点で「変更あり」と記録されます。Bの`set_if_neq`は`PartialEq`で比較し、違うときだけ書き込みます。どちらも1回目が100件なのは、追加されたばかりのコンポーネントを`Changed`が変更として数えるためです。初回の全件一致を前提に書くか、`Added`と分けて扱う必要があります。 0.20では、コンポーネントに`#[component(summary_tick)]`を付けると列全体の変更ティックも記録され、変更の少ない列を`Changed`の検査で丸ごと飛ばせるようになりました。書き込みのたびに記録が2回になるため、「頻繁に問い合わせるが、めったに変わらない」コンポーネントに限って付けます。 ### iter\_manyの0.20での変更とResultによるエラー処理 手元に持っているエンティティIDの一覧からまとめて引く`iter_many`は、0.20で要素が`Result`になりました。0.19までは条件に合わないIDが黙って読み飛ばされていましたが、今は理由付きのエラーとして返ります。 ``` let a = w.spawn(Hp(10)).id(); let b = w.spawn_empty().id(); // Hp を持たない let c = w.spawn(Hp(30)).id(); w.despawn(c); // 削除済み let mut q = w.query::<&Hp>(); for r in q.iter_many(&w, [a, b, c]) { println!("{r:?}"); } ``` ``` Ok(Hp(10)) Err(QueryDoesNotMatch(2v0, ArchetypeId(0))) Err(NotSpawned(Invalid(InvalidEntityError { entity: 3v0, current_generation: EntityGeneration(1) }))) ``` 旧来の「合うものだけ処理する」動きにするなら`.flatten()`を挟みます。削除済みのIDを握り続けているバグを見つけたいなら、`Err`をログに出すほうが原因に早くたどり着けます。 ## Commandsが反映されるタイミングと同期点 `Commands`で行うエンティティの生成・削除やコンポーネントの付け外しは、呼んだ瞬間には反映されず、キューに積まれます。並列実行中のシステムが同じテーブルを書き換えないようにするための仕組みです。では、生成したシステムの直後に並べたシステムからは見えるのか。`.chain()`・0.20で追加された`.chain_weak()`・`.chain_ignore_deferred()`で比べました。 ``` #[derive(Component)] struct P; fn spawner(mut c: Commands) { c.spawn(P); } fn reader(q: Query<&P>) { println!(" reader sees {}", q.iter().count()); } // mode ごとに World と Schedule を作り直して1回だけ実行 s.add_systems((spawner, reader).chain()); s.add_systems((spawner, reader).chain_weak()); s.add_systems((spawner, reader).chain_ignore_deferred()); ``` ``` chain: reader sees 1 after schedule: 1 chain_weak: reader sees 1 after schedule: 1 chain_ignore_deferred: reader sees 0 after schedule: 1 ``` `.chain()`や`.before()`・`.after()`で順序を付けると、Bevyは`Commands`を使うシステムの後ろに同期点（`ApplyDeferred`）を自動で挟み、キューを適用してから次を動かします。`chain_weak`はデータの読み書きが実際にぶつかるシステムの間にだけ順序を残す緩い版ですが、`Commands`を出すシステムは常に「ぶつかる」扱いなので、同期点も残ります。同期点では並列実行が一度止まるので、性能が気になる箇所では`chain_ignore_deferred`で外し、反映はスケジュールの最後に任せる選択肢があります。 注意点として、`chain_weak`はスケジューラから見えない依存（`Res`の内部可変性・チャネル・グローバル変数）を守りません。0.20では描画やUIの組み込みシステムセットがこの弱い順序に切り替わったため、そうしたセットに自作システムを差し込み、見えない依存で前のセットの完了を待っていたコードは、明示的に`.after(...)`を付ける必要があります（[0.19から0.20への移行ガイド](https://bevy.org/learn/migration-guides/0-19-to-0-20/)）。 ### despawn\_allによる一括削除と処理時間の比較 0.20には、フィルタに合うエンティティを1つのコマンドでまとめて消す`commands.despawn_all::>()`が入りました。条件付きの`despawn_all_where`もあります。手元で、1体ずつ`despawn`する書き方と比べました（releaseビルド・各3回）。 | 削除する数 | 1体ずつdespawn | despawn\_all | | ----- | ----------- | ------------ | | 1万体 | 0.76〜1.04ms | 0.51〜0.56ms | | 10万体 | 9.9〜10.3ms | 5.4〜7.3ms | 10万体で約1.4〜1.9倍の差で、リリースノートの計測（1.53〜1.70倍）と同じ程度です。ステージ切り替えで敵や弾をまとめて片付ける場面で効きます。後述の`DespawnOnExit`は内部でこの一括削除を使うようになったので、コードを変えなくても恩恵を受けます。 ## ストレージ：TableとSparseSetの使い分け（実測） Bevyは同じコンポーネントの組み合わせを持つエンティティを1つのアーキタイプにまとめ、既定ではコンポーネントごとの連続した配列（Table）に並べて格納します。走査は速い一方、コンポーネントを付け外しするとエンティティを別のテーブルへ丸ごと移す必要があります。これを避けるのが`#[component(storage = "SparseSet")]`です。 ``` #[derive(Component)] #[component(storage = "SparseSet")] struct Stunned; ``` 位置と256バイトのデータを持つエンティティに目印を1つ付けたとき、アーキタイプとテーブルの数は次のように変わりました。SparseSetの目印はアーキタイプを増やしますが、テーブルは増やしません。 | 状態 | アーキタイプ | テーブル | | --------------- | ------ | ---- | | 付ける前 | 3 | 3 | | SparseSetの目印を追加 | 4 | 3 | | さらにTableの目印を追加 | 5 | 4 | 速度差も測りました。条件はbevy\_ecs 0.20.0・releaseビルド・Rust 1.99.1・Intel Core i9-9880H（メモリ16GB）のMacです。付け外しは10万体への追加・削除を5周する計測（50万組、追加と削除を別々に数えると計100万操作）を3回、走査は100万体のうち半数に付けた50万件を20回読む計測を6回行い、表には最小〜最大を載せています。 | 操作 | Table | SparseSet | | ---------------- | --------- | --------- | | 追加と削除50万回 | 164〜188ms | 55〜60ms | | 値を読む走査（50万件×20回） | 25〜26ms | 30〜32ms | | 目印で絞るだけの走査（同） | 25ms | 27〜28ms | 付け外しはSparseSetが約3倍速く、値を読む走査は6回ともTableが約2割速い結果でした。データを持たない目印を`With`の絞り込みにだけ使う場合も、Tableが1割ほど速くなっています。この計測条件では、付け外しのコストを下げたい「気絶中」「選択中」のような目印はSparseSetを候補にし、位置や体力のように毎フレーム値を読むデータはTableのままにします。0.19で追加された`contiguous_iter_mut`はTableの連続配列をスライスで渡してSIMDの自動ベクトル化を効かせる機能で、取得データが`ContiguousQueryData`を満たし、クエリ全体がdenseであることが必要です。取得データだけでなく`With`・`Without`の対象にもSparseSetを含めず、フィルタに`Changed`・`Added`を含まないことが条件です。 ## 古いBevyのコードが0.20で動かない理由と直し方 Bevyの解説記事を検索すると、`EventWriter`・`SpriteBundle`・`On`・Run Criteriaといった書き方が出てきます。どれも現行の0.20では書き方が変わっています。版ごとに見ていきます。 ### 0.20で変わったECSの書き方 最も多くの既存コードに当たるのはオブザーバーの型引数です。0.19までの`On`は、0.20.0では次のエラーで止まります。 ``` error[E0107]: struct takes 1 generic argument but 2 generic arguments were supplied ``` 監視するコンポーネントはイベント側の型引数に移り、`On>`と書きます。`Insert`・`Discard`・`Remove`・`Despawn`も同じです。ほかの変更は次のとおりです。 - 排他システムの`&mut World`は、引数の先頭でなくても置けるようになりました（`fn f(mut n: Local, world: &mut World)`が通ります）。 - `debug` featureを有効にすると、`ScheduleBuildSettings`の`shuffle_seed`で順序の決まっていないシステムの実行順を乱数で入れ替えられます。たまたま正しい順で動いているだけのバグを炙り出す用途です。 - スプライトの描画は`Mesh2d`と`SpriteMaterial`の仕組みに移りました。同じZ座標で重なるスプライトの前後が変わることがあるので、重なりうるものにはZを明示します。 - `ui::widgets::Button`と`Interaction`は非推奨になり、`ui_widgets::Button`と`Hovered`・`Pressed`コンポーネントへ移りました。 `NextState::set_if_neq`は`set_if_different`に改称されました。変更検知の`set_if_neq`と名前がぶつかるためです。移行ガイドは「非推奨の互換メソッドを残した」と書いていますが、公開されたbevy\_state 0.20.0には旧名が1つも残っていません。`ResMut>`越しに旧名を呼ぶと変更検知側のメソッドに解決され、次のような原因の見えにくいエラーになります（0.20.0で確認）。 ``` error[E0277]: can't compare `bevy::bevy_state::state::NextState` with `bevy::bevy_state::state::NextState` ``` ### システムのパニックでアプリを落とさない設定（0.20） 0.20から、システム・コマンド・オブザーバーの中で起きたパニックも、`Result`のエラーと同じくエラーハンドラに渡されるようになりました。既定のハンドラは再びパニックさせるので動きは従来どおりですが、ハンドラを差し替えれば処理を続けられます。2フレーム目だけパニックするシステムで確かめました。 ``` use bevy_ecs::error::{FallbackErrorHandler, warn}; fn buggy(f: Res) { if f.0 == 2 { panic!("frame 2 で落ちた"); } } world.insert_resource(FallbackErrorHandler(warn)); s.add_systems((tick, buggy, report).chain()); // 3回実行 ``` | ハンドラ | 出力された行 | | ----------- | --------------------- | | 既定のまま | frame 1 done の後に終了 | | `warn`に差し替え | frame 1・2・3 done まで継続 | `App`では`.set_error_handler(bevy::ecs::error::warn)`で同じ設定になります。開発中は既定のハンドラで原因を調べます。配布版で`warn`に切り替えるのは、失敗後も状態の整合性を保てる処理に限り、継続できない失敗には終了や復旧の方針を定めます。エラーには`.context("...")`で説明を重ねられるようにもなりました。 ### EventとMessageの区別（0.17の改称） 0.17で、システム間でバッファを介して受け渡す従来の「イベント」は`Message`に分離されました。`EventWriter`・`EventReader`・`Events`は、それぞれ`MessageWriter`・`MessageReader`・`Messages`になり、送信メソッドは`write`です。現在の`Event`は、`commands.trigger(...)`で発火させてオブザーバー（`On`を引数に取る関数）が受け取る仕組みを指します。ただし、`commands.trigger(...)`はコマンドを予約するため、オブザーバーが実行されるのはコマンド適用時です。毎フレームまとめて処理するならMessage、発生したイベントごとに個別のオブザーバーで反応させるならEventを選びます。 ### BundleからRequired Componentsへ（0.15） 0.15で`SpriteBundle`・`NodeBundle`・`PbrBundle`などの組み込みBundleは非推奨になり、`#[require(...)]`で必要なコンポーネントを宣言する方式に置き換わりました。0.20.0のソースでも`Sprite`は`Transform`・`Visibility`・`VisibilityClass`・`Anchor`を要求しており、`Sprite`を1つ`spawn`すればこれらが自動で付きます。さらに古い0.9以前の記事にあるStageとRun Criteriaは、0.10のスケジューラ刷新でシステムセットとRun Conditions（`.run_if(...)`）に置き換わりました。0.19ではリソースのエンティティ化に加え、ライフサイクルイベントの`Replace`が`Discard`に改称されています。 移行するときは、`cargo build`のエラーを移行ガイドの見出しで検索するのが最短です。改称だけの項目は一括置換で片付くので先に済ませ、同一ステート遷移のように挙動が変わった項目を後から確認します。 ## Stateで画面遷移を組む：タイトル・プレイ・ゲームオーバー タイトル画面からゲーム本編へ、といった遷移は`States`で表します。次のコードは、ウィンドウを出さない最小構成（`default-features = false`で`bevy_state`・`std`・`multi_threaded`だけを有効化）のbevy 0.20.0で実行しました。 ``` use bevy::prelude::*; use bevy::state::app::StatesPlugin; #[derive(States, Debug, Clone, Copy, PartialEq, Eq, Hash, Default)] enum GameState { #[default] Title, Playing, GameOver } #[derive(Resource, Default)] struct Frames(u32); #[derive(Component)] struct Enemy; fn main() { App::new() .add_plugins((MinimalPlugins, StatesPlugin)) .init_state::() .init_resource::() .add_systems(OnEnter(GameState::Title), || println!("enter Title")) .add_systems(OnEnter(GameState::Playing), spawn_level) .add_systems(OnExit(GameState::Playing), || println!("exit Playing")) .add_systems(OnEnter(GameState::GameOver), |mut exit: MessageWriter| { println!("enter GameOver"); exit.write(AppExit::Success); }) .add_systems(Update, (tick, play.run_if(in_state(GameState::Playing))).chain()) .run(); } fn spawn_level(mut c: Commands) { println!("enter Playing: spawn 3 enemies"); for _ in 0..3 { c.spawn((Enemy, DespawnOnExit(GameState::Playing))); } } fn tick(mut f: ResMut, s: Res>, mut next: ResMut>) { f.0 += 1; println!("frame {} state {:?}", f.0, s.get()); if f.0 == 2 && *s.get() == GameState::Title { next.set(GameState::Playing); } } fn play(q: Query<&Enemy>, f: Res, mut next: ResMut>) { println!(" play: enemies={}", q.iter().count()); if f.0 >= 4 { next.set(GameState::GameOver); } } ``` ``` enter Title frame 1 state Title frame 2 state Title enter Playing: spawn 3 enemies frame 3 state Playing play: enemies=3 frame 4 state Playing play: enemies=3 exit Playing enter GameOver frame 5 state GameOver ``` 2フレーム目に`NextState`へ予約した遷移は、そのフレームではなく次のフレームの冒頭で実行されています。遷移は`PreUpdate`の直後に走る専用のスケジュール（`StateTransition`）で処理されるため、同じフレームのうちに`State`を読み直しても値は変わりません。`DespawnOnExit`を付けたエンティティはPlayingを抜けるときに自動で消えるので、ステージ片付けのシステムを書く必要はありません。 `NextState::set`で現在と同じステートを指定すると、0.18からは`OnExit`・`OnEnter`が走り、0.19からは`DespawnOnExit`・`DespawnOnEnter`も発火します。0.20.0で、Playingのまま1フレーム目に`set(Playing)`、2フレーム目に`set_if_different(Playing)`を呼ぶと、出力は次のとおりでした。 ``` frame 1 entities=1 set(Playing) OnExit Playing OnEnter Playing frame 2 entities=1 set_if_different(Playing) frame 3 entities=1 ``` リトライで同じステージをやり直したいなら`set`、意図しない再入を避けたいなら`set_if_different`を使います。ポーズ中だけ存在する子ステートには`SubStates`、他のステートから導出するだけのものには`ComputedStates`があります。 ## Bevyの始め方：Cargo.tomlとビルド時間の短縮 Rustを入れたら`cargo new my_game`でプロジェクトを作り、`cargo add bevy`で依存を追加します。Cargoの基本操作は[Cargoのインストールと主要コマンド一覧](/tech/details/9572/)で確認できます。 ### featureの選び方と3D・UIの有効化 0.20.0の既定featureは`2d`・`3d`・`ui`・`audio`の4つの束です。3Dゲームを作るなら既定のままで足ります。2Dだけのゲームなら`default-features = false`にして`2d`と`audio`だけを選ぶと、依存が減ってビルドが軽くなります。`2d`・`3d`には`ui`が含まれないため、メニューやスコア表示にbevy\_uiを使うなら`ui`も加えます。描画はRust製のグラフィックスAPIであるwgpu（bevy\_render 0.20.0が依存するのは30系）の上に作られており、仕組みは[wgpuで三角形描画とGPU計算を動かす手順](/tech/details/4094/)で解説しています。 Linuxでは、ウィンドウ・音声・入力のためにOSのライブラリが別途必要です。Ubuntuなら[公式のLinux依存一覧](https://github.com/bevyengine/bevy/blob/v0.20.0/docs/linux%5Fdependencies.md)どおり`sudo apt-get install g++ pkg-config libx11-dev libasound2-dev libudev-dev libxkbcommon-x11-0`を入れます。既定featureに`wayland`が含まれるため、`libwayland-dev libxkbcommon-dev`も入れます（`wayland` featureを外した場合は不要）。 ### 初回ビルドの長さとコンパイル短縮の設定 Bevyは依存クレートが多く、初回ビルドに時間がかかります。手元のIntel版Mac（Core i9-9880H・メモリ16GB・Rust 1.99.1）で新規プロジェクトを`cargo build`（devプロファイル）した初回の所要時間は、cargoの表示で`bevy_ecs`単体57秒、上のState例の最小構成1分16秒でした。依存クレートの一部はダウンロード済みの状態で、所要時間は有効にするfeatureやキャッシュの状態で変わります。既定featureをすべて入れた構成はさらに長くなります。[公式のセットアップガイド](https://bevy.org/learn/quick-start/getting-started/setup/)が勧める設定は次の3つです。 ``` [profile.dev] opt-level = 1 [profile.dev.package."*"] opt-level = 3 ``` 自分のコードは軽く最適化し、変更しない依存クレートだけ強く最適化する設定です。デバッグビルドのままだとゲームの動作が極端に遅くなるのを防げます。2つ目は`cargo run --features bevy/dynamic_linking`でBevyを動的ライブラリとして扱い、変更のたびの静的リンクを省く方法です。配布用のビルドでは無効にします。3つ目はリンカーをlldやmoldに替える方法です。ただしmacOSについては、同じガイドが「既定のリンカーld-primeのほうがLLDより速い」としているので、替える必要はありません。 ## Bevyを選ぶべきでない場面と他エンジンとの分かれ目 Bevyが向かないのは、次のどちらかに当てはまるプロジェクトです。 - デザイナーやプランナーがGUIのエディタでシーンを組む前提のチーム。0.20のリリースノートも、シーン形式BSNやリモートインスペクターを「エディタの部品」として順に出している段階で、エディタ本体は入っていません。 - 長期の商用案件で、必要な不具合修正や対象OSへの対応に伴うエンジン更新・移行検証の工数を確保できないプロジェクト。0.xのまま数か月ごとに破壊的変更が入り、0.20のObserverのように多くのコードに当たる変更もあります。 逆に、Rustで書きたい、ロジックをテストしやすい形で持ちたい、エンジン内部まで読んで直したい、という条件ならBevyは有力です。GUIエディタ込みの無料エンジンが欲しいなら[Godotのインストール手順と動作要件](/tech/details/7777/)、アセットと求人の多さを重視するなら[Unity 6.3 LTSの新機能と変更点](/tech/details/10417/)も比較してください。 ## よくある質問 ### Bevyは商用利用できますか？ できます。Bevyは`MIT OR Apache-2.0`のデュアルライセンスで、利用者はどちらかを選べます。ロイヤリティや売上に応じた支払いはありません。配布時は、選んだライセンスの条件に従います。MITでは著作権表示と許諾文を含め、Apache-2.0ではライセンスの写しの提供に加え、変更したファイルの変更表示や、該当するNOTICEの保持などの条件を確認します。依存クレートや同梱素材のライセンスも別途確認します。 ### 古いBevyチュートリアルのコードが動かないのはなぜですか？ 多くの記事が0.19以前のAPIで書かれているためです。0.20では`On`が`On>`に、`NextState::set_if_neq`が`NextState::set_if_different`になり、0.17では`EventWriter`が`MessageWriter`に、0.15では`SpriteBundle`などの組み込みBundleが非推奨になりました。記事の冒頭か`Cargo.toml`で対象の版を確かめ、公式の移行ガイドで差分を追ってください。 ### BevyでUIやGUIは作れますか？ 作れます。`bevy_ui`の`Node`コンポーネントにFlexboxかCSS Gridのレイアウトを指定して画面を組み、レイアウト計算にはtaffyクレート（0.20.0では0.14系）が使われています。0.20ではエディタ向けのウィジェット集Feathersに色入力・スクロールリスト・ドロップダウンが加わり、旧`Button`は`ui_widgets::Button`へ移りました。 ### bevy\_ecsだけを他のRustプロジェクトで使えますか？ 使えます。`bevy_ecs`は単独のクレートとして公開されており、この記事の最小コードもウィンドウを持たない`bevy_ecs`単体で実行しました。シミュレーションやサーバー側の状態管理にECSだけを持ち込む使い方ができます。 ### Bevyに物理エンジンは入っていますか？ 本体には含まれていません。0.20.0のfeature一覧177項目にも物理演算の項目はありません。公式のアセット一覧のPhysicsカテゴリに、ECSで動く2D/3D物理エンジンのAvianと、Rapierを組み込むbevy\_rapierが第三者製として掲載されています。 ## 関連記事 - [Rust入門｜環境構築から所有権・基本文法、受託開発での採用判断まで](/tech/details/15373/) - [wgpuとは？Rustで三角形描画とGPU計算を動かす手順【wgpu 30対応】](/tech/details/4094/) - [Cargo（Rust）とは？インストールとcargo installの使い方・主要コマンド一覧](/tech/details/9572/) - [Godotのインストール方法｜Windows・Mac・Linux別の手順と日本語化・動作要件【4.7.2対応】](/tech/details/7777/) - [Unity 6.3 LTS（6000.3）の新機能と変更点｜最新パッチ・サポート期限・6.0からの移行](/tech/details/10417/) --- 出典: [Bevy ECSとは？Rust製ゲームエンジンの仕組みと書き方を0.20で実行検証]()（株式会社一創）