Rust 製ゲームエンジンと関連記事
abechantaRust, ECS で検索して下記がヒット。
Bevy というゲームエンジンで提供されているクラスそれぞれの、短いサンプルコードが掲載されています。
Bevy の具体的な使い方が半分くらいイメージできました。
abechantaECS の本質をもう少し理解したくて追加で検索。
元ネタをベースとした Entity と Component の C++ 実装がとても参考になりました。
元ネタに無い Unity 風 GameObject ラッパーの実装例は、私が感じていた疑問を代弁してくれたように感じました。
改めて分かったのは、どうも「データ指向」という標語が信用ならないということでしょうか。
（人によっても揺らいでそうなので、もう気にしないことに）
abechanta先のエントリーからは「元ネタと出会えて良かった」風な空気が伝わってきたので、元ネタにもアクセス。
英語を毛嫌いせず読破して、とても良かったです。
「C++ で 500 行のヘッダーのみ」というシンプルさは、強烈でありながら、ECS アプローチの本質を良く捉えているなと感じました。
読み進めるときも、コンポーネントプールの Bitset なデータ構造に無駄を感じながらだったので、UE や Unity の Archetype なデータ構造に深く納得できました。
プログラム的に見てポイントは 2 つあるな、と理解しました。
- ゲームエンジンの最小構成要素は、究極的にはただの
uint64_tで良かった（素のGameObjectですら多機能過ぎ） - 最適化のためには、①AoS から SoA への転換と、②System（ふるまい）と Entity のデカップリングを前提としている（ここからキャッシュの恩恵と、マルチスレッドの恩恵をそれぞれ享受できる）
abechantaRust, ECS で検索して下記がヒット。
さらっとした記事ですが、Amethyst というゲームエンジンにおける Entity の定義と、Component 利用の一例、System 利用の一例が紹介されています。
ECS の解説記事を読んでいると「何をコンポーネントと呼び、どんな挙動をシステムと呼ぶか」がふんわりしがちですけど、この記事を読んで少し軌道修正できました。
abechantaRust, ゲームエンジンで検索して下記の記事がヒット。
メジャーなゲームエンジンの評判についてまとめられていて、非常に参考になりました。
調査すべき対象が数倍に増えました（泣）
- Amethyst の後継が Bevy であること
- Amethyst ではデータ記述に RON(Rusty Object Notation) を採用していること
- Bevy の UI がなにやら使いやすそうであること
- Fyrox(元 rg3d、Rusty Graphics 3D?) のエディター（GUI）が多機能そうであること
- Piston は古参ながら開発が活発で、定番であること
- Piston ではイベントループでロジックが処理されること
- Nannou はややメディアアート系のものとして紹介されていた
abechanta「Amethyst の後継が Bevy」という記述の真意を確認するべく、元ネタにアクセス。
開発中止の経緯については詳しくは語られていないけど、コミュニティが拡大する中でプロジェクトの方向性が発散しがちで、創設者の当初のアジェンダからも逸脱していった結果のようです（あるいは営利的な活動や受託開発へとピボット？）
Amethyst については技術的深掘りの必要は無さそうですが、Rust でのゲーム開発のしおり（旅）という段落では、有望なプロジェクトがいくつか紹介されていました。
- Macroquad.rs はマルチプラットフォームのミニマルな 2D グラフィックライブラリ
- rg3d（現 Fyrox）はエディターを備えた 2D/3D ゲーム開発環境
- godot-rust は Rust 版の Godot エンジン（Godot スクリプト資産が流用できそう）
- Bevy は Amethyst と同じ ECS-powered なゲームエンジン
- 3D グラフィックを始めるなら wgpu はオススメ（Bevy でも採用）
- ゲームエンジンを作りたいなら Scion がオススメ。ECS-powered な 2D ゲームライブラリ（wgpu と winit を利用）
abechantaECS のことを調べた際に気になっていたので、ちょっと脱線。
ゲームエンジンのデザインパターンを解説するサイトを 10 日ほど掛けてななめ読み。
夢中で読み進めつつ、かなり衝撃を受けました。
ゲームプログラミング特有の課題と対策がとても分かりやすく具体的にまとめられていました。
ゲーム開発では多用されがちなシングルトンがアンチパターンとして紹介されている点が一番の驚きでした。
（読破後、これがとうの昔に翻訳されて書籍化されていたことを知り、茫然自失w）
abechantaArete Games という会社[1] から、Rust で実装された ECS powered な商用ゲームエンジン Arete Engine の発表がありました。
公式サイトは↓こちら。
絶賛開発中ではありますが、ライセンスは Unity に近い体系になるそうです[2]。
デモアプリ Arete: Spacer が GitHub と AppStore にアップされています。
ヴァンパイア系です。
リリースを見ると、Unified Memory Architecture に特化したレンダリングエンジンであるという点が強調されています。
ではディスクリート GPU を積んでいるデスクトップ PC ではどうなのか、というところと、「1000x faster than Unity」（Unity の 1000 倍速い）という Reddit の開発者コメント が気になります。
ECS の S（システムロジックやアルゴリズム）部分の処理グラフ構築の柔軟性と、それらを随時 CPU から GPU へとオフロードして、実行環境にアダプティブに最適化する機構（ロードバランシング）が高速化のキモのようです。
これらの実装にはとても興味をそそられますが、残念ながらソースコードを入手することは難しそうです（ビジネスするんだからそりゃそうか）。
abechantaECS がゲームデザイン（とレベルデザイン）の現場でどのように作用するかを、より具体的に示した記事（英語）が大変分かりやすいので紹介します。
タワーディフェンスゲームの実装を想定して、ランドマーク、ミサイルランチャー、敵ミサイルなどの Entity を、「どういったコンポーネントセットで構成していくか」、「どういったシステムで実装していくか」を分かりやすく説明しています。
例として提示されているシステム仕様書の体裁が良くできていて、とても明快です。
そのままゲームの実装をはじめられそうに感じました。
プレイヤーがゲーム画面からゲームのルールを認知するのと同じような観点で、このような小さなシステムを組み上げていくんですね（マイクロサービスアーキテクチャーにも似ているな）。
なおこの記事は 3 回に分かれているうちの 2 回目の投稿で、続く 3 回目では ECS の要求仕様について考察しています。
こちらも参考になります。