私はできる限り最善を尽くして回答しますが、確信が持てない特定の「ベストプラクティス」がありますが、できる限り明確に分類するように努めます。
FSM
まず、Minerチュートリアルは、Mat Bucklandによる例によるプログラミングゲームAIからのものです(AIの紹介として入手することをお勧めします)。彼は構造体ではなく、状態ごとに列挙型を使用します。あなたの例の構造体では、状態としてブール値を持っているので、これらを同時にいくつでもオンにすることができます。これにより、必要な動作が発生する可能性がありますが、FSM(有限状態マシン)の場合よりも、多くの場合、望ましくない動作が発生します。
例えば:
enum
{
WANDER_AROUND,
ATTACK,
RUN_AWAY,
};
第二に、それは彼が状態を説明する唯一の方法ではありません。私が個人的に好む方法(状況に応じて)は、Enter()、Exit()、およびUpdate()関数を持つStateという抽象クラスを作成することです。次に、Stateクラスのサブクラスとして状態を作成します。
この写真のように(実際にそのリンクのページ2にあります):

状態パターン
私の個人的な意見では、状態パターンはソフトウェアがいくつかの状態を持つソフトウェア設計の一部にすぎません。実装は、開発者にダウンしています。大きなswitchステートメントを使用することと、上で概説したようにすべての状態を実行する完全な状態マシンを作成することの間に、適切な違いがあるとは思いません。彼らは本質的に同じことをしています。その点で、あなたの質問の1つに対する答えは「はい」です。このページでは、状態パターンについて説明していると思います。
長所短所
状態駆動型設計の実装に使用する方法には、長所と短所があります。
If / ElseまたはSwitchステートメントの使用
長所:
- 状態の条件の追加と確認が非常に簡単
- 非常に迅速にプロトタイプを作成できます
短所:
- たくさんの状態があるとき、それは非常に醜く、非常に速く変わります。
- 遷移、状態に入る/終了するときの影響、または状態に固有の何かを追跡することは難しい
オブジェクト指向のステートマシンの使用
長所:
- 高度な拡張性-抽象状態クラスを継承する新しい状態を作成するだけです
- 簡単に保守可能-各状態は独自のクラスに存在するため、スパゲッティのようなコードを心配する必要はありません。他の状態を気にすることなく、その状態に関連付けられた条件を簡単に確認できます。
- 直感的-この種のステートマシンを使用してチームプロジェクトで作業している場合、コードを読む人にとって非常に簡単になります。特定の状態に到達するためだけに、コード行を何行も読む必要はありません(「常に、コードを管理するプログラマーが、どこに住んでいるかを知っている精神病者であるかのようにプログラムしてください!」:))
短所:
- わずかな学習曲線-この設計は、実装するときに頭が完全に丸くなるまでに時間がかかる場合があります
- 私はこの方法を好むので、正直にこれ以上考えることはできませんが、誰かがそれに追加したい場合は、コメントしてください、私はそれらを追加します。
これですべての質問に答えられるといいのですが。実際、プログラミングゲームAIの例をコピーしたばかりですが、Matはステートマシンが「ステートデザインパターン」として知られていると述べています。個人的には、私は同意しませんが、一人一人に。
それが役に立てば幸い :)