ゲーム状態「スタック」？

ゲームの状態をゲームに実装する方法を考えていました。主なものは次のとおりです。

• 半透明の上位の状態-一時停止メニューから背後のゲームまで見ることができる

• OO-Iの何かは、これをより簡単に使用し、背後にある理論を理解し、組織化を維持し、さらに追加することに気付きます。

リンクリストの使用を計画しており、スタックとして扱いました。これは、半透明のために以下の状態にアクセスできることを意味します。
計画：状態スタックをIGameStatesへのポインターのリンクリストにする。一番上の状態は独自の更新コマンドと入力コマンドを処理し、その下の状態を描画するかどうかを決定するメンバーisTransparentを持っています。
それから私はできました：

states.push_back(new MainMenuState());
states.push_back(new OptionsMenuState());
states.pop_front();

プレーヤーの読み込みを表すために、オプションに移動してから、メインメニューに進みます。
これはいいアイデアですか、それとも...？他の何かを見るべきですか？

ありがとう。

coderangerと同じエンジンで作業しました。私は異なる視点を持っています。:)

まず、FSMのスタックがありませんでした-状態のスタックがありました。状態のスタックは単一のFSMを作成します。FSMのスタックがどのようになるかはわかりません。おそらく複雑すぎて実用的ではありません。

私たちのグローバルステートマシンの最大の問題は、ステートのセットではなく、ステートのスタックであったことです。これは、たとえば、... / MainMenu / Loadingが... / Loading / MainMenuとは異なることを意味します。これは、ロード画面の前または後にメインメニューが表示されたかどうかによって異なります（ゲームは非同期で、ほとんどがサーバー駆動です）。

これが見苦しい2つの例として：

• LoadingGameplay状態などにつながったため、Gameplay状態内で読み込むためのBase / LoadingとBase / Gameplay / LoadingGameplayがあり、通常の読み込み状態で多くのコードを繰り返す必要がありました（ただし、すべてではなく、 ）。
• 「キャラクター作成者の場合はゲームプレイに、ゲームプレイの場合はキャラクターセレクトに、キャラクターセレクトの場合はログインに戻る」などのいくつかの機能がありました。同じインターフェースウィンドウを異なる状態で表示したいが、戻る/進むボタンは引き続き機能します。

名前にもかかわらず、それはあまり「グローバル」ではありませんでした。ほとんどの内部ゲームシステムは、内部状態を追跡するためにそれを使用しませんでした。これは、他のシステムで状態をいじりたくないためです。他のユーザー、たとえばUIシステムは、これを使用できますが、状態を独自のローカル状態システムにコピーする場合にのみ使用できます。（UI状態のシステムには特に注意が必要です。UI状態はスタックではなく、実際にはDAGであり、その上に他の構造を強制しようとすると、使用するのがイライラするUIしか作成されません。）

ゲームフローが実際にどのように構成されているかを知らないインフラストラクチャプログラマからコードを統合するためのタスクを分離したので、パッチャーを書いている人に「Client_Patch_Updateにコードを入れて」、グラフィックを書いている人に「Client_MapTransfer_OnEnterにコードを入れて」ロードすると、問題なく特定のロジックフローを交換できます。

サイドプロジェクトでは、スタックではなく状態セットで幸運がありました。無関係なシステム用に複数のマシンを作成することを恐れず、「グローバルな状態」のtrapに陥ることを拒否しますグローバル変数を使用して物事を同期するための複雑な方法-確かに、あなたはいくつかの締め切り近くでそれを行うことになりますが、それをあなたの目標として設計しないでください。基本的に、ゲーム内の状態はスタックではなく、ゲーム内の状態はすべて関連しているわけではありません。

GSMはまた、関数ポインターと非ローカル動作が行う傾向があるため、物事のデバッグをより困難にしましたが、そのような大きな状態遷移のデバッグは、それができる前はあまり面白くありませんでした。状態スタックの代わりに状態セットは実際にはこれを助けませんが、あなたはそれに注意する必要があります。関数ポインターではなく仮想関数は、それをいくらか軽減するかもしれません。

これは、非常に役立つことがわかったgamestateスタックの実装例です。http：//creators.xna.com/en-US/samples/gamestatemanagement

C＃で記述されており、コンパイルするにはXNAフレームワークが必要ですが、コード、ドキュメント、ビデオを確認するだけでアイデアを得ることができます。

状態遷移、透過状態（モーダルメッセージボックスなど）、および読み込み状態（既存の状態のアンロードと次の状態の読み込みを管理する）をサポートできます。

私は（C＃以外の）趣味のプロジェクトで同じ概念を使用しています（確かに、大規模なプロジェクトには適さないかもしれません）。

これは、使用するFSMのスタックに似ています。基本的には、各状態にエンター、イグジット、ティック機能を与え、それらを順番に呼び出します。ロードなどの処理にも非常に適しています。

「Game Programming Gems」ボリュームの1つには、ゲームの状態を対象としたステートマシンの実装が含まれていました。http://emergent.net/Global/Documents/textbook/Chapter1_GameAppFramework.pdfには、小さなゲームで使用する方法の例がありますが、Gamebryo固有のもので読みやすいものであってはなりません。

議論に少し標準化を加えるために、この種のデータ構造の古典的なCS用語はプッシュダウンオートマトンです。

状態システムの機能を制限するだけでなく、スタックが完全に必要かどうかもわかりません。スタックを使用すると、いくつかの可能性の1つに状態を「終了」できません。「メインメニュー」から始めて「ゲームの読み込み」に移動するとします。保存したゲームを正常に読み込んだ後に「一時停止」状態に移行し、ユーザーが読み込みをキャンセルした場合は「メインメニュー」に戻ります。

終了時に追跡する状態を指定するだけです。

現在の状態より前の状態に戻りたい場合、たとえば「メインメニュー->オプション->メインメニュー」や「一時停止->オプション->一時停止」の場合、起動パラメータとして状態に渡します。戻る状態。

遷移などの別の解決策は、宛先エンジンとソースステートをステートマシンと共に提供することです。ステートマシンは、「エンジン」にリンクされる可能性があります。真実は、ほとんどのステートマシンはおそらく手元のプロジェクトに合わせて調整する必要があるでしょう。1つのソリューションがこのゲームまたはそのゲームに利益をもたらす可能性があり、他のソリューションがそれを妨げる可能性があります。

class StateMachine
{
public:
    StateMachine(Engine *);
    void Push(State *);
    State *Pop();
    void Update();
    Engine *GetEngine();

private:
    std::stack<State *> _states;
    Engine *_engine;
};

状態は、現在の状態とマシンをパラメーターとしてプッシュされます。

void StateMachine::Push(State *state)
{
    State *from = 0;
    if (!_states.empty()) from = _states.top();
    _states.push(state);
    state->Enter(this, from);
}

状態は同じ方法でポップされます。Enter()下位を呼び出すかどうかStateは実装の問題です。

State *StateMachine::Pop()
{
    _ASSERT(!_states.empty());
    State *state = _states.top();
    State *to = 0;
    _states.pop();
    if (!_states.empty()) to = _states.top();
    state->Exit(this, to);
    return state;
}

入力、更新、または終了するときに、State必要なすべての情報を取得します。

void SomeGameState::Enter(StateMachine *sm, State *from)
{
    Engine *eng = sm->GetEngine();
    eng->GetKeyboard()->KeyDown.Bind(this, &SomeGameState::KeyDown);
    LoadLevelState *state = new LoadLevelState();
    state->SetLevel(eng->GetSaveGame()->GetLevelName());
    state->Load.Bind(this, &SomeGameState::OnLevelLoaded);
    sm->Push(state);
}

void SomeGameState::Update(StateMachine *sm)
{
    Engine *eng = sm->GetEngine();
    float time = eng->GetFrameTime();
    if (shouldExit)
        sm->Pop();
}

void SomeGameState::Exit(StateMachine *sm, State *from)
{
    Engine *eng = sm->GetEngine();
    eng->GetKeyboard()->KeyDown.UnsubscribeAll(this);
}

いくつかのゲームで非常によく似たシステムを使用しましたが、いくつかの例外を除いて、優れたUIモデルとして機能します。

発生した唯一の問題は、特定の場合に新しい状態をプッシュする前に複数の状態をポップバックすることが必要な場合です（通常はUIが悪いため、UIをリフローして要件を削除します）。線形フロー（データを次の状態に渡すことで簡単に解決できます）。

実際に使用した実装はスタックをラップし、更新とレンダリングのロジック、およびスタックの操作を処理しました。スタックの各操作は、状態のイベントをトリガーして、発生した操作を通知します。

スワップ（リニアフローの場合はポップ＆プッシュ）やリセット（メインメニューに戻る、またはフローを終了する）などの一般的なタスクを簡素化するために、いくつかのヘルパー関数も追加されました。

これは、ほとんどすべてのプロジェクトで採用しているアプローチです。非常にうまく機能し、非常にシンプルだからです。

私の最新のプロジェクトSharplikeは、制御フローをこのように正確に処理します。私たちの状態はすべて、状態が変化したときに呼び出される一連のイベント関数と結びついており、同じ状態マシン内に複数の状態のスタックを持ち、それらの間で分岐できる「名前付きスタック」の概念を特徴としていますツール、および必要ではありませんが、持っていると便利です。

Skizzによって提案された「コントローラーが終了時にどの状態に従うべきか」と言うパラダイムに注意してください。構造的に健全ではなく、ダイアログボックスのようなものを作成します（標準のスタック状態パラダイムでは、状態サブクラス（新しいメンバーを含む）、呼び出し状態に戻ったときにそれを読み取る）、必要以上にはるかに困難です。

基本的に、この正確なシステムをいくつかのシステムで直交的に使用しました。たとえば、フロントエンドおよびゲーム内メニュー（別名「一時停止」）状態には、独自の状態スタックがありました。ゲーム内のUIもこのようなものを使用していましたが、状態の切り替えが色づくが状態間で共通の方法で更新される「グローバル」な側面（ヘルスバーやマップ/レーダーなど）がありました。

ゲーム内メニューはDAGによって「より良く」表現される場合がありますが、暗黙のステートマシン（別の画面に移動する各メニューオプションはそこへの行き方を知っており、戻るボタンを押すと常に一番上の状態になります）まったく同じ。

これらの他のシステムの一部には「トップステートの置換」機能もありましたが、通常、次のように実装されStatePop()ていましたStatePush(x);。

メモリカードの処理は、実際には大量の「操作」を操作キューにプッシュしたため、同様でした（LIFOではなくFIFOのように機能的にスタックと同じことを行いました）。この種の構造の使用を開始すると（「現在1つのことがあり、終了すると自動的にポップします」）、コードのすべての領域に感染し始めます。AIでさえ、このようなものを使用し始めました。AIは「無知」であり、プレイヤーがノイズを発したが「見えなかった」ときに「心配」に切り替わり、プレイヤーが見えたときに最終的に「アクティブ」に上昇しました段ボール箱に入れて、敵にあなたのことを忘れさせてください！私が苦いわけではありません...）。

GameState.h：

enum GameState
{
   k_frontend,
   k_gameplay,
   k_inGameMenu,
   k_moviePlayback,
   k_numStates
};

void GameStatePush(GameState);
void GameStatePop();
void GameStateUpdate();

GameState.cpp：

// k_maxNumStates could be bigger, but we don't need more than
// one of each state on the stack.
static const int k_maxNumStates = k_numStates;
static GameState s_states[k_maxNumStates] = { k_frontEnd };
static int s_numStates = 1;

static void (*s_startupFunctions)()[] =
   { FrontEndStart, GameplayStart, InGameMenuStart, MovieStart };
static void (*s_shutdownFunctions)()[] =
   { FrontEndStop, GameplayStop, InGameMenuStop, MovieStop };
static void (*s_updateFunctions)()[] =
   { FrontEndUpdate, GameplayUpdate, InGameMenuUpdate, MovieUpdate };

static void GameStateStart(GameState);
static void GameStateStop(GameState);

void GameStatePush(GameState gs)
{
   Assert(s_numStates < k_maxNumStates);
   GameStateStop(s_states[s_numStates - 1])
   s_states[s_numStates] = gs;
   s_numStates++;
   GameStateStart(gs);
}

void GameStatePop()
{
   Assert(s_numStates > 1);  // can't pop last state
   s_numStates--;
   GameStateStop(s_states[s_numStates]);
   GameStateStart(s_states[s_numStates - 1]);
}

void GameStateUpdate()
{
   GameState current = s_states[s_numStates - 1];
   s_updateFunctions[current]();
}

void GameStateStart(GameState gs)
{
   s_startupFunctions[gs]();
}

void GameStateStop(GameState gs)
{
   s_shutdownFunctions[gs]();
}