Rust はエンジン用であり、ゲーム用ではない

LogLog Gamesが最近投稿した 3年間のRustゲーム開発を終えては、Rustでゲーム開発をしている人にとって必読の記事です。小規模なインディー開発者組織と、彼らのRust開発の経験に焦点を当てています。まだ読んでいない方は、先に読んでください。または、少なくとも以下をご覧ください。 Twitterのコメント良いものが見つかると思います。☺️

素晴らしい! これで、同じ認識ができたので、これらの問題について少し議論したいと思います。ただし、ゲーム エンジン全体から始める必要はありません。良い例はたくさんあります! UI について触れてみましょう。

言語が安定して以来、熱心な開発者のさまざまなグループが 何年もかけて Rusty UI ツールキットの作成に取り組んでいます。一般的に、このプロジェクトには 2 つの見方があります。安全性と効率性を継承しながらもスタイルと読みやすさを犠牲にして Rust の借用チェッカーを採用するか、典型的な UI プログラミングに近いシステムを作成するかのどちらかです。

借用チェッカーのユーザーは、呼び出し側がアプリケーションの状態に関するすべてを指定して、それをすべてまとめる必要があるため、抽象化に異なる方法でアプローチする必要があります。これらのツールキットは、React のように動作する傾向があり、多くの場合、何らかの prop のような状態を維持します。ただし、React の場合のようにコードベースを維持するのはかなり難しいと感じます。借用チェッカーが常に邪魔をします。もう少し何かを行わないと、既存のコンポーネントを再利用するのは困難です… すぐにこれらの課題について考えることで、一部のユーザーは長い道のりを歩むことになり、 まだ終わってない。

それでも、ある程度人気があり成功している伝統的なツールキットがあります。これはマクロ依存型または型消去型です。ほとんどの「フレームワーク」はこの機能の一部を目指しており、実質的にすべての主要プレーヤーは型と状態の宣言に手続き型マクロを使用しています。型消去も一般的であり、一部の実装者はこれを大量に使用しています。 mem::transmute そして一般 unsafeこれらは必ずしも悪いというわけではありませんが、完全に別の言語を形成し始めています。これはあなたが知っていて愛しているRustのままです。便利なライブラリ、明確に定義されたルール、代数型システムを備えています。 Result、 Option、簡単な糸通し、そして技術的な（しかしよく考えられた） async フォーマット。

ただし、安全機能も無効になっています。特に実行時の問題の領域では、自由度と安全性の点で C に似ています。

この Rust は Bevy の動作方法です。

ビービーとマジック

今すぐ、 ビービーエンジン は、ゲーム開発における Rust の第一の選択肢です。これは、約 1,000 人の貢献者からなる巨大な基盤によって支えられています。ただし、Bevy は言語の限界を押し広げており、Bevy のコンパイルをやや不安定にする特定の機能があります。

まず、Bevyは型消去を多用します。プラグインシステムは、動的な型解決の概念に基づいています。追加しようとするときに、コンパイル時のリフレクションに似たものを使用します。 Plugins に Appこれらは共有オブジェクト/ライブラリ ファイルから動的にロードすることもできるため、「真の」改造が可能になります。これらはリフレクションのプロセスを通じて型消去されます。

実際、Bevyは ユーザー と リフレクションのカスタム実装マクロ システム内に組み込まれており、型消去に似た機能です。

Bevyも使用 panic!() コードベース内にかなり多くの問題があります。プラグインの追加やアプリの実行など、コンパイル時にエラーが発生するのが理想的ですが、そうではありません。代わりに、実行時に、おそらく「コールド」パスでエラーが発生し、一般的なゲームエンジンが通常の静的解析で検出する問題を引き起こします。明確にするために、これらの問題のいくつかは、次のようなもので対処できます。 PhantomData 型の状態を維持するためのジェネリック 実行前に実行できるものもありますが、多くはエンジンの奥深くに組み込まれているか、または「本物の」リフレクション（または追加の const 設備）。

他のものは修正が不可能です。例えば、プラグインシステム 動的読み込みをサポート、ほとんどのテクニックは const、コンパイル時のリフレクション、そして PhantomData マーカー タイプは、パニックに陥ることなく実装するのが困難または不可能です。

これらの便利な機能は、Rustの魔法のようなものです。マクロと型消去はどちらも型システムの範囲を厳しく制限し、コンパイラの有効性を低下させ、多くの場合、次のような問題を引き起こします。 Any 証明されていないタイプや完全にクラッシュするタイプ rustc。

私が何を言いたいのかお分かりですか? Rust を使用すると、多くのウイルスの問題が完全になくなると期待されます。 Result 代数的データ型を使用するとかなり多くのことが可能になりますが、Rust の静的解析に干渉し始めると、最も重要な機能の多くが失われます。

魔法は消えた

新しい言語が必要なようです。Bevy Engineが問題なのではなく、Rustの保証の不整合が問題なのです。主に、緩い型付けの ECSの性質。 void ポインターもほとんど同じですが、C プログラマーはジェネリックの代わりにポインターを「期待」するようになりました。Rust 開発者が同じことをするべきではないと思います。

Bevyの魔法の接着剤のもう一つの例は、タスク/並行処理システムです。今のところ、 bevy 外部をほとんどサポートしない async ユーザー側で、次のようなプラグインが役立ちます。 bevy_async_ecs そして bevy-async-taskただし、どちらもほとんどテストされておらず、追加のユーザーが必要です。

理論的には、Bevyはこれらの機能をAPIに統合することができます。ユーザーは、 async オペレーションは進行中であり、内部の問題に対して手抜きの解決策を考案する必要はない。しかし、私は「2018年版」のような Future 特に実装が急いでいる場合は、エラーが発生して人々を困らせることになります。 crossbeam （本物ではなく std APIはBevyのさまざまな部分でまだ使用されています。私はBevyにそのような抜本的な変更がもたらされるとは期待していませんし、それが必ずしも全体に影響を与えるとも思っていません。 sync/async API の分割。これは膨大な作業です。

そうですね、新しい言語が必要だと思います。それでもBevyの魔法は実行でき、そのツールを使い、代数型のような便利な構造を含めることができます。 Result、そして「ハードウェアに近い」ままです。ただし、同時実行性/非同期性や動的なプラグインの読み込みなどの複雑な問題を、ユーザーにまったく考えさせることなく処理できます。

Bevy の貢献者がそのような言語を望んでいるかどうかはわかりません。現在のエンジンはすでに大規模な取り組みであり、設計、開発、バグの新たな層を導入することになります。しかし、多くの重大な問題が完全に修正され、Bevy Engine プロジェクト内のいくつかのニッチな問題が解消されるでしょう。

6月、新たな敵

私が説明した問題は、大規模で拡張可能な Rust ライブラリを作成する際の複雑さを表しています。ただし、これらの問題はライブラリのメンテナーに害を及ぼすのではなく、ユーザーにのみ害を及ぼします。ゲームを書いたりユーザー インターフェイスを作成したりする場合、摩擦を最小限に抑えることが求められます。Rust は、ユーザーが制御できる場合にはその点で優れていますが、拡張された言語機能がなければ、普通に感じられる具体的なエンジン API を作成することは困難です。他の言語が完璧であるという意味ではありません。

• Python はインタープリタ型で、速度が遅く、Rust の優れた構成要素の一部が欠けています。ただし、使いやすさから 2D ゲームには適しています。
• GDScript には最小限のツールしかありません。Rust の優れた lint 機能と静的解析機能のほとんどが欠けています。
• C と C++ は、安全性、可読性、シンプルさの点で問題を抱えています。どちらも、信頼性の高いコードを書くための満足のいく言語機能が欠けています。
  • 安全性が多少向上したため、C++ に対してはそれほど厳しくないのですが、C++ で (または C++ 用に) エンジンを書くのは、まだ不安定な土台の上に構築しているように思えます。
• C# はゲームの作成には最適ですが、Rust や他の言語の優れたアイデアがいくつか欠けています。

私は上記の最良の特徴から学習する言語を想像しています。 Rustのような言語、June、良いスタートのように感じます。実質的にはRustですが、 グレイドン・ホーアが望んだスタイルJune はまだ完成しておらず、比較的使いやすいレベルに達するにはまだ長い道のりがありますが、近い将来、June (または派生言語) がゲーム開発の世界に浸透すると確信しています。

6月の「共有ライフタイム」は、実質的にすべての下流のケースでユーザーエクスペリエンスを大幅に改善するはずです。何よりも素晴らしいのは、著者らがRustとの相互運用性も計画していることです。ただし、これは現在、安定したABIを待っているところです。 まだ遠い 現時点では、まだ完了していません。ただし、完了すれば、すべての Rust ライブラリが利用可能になり、6 月はこのコミュニティのもう 1 つの素晴らしい部分になります。

錆の修復

Rust 自体をどう改善できるかと尋ねる人もいるでしょう。間違いなく可能ですので、それについて触れてもいいでしょう。私の考えでは、コミュニティが Rust をゲーム開発に最適なものにしたいのであれば、言語機能の強化が必要になります。具体的には、次のとおりです。

これらの問題に精通していて、それについて何かアイデアをお持ちの場合（または私が知らないことを知っている場合）、お気軽にご連絡ください。 メールで連絡する またはGitHubで 直接。言語をより良い場所に導くお手伝いをしたいと思っています。

もっと良いのは、コミュニティのために文書化することです。問題追跡システムで、よく文書化された問題がいくつか出てくるのを見たいですね。RFC や詳細な問題がない場合は、Zulip を追跡してブログ投稿を読むのが最善の選択肢です。それを修正するのは… 良いことです。🥹

これらの変更により、私たちは前進するでしょう。