アドベンチャーゲームのさまざまな状態のコーディング

私はアドベンチャーゲームを計画していますが、ストーリーの進行状況に応じてレベルの動作を実装する正しい方法がわかりません。

私のシングルプレイヤーゲームは、プレイヤーがゲーム内のさまざまなポイントで町の人々と対話しなければならない巨大な世界を特徴としています。ただし、ストーリーの進行状況に応じて、プレイヤーにはさまざまなものが提示されます。たとえば、ギルドリーダーは町の広場から市内のさまざまな場所に場所を変更します。ドアは、特定のルーチンを終了した後の1日の特定の時間にのみロック解除されます。特定のマイルストーンに到達した後にのみ、異なるスクリーン/トリガーイベントが発生します。

私は最初にswitch {}ステートメントを使用してNPCの発言内容または検索対象を決定し、グローバルgame_state変数の状態を確認した後にのみクエストの目的を相互作用可能にすることを考えました。しかし、オブジェクトの動作を変更するために、さまざまなゲームの状態やスイッチケースにすぐに出くわすことに気付きました。そのswitchステートメントはデバッグするのも非常に難しく、レベルエディターで使用するのも難しいかもしれません。

したがって、複数の状態を持つ単一のオブジェクトを持つのではなく、単一の状態を持つ同じオブジェクトの複数のインスタンスを持つ必要があると考えました。そうすれば、レベルエディターのようなものを使用する場合、NPCのインスタンスを、彼が登場する可能性のあるすべての異なる場所に配置することができます。また、会話状態ごとのインスタンスも配置できます。しかし、それは、レベルの周りに浮かぶ非アクティブで不可視のゲームオブジェクトがたくさんあることを意味します。これは、メモリの問題か、レベルエディタで見づらいかもしれません。

または、単純に、ゲームの状態ごとに同一だが別々のレベルを作成します。これは最もクリーンでバグのない方法ですが、レベルの各バージョンが実際に同一であることを確認する大規模な手動作業のように感じます。

私のすべての方法は非常に非効率だと感じているので、私の質問を要約すると、ストーリーの進行状況に応じてレベルの動作を実装するためのより良いまたは標準化された方法はありますか？

PS：私はまだレベルエディターを持っていません-JME SDKのようなものを使用するか、自分で作成することを考えています。

この場合に必要なのは、状態設計パターンだと思います。各ゲームオブジェクトのインスタンスを複数持つ代わりに、単一のインスタンスを作成しますが、その動作を別のクラスにカプセル化します。考えられる動作ごとに1つずつ、複数のクラスを作成し、すべてのクラスに同じインターフェースを与えます。1つをゲームオブジェクトに関連付け（初期状態）、条件が変わったとき（マイルストーンに到達したとき、時刻が過ぎたときなど）、そのオブジェクトの状態を切り替えます（つまり、ゲームロジックに応じて別のオブジェクトに関連付けます）該当する場合はそのプロパティを更新します。

状態インターフェースがどのように見えるかの1つの例（完全に構成されています-このスキームが提供する制御レベルを示すためだけです）：

interface NPCState {
    Scene whereAmI(NPC o);
    String saySomething(NPC o);
}

そして、2つの実装クラス：

class Busy implements NPCState {
    Scene whereAmI(NPC o) {
        return o.getWorkScene();
    }
    String saySomething(NPC o) {
        return "Can't talk now, I'm busy!";
    }
}

class Available implements NPCState {
    Scene whereAmI(NPC o) {
        return TAVERN;
    }
    String saySomething(NPC o) {
        String[] choices = o.getRandomChat();
        return choices[RANDOM.getInt(choices.length)];
    }
}

状態の切り替え：

// The time of day passed from "afternoon" to "evening"
NPCState available = new Available();
for ( NPC o : list ) {
    Scene oldScene = o.state.whereAmI(o);
    o.state = available;
    Scene newScene = o.state.whereAmI(o);
    moveGameObject(o, oldScene, newScene);
    ...

重要なNPCにはカスタム状態がある場合があり、状態選択ロジックはよりカスタマイズ可能であり、ゲームのさまざまなファセットに対して異なる状態を持つことができます（この例では、場所とチャットの両方を伝えるために単一のクラスを使用しましたが、それらと多くの組み合わせを行います）。

これはレベルエディターでもうまく機能します。レベルの「グローバル」状態を切り替える単純なコンボボックスを使用し、その状態で表示したいゲームオブジェクトを追加および再配置できます。ゲームエンジンは、オブジェクトが正しい状態になったときにそのオブジェクトを実際にシーンに「追加」するだけですが、そのパラメーターはユーザーフレンドリーな方法で編集可能です。

（免責事項：私はゲームエディターの実世界での経験がほとんどないため、プロのエディターがどのように機能するかについて自信を持って言うことができますが、状態パターンについての私のポイントは引き続き保持されます。リソース。）

私が検討する選択肢は、個々のオブジェクトを異なるゲーム状態に応答させるか、異なるゲーム状態で異なるレベルを提供することです。これら2つの間の選択は、ゲーム内で正確に何をしようとしているかによって異なります（異なる状態は何ですか？状態間でゲームがどのように移行するかなど）。

いずれにせよ、状態をゲームコードにハードコーディングすることでそれを行いません。NPCオブジェクトの大規模なswitchステートメントではなく、データファイルから連想配列に読み込まれたNPC動作の代わりに、その連想配列を使用して、関連付けられた状態に対して異なる動作を実行します。

if (state in behaviors) {
  behaviors[state]();
}

オブザーバーパターンを使用してマイルストーンの変更を探すのはどうですか？変更が発生した場合、一部のクラスはこれを認識し、たとえば、npcに対して行う必要がある変更を処理します。

前述の状態設計パターンの代わりに、戦略パターンを使用します。

NPCがキャラクターと対話できる方法がn個あり、mが自分の位置にいる可能性がある場合、最大（m * n）+1個のクラスを設計する必要があります。戦略パターンを使用すると、n + m + 1クラスになりますが、これらの戦略は他のnpcsでも使用できます。

そのため、マイルストーンを処理するクラスと、このクラスを監視し、npcまたは敵、または変更する必要があるものを処理するクラスが存在する可能性があります。オブザーバーが更新された場合、オブザーバーは自分が支配するインスタンスに何かを変更する必要があるかどうかを判断します。たとえば、NPCクラスは、コンストラクターで、NPCマネージャーに更新する必要がある場合と更新する必要があるものを通知します...

指定されたアプローチはすべて有効です。それは、あなたがどんな瞬間にいるかによって異なります。多くのアドベンチャーまたはMMOは、これらの組み合わせを使用します。

たとえば、重要なイベントがレベルの大部分を変更する場合（たとえば、借金取りがアパートを一掃し、その中の全員が逮捕される場合）、通常、部屋全体を同じように見える2番目の部屋に置き換える方が簡単です。

OTOH、キャラクターがマップを歩き回り、さまざまな場所でさまざまなことを行う場合、多くの場合、単一の俳優がさまざまな行動オブジェクトを介して回転します（たとえば、まっすぐ歩く/会話なしvsここに立つ/ミッチの死についての会話）目的が達成されている場合は「隠されている」。

ただし、通常、手動で作成したオブジェクトの複製を作成しても問題は発生しません。いくつのオブジェクトを作成できますか？ゲームがループオーバーできるより多くのオブジェクトを作成でき、それらの「隠された」プロパティを見てスキップすると、エンジンが遅すぎます。それで、私はそれについてあまり心配しません。多くのオンラインゲームは実際にこれを行います。特定のキャラクターやアイテムは常に存在しますが、対応するミッションを持っていないキャラクターには表示されません。

アプローチを組み合わせることもできます。アパートの建物に2つのドアを設置します。1つは「借金取りの前」のアパートへ、1つは後のアパートへと続きます。廊下に入ると、ストーリーの進行に適用されるもののみが実際に表示されます。そうすれば、「アイテムがストーリーの現在のポイントで表示される」ための一般的なメカニズムと、単一の目的地を持つドアを持つことができます。代わりに、交換可能なビヘイビアを持つことができるより複雑なドアを作成することもできます。その1つは「フルアパートメントに行く」、もう1つは「空のアパートに行く」です。本当にドアの行き先だけが変わる場合、これは無意味に思えるかもしれませんが、外観が同様に変わる場合（たとえば、ドアの前の大きなロックが最初に割れなければならない場合）、