開発中の 2D フレームワークについて

GameEngineDev Advent Calendar 2022 11 日目の記事です。

開発中の 2D フレームワークについて共有します。

『GameEngineDev』カレンダーの記事ですが、 2D フレームワークに関する投稿となります。スケールが落ちますがご了承ください 🙇

背景

作っているもの

開発中フレームワークの名前は inkfs 🦑 です。ライブラリを組み合わせた程度のものですから、経験者なら 2 週間程度で再現できるでしょう。

ライブラリが担当するのはメディアの処理で、ウィンドウ・インプット・グラフィクス・テキスト・オーディオなどがあたります。その上の薄いレイヤが inkfs です。

ゲームエンジンとの違い

『ゲームエンジン』は『フレームワーク』よりも大規模な開発が伴っている印象があります。アセット処理の GUI ツールが付属していたり、ブラウザやスマートフォンなど様々なプラットフォームに対応します。

あるいは低レイヤ寄りのライブラリを自作していたら、『ゲームエンジン』に当たると思います。必要な知識も段違いです。そうした感覚がぼんやり共通されている気がします。

主なモジュール

inkfs 🦑 の主なモジュールを紹介します。

1. ECS (Entity-Component-System)

inkfs 🦑 は Rust でゲームを作るためのフレームワークです。

Rust でゲームを作る際は、データの持ち方が重要です。たとえば、

グローバル変数
ゲーム開発に必要なグローバル変数は、描画コンテクストやゲームマップなどです。 Rust に継承はありませんから、コンポジションしようとなります。しかしデータのネストが深くなると、借用の分割も面倒です。
キャラデータ
ロボットや蝙蝠など、異なる種類のキャラクターデータを一括で処理したいことがあります。　trait で抽象するとポインタが増えますし、 trait の組み合わせでうまく表現できなくなる懸念があります。

これらは Entity-Component-System を使うと一気に解決します。むしろ伝統的なゲームの作り方の方が Rust ではチャレンジングだったりします。

2. Scene graph

inkfs 🦑 のシーングラフは ECS の上に作っています。

Renderable の共通コンポーネント

どの rendearble も以下のコンポーネントを持ちます:

Node
親子関係の連結リストです。
Transform (LocalTranform + GlobalTransform)
ZOrder

様々な種類の renderable

様々な renderable をコンポーネントで表現できます:

Primitive
Sprite
NineSliceSprite
Text, RasterText

アニメーションも容易に表現できます。

ソート

上の renderable は様々なデータに分かれていますが、頂点データに変えた後には同質のデータです。以下の DrawCall を作成後、 z_order でソートしてから描画しています:

pub struct DrawCall {
    pub z_order: ZOrder,
    pub verts_range: ops::Range<u32>,
    pub tex_id: rgpu::Id<rgpu::Texture>,
}

3. ウィンドウ・入力 (`sdl2`)

主なウィンドウのライブラリ

ウィンドウ表示・入力処理のライブラリとしては SDL や GLFW が有名です。

SDL が最も安心な気がします。様々なサブモジュールが付属しますが、『ウィンドウ操作のシェル』のように扱うのが良いとされています。
GLFW は "GL" とありますが OpenGL 以外のユーザも使用できます。僕は使ったことがありません。
Rust 製のライブラリとしては winit もあります。以前は macOS での動きがあまりよく無かったのですが、最近の動向はどうなのか……

入力処理

イベント駆動にするか、すべてのキー入力イベントを 1 つの Input オブジェクトに集約すると思います。僕は後者が好みです。

inkfs 🦑 では主に FNA の Input モジュールを参考に、入力状態のダブルバッファを持っています。また『仮想キー』のモジュールを作り、『Enter または Space』のようなキーを定義できるようにしています。

FPS カウンター

平均FPSを楽に近似するにある式を使うと簡単です。

僕はなぜか spike の計算が上手くいってないですが……

4. グラフィクス (`wgpu`)

もくもく

やばい

wgpu は Learn Wgpu で見ると簡単なフレームワークのようですが、所有権が絡んで独自の制限がかかります。

`wgpu::RenderPass<'w>` と借用ルール

古典的な SpriteBatch は、頂点データの作成と描画関数の呼び出しを交互に行います。しかし wgpu を使っていると、まず頂点データを作成し、それから一気に描画関数を呼び出すという形になりがちです。

この方式は pipelined rendering に繋がります。

この方式に至るのは、 wgpu::RenderPass<'w> が Drop トレイトを実装するためです。この場合 Drop Check という強烈な制約がかかり、 RenderPass のメソッドの引数はすべて RenderPass を Drop するまで immutable になる……と思います。この制限下で伝統的な SpriteBatch をそのままポートするのはたぶん無理です。

Bevy Engine から学んだこと

wgpu の典型的な使い方は Bevy Engine から学べます:

wgpu のデータ型を共有ポインタにする
Pipelined rendering
デフォルトの TextureFormat の設定方法

Uniform array
wgpu の uniform は immutable です。 1 フレームに uniform の更新を複数回実行すると、最後の更新が適用された後の unifrom がそのフレームで使用されます。複数の uniform を持つ方法として uniform array を使ってみたいと思うのですが‥‥
Texture array
Draw call を減らせそうなので気になっています。