手続き型の生成、ゲームの更新、バタフライ効果

注：数日前にStack Overflowでこれを尋ねましたが、ビューが非常に少なく応答がありませんでした。代わりにgamdev.stackexchangeで尋ねるべきだと考えました。

これは、以前に生成されたコンテンツを壊すことなく、複数のリリース後更新を通じて手続き型生成システムを維持することに関する一般的な質問/アドバイスです。

ゲームの手続き型コンテンツを作成するときに、「バタフライ効果」の問題を回避するための情報と手法を見つけようとしています。シードされた乱数ジェネレータを使用する場合、乱数の繰り返しシーケンスを使用して、再現可能な世界を作成できます。一部のゲームは、生成された世界を生成後にディスクに保存するだけですが、手続き型生成の強力な機能の1つは、同じ方法で領域を再作成するために数列の再現性に複数回頼ることができるということです。持続。私の特定の状況の制約のため、永続性を最小限に抑える必要があり、純粋にシードされた濃度にできるだけ依存する必要があります。

このアプローチの主な危険性は、手続き型生成システムのわずかな変更でさえ、世界全体を変更する蝶の影響を引き起こす可能性があることです。これにより、プレイヤーが探索している世界を破壊することなくゲームを更新するのは非常に難しくなります。

この問題を回避するために私が使用してきた主な手法は、複数のフェーズで手続き型生成を設計することです。各フェーズには、独自のシード乱数ジェネレーターがあります。つまり、各サブシステムは自己完結型であり、何かが壊れても、世界のすべてに影響を与えることはありません。ただし、これはゲームの孤立した部分であっても、依然として「破損」の可能性が多いようです。

この問題に対処するもう1つの方法は、コード内でジェネレーターの完全なバージョンを維持し、特定のワールドインスタンスに適切なジェネレーターを使い続けることです。これは私にとってはメンテナンスの悪夢のように思えますが、誰かが実際にこれを行っているかどうか知りたいです。

したがって、私の質問は、特にバタフライ効果のこの問題に対処するための、特にリリース後のゲームアップデートのコンテキストでの一般的なアドバイス、テクニック、およびデザインパターンの要求です。（うまくいけば、それは広すぎる質問ではありません。）

現在Unity3D / C＃で作業していますが、これは言語にとらわれない質問です。

更新：

返信ありがとうございます。

ますます静的データが最良かつ最も安全なアプローチであるように見えます。また、大量の静的データを保存することはオプションではない場合、生成された世界で長いキャンペーンを行うには、使用されるジェネレーターの厳密なバージョン管理が必要になります。私の場合の制限の理由は、モバイルベースのクラウドの保存/同期の必要性です。私の解決策は、重要な事柄に関する少量のコンパクトデータを格納する方法を見つけることかもしれません。

ストームウィンドの「ケージ」の概念は、物事を考える上で特に有用な方法だと思います。ケージは基本的には再シードポイントであり、小さな変更、つまりバタフライのケージの実行に伴う影響を防ぎます。

ここでベースをカバーしたと思います：

• 変更による波及を制限するために、複数のジェネレーターを使用するか、間隔を置いて再シードします（空間ハッシュを使用するなど）。これはおそらく化粧品のコンテンツで機能しますが、指摘したように、1つのセクションに含まれる破損を引き起こす可能性があります。

• 保存ファイルで使用されているジェネレーターのバージョンを追跡し、適切に応答する。「適切」の意味は...

  • 以前のすべてのバージョンのジェネレーターの履歴をゲームの実行可能ファイルに保存し、保存に一致するバージョンを使用します。これにより、プレイヤーが古いセーブを使い続けると、バグの修正が難しくなります。
  • この保存ファイルが古いバージョンのものであることをプレーヤーに警告し、別の実行可能ファイルとしてそのバージョンにアクセスするためのリンクを提供します。キャンペーンが数時間から数日続くゲームに適しています。数週間以上プレーする予定のキャンペーンには適していません。
  • n実行可能ファイルには最新のジェネレーターバージョンのみを保持します。保存ファイルがこれらの最新バージョンのいずれかを使用している場合は、保存ファイルを最新バージョンに更新（提供）します。これは適切なジェネレーターを使用して、古い状態をリテラル（または、非常に類似している場合は同じシード上の新しいジェネレーターの出力からのデルタ）にアンパックします。これ以降の新しい状態は、最新のジェネレーターからのものです。ただし、長期間プレイしないプレイヤーは取り残される可能性があります。そして最悪の場合、ゲームの状態全体をリテラル形式で保存することになり、その場合も同様です...

• 生成ロジックを頻繁に変更することが予想され、以前のバージョンとの互換性を壊したくない場合は、ジェネレーターの決定論に依存せず、状態全体を保存ファイルに保存してください。（すなわち、「それを軌道から核にかけなさい。それは確かにする唯一の方法です」）

単一数発生器から決定論的に保つための簡単な十分なはずです- -のではなく、このようなバタフライエフェクトの主な供給源は、間違いなく数世代ではない使用のクライアントコードでこれらの数字の。コードの変更は、物事を安定させるための真の課題です。

コード：ユニットテストマイナーな変更が他の場所で意図せずに発生しないようにするための最良の方法は、ビルドにすべての生成的側面の完全なユニットテストを含めることです。これは、1つの変更が他の多くに影響を与える可能性があるすべてのコンパクトコードに当てはまります。単一のビルドで何が影響を受けたかを確認できるように、すべてのテストが必要です。

番号：周期的なシーケンス/スロットすべてに対応する1つの番号ジェネレーターがあるとします。それは意味を割り当てません、それは単に他のPRNGのように順番に数字を吐き出すだけです。2つの実行で同じシードが与えられた場合、同じシーケンスが得られますか？次に、物事を考えて、ランダムな値を定期的に提供する必要があるゲームの30の側面があると判断しました。ここでは、30スロットのサイクリングシーケンスを割り当てます。たとえば、シーケンスの最初の数値はすべてラフな地形レイアウトで、2番目の数値は地形の摂動です...など... 10番目の数値ごとに、AI状態に多少のエラーが追加されてリアルになります。あなたの期間は30です。

10を超えると、20のスロットが解放され、ゲームの設計が進むにつれて他の側面に使用できるようになります。ここでのコストはもちろん、スロットが現在使用されていない場合でもスロット11〜30の番号を生成する必要があることです。つまり、期間を完了して、次の1〜10のシーケンスに戻る必要があります。CPUコストはかかりますが、（空きスロットの数によっては）わずかなはずです。もう1つの欠点は、開発プロセスの最初の段階で使用可能にしたスロットの数に最終的な設計を確実に収容できるようにする必要があることです。最初から割り当てる数が多いほど、「空の」スロットが多くなります。物事を機能させるために、潜在的にそれぞれを通過する必要があります。

これの影響は次のとおりです。

• あなたはすべての数を生成する1つのジェネレータを持っています
• 数値を生成する必要があるアスペクトの数を変更しても、決定論には影響しません（期間がすべてのアスペクトに対応するのに十分な大きさである場合）

もちろん、ゲームが一般に利用できない期間が長くなります。つまり、いわばアルファ版です。そのため、プレーヤーに影響を与えることなく、30から20アスペクトに削減することができます。あなたは割り当てられていた方法で開始時にあまりにも多くのスロットを。もちろん、これはいくつかのCPUサイクルを節約します。しかし、良いハッシュ関数（自分で書くことができます）はとにかく高速であることを覚えておいてください。そのため、追加のスロットを実行する必要があるため、コストがかかることはありません。

PCGでの永続性が必要な場合は、PCGコード自体をデータとして扱うことをお勧めします。通常のコンテンツや生成されたコンテンツを持つリビジョン間でデータを永続化するのと同じように、リビジョン間でデータを永続化したい場合は、ジェネレーターを永続化する必要があります。

もちろん、最も一般的なアプローチは、生成データを静的データに変換することです。

PCGゲームでは永続性が異常であるため、多くのジェネレーターバージョンを保持しているゲームの例はわかりません。そのため、permadeathがPCGと密接に関連していることがよくあります。ただし、同じゲーム内に、同じタイプの複数のPCGの例がたくさんあります。たとえば、Unangbandにはダンジョンルーム用の独立したジェネレータが多数あり、新しいジェネレータが追加されても、古いジェネレータは引き続き同じように動作します。それが保守可能かどうかは、実装次第です。それを保守可能に保つ1つの方法は、スクリプトを使用してジェネレータを実装し、ゲームコードの残りの部分でそれらを分離しておくことです。

私は約30000平方キロメートルの面積を維持し、約100万の建物やその他のオブジェクトを保持しているだけでなく、その他のものをランダムに配置しています。屋外でのシミュレーション 保存されるデータは約4 GBです。収納スペースがあるのはラッキーですが、容量に制限はありません。

ランダムは制御されていないランダムなものです。しかし、少しケージに入れることもできます。

• 開始と終了を制御します（他の投稿で述べたように、シード番号と生成された番号の数）。
• たとえば、その数値空間を制限します。0から100の間の整数のみを生成します。
• 値を追加して、その数値空間をオフセットします（例：100 + [0から100までの生成された数値]は、100から200までの乱数を生成します）
• 拡大縮小する（例：0.1を掛ける）
• そして、その周りに様々なケージを適用します。これは、世代の一部を削減、廃棄することです。例えば。2次元空間で生成する場合は、数値ペアの上に長方形を置き、外にあるものをスクラップできます。または円、または多角形。3D空間の場合、たとえば、球または他の形状の内部に存在するトリプレットのみを受け入れることができます（現在は視覚的に考えていますが、これは必ずしも実際の視覚化や配置とは関係ありません）。

それだけです。ケージは、残念ながらデータも消費します。

フィンランド語のHajota ja hallitseには格言があります。Divide and conquerに変換します。

私は細部の正確な定義という考えをすぐに放棄しました。ランダムは自由を望んでいるので、自由を得ました。蝶を飛ばそう-檻の中。代わりに、ケージを定義する（そしてメインテイン!!）ための豊富な方法に焦点を当てました。彼らがどんな車であるかは関係ありません、それらが青かダークブルーである限り（退屈な雇用主は一度言った:-)）。「ブルーまたはダークブルー」は、ここでは（非常に小さい）ケージであり、色の次元に沿っています。

数値空間を制御および管理するために、何が管理可能ですか？

• ブールグリッドは（ビットが小さい！）
• コーナーポイントは
• 木構造のように（=「ケージを保持するケージ」に続く）

メンテナンスとバージョンの互換性について...
：if version = n then
：elseif version = m then ...
はい、コードベースは大きくなります:-)。

身近なこと。先に進む正しい方法は、分割して征服するための豊富な方法を定義し、その上でいくつかのデータを犠牲にすることです。次に、可能であれば、（ローカルで）ランダム化の自由を与えます。制御することが重要ではありません。

DMGregoryによって提案されたおかしい "nuke it fom orbit"と完全に互換性がないわけではありませんが、おそらく小さく正確な核を使用しますか？:-)