24 時間で Rust をプレイ: 個人的な開発体験

この記事では、Rust で小さなゲームを開発した私の個人的な経験について話します。 実用的なバージョンを作成するのに約 24 時間かかりました (私は主に夕方か週末に作業しました)。 ゲームは完成には程遠いですが、この経験はやりがいのあるものになると思います。 ゲームをゼロから構築するときに学んだことと観察したことを共有します。

スキルボックスは次のことを推奨します。 XNUMX年間の実践コース 「私はプロのウェブ開発者です」.

リマインダー： 「Habr」のすべての読者が対象 - 「Habr」プロモーション コードを使用してスキルボックス コースに登録すると 10 ルーブルの割引。

なぜ錆びるのか？

私がこの言語を選択したのは、この言語について良いことをたくさん聞いており、ゲーム開発においてこの言語がますます人気があると見ているからです。 ゲームを書く前、私は Rust で単純なアプリケーションを開発した経験がほとんどありませんでした。 これは、ゲームを作成する際に自由感を与えるのに十分でした。

なぜそのゲームなのか、どんなゲームなのか？

ゲームを作るのは楽しいですよ！ もっと理由があればいいのですが、「家庭」プロジェクトでは、通常の仕事とあまり関係のないトピックを選びます。 これは何のゲームですか? Cities Skylines、Zoo Tycoon、Prison Architect、そしてテニスそのものを組み合わせたテニス シミュレーターのようなものを作りたかったのです。 一般的に、それは人々が遊びに来るテニスアカデミーについてのゲームであることが判明しました。

技術研修

Rust を使用したいと思っていましたが、使い始めるのにどのくらいの基礎作業が必要になるか正確にはわかりませんでした。 ピクセル シェーダーを作成したり、ドラッグ アンド ドロップを使用したくなかったので、最も柔軟なソリューションを探していました。

役立つリソースを見つけたので、共有します。

• もう遊んでいますか — ゲーム開発に必要な Rust 要素のリスト。
• Rust ゲーム開発サブレディット;
• 無料のピクセルアート。

いくつかの Rust ゲーム エンジンを検討し、最終的に Piston と ggez を選択しました。 以前のプロジェクトに取り組んでいたときにそれらに出会いました。 最終的に、小規模な 2D ゲームの実装には ggez の方が適していると思われたので、ggez を選択しました。 Piston のモジュール構造は、初心者の開発者 (または初めて Rust を扱う人) にとっては複雑すぎます。

ゲーム構造

私はプロジェクトのアーキテクチャについて考えることにしばらく時間を費やしました。 まずは「土地」、人、そしてテニスコートを作ります。 人々はコート内を動き回って待たなければなりません。 プレイヤーは時間の経過とともに向上するスキルを持っている必要があります。 さらに、新しい人物や法廷を追加できるエディターも必要ですが、これは無料ではなくなりました。

すべてを熟考した後、私は仕事に取り掛かりました。

ゲーム作成

始まり: 円と抽象化

ggez の例を参考にして、画面上に円を表示しました。 素晴らしい！ ここでいくつかの抽象化を行います。 ゲームオブジェクトという概念から抽象化できたらいいのにと思いました。 各オブジェクトは、次のようにレンダリングおよび更新する必要があります。

// the game object trait
trait GameObject {
    fn update(&mut self, _ctx: &mut Context) -> GameResult<()>;
    fn draw(&mut self, ctx: &mut Context) -> GameResult<()>;
}
 
// a specific game object - Circle
struct Circle {
    position: Point2,
}
 
 impl Circle {
    fn new(position: Point2) -> Circle {
        Circle { position }
    }
}
impl GameObject for Circle {
    fn update(&mut self, _ctx: &mut Context) -> GameResult<()> {
        Ok(())
    }
    fn draw(&mut self, ctx: &mut Context) -> GameResult<()> {
        let circle =
            graphics::Mesh::new_circle(ctx, graphics::DrawMode::Fill, self.position, 100.0, 2.0)?;
 
         graphics::draw(ctx, &circle, na::Point2::new(0.0, 0.0), 0.0)?;
        Ok(())
    }
}

このコード部分により、同様に優れたループで更新およびレンダリングできるオブジェクトの優れたリストが得られました。

mpl event::EventHandler for MainState {
    fn update(&mut self, context: &mut Context) -> GameResult<()> {
        // Update all objects
        for object in self.objects.iter_mut() {
            object.update(context)?;
        }
 
        Ok(())
    }
 
    fn draw(&mut self, context: &mut Context) -> GameResult<()> {
        graphics::clear(context);
 
        // Draw all objects
        for object in self.objects.iter_mut() {
            object.draw(context)?;
        }
 
        graphics::present(context);
 
        Ok(())
    }
}

main.rs にはすべてのコード行が含まれるため、このファイルが必要です。 ファイルを分離し、ディレクトリ構造を最適化するのに少し時間を費やしました。 その後の様子はこんな感じです。
リソース -> ここにすべてのアセットがあります (画像)
SRC
- エンティティ
— game_object.rs
— サークル.rs
— main.rs -> メインループ

人、床、画像

次のステップでは、人物ゲーム オブジェクトを作成し、画像を読み込みます。 すべては 32*32 タイルに基づいて構築する必要があります。

テニスコート

テニスコートがどのようなものかを研究した結果、4*2のタイルでテニスコートを作ることにしました。 当初は、このサイズの画像を作成したり、8 つの個別のタイルを組み合わせたりすることが可能でした。 しかしその後、必要な固有のタイルは XNUMX つだけであることに気付きました。その理由は次のとおりです。

このようなタイルは合計 1 つあります: 2 と XNUMX。

コートの各セクションはタイル 1 またはタイル 2 で構成されます。これらは通常どおりにレイアウトすることも、180 度反転してレイアウトすることもできます。

基本構築（組立）モード

サイト、人物、地図のレンダリングをなんとか達成した後、基本的なアセンブリ モードも必要であることに気付きました。 私はこれを次のように実装しました。ボタンが押されるとオブジェクトが選択され、クリックするとオブジェクトが目的の場所に配置されます。 したがって、ボタン 1 でコートを選択でき、ボタン 2 でプレーヤーを選択できます。

ただし、1 と 2 の意味を覚えておく必要があるため、どのオブジェクトが選択されているかを明確にするためにワイヤーフレームを追加しました。 見た目はこんな感じです。

アーキテクチャとリファクタリングに関する質問

これで、人、コート、床などのゲーム オブジェクトがいくつかできました。 ただし、ワイヤーフレームが機能するためには、各オブジェクト エンティティに、オブジェクト自体がデモンストレーション モードにあるのか、それともフレームが単に描画されているのかを通知する必要があります。 これはあまり便利ではありません。

いくつかの制限を明らかにする方法でアーキテクチャを再考する必要があるように私には思えました。

• それ自体をレンダリングおよび更新するエンティティを持つことは、そのエンティティがレンダリングすべきもの (画像とワイヤーフレーム) を「認識」できないため、問題になります。
• 個々のエンティティ間でプロパティと動作を交換するためのツール (is_build_mode プロパティや動作レンダリングなど) が不足している。 継承を使用することは可能ですが、Rust で実装する適切な方法はありません。 私が本当に必要としていたのはレイアウトでした。
• 人々を法廷に割り当てるには、エンティティ間の対話のためのツールが必要でした。
• エンティティ自体はデータとロジックの混合物であり、すぐに制御不能になってしまいました。

さらに調査してアーキテクチャを発見しました ECS - エンティティコンポーネントシステム、ゲームでよく使われます。 ECS の利点は次のとおりです。

• データはロジックから分離されています。
• 継承ではなく合成。
• データ中心のアーキテクチャ。

ECS は、次の XNUMX つの基本概念によって特徴付けられます。

• エンティティ - 識別子が参照するオブジェクトのタイプ (プレーヤー、ボール、またはその他のものである可能性があります)。
• コンポーネント - エンティティはコンポーネントで構成されます。 例 - レンダリング コンポーネント、場所など。 これらはデータ ウェアハウスです。
• システム - オブジェクトとコンポーネントの両方を使用し、さらにこのデータに基づく動作とロジックが含まれています。 例としては、レンダリング コンポーネントを使用してすべてのエンティティを反復処理してレンダリングを実行するレンダリング システムがあります。

調査した結果、ECS が次の問題を解決することが明らかになりました。

• 継承の代わりにレイアウトを使用してエンティティを体系的に整理します。
• 制御システムを通じてコードの混乱を取り除く。
• is_build_mode などのメソッドを使用して、ワイヤフレーム ロジックをレンダリング システム内の同じ場所に保持します。

ECS導入後はこうなりました。

リソース -> ここにすべてのアセットがあります (画像)
SRC
- コンポーネント
—position.rs
— person.rs
— テニスコート.rs
— フロア.rs
- ワイヤーフレーム.rs
—mouse_tracked.rs
- リソース
—mouse.rs
- システム
— rendering.rs
— constants.rs
— utils.rs
— world_factory.rs -> ワールドファクトリー関数
— main.rs -> メインループ

私たちは裁判所に人を割り当てます

ECS は生活を楽にします。 これで、エンティティにデータを追加し、そのデータに基づいてロジックを追加する体系的な方法ができました。 そしてこれにより、法廷内の人の配置を整理することが可能になりました。

私が何をした：

• 割り当てられた裁判所に関するデータを個人に追加しました。
• 分散した人々に関するデータを TennisCourt に追加しました。
• CourtChoosingSystem を追加しました。これにより、人々とコートを分析し、利用可能なコートを検出し、そこに選手を分配することができます。
• 裁判所に割り当てられた人を探し、そこにいない場合は、必要な場所に人を送ります。

要約

このシンプルなゲームに取り組むのが本当に楽しかったです。 さらに、Rust を使用して書いてよかったと思います。その理由は次のとおりです。

• Rust は必要なものを提供します。
• Rust には優れたドキュメントがあり、Rust は非常にエレガントです。
• 一貫性はクールです。
• 私が C++ でよく行っていた、クローン作成、コピー、またはその他の同様の操作に頼る必要はありません。
• オプションは非常に使いやすく、エラーをうまく処理します。
• プロジェクトがコンパイルできた場合、99% の確率で、正しく動作します。 コンパイラのエラー メッセージは、私が見た中で最高のものだと思います。

Rust でのゲーム開発はまだ始まったばかりです。 しかし、Rust を誰にでも公開するために取り組んでいる、安定したかなり大規模なコミュニティがすでに存在します。 したがって、私はこの言語の将来を楽観的に見ており、私たちの共通の取り組みの結果を楽しみにしています。

スキルボックスは次のことを推奨します。

• オンラインコース 「職業フロントエンド開発者」.
• 実践コース 「モバイルデベロッパーPRO」.
• 実践一年コース 「0からPROまでのPHP開発者」.

出所： habr.com