ゲーム作成に役立つオブジェクト指向６
はじめに
前回のInterpreterパターンは、
そのままではゲームに使うことはできません。
それは、
Nodeクラスに、キャラの行動パターンを記述しなければならない
からです。
それを回避する方法がVisitorパターンです。
Visitorパターンとは？
Visitorとは、「訪問者」のことです。
今回の例で言えば、敵オブジェクト(Enemy)が「訪問者」です。
そして、その受け入れ先が、構文解析クラス(Node以下)となります。
EnemyがNodeをぐるぐる回りながら、スクリプトの命令を実行する、
というようなイメージになります。
クラス図は？
前回との大きな違いは、
- ITaskインターフェース、Enemyクラスの追加
- NondeのparseメソッドのパラメータにEnemyを追加
ということになります。
ITaskというのは、タスクシステムの「タスク」ですね。
これを継承してEnemyクラスを実装します。
parseメソッドのパラメータにEnemyがあるのは、
Nodeの中をぐるぐる回るためですね。
さて、ほかにもクラスが増えていますが、
TopNode/RepeatingNodeは、「NonterminalNode」にあたり、
AttackingNode/MovingNode/ExplodingNodeは「TerminalNode」にあたります。
処理の流れは？
- Enemyクラスの生成
- Contextクラスを生成し、スクリプトを読み込ませる
- TopNodeクラスを生成し、parseメソッドにContext、thisポインタを渡す。
というのがNodeの入り口までの流れです。
そうしてNodeの中をぐるぐる回っているうちに、
「TerminalNode」に達します。
そうした場合には、パラメータのenemy.execScriptメソッドに、thisポインタを渡します。
これにより、Enemyが動き出すわけです。
なぜ、「TerminalNode」のthisポインタを渡すのかというと、
まず、
- 処理の振り分けができる
ということがあります。
（まあ、ここらへんは好みの問題ではあります。
たとえば、「TerminalNode」を１つにして、if〜else if〜で分けるという手もあります）
さらに、
例えば、攻撃したりする場合には、
「どの攻撃方法で攻撃するか？」
という情報や、
移動する場合には、
「どこに移動するのか？」
という情報が必要になります。
それを自フィールドに詰めてあげれば、
Enemy.execSpript内でパラメータを覗くことができるようになるわけです。
ということで、Visitorパターンでしたー。
