クリケット マネージャーの統計ゲームを作成しています。ゲームのボールごとのシミュレーションを作成する必要があります。ゲーム/ボールの結果は、プレーヤーの統計や、天候や選択した戦術などのその他の外的要因の影響を受けます。
私はほとんどのゲームがステート マシンとして実装できることを読んでいて、魅力的に聞こえますが、私はクリケットの初心者なので、このゲームをステート マシンとして想像することはできません。
ボールはステート マシン、試合、プレーヤー、または 3 つすべてである必要があります。また、このステート マシンを (イベントを通じて) どのように調整するのかもわかりません。
また、状態と遷移を識別するのに苦労しています。どんな助けでも大歓迎です。
だから私はあなたの質問から理解しています-あなたのクリケットマネージャーのゲームは、プレーヤーの統計（ボウラーのスキル/経験、打者のスキル/経験、フィールディング/ウィケットキーピングの統計など）と他の関連する変数に応じてボールごとに試合をシミュレートします。私の理解では、これはクリケットゲームの視覚的表現というよりもアルゴリズムエンジンになります。
さて、あなたの質問に答えてください。まず第一に、あなたがFSMを正しい方法で見ているとは思いません。FSMは、その存続期間のどの時点でも、実行可能な多くの状態の1つになるように設計されたコードです。各状態には、通常、異なる更新ルーチンがあります（それがポイントです）。また、各状態は、事前定義されたトリガー/イベントで別の状態に遷移できます。理解する必要があるのは、状態が同じエンティティに対して異なる動作を実装することです。
現在、「ほとんどのゲームはステートマシンとして実装できます」-「ステートマシン」ではなく、ステートマシンのネスト全体です。ゲーム内のいくつかのマネージャークラス、レンダラー、ゲームプレイオブジェクト、メニューシステム、多かれ少なかれすべてが独自のステートマシンで動作します。この例の目的のために、ゲームキャラクター、たとえばボクサーを想像してみてください。'CBoxer'（？）クラスにあるいくつかの状態は、'Blocking'、'TakingHit'、'Dodge'、RightUpper'、'LeftHook'などになります。
ただし、FSMは設計構造であり、目前の問題の解決策を想定する方法であることに注意してください。必ずしも使用する必要はありません。ステートマシンなしで完全なゲームを作ることができます（私は思う:)）。しかし、FSMを使用すると、コードデザインが非常に直感的でわかりやすくなり、適切なサイズのプロジェクトでコードを見つけるのは率直に言って困難です。
動作中のFSMのコードサンプルをいくつか見てみることをお勧めします。その背後にあるアイデアを理解すると、どこでもそれらを使用していることに気付くでしょう:)
最初のステップとして、クリケットのルールとボールの結果のモデルを調べて、前のボールが特定のボールにどのように影響するかを要約する必要があります。
次に、追跡する必要があるものと、それを表すためにステートマシンを使用するのが便利かどうかを特定します。たとえば、統計は通常、FSMとして追跡するのにあまり便利ではありません。
その情報を念頭に置いて、モデルを構築できるはずです。追跡する必要のある情報は、ステートマシンまたは特定の状態の内部値のいずれかです。ボール間の相互作用により、あるマシンから別のマシンに循環する遷移とイベントが決まります。