質問: new Walk(); public void MoveTo(Vector3 destination) { if (null != _moveLogic) { _moveLogic.MoveTo(destination); } } public void Stop() { if (null != _moveLogic) { _moveLogic.Stop(); } } } ```
回答: 私はゲームプログラミングをしませんが、この手の質問は色々な意見があった方が良いと思うので回答してみます。 Strategyパターンとしては正しい切り分けをしていると思います。表層的なクラス(今回はキャラクター)は各種状態とアルゴリズムを纏めることが要求されているので、細かい動作の変更によってこのクラスを修正するのはおかしいですよね。 ゲームの進行上キャラクターをある地点に移動させたい 1. ゲームエンジンがCharacterにアクセス CharacterがMoveInterfaceにアクセス ⇒ 〇 2. ゲームエンジンがCharacterのMoveInterfaceにアクセス ⇒ × というように私は考えるので、上記コード自体には違和感はありませんでした。 複雑なオブジェクトを構成する場合、一次的に中身がスカスカのクラスができてしまうことはあります。 ただし、MoveInterfaceは移動方法と言いつつ、座標等も管理していそうなのでもしも移動している座標を管理しているならそれはちょっと違うだろう、と思いました。移動方法は進行状況を管理するべきではありません。座標情報自体はキャラクターと紐づくべきですから、そうなるとキャラクターのインターフェースと移動アルゴリズムのインターフェースは変わってくるはずです。 他の考え方としては... キャラクターが状態だけを持っていればいいのでは?ということを気にされていると思います。 ようは、MoveKindだけキャラクターは持てばいいんじゃないのか、ということです。 3Dのゲーム等ではシーン切り替えで1人のキャラクターが複数の座標位置と紐づいたりする場合があります。 そうなると、シーン毎に座標等の状態は管理しなくてはいけなくなります。 こうなると、キャラクター自体をもっと抽象的な状態に保つために ・キャラクターに移動方法という状態を持たせる ・ゲームエンジン側で移動方法とアルゴリズムのマッチングを行い、表示したモデルを移動させる ・ゲームエンジン側がモデルとキャラクターの紐づきを把握している という切り分けが行われているんじゃないか、と思っています。 キャラクターが保持する情報に直接的なアルゴリズムが含まれていないと、簡単なフラグの切り替えだけで移動方法が変更できる等の利点もあります。 ただこれはシーン切り替えが無ければ抽象化レイヤを追加して複雑にしただけと言えますから、作るゲームの規模で考えれば良いんじゃないかと思います。 あとは強いて気になった点を挙げるならMoveInterfaceという名前でしょうか、これはC#的な名前ではないですね。