オブジェクト指向はゲームづくりに向かないのその３です。

これまで、オブジェクト指向の「継承」の仕組みと、「オブジェクトをクラスで表す」仕組みが、ゲームづくりにとっては柔軟性が低く、複雑なコードになりがちで、バグを生みやすいことを示して来ました。

では、この問題を解決するためにはどうしたら良いでしょうか？

そこで筆者が提案したいのが、Entity Component System (以下ECS)による設計です。

ECSというと、UnityのECSを想起する人が多いかも知れませんが、ここでは、一般的なECSによる設計の話をします。
また、UnityのECSでは、どちらかというと実行速度にフォーカスが当たった説明がなされがちですが、ここではECSの設計の柔軟さ、メンテナンス性の良さについて、主に話題にします。

ECSについての予備知識として、Wikipediaや、"Entities, components and systems” by Mark Jordanを軽く読んでおいた方がいいかもしれません。

では、その１で示した、見下ろし型のアクションゲームをECSで実装するとどうなるか、見ていきたいと思います。
同じ流れで、設計を進めてみます。

まず開発の初期段階では、プレイヤーと敵がいて、動かして攻撃ができる、程度を作ることになったとしましょう。
エンティティ、コンポーネント、システムの構成を図にしてみました。（クラス設計図だとイメージがつきにくいので、動作時のメモリの状態を描いています）

水色は各種コンポーネントのインスタンス、黄緑は、システムを表す関数です。

各コンポーネントにはエンティティIDが割り振られています（図の紫色の◯）。エンティティは、プレイヤー、敵などのキャラ（オブジェクト指向で言うオブジェクト）を表し、生成される度にユニークなIDが割り当てられます。

ECSでは、プログラム上にPlayer,Enemyといったクラスはありません。
この図で言えば、InputとPositionを持つエンティティは、プレイヤーとして振る舞う、AIとPositionを持つエンティティは、敵として振る舞う、という事になります。

コンポーネントは単なるデータで、機能を持ちません。様々なゲームロジックはシステムの方で記述します。
各システムの動作を見てみましょう。

Inputシステムは、Inputコンポーネントを更新するためのシステムです。
OS等の環境からキー入力を取得し、Inputコンポーネントの「進みたい方向」のデータをセットします。

AIシステムは、AIコンポーネントを更新するためのシステムです。
ここでは、AIは単に「進みたい方向」だけをデータとして持っています。
AIシステムは、Positionコンポーネント（のリスト）から、敵の位置を見つけ出し、自分の位置との差分を計算することで、「進みたい方向」をセットします。

※本当は、MoveIntent コンポーネント（進みたい方向を表すコンポーネント）を１つ作った方が良いと思いますが、ここでは簡単のために、Input,AIがそれぞれ進みたい方向を持つことにしています。

InputまたはAIの情報を元に、そのフレームでの速度を決定します。
将来的に、コリジョンの計算もここで行うことを想定しています。

Velocityの情報を元に、Positionを更新します。

一応ここまでで、プレイヤーと敵キャラが動く仕組みまでできました。

上の図を、システムとコンポーネントの関係に着目して図に描いてみると、こうなります。

システムは図の上から順番に呼ばれます。こうして見ると、各コンポーネントが何に依存して変化しているか、データが上から順番に変化しながら伝搬している様子がわかると思います。

さて、ここまでで移動の処理はできたのですが、攻撃してそれがヒットする様にするのは、さらに実装が必要になります。
新たに Animatorコンポーネント、AttackColliderコンポーネント、DefenseColliderコンポーネントを追加します。

攻撃の当たり判定はアニメーションに依存するので、Animatorコンポーネントでアニメーションのフレーム値を管理し、それに連動してコライダが変化するようになっています。

ここでは省略しますが、DefenseColliderの「ヒットしているフラグ」が立っていたら、別のシステム（Healthシステム的なもの）で、ダメージ計算とHPの減算などを行います。

ここまでで、土台の実装は完了です。

さて、開発が始まって１ヶ月が経ちました。ここで企画から「空を飛ぶ敵を作りたい」という要望が来たとします。
空を飛ぶ敵の要件は

だったとします。

次の実装に移りたいところですが、長くなってしまったので、その４で・・・