インターフェースとリフレクションを利用した移動タイプ管理の設計例

はじめに

　タクティカルバトル(シミュレーション)ゲーム開発において、「移動タイプ」を柔軟に管理したいという要望は非常に多いと思います。
タイルマップ(Tilemap)を利用した実装にもおいても、きっと同じ悩みがあるでしょう。

　たとえば、歩兵、騎兵、飛行兵などの「兵種」によるもの、あるいは軽歩、鈍歩、飛行などの「歩行タイプ」によるものなど、ゲーム内容により様々な「移動タイプ」があると思います。
加えて地形の影響を受けるかどうかで処理が変わる(移動範囲が変わる)ため、それぞれに応じた移動ロジックを用意する必要があります。
例えば、水辺には侵入できない兵種がある、山を通過するには移動コストが多くかかる兵種がある、といったケースです。

　このような設計においては、enum と switch 文による分岐による実装が多いかと思います。

　本記事では代わりにインターフェースを用いた拡張性の高い実装と、リフレクションを活用して型のインスタンスを動的に生成する方法(ファクトリーパターン(Simple Factory))を紹介します。
これにより、switch 文を使わない、変更に強い設計が可能になります。

課題

　この記事では、タイルマップを利用する前提で、移動タイプは兵種をベースに進めていきます。

　まず兵種について、MoveTypeEnum という enum 型を用意しておきます。兵種が増えた際には列挙子の追加を行います。
それを CharaData クラス内に MoveTypeEnum という enum 型の変数として宣言されているとします。

MoveTypeEnum.cs

/// <summary>
/// 兵種の種類
/// </summary>
public enum MoveTypeEnum {
    Infantry,   // 歩兵
    Cavalry,    // 騎兵
    Flying      // 飛行兵

　　// TODO 兵種が増えたり減ったりしたら追加・修正する

}

CharaData.cs(抜粋)

/// <summary>
/// キャラのデータ
/// </summary>
using System.Collections.Generic;

[System.Serializable]
public class CharaData {

    public int charaId;
    public int movePower;           // 移動力
    public string name;

    public MoveTypeEnum moveType;   // 移動タイプ
}

　さて兵種ごとに異なる移動ルールとして、兵種には以下のような違いがあるとします。

＜仮の設定＞

　・歩兵：山は通れない
　・騎兵：森で移動コストが上がる
　・飛行兵：すべての地形を無視して移動できる

　こちらの要件を満たすため、switch 文と enum を組み合わせた方法の実装例です。

// キャラの移動タイプを見て判定
switch (charaData.moveType) {

    // 歩兵の場合
    case MoveTypeEnum.Infantry:

　　　　// 歩兵の移動可能なタイルや、移動コストを算出(山は通れない)

        break;

    // 騎兵の場合
　　case MoveTypeEnum.Cavalry:
    
　　　　// 騎兵の移動可能なタイルや、移動コストを算出(森で移動コストが上がる)

        break;

　　// 飛行兵の場合
    case MoveType.Flying:

　　　　// 飛行兵の移動可能なタイルや、移動コストを算出(すべての地形を無視して移動できる)

        break;


    // TODO もしも移動タイプが追加されたら、ここに追加していく

}

　このように enum と switch を使った場合、新しい移動タイプの追加・削除のたびに、switch文(計算ロジック)を修正する必要があります。

　またこれは残念ながら「オープン/クローズド原則」に反してしまっています。（コードは拡張に開かれ、修正に閉じているべき）

解決策例①　－インターフェースの活用－

　こういったケースにおいては、インターフェースを活用することで、拡張性を保ちつつ、責務を分離した形で設計と実装を行うことが可能です。

　今回は IMoveType インターフェースを作成し、２つのメソッドを定義しています。
またここではタイルマップ用のクラスとして、別の記事にある AdvancedTile クラスを利用しています。

　　→　Tilemap の移動コスト管理方法例

IMoveType.cs

using UnityEngine.Tilemaps;

/// <summary>
/// 各兵種の移動タイプが実装するインターフェース。タイルが移動可能か、移動コストを取得できる。
/// </summary>
public interface IMoveType {

    /// <summary>
    /// 指定タイルに侵入できるかどうかを返します。
    /// </summary>
    /// <param name="tile">対象タイル</param>
    /// <returns>侵入可能か</returns>
    bool IsWalkable(TileBase tile);

    /// <summary>
    /// タイルに侵入する際の移動コストを返します。
    /// </summary>
    /// <param name="tile">対象タイル</param>
    /// <returns>移動コスト</returns>
    int GetMoveCost(TileBase tile);
}

　インターフェースではメソッドの内部実装は行いません。各クラスにおいて振る舞いを変える形で書きます。

　こちらのインターフェースを実装したクラスを、移動タイプの数だけ作成して、そちらに移動タイプごとの処理を実装するようにします。
これにより、歩兵や飛行兵は以下のようにそれぞれのクラスとして定義できます。

＜歩兵の移動タイプ＞

InfantryMoveType.cs

using UnityEngine.Tilemaps;

public class InfantryMoveType : IMoveType {

    public bool IsWalkable(TileBase tile) {

　　　　// tile 変数の型が AdvancedTile クラスである場合
        if (tile is AdvancedTile advTile) {

            // 山は歩兵は通れない、それ以外は通れる
            return advTile.terrainType != TerrainType.Mountain;
        }

        return false;
    }

    public int GetMoveCost(TileBase tile) {

　　　　// tile 変数の型が AdvancedTile クラスではない場合
　　　　if (tile is not AdvancedTile advTile) {
        　　return 1;
　　　  }

　      return advTile.terrainType switch {
            TerrainType.Plain => 1,
            TerrainType.Water => 1,
            TerrainType.Forest => 2,
            TerrainType.Mountain => 999, // 通れない扱い
            _ => 1,
        };
    }
}

＜騎兵の移動タイプ＞

CavalryMoveType.cs

using UnityEngine.Tilemaps;

public class CavalryMoveType : IMoveType {

　　public bool IsWalkable(TileBase tile) {

　　　　// tile 変数の型が AdvancedTile クラスである場合
    　　if (tile is AdvancedTile advTile) {
        　　// どの地形も通れる
        　　return true;
    　　}
　　}

    public int GetMoveCost(TileBase tile) {

　　　　// tile 変数の型が AdvancedTile クラスではない場合
　　　　if (tile is not AdvancedTile advTile) {
        　　return 1;
　　　  }

　      return advTile.terrainType switch {
            TerrainType.Plain => 1,
            TerrainType.Water => 1,
            TerrainType.Forest => 2,
            TerrainType.Mountain => 1,
            _ => 1,
        };
    }
}

<飛行兵の移動タイプ>

　こちらのみ引数を AdvancedTile にして、処理内部を簡潔化していますが、ほかの MoveType と同じようにも書けます。

FlyingMoveType.cs

public class FlyingMoveType : IMoveType {
    public bool IsWalkable(AdvancedTile tile) => true; // 飛行はすべて通過可能
    public int GetMoveCost(AdvancedTile tile) => 1;    // 飛行は常に1コスト
}

　このようにして MoveTypeEnum の列挙子に合わせた形で、IMoveType インターフェースを実装したクラスを用意します。

　移動タイプの各クラス名は、【MoveTypeEnum 内の列挙子の名前＋ MoveType】の書式で合わせておきます。(MoveType はクラス名と合わせるために付けています。)
このように書式を統一しておくことで、リフレクションの機能を合わせて利用することが容易になるためです。

補足①　－なぜインターフェースを使うのか？ー

　１．責務を分けられる：
　　　　　兵種ごとの移動ルールを、キャラやマネージャーから独立して管理できる。

　２．変更に強い：
　　　　　新しい兵種を追加しても、他のコードには一切手を加えずに済む。

　３．テストがしやすい：
　　　　　それぞれの移動ロジックだけを個別にテスト可能。

　４．コードが見やすい：
　　　　　switch文が不要になり、条件分岐が減って読みやすくなる。

　この設計では、新しい移動タイプが増えた場合にはプログラムを修正することはせず、
IMoveType インターフェースを実装したクラスを１つ追加すれば拡張が可能です。

　また処理の修正を行う場合にも各クラスのみで済むため、修正による影響範囲を最小限に抑えることが可能です。

補足②　－タイル自体に「通れるかどうか」を持たせると何が起こるのか？－

　持たせたい気持ちはわかりますが、それは「誰にとって通れるのか？」という問いに答えられません。

　歩兵にとって通れない場所でも、飛行兵は自由に移動できることが多いでしょう。
そのため、タイル単体での判定では柔軟性に欠ける設計になります。
「どの兵種がそのタイルを通れるか」という判断は、タイルではなく、兵種（IMoveType）側が持つべき責務です。

　よって、よりよい解決方法としましては、通行判定とコストのロジックをタイルから切り離し、兵種側（IMoveType 実装クラス）に持たせることで、責任の分離ができます。

解決策例②　ーリフレクションの活用ー

　C# にはリフレクションという機能があります。
その１つに、string 型の文字列をクラス名(型名)に置き換えて、同名の型情報がプロジェクト内に存在する場合には
インスタンスを動的に生成する Activator.CreateInstance メソッドが用意されています。

　今回のように兵種を enum(あるいは string)として持っている場合、以下のようにしてクラス名から動的にインスタンス化できます。

　例えば、Cavalry という enum の列挙子を string 型に置き換えて、そのあとに MoveType をくっつけます。
そうすることで、先ほど作成したクラス名と同じ CavalryMoveType という名前の文字列になります。

　これを「クラス名(型名)」として調べて、同じ名前のクラス名が存在しているなら、それを CavalyMoveType のインスタンスとして生成する、という処理です。

using System;
using UnityEngine;

public static class MoveTypeFactory {

    /// <summary>
    /// 移動タイプに応じた MoveType の生成
    /// </summary>
    /// <param name="moveType"></param>
    /// <returns></returns>
    public static IMoveType Create(MoveTypeEnum moveType) {

        // Enum 名 + MoveType の文字列を作成して、クラス名と照合させる
        string className = $"{moveType}MoveType";  // 必要に応じて NameSpace を追加
        Type type = Type.GetType(className);

        // type が特定のインターフェース(IMoveType)を含んでいるか判定(Type.IsSubclassOf ではインターフェースは調べられない)
        if (type != null && typeof(IMoveType).IsAssignableFrom(type)) {

            // リフレクションを利用してインターフェースを実装しているクラスのインスタンスを作成
            return Activator.CreateInstance(type) as IMoveType;
        }

        Debug.Log($"MoveType クラス {className} が見つかりません");
        return null;
    }
}

　CharaData クラスに設定されている MoveTypeEnum 型の情報は、あくまでも Enum 型であり、これをそのまま使うとなると、最初に提示したような switch 文などによる分岐を作らざるを得なくなります。

　そこで今回は、この MoveTypeEnum 型の情報を利用し、事前に用意しておいた IMoveType インターフェースを実装したクラスとして使えるように処理しているのが、上記のリフレクションを活用した処理になります。

　こうすることで、CharaData には、MoveTypeEnum 型に応じた移動タイプの情報を処理できるクラスが追加されますので、
あとはこのクラスを活用して、歩兵の移動であったり、騎兵の移動であったりを表現していくことが可能になります。

インターフェースとリフレクションの注意点

インターフェースの注意点

　抽象的な設計になるため、全体像を把握していないとどこで何が使われているか分かりづらくなることがあります。

　初期段階では実装が増えて煩雑に見えることもありますが、拡張性を意識した設計には不可欠です。

　特に明確な責務を意識して設計すれば、長期的にメンテナンス性が高くなります。

リフレクションの注意点

　文字列で型を指定するため、型名の変更やミススペルにより null が返る可能性(実行時エラーになる可能性がある（＝エディタ上で検知できない）)があります。

　また頻繁にリフレクションを使うと、パフォーマンスに悪影響を及ぼすことがあります。
基本的には初期化時だけに使用し、以後はキャッシュして使い回しましょう。
今回のケースでは初期化時のみですので、特に問題ありませんが、実行数は少ないに越したことはありません。

　またアセンブリや名前空間などにも考慮する必要があります。
今回は名前空間を利用していませんが、名前空間内にクラスが存在しているのであれば、【名前空間.クラス名】の書式(完全修飾子名)で指定を行わないとクラスを見つけることができません。

実装例

　CharaUnit クラスを作成します。

　こちらは実際に画面に配置されるキャラ用のオブジェクトにアタッチする前提のクラスです。このオブジェクトはプレハブで利用する可能性も高いでしょう。

CharaUnit.cs(抜粋)

using System.Collections.Generic;

public class CharaUnit : MonoBehaviour {
    public CharaData charaData;
    public OwnerType ownerType;

    public IMoveType moveType;


　　// テスト用
    void Start() {
        Initialize(charaData);    
    }

    public void Initialize(CharaData charaData) {
        this.charaData = charaData;

        moveType = MoveTypeFactory.Create(charaData.moveType);
        Debug.Log(moveType);

        // TODO ターン購読
        // プレイヤーのターンになったらリフレッシュする

    }
}

　こちらをキャラ用のゲームオブジェクトにアタッチして、Start メソッドを利用してテストを行います。
実際には Start メソッドではなく、このプレハブを生成し、その後 Initialize メソッドを実行する、という処理の流れになると思います。

　CharaData の情報はインスペクターで設定可能ですので、MoveTypeEnum 型の moveType を任意の列挙子に変更してください。

　あとはゲームを実行して、リフレクションを利用して、IMoveType インターフェースを実装したクラスのインスタンスを生成されるかを確認します。
たとえば、Cavalry を設定しているなら、CavalryMoveType のインスタンスの生成が目標です。

　Debug.Log メソッドを記述してありますので、Console ビューを確認し、moveType 変数で指定した名前を持つクラス名が表示されれば、無事にインスタンスの生成が成功です。

　例えばタイルマップを使ったゲームであれば、各 CharaUnit クラスの～ MoveType クラスにアクセスすれば、IsWalkable メソッドにより移動できるタイルを各移動タイプごとに判定できますし、
GetMoveCost メソッドにより、タイルの地形に合わせた移動タイプごとの移動コストを取得することが可能です。

改良案　－リフレクションで生成したインスタンスをキャッシュして再利用する－

　無事にリフレクションの処理が動いて MoveType クラスのインスタンスが生成されたら、次は MoveTypeFactory クラスを改良してみましょう。

　現在のリフレクションの処理は、CharaUnit 1体につき、１つのインスタンスを生成するようになっています。
そのため、ゲーム内に CharaUnit が20体生成されれば、同じ数だけリフレクションが実行されて、20のインスタンスが生成される仕組みです。

　ですが、今回の場合、それぞれのインスタンスはステート（内部状態）を持たないクラスです。
移動可能かどうかやコストの算出は、毎回同じ条件で同じ結果が出る処理なので、こういったケースではシングルトン的に、同じインスタンスを何度も使い回した方が効率的です。

　つまり、CharaUnit が20体いたとしても、MoveType のクラスは現在のところ3種類しかなく、また処理の結果も同じになる(個別に Hp が異なるといった設定値がない)ので、
20個のインスタンスを作るのは無駄な処理なのではないか？　ということです。
　
　そこで、各 MoveType クラスを１つずつだけインスタンス化して、それを再利用する方法に修正してみましょう。

　まず Dictionary を新しく宣言し、enum の列挙子(Key)と対応するクラス(Value)をマッピング(関連付け)できるようにしておきます。
例えば、Flying(enum) と FlyingMoveType(IMoveType インターフェースを実装したクラス) が１セットになっている形です。
こういった形になっている1まとまりをマッピングと呼びます。

　これをゲーム開始時に１回だけ処理したいので、新しくコンストラクタを作成し、その初期化処理内で列挙子の数だけ繰り返して、最初にインスタンスを作成しておきます。

　あとは、CharaUnit ごとに、そのインスタンスの参照をもらって使うためのメソッドを用意します。

　このように改良することで、例えば、CharaUnit が20体いる場合、今までであれば同じ MoveType であってもインスタンスをするので計20回のリフレクションが必要でしたが、
最初に enum の列挙子の数だけリフレクションでインスタンスを生成しておいて、あとは CharaUnit 側には参照させるだけ、という構造に変化しました。

　今後は CharaUnit の数に関係なく、すでにキャッシュされている必要な MoveType を渡すだけで済むようになりますので、
ゲーム開始時以外にはリフレクションを実行する必要もなくなり、大変効率的な処理が出来上がります。

MoveTypeFactory.cs

using System;
using System.Collections.Generic;
using UnityEngine;

public static class MoveTypeFactory {

    private static readonly Dictionary<MoveTypeEnum, IMoveType> _cache = new();   // enum の列挙子と、対応するクラスをマッピングして、インスタンスをキャッシュしておく

    /// <summary>
    /// コンストラクタ
    /// </summary>
    static MoveTypeFactory() {

        // すべての列挙子の数だけ処理する
        foreach (MoveTypeEnum moveType in Enum.GetValues(typeof(MoveTypeEnum))) {
            
            // リフレクションを利用してインスタンス作成(すでにある Create メソッドを利用)
            var instance = Create(moveType);

            // 作成できた場合のみ Dictionary に追加してキャッシュしておく
            if (instance != null) {
                _cache[moveType] = instance;
            }
        }
    }

    /// <summary>
    /// 外部クラスから利用
    /// キャッシュから該当する IMoveType を取得
    /// </summary>
    /// <param name="moveType"></param>
    /// <returns></returns>
    public static IMoveType Get(MoveTypeEnum moveType) {

        // 該当する MoveType が存在するかチェックし、存在している場合には、その MoveType の参照を返す
        if (_cache.TryGetValue(moveType, out var instance)) {
            return instance;
        }

        Debug.Log($"MoveType {moveType} は未定義です");
        return null;
    }

    /// <summary>
    /// リフレクションで移動タイプに応じた MoveType クラスを生成(外部からも使える汎用メソッド)
    /// </summary>
    /// <param name="moveType"></param>
    /// <returns></returns>
    public static IMoveType Create(MoveTypeEnum moveType) {

        // Enum 名 + MoveType の文字列を作成して、クラス名と照合させる
        string className = $"{moveType}MoveType";  // 必要に応じて NameSpace を追加
        Type type = Type.GetType(className);

        // type が特定のインターフェース(IMoveType)を含んでいるか判定(Type.IsSubclassOf ではインターフェースは調べられない)
        if (type != null && typeof(IMoveType).IsAssignableFrom(type)) {

            // リフレクションを利用してインターフェースを実装しているクラスのインスタンスを作成
            return Activator.CreateInstance(type) as IMoveType;
        }

        Debug.Log($"MoveType クラス {className} が見つかりません");
        return null;
    }
}

　今回のような形での実装に改良することにより、リフレクションのコスト削減が行えています。
リフレクションは実行時に動的に型情報を取得してインスタンスを作成するため、パフォーマンスコストが高い処理です。

　今回はキャラの初期化時のみではありますが、やはり可能な限り、少ない処理数の方がよいです。

　・最初の一度だけリフレクションで生成し、
　・あとは Dictionary<MoveTypeEnum, IMoveType> 経由で使い回す(再利用)

　インスタンスを再利用させることで、大幅なコスト削減になります。

　また、リファクタリング・デバッグのしやすさも向上します。
すべての MoveType が MoveTypeFactory で管理されるようになるため、

　・どこで何が使われているかが一元管理できる
　・不要な MoveType を見つけやすい
　・新しい型の追加にも強くなる

　こういったメリットも上げられます。

　次に CharaUnit クラス側の MoveTypeFactory への呼び出し命令 Create メソッドから Get メソッドに置き換えます。

CharaUnit.cs(抜粋)

using System.Collections.Generic;

public class CharaUnit : MonoBehaviour {
    public CharaData charaData;
    public OwnerType ownerType;

    public IMoveType moveType;


　　// テスト用
    void Start() {
        Initialize(charaData);    
    }

    public void Initialize(CharaData charaData) {
        this.charaData = charaData;

        //moveType = MoveTypeFactory.Create(charaData.moveType);

        // こちらに置き換え
        moveType = MoveTypeFactory.Get(charaData.moveType);


        Debug.Log(moveType);

        // TODO ターン購読
        // プレイヤーのターンになったらリフレッシュする

    }
}

　以上で完成です。

　こちらで同じようにゲームを実行して処理が正常に動作するかを確認してみてください。

　最後に注意点です。

　まず前提として、IMoveType インターフェースを実装したクラスが状態を保持しない設計であること（＝再利用可能であること）。
クラスが Hp や攻撃力といった変数などを持ち、インスタンスごとにその都度値が変化してしまうと、処理結果が異なる結果となるため、再利用ができない状態になります。

　もし将来、兵種ごとにカスタマイズ可能な MoveType を作る場合（＝状態を持つ場合）は、この方式では再利用ができません。
その場合は毎回 new する必要があります。(改良前のように、毎回 Create メソッドを使ってリフレクションを利用する)

　複数スレッドで使う場合はスレッドセーフ設計に注意ですが、基本的には Unityの通常用途では問題はありません。

まとめ

　拡張性を意識した設計をしたい方にとって、インターフェースとリフレクションはとても強力な武器になります。
ゲーム開発において「仕様の追加・変更」が頻繁に起こる場面では、特に威力を発揮する考え方です。

　今後は、移動だけでなく攻撃やスキルなどにもこの考え方を応用していくことで、プロジェクト全体の拡張性をさらに高めることができます。

このページを編集するこのページを元に新規ページを作成

印刷する

コメント（0）

インターフェースとリフレクションを利用した移動タイプ管理の設計例 - i-school 先頭へ

コメントをかく

名前	ユーザIDを使用しないで書き込む	ユーザーIDを使う	ログインする
画像コード	画像に記載されている文字を下のフォームに入力してください。
備考	「http://」を含む投稿は禁止されています。
本文
利用規約をご確認のうえご記入下さい

i-school