Bevy 0.12 - Rust製のデータ駆動ゲームエンジン

 (bevyengine.org)
2 ポイント 投稿者 GN⁺ 2023-11-05 | 1件のコメント | WhatsAppで共有
  • レンダラーが選択可能な Deferred Rendering をサポートし、マテリアルごとに forward または deferred パスを選択でき、DefaultOpaqueRendererMethod でグローバルなデフォルト値を設定可能
  • 既存の Bevy アプリやプラグインは、0.11 to 0.12 Migration Guide を通じて 移行 手順を確認する必要がある
  • Bevy Asset V2 は、アセットの前処理、.meta ファイルベースの設定、複数の AssetSource、再帰的依存関係のロードイベント、非同期アセット I/O、改善されたハンドルをサポートする
  • アセット前処理は AssetPlugin { mode: AssetMode::Processed } と bevy/asset_processor Cargo 機能で有効化できるが、現時点ではほとんどのユースケースでまだ推奨されていない
  • Android ではアプリ一時停止時にクラッシュしなくなり、再開前まではシステムの実行を停止し、ApplicationLifetime::Suspended と ApplicationLifetime::Resumed イベントを提供する
  • StandardMaterial に specular_transmission, diffuse_transmission, thickness, ior, attenuation_color, attenuation_distance が追加され、ガラス・水・プラスチック・葉・紙のような透過マテリアル表現をサポートする
  • glTF ローダーが KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume, KHR_materials_emissive_strength 拡張をサポートし、TEXCOORD1 または UV1 の 2 番目の UV マップを取り込める
  • Draw command の自動 batching/instancing が可能になり、同じマテリアルとメッシュを持つエンティティを現在バッチ化でき、NoAutomaticBatching コンポーネントで除外できる
  • シャドウは PCF Shadow Filtering を導入し、DirectionalLight と SpotLight でより滑らかな影をサポートし、デフォルト方式は ShadowMapFilter::Castano13 である
  • ECS に one-shot systems が追加され、システムを登録した後 SystemId で必要なときに実行できるが、exclusive system、system piping 用 system、自分自身の呼び出し、並列評価はサポートしない
  • FixedTime は削除され、Time は FixedUpdate でも文脈に応じた値を返し、FixedUpdate が過度に蓄積されてアプリが停止する「death spiral」を防ぐ
  • AnimationPlayer では set_elapsed は seek_to に、stop_repeating は set_repeat(RepeatAnimation::Never) に置き換えられ、elapsed はアニメーション速度の影響を受けない実際の経過時間を返す
  • Bevy shader import は Rust スタイル構文に変わり、#import bevy_pbr::forward_io::VertexOutput、波括弧による複数 import、部分パス import、完全修飾パスの使用をサポートする
  • UI では UiMaterial によりカスタム material shader を UI ノードで使用でき、Outline コンポーネントによりレイアウト領域を占有しないノードのアウトラインをサポートする
  • アクセシビリティ統合には ManageAccessibilityUpdates リソースが追加され、その値が false のときエンジンのアクセシビリティツリー自動更新を停止できる

関連記事

1件のコメント

 
GN⁺ 2023-11-05
Hacker News の意見

  • Bevy は Unity や Godot のような従来型エンジンと比べると、ゲームの作り方がまったく異なる
    UI やスクリプティングなしにすべてを Rust コードで処理するので、libGDX や Cocos2D-x により近い。ただし ECS と Rust を使うためコーディングのやり方もまた大きく変わり、実質的に独自の島にいるような感覚がある
    Bevy で成功したインディーゲームを見てみたいが、ほとんどのゲーム開発者は、すでに学んでいて周囲でも使われている従来型のツールをより好む可能性が高い。ゲームを作りたい人と Rust も好む人の重なりは大きくなく、その中でも実験的な新しいエンジンを学ぶのに相当な時間と労力をかけるより、信頼と資料が蓄積されたツールを選ぶ人が多そうに見える
    個人的には、Bevy には Bevy と Rust ベースの IDE とスクリプティング言語が必要だと思う。新しいプロジェクトに大きな労力を投じなければならない障壁が消えるわけではないが、Rust 経験がなく、コードの壁から始めることを負担に感じる新規ユーザーにはずっと親しみやすくなり得る。Unity や Godot のように、キャンバス上で数時間以内にごく基本的なプロトタイプを作れる方法とは対照的だ
    開発者がスクリプティング言語に反対していると理解しているが、ホットリロードとより深いデバッグは必要で、Rust だけでは効果的に行うのは難しいと思う。多くのゲーム開発者は Rust と借用チェッカーに圧倒されるかもしれない。ただ、今は自分で実装する時間もリソースも意欲もない

    • Bevy は構造上、借用チェッカーと直接ぶつかることは多くない。コンポーネントとリソースは概ね所有型を使い、Query と Ref を通じて大きな心配なく扱える
      Bevy を少し触ってリポジトリを確認してみたところ、ライフタイム表記は 0 個だった
    • ゲーム開発で最も時間を食うのはアセット管理で、その次がプログラミングであることが多かった。Bevy のようなエンジンはバグ修正時間を減らそうとするが、アセットパイプラインが不足していると、その削減分をアセット側で失うことになる
      スクリプティング言語は多少役立つだろうが、現在 Bevy を使う人たちは非常に技術寄りの傾向が強く、専業デザイナーではないことも多いので、切実な需要はそれほど大きくなさそうだ
      Rust コミュニティがゲーム開発に与える影響には期待しており、いつか貢献したいが、今は述べた理由から C++/C# パイプラインを維持するつもりだ。Rust は脇でしっかり学び、ツールが成熟したら以後のプロジェクトで検討できる
      ホットリロードはコンパイル時間が耐えがたくなったときの応急処置であることが多い。平均 4 秒、フル再コンパイル 20 秒程度なら、フルコンパイルを避ける方法に多くのリソースを割く必要は小さくなる
      ただし Rust は全般的にコンパイル時間が長いと聞いているため、スクリプティングやホットリロードの必要性は思ったより早く来るかもしれない。それでも現在進行中のインディープロジェクトは、まだその壁に達しない可能性が高い
    • IDE はかなり前から計画されており、今回のリリース後の最優先課題だと理解している
      Bevy の創始者である Cart は、Bevy は Rust ファーストであるべきだと考えており、個人的にも同意している。だからといって複数のスクリプティング言語向けプラグインを作れないという意味ではなく、実際すでにいくつか存在する

  • Bevy の創始者でありプロジェクトリードです。何でも質問してください

    • 会社規模に比べてかなり大きな WASM アプリを Bevy で作っているが、エンジンを使う体験は非常に良かった
      Bevy とコミュニティは素晴らしい。いくつかチケット対応が必要だったが、コアコントリビューターの一人を見つけてスポンサーし、依頼を最後まで進めてもらうのはとても簡単だった。たとえばモーフターゲットがそうだった
      Carter は本当に重要なものを作っており、その背後には素晴らしい推進力がある。Bevy は Web 配布が非常に簡単で、もっと多くの人が見てみる価値がある。コミュニティも良く、助けを求めるのも簡単だ
    • ドキュメントが限られているため、参入をためらってしまう。Bevy の本は数分で読み終わり、詰まったときに参照できる資料がすぐ尽きる
      ドキュメントはいつ改善されるのか？ リリースノートを見ると、理想的には各機能ごとに複数ページのドキュメントがあるとよさそうだ。作業量が多いことは理解しているし、完全なドキュメントは安定化後でないと難しいのかもしれない
    • 趣味のゲーム開発者として新しいプロジェクトを始めるなら、Bevy でやると思う。Love と Godot の中間あたりをうまく切り分けた感じで、Love より堅牢だが Godot ほど初心者向けではないようだ
      Bevy はどれくらい意見の強いエンジンなのか？ 機能と開発者の使いやすさの間で妥協しなければならなかったことがあるのか気になる
      今 Bevy に最も理想的なプロジェクトはどんな種類だろうか？
    • Rust と Bevy でゲームを書くと、他の言語と比べてどのような長所と短所があるのか気になる。特に性能、安全性、開発速度の面を聞きたい
    • 動的システムと一級の Bevy スクリプティングを可能にする機能は、いつ見られるだろうか？
      スクリプティングプラグインはいくつかあり、今は主に rhai に注力しているようだが、適切な Bevy サポートが不足していて行き詰まっている感じがする
      現在の Bevy の焦点が Rust 専用ゲームであれそうでなかれ、スクリプティング需要はあり、すでにサードパーティの解決策を探すのに忙しい人たちがいる。今すぐ公式 Bevy スクリプティングを期待しているわけではないが、サードパーティ crate が動作できる基盤は Bevy が受け入れるべきだと思う

  • 記事では遅延レンダリングが MSAA をサポートしないとしているが、これは素朴な実装でのみ正しい話だ
    たとえば事前パスで複雑なピクセルのステンシルマスクを作り、階層的な早期ステンシル拒否を使って、複雑なピクセルにはサンプル単位のパスを、そうでないピクセルにはピクセル単位のパスを実行できる。SIMD レーンの活用は完璧ではない
    また、複雑なピクセルマスクを処理するパスを用意して (x, y, sample) 座標バッファを集めれば、その後の単一のハイブリッドなピクセル単位/サンプル単位のコンピュートシェーダーパスで、完璧な SIMD レーン活用も可能になる

    • 興味深い。以前これを考えたことがあるが、遅すぎるだろうと仮定していた。その手法でリリースされたタイトルを知っているか気になる

  • しばらく Bevy でゲームを作っている。コードも見られるし、質問してもかまわない
    https://ant.care/
    https://github.com/MeoMix/symbiants
    これまでの悩みは、UI システムがウィジェットを快適に作るにはあまりに冗長だったので egui に切り替えたものの、1年以内にはネイティブの Bevy に戻ることになりそう、という点。egui にも大きな制約がある
    親子関係のサポートはあまり多くなく、ECS はある程度それを嫌う構造になっている。スプライトにラベルを付け、スプライトを移動・回転させつつ、ラベルは位置だけ追従して回転は追従しないようにするのが、思ったより難しかった
    セッションをまたいだエンティティの永続化は標準ではサポートされていない。Entity はクライアント側の一意性のためのもので、保存された親子関係を簡単に再生成することも自動では行われない
    まだ WASM の並列性 はサポートされていないが、Bevy のアーキテクチャは、タスクの並列化によって性能向上を得られるようにシステムの順序を柔軟にしておく設計が多い
    空間クエリは ECS の目標と衝突するように感じる。型基準、つまりエンティティが Position を持つかどうかで探すのではなく、Position の値で探したくなると、クエリエンジンと同期しなければならない補助キャッシュが大量に生まれる
    commands でワールドを変更すると、性能のためにバッチ処理されるよう遅延されるが、遅延動作が多いとワールドを積極的に変更するシステムを作るのが難しい。そのため apply_deferred を頻繁に呼び、競合状態を解決するためにカスタムコマンドを使うことになる
    Android の WASM、特に Pixel 6 と Chrome の組み合わせは現在動作しないが、下位依存関係の問題なので Bevy 13 で修正される予定
    長所は、Rust エンジンと Rust ゲームの組み合わせが非常に作業しやすく、Rust+WASM も技術に足を引っ張られている感じがほとんどないこと。頭が ECS 的に考え始めると元に戻るのが難しく、とても柔軟。もしかすると柔軟すぎるくらい
    コミュニティが活発なので問題について話せる相手を見つけやすく、ドキュメントは多くないが例は多い。将来への楽観も大きく、開発速度が速く、リリースごとに主要な懸念点をかなり前進させている

    • ちなみに ant.care は iPhone では動作しない。Safari と Firefox の両方でテストしたが、Web サイトが少ししてから無限ループで再読み込みされる

  • リリースノート がすばらしい
    熟練したゲーム／エンジン開発者にとっては一部が入門的すぎるかもしれないが、その世界に常にいるわけではない立場からすると、変更点の説明とトピック解説のバランスが非常によかった

  • Rust で書かれたゲームは5本なのに、ゲームエンジンは50個あるという冗談を見た
    実際に Bevy で作られたゲームの一覧 はあるのだろうか？

  • どのフレームワークも、より従来型の何かをシンプルでクリーンかつ高速に実装すると言って始まるが、派手な機能は不足している。
    そのうち機能面で追いつくにつれて、同じように複雑な怪物になり、その循環が繰り返される。

    • ソフトウェアプロジェクトのライフサイクルを大きく見れば妥当だが、ソフトウェアの単純さや使いやすさに関するどんな主張にもそのまま当てはめられるので、特に有用な批判には見えない。
      結論が「機能を追加するすべての使いやすいソフトウェアは失敗する運命にある」ように聞こえて、少し大げさだ。
      Bevyのアーキテクチャや機能追加の方法について、具体的な考えや懸念があるのか気になる。そうした運命を避けようと最善を尽くしている。
    • 同意しないわけではないが、Bevyにはほとんどのフレームワークにない強みであるモジュール性がある。概念だけでなく、実際にうまく機能すると証明されているモジュール性だ。
      Tiny Gladeはbevy_ecsを使っているが、Bevyのレンダリングクレートはまったく使っていない。個人的にも代替レンダリング経路、たとえばレイトレーシングやGPU駆動のメッシュレット＋可視性バッファレンダリングを実装する作業中のPRがいくつかあるが、Bevy内部はほとんど変わらない。
      ユーザー側から見ても、あまり変わらない。アプリにFeatureFooPluginを追加してFooComponentのようなものを使えば動く。
      個別のクレートやプラグインは肥大化する可能性があるが、Bevy全体は大丈夫だろう。ユーザーはそうしたプラグインを無視して、自分により合う別のものを使えばよい。
      また、これはゲームエンジンだ。定義上、肥大化して複雑な怪物であり、どこかのゲームには役立つかもしれないので、ありとあらゆる機能を吸収することになる。重要なのは、機能の肥大化が使い勝手にどう影響するかだ。機能が1000個あっても、その大半とやり取りする必要がないなら、まったく問題ない。
    • 要は、プロジェクトがAPIをシンプルでクリーンかつ高速に保つために、過去と決別する意思があるかどうかだと思う。
      後方互換性を気にする必要がない新しいプロジェクトほど簡単だという話はその通りだ。私が見たBevyには、ユーザーに良い使用感を求め、API表面を減らそうとする文化が強い。Rustのパッケージングのおかげかもしれないが、そのために過去と断絶することにかなり積極的なので、好ましく見ている。
      cargoの良いところは、Bevyに依存することにしても、将来のバージョンで壊れるとしても、動くターゲットを追いかける必要がない点だ。そのまま自分のバージョンに留まればよい。それでも最新版へ移行しやすいようにガイドも提供している。少なくとも、Bevyを少し触ってみた私の経験ではそうだった。

  • 0.10から0.11へ上げるときはアプリにかなり多くの変更が必要だったが、今回はそのままコンパイルできた。

  • Bevyは、特に大きなプロジェクトで気に入っているゲームエンジンの1つだ。Asset V2の前処理と.metaファイルが非常に有用そうに見える。
    今後のリリースでのライトマップ対応にも期待している。

  • Webの例を見ていてUIセクションを見たが、すべてキャンバス内で処理されているようだ。
    UIを代わりにDOMで作ってWASMにつなげられるだろうか？

    • 可能で、実際にそうしている例を見たことがある。UIとBevyの間で情報をやり取りする方法を作る必要がある。
      Rust、つまりWASM側ではweb_sysのような方法があり、JavaScript側ではWASM関数を呼び出す方法もあるので、選択肢は多い。