自分の冒険を選択-選択肢スタック

私は現在、独自のアドベンチャーゲームを選択して構築しています。これで、すべての選択に対して1つの結果が得られ、線形フローを作成するのは簡単ですが、以前のすべての選択が次の結果に影響を与えるための優れたアルゴリズムはありますか？私は明らかに以前のすべての選択を保存し、決定する大きな 'IF'ステートメントを持つことができましたが、もっと良い方法があるかどうか疑問に思いましたか？

私の一部は、すべての選択肢に「スコア」が必要かどうかを疑問に思っており、これを使用して（おそらくしきい値を使用して）次のアクションを決定し、各アクションをスコアに追加します。

私は主にこれをswift / SpriteKitで行っていますが、この時点でのコードよりもコンセプトのほうが重要だと思います。

以下のジョシュのコメントに応じて：

現時点ではまだ概念段階にあると思いますが、各「ページ」はカスタムオブジェクトまたはjsonファイルのいずれかになります。私はあなたの答え（現在は削除されています）について考えていましたが、各ENUMオプションを少し持っているかもしれません。次に、各ページに「スコア」を付けることができます。次に、選択した前のオプションを使用して、どのビットが設定され、どのページを決定するかを決定します。私が「ストーリー」をどのようにフォーマットするかを決定するのをほとんど手助けし始める前に、この問題に対する既存の解​​決策があったのかと思っただけだと思います

形式の大まかな推測：

  { "text":"You arrive in the dungeon and there are 2 doors",
   "options":[
    1: "Go left",
    2: "Go Right"
    ],
   "score" : 0 // first page
  }
  {"text" "You went left and meet a dragon",
  "options":[
    0: "Game over, you were eaten" // something to handle game over
    ],
   "score" : 1 
  }
  {"text" "You meet a mushroom who tells you the princess is in another castle",
  "options":[
    4: "Give up, game over", // something to handle game over
    8: "Jump down the pipe"
    ],
   "score" : 2 
  }

ありがとう

多くのアドベンチャー/ RPGゲームは、これを2つの方法で処理します（私が知らないものがあるかもしれません）。

フラグの使用

1つ目は、何かが発生した場合にフラグを設定することです（通常はビットマスク）。追跡するものがあまりない場合は、これで問題ありません。部屋/出会いで、何かを変える旗に対するチェックがあるかもしれません。あなたの例ではルールを追加できます：

{"text" "You meet a mushroom who tells you the princess is in another castle",
"options":[
  4: "Give up, game over", // something to handle game over
  8: [64:"Jump down the pipe", "Exit stage left"]
  ],
 "score" : 2
 "setflag" : 32
}

flags & 64が設定されている場合にのみ、2番目のオプションが表示されます。setflagシーンが表示された場合、または特定の選択が行われた場合にも、オプションを実装できます。

アイテムの使用

2番目のオプションは、アイテムをプレーヤーのインベントリに追加することです。これらは、ゲームでよく見かける「クエストを完了するために必要なアイテム」です。これらは基本的に移植可能な「フラグ」として機能します。これは2つの方法（または組み合わせ）で実装できます。

• アイテムは「フラグ」です。シーンまたはダイアログで、プレイヤーがインベントリに特定のオブジェクトを持っているかどうかを確認します。これは、上記の「フラグのチェック」メカニズムによく似ています。利点は、使い慣れた名前の付いたオブジェクトに対してチェックするので、エンカウンターを設計する方がはるかに簡単なことです。

• アイテムには、フラグとして機能するプロパティがあります。たとえば、The Witcher 3では、プレイヤーは幻想的な壁を一掃できるオブジェクトを取得します。そのアイテム自体は「フラグ」である可能性がありますが、オブジェクトがプロパティを持っている可能性もありますcan_dispel_illusions。ここでの利点は、同じシナリオで使用できる複数のオブジェクトを実装できることです。したがって、シーン/ダイアログ/ドアは、プレイヤーがプロパティを持つ「何か」をインベントリに持っているかどうかを確認できますcan_dispel_illusions。

これにより、プレイヤーに選択の錯覚を与える可能性が与えられます。プレーヤーがシーン1で魔女に遭遇せず、したがって「ワンドオブディスペル」を逃した場合、プレーヤーは後で怪しげな商人から「リングオブディスペル」を取得して、ゲームの勝てない状態を防ぐことができます。

プレーヤーに「実際の」インベントリを提供する予定がない場合、クエストアイテムはプレーヤーに非表示のリストに移動する可能性があります。

例：

{"items":[
  "Wand of Dispel": { "properties": ["can_dispel_illusions","illumination"]}
]}

そして：

{"text" "The corridor ends in a dead end. The wall feels cold when you touch it.",
"options":[
  4: "Turn back", 
  8: {"can_dispel_illusions": "Check if the wall is real."} 
  ],
 "score" : 2 
}

{"text" "The witch hands you an object. She observes what you're going to do next.",
"options":[
  14: "Leave the witch's house", 
  22: "Look at the object."} 
  ],
 "giveitem" : "Wand of Dispel" 
}

私があなたのアプローチについて詳しく説明している1つの解決策は、関連するスコアを持つさまざまな属性を持つことです。一部の選択では、これらのスコアの1つ以上が変更されます。スコアは、プレーヤーが利用できる選択肢を変更する場合があります。

たとえば、ストーリーの早い段階で、オプションの戦闘遭遇があるかもしれません。プレイヤーが戦闘に従事している場合、勇気属性は増加しますが、逃げると減少します。後で、特定のストーリーブランチは、勇気スコアが指定されたしきい値を上回ったか下回った場合にのみ使用可能になる可能性があります。さらに深みを増すには、いくつかの決定が複数のスコアに影響を与える必要があります。たとえば、ポケットを選択すると、ステルススコアが増加し、正直スコアが減少します。

一般に、このアプローチがシミュレーションタイプのインタラクティブフィクションで使用されるのを見てきました。Choice Of GamesのDan Fabulich が、ゲームデザインラウンドテーブルのこのエピソードでこの解決策について話し合うのを聞くことができます。

このアプローチの利点は次のとおりです。

• 決定ごとに一意のエンディングを提供する必要がないため、必要なエンディングの総数を削減
• 特定のエンディングに到達する方法は複数ある可能性があり、やりがいのあるプレイスタイルの多様性を可能にします

いくつかの欠点は次のとおりです。

• 決定が単一の属性に依存する場合、それは浅くて定型的である可能性があります
• 逆に、意思決定が複雑すぎると、ゲームとストーリーのバランスを取ることが難しくなります

これは、ストーリー主導型のゲームが直面する大きな問題です：組み合わせ爆発。したがって、BiowareやTelltaleゲームなどを見ると、最も一般的なアプローチは、ストーリーをより直線的なものに制限し、それらの章に限定されたアクションの結果を維持しようとすることです。

Biowareが使用しているアプローチは、各ストーリーを個別のスレッドまたはサブアークに分割しているようです。アークはほとんど独立していますが、同時に発生し、すべてがエンディングの原因となる場合があります。そうすれば、アークの各組み合わせをモデル化する必要はなく、アーク間でチャプターを交互に配置するだけで、結果は現在処理している特定のサブアーク、またはアークの終了方法に制限されます。（または、キャラクターのアークを終了する方法。そのNPCが不要になった場合、多くの場合、それらを殺す、逮捕する、または解放するなどの選択肢が与えられますが、結果は残りの部分に限定されます。物語の）

物語全体の結末は、各弧がどのように終わったかを知るだけでよく、物語全体をきちんとした小さな弓で結びます。

それをプログラムでどのようにモデル化しますか？

これは単に問題を1レベル下に押し下げます（各サブアークは単純なストーリーのように違いを追跡する必要があるため）が、基本的にはフラグの配列（ビットフィールド、またはフラグを表すアイテムのリストなど）があります。各サブアークの特定の結果に影響を与える能力）。

また、エンディングを伝えるときは、通常、結果についてプレーヤーに伝えるときに交互に同じアプローチをとります。各サブアークの結果は独自の段落/会話ノードを取得し、条件を大幅に簡略化します。

少し時間がかかるかもしれませんが、独自のツリー（ビヘイビアーツリーやダイアログツリーのようですが、ページ用）の開発は有益かもしれません。そして、それらの1つをモデルとして使用できます。このようなもの：

ダイアログツリーはどのように機能しますか？

これにより、特定のニーズに合わせて調整できますが、ほとんどの作業はコードで処理できます。

ルールエンジンタイプのアプローチを使用した場合はどうなりますか？プレーヤーがNPCと対話すると、ゲームは、過去の選択/動作によって作成されたフラグで始まり、事前に定義された一連のルールに対してそれをチェックするストリップルールエンジンを実行します。Droolsのようなものはおそらく低速であるだけでなく、大きすぎて野心的ですが、限定スコープルールエンジンは理論的にはより優れたパフォーマンスと多くの柔軟性を提供します。