RPGゲームで複数のストーリースレッドを処理する方法は？

複数のストーリースレッドを持つRPGゲームを設計しました。つまり、ユーザーの選択に応じて、発生する場合と発生しない場合があり、いくつかの方法で同じことを達成でき、エンディングが異なる場合があります。

私は単純な意思決定エンジンを実装しましたが、それはうまく機能しますが、1つの大きな欠陥があります。あなたが決定を下す瞬間に、ストーリーはあなたの決定によってすぐに影響を受けます。 。これは、ストーリーがツリー構造のブランチのように展開し、常に次のノードを知る必要があるためです。内部では、キューを使用して決定が実装されます。各ノードは前のノードと次のノードを認識します（または、決定ノードの場合は、ユーザー入力を待って次のノードを設定します）

複雑な決定エンジンを持つゲームをたくさん見ましたが、どのように作られているのでしょうか？物事を本当に簡単にする特別なデザインはありますか？誰かが似たようなことをして、これに取り組む方法のヒントをくれましたか？

更新1：

重要な側面は、外部コードから操作できるように、ストーリーコードを何らかの形で独立させて管理することです。これをエンジンとして使用する予定であるため、可能な選択肢も外部ファイルから取得する必要があります。コードは完全に抽象的でなければなりません。

また、私はデザインソリューション、それを行うための良い方法、他の人がそれをどのようにやったか、に興味があります。

キューを有向非巡回グラフ（DAG）に一般化することもできます。これらについてはウィキペディアで読むことができます。基本的に、各ノードは、「依存」する1つ以上の親ノードを持つことができます。サイクルは許可されません。つまり、AがBに依存している場合、BはAに依存できません（直接または他のノードの間接チェーンを介して）。

各ノードは「アクティブ」または「非アクティブ」状態にあり、すべての親がすでにアクティブになっている場合にのみアクティブになります。グラフの構造（ノードの種類と接続方法）はゲームデータの一部ですが、アクティブ/非アクティブ状態はプレイヤーのセーブデータの一部です。

このようにして、次のようなモデルを作成できます。ツリーを植えるとき、タスクに「plantedTree」をアクティブとしてマークします。その後、ゲームの後半で、別のタスク "treeGrown"が "plantedTree"と他のノード（ストーリーの一部）の両方を親として指定します。次に、「treeGrown」は、プレイヤーがストーリーのそのポイントに到達したときにのみアクティブになり、「plantedTree」もアクティブになります。

親のいずれかがアクティブになった場合にアクティブになるノード、1つの親によってアクティブになり別の親によって非アクティブになったノードなど、他の機能を含めることができます。複数の相互依存するスレッドでストーリーを作成するための非常に一般的なフレームワークです。

私が理解していることから、あなたが望むのは意思決定エンジンだけでなく、ルールエンジンでもあります。各決定に対して、その決定によって定義されたルールのサブセットを実行します。これらのルールの実行は、ツリーの例のような特定のエンティティの状態に依存することがよくあります。

基本的に、プレイヤーが決定を下すとき、その決定を検索し、ルールを実行してから、通常のように次の利用可能な決定のセットを提供します。ただし、ルールの一部は既に実行されている他のルールに基づいてのみ実行されるという点で、ルールは動的です。

上のいくつかのより多くのウィキペディア。

ルールエンジンを使用する場合のサブヘディング（強調は私の場合）から：

• 問題は、従来のコードには複雑すぎます。
• 問題は複雑ではないかもしれませんが、堅牢な構築方法を見つけることはできません。
• 問題は、明らかなアルゴリズムベースのソリューションを超えています。
• 解決するのは複雑な問題です。明らかな従来の解決策がないか、問題が完全に理解されていません。
• ロジックは頻繁に変更されます
• ロジック自体は単純かもしれませんが、ルールは頻繁に変更されます。多くの組織では、ソフトウェアのリリースはまれであり、ルールは、合理的かつ安全な方法で必要で期待される「俊敏性」を提供するのに役立ちます。
• ドメインの専門家やビジネスアナリストはすぐに利用できますが、技術的ではありません。
• ドメインの専門家は、多くの場合、ビジネスルールとプロセスに関する豊富な知識を持っています。通常、それらは技術的ではありませんが、非常に論理的です。ルールを使用すると、独自の用語でロジックを表現できます。もちろん、彼らはまだ批判的に考え、論理的な思考ができる必要があります。非技術的な立場にある多くの人々は、正式な論理のトレーニングを受けていないので、注意して作業してください。ルールでビジネス知識を体系化することにより、ビジネスルールとプロセスが現在理解されている方法に穴が開くことがよくあります。

注意すべきことの1つは、ルールエンジンは、簡略化されたドメイン固有の「言語」またはYAMLのようなものを使用して最適に実装される場合があることです。XMLは提案しません。

イベントは純粋にユーザーの決定に基づくものではないことを考慮する必要があります。既に述べたように、一連の決定シーケンスが取られたときに何らかのイベントが追加されなければならず、その後、何かが追加されます（2日後など）。

あなたが必要だと思うのは、イベントをモデル化する方法とそれをトリガーする方法です。前者は特定のケースにより限定されていますが、後者はイベントを直接または間接的にトリガーする階層状態マシン（HSM）によってモデル化できます。

ステートマシンは、階層構造によってのみ軽減される次元の呪いに苦しむことに留意してください。すぐに、HMSを使用してステータスの複雑な意味をモデル化する必要があることを理解しますが、それを照会する方法も提供します。

このシナリオでは、HSMと基本的なイベントコールバックの両方によって処理される基本的なイベント（ユーザーの決定、時間、天候の変化など）があります。HSMは「メモリ」のモデルを提供し、コールバックは、決定/外部イベントのシーケンスの結果を計算するためにそのメモリを使用する方法を記述する方法を提供します。

また、計算する必要があるステータスの「アスペクト」ごとに1つずつ、HMSの辞書（またはその他のコレクション構造）を使用することになります。例としては、関連するHMSイベントと、イベントをトリガーするためにコールバックが行う決定に使用するイベントがあります。

このインフラストラクチャはすべて、人間のダンジョンマスターの行動を模倣する目的に役立ちます。彼は通常、プレイヤーの決定と環境条件のために、現在の状況（HMS ["外部"]）の精神記録を取ります。何かが追加された場合、メンタルレコードを使用して決定を下し、何らかの状況が追加された場合に同様の反応を避けるために、内部戦略ステータス（HSM ["internal"]）も記録できます。