<p>OpenApocは、ミッションごとにすべての範囲のOGマップを生成するわけではありません</p>

これがマップ生成に関するIstrebitelからの応答です

私が覚えていることから、元のゲームファイルには、スラムの9または18の異なるブロックのようなブロックのリストがあり、各ブロックには最小および最大の発生数があり、マップサイズ自体は最小および最大の可能なサイズで定義されています。 次に、ジェネレーターはランダムにブロックを選択して照合し、ランダムなマップを作成します。

OpenApocに巨大または小さなサイズのマップを生成させるには、これらの「ブロック数XYZ」の数値をどこから読み取っても編集するか、コードですばやく変更します（ファイルから読み取るのではなく、静的に読み取る、つまり常にファイル内のスラムに設定されているものを生成する代わりに、スラムの4x4x1マップを生成します）。
より詳細な説明は次のとおりです。

• すべてのマップには独自のチャンクサイズがあります
• すべてのマップはブロックで構成されています。 ブロックはテンプレートです。たとえば、さまざまな種類のスラムセクター、またはさまざまな種類のx-comベースブロックです。 これらはランダムに組み合わされてマップを形成します
• ブロックのサイズはチャンク単位で可変です。 たとえば、1x1x2ブロック（リフト）、1x2x1ブロック（廊下）、および多くの1x1x1ブロック（アパート自体）があるタイルセットの豪華なアパートがあります。 UFOは、1つの2x2x2ブロックのみを特徴とする単純な2x2x2マップです。 NS。
• すべてのブロックには、最小および最大のオカレンスがあります。 Luxury apptsの例では、リフトブロックの最小出現回数は1です。そうでない場合、このブロックのないマップが生成され、フロアは次のようになります。
  リフトがなく、アパートと1レベルの廊下しかないため、地形を破壊せずにアクセスすることはできません。
• すべてのマップには、すべての軸にチャンク単位の最小サイズと最大サイズがあります（または、通常のチャンクサイズに1をランダムに加算または減算するだけですか？覚えていません）
• マップ生成のアルゴリズムは不明であり、リバースエンジニアリングされていないため、最初から作成しましたが、バニラの近くで機能しているように見えました。
• AFAIK、私のアルゴリズムは最初に行って必須ブロックのリストを作成し、それらをすべてランダムに配置します
• 次に、残りのブロックのリストを作成し（残りの最大発生回数> 0）、マップが完了するまでこれらのブロックの1つをランダムに配置します
• 配置できない場合は、テトリスのようにシャッフルしてスペースを空けます（ただし、通常、これは発生しません）
• マップを作成できない場合は、他のサイズで再試行します
• 次に、あきらめてエラーを吐き出します（通常、バニラマップテンプレートではこれに到達することはありません）
• すべてのブロックを配置すると、マップ自体が生成されます
• マップオブジェクトを作成し、ブロック（壁、装飾、アイテムのスポーンポイントなど）に基づいてマップをオブジェクトで埋めます。

istrebitelからのさらなる更新

ええ、私はほとんどそれに到達したと思います-より多くの敵の数のためのより大きなマップ。
スポーンエージェントが機能する方法は、マップがLOSに分離されることです。
パスファインディング、LOS計算、および
すべて同時にスポーンします。 マップブロック内のすべてのタイルはに属します
すべてボックス型のLOSブロックの1つ。 次に、グローバルがあります
特定のエッジでマップを終了または開始できるかどうかを設定します。
すべての地図。 これに基づいて、LOSブロックはスポーンする資格があるかどうかのどちらかです
特定の忠誠の単位。 ブロックに設定された値のセットがあります
これを支配します。 これらの値は、
フォーラムまたはプロジェクトに添付されたtxtファイル。 覚えていれば
正しくは、プレイヤーユニット、エイリアンユニットのブロックスポーン値があります。
敵対的な部隊、民間部隊、おそらく民間のx-com人員は
私が覚えていない、そして私が覚えている別のもの、多分そうではない
女王を産むための特別なブロックがあります。

したがって、分隊のサイズに基づいてマップサイズを選択する方法は、次のいずれかになります。
ブロックをインテリジェントに調査し、どのブロックがいくつを提供するかを確認します
産卵の機会とそれに基づいて判断する、または多分バニラ
「X以上の場合はYサイズを使用する」に似たハードコードされたハックがありました

また、注意すべきことの1つは、この問題を解決したとは思わないということです。
いくつかのブロックが作成され、敵対的なパーティのスポーンポイントがLOSにある可能性があります
たとえば、MARSEC倉庫のように、お互いに
エントリポイントから多くのmarsecセキュリティスポーンポイント。 ゲーム
どういうわけかあなたがスポーンするような状況が決してないことを保証します
敵のLOS。 ユニットを一度、背中合わせにスポーンできます。
彼らはお互いを見て少し移動しますが、敵と一緒にスポーンすることはできません
すでにLOSにあります。 論理的には、ゲームはどういうわけか従う必要があります
このブロックがどこにあるかに基づいて、スポーンポイントまたはLOSブロックを除外します
すでにスポーンされたユニットによって観察されます。 論理的には、
理論的なオープンフィールドマップが生成されます。これは紙の上では十分です。
スポーンポイントは、参加しているすべてのユニットをスポーンしますが、スポーンしません。
スポーンされたユニットはすべてを見るので、すべてのユニットをスポーンするのに十分なブロックがあります
ブロック全体。 バニラにはそのようなオープンフィールドはなかったと思います
ブロックするので、これは決して起こりませんが、これを改造すると、おそらく
意志と私たちはそのための準備ができている必要があります。

この問題に関連する他のものについては＃396を参照してください