ゲーム用に大陸の地図を作成した方法

パート1. SVGと座標系

最近まで、私のドラゴンズアバウンドゲームのマップサイズは修正されており、やや非決定的でした。 私はそれらを「地域」であると考えました-全世界の地図ではなく、例えばアメリカの西海岸やヨーロッパの一部などの重要な部分です。 私はこのスケールにかなり満足していましたが、ゲームを少し実験して、全世界（または少なくとももっと大きなマップ）を生成できるかどうかを確認したかったのです。 しかし、始める前に、ファンタジーの世界地図について少し話しましょう。



世界は大きな空間です。 ファンタジーの「世界」カードのほとんどは、実際のサイズにさえ近いものではありません。 たとえば、ロードオブザリングアクションが行われる中つ国を考えてみましょう。









巨大な世界がそこに捕らえられているように見えますが、実際には、中つ国はヨーロッパに基づいて作成されました。









つまり、トールキン世界の「世界」の実際の地図は、中つ国の地図（！）の約50倍になります。 実際、私が見たファンタジー世界地図のほとんどは、大陸の大きさに関する領域を表示しています。









これは、ファンタジーカードスタイルで視覚化された最大の領域のようです。



つまり、実際の「世界地図」を生成するタスクはおそらく野心的すぎるでしょう。 大陸（または大陸の一部）の地図を作成することを目指した方が良いでしょう。 （ただし、カードを「世界」のサイズと見なす方が便利です。）カードのサイズはどうすればよいですか？ 現在のDragons Aboundカードが「亜大陸」サイズである場合、8〜10倍大きいカードを生成する必要があると想定できます。



大きなマップを生成するタスクに進む前に、ゲームで使用されているさまざまな座標系をよりよく理解する必要があります。 私は、Martin O'Learyのソースコードから多くの座標系を借りました。それらの相互作用は、2年間作業しても混乱を招く可能性があります。 通常、私はそれらを実験せずに何とかしましたが、大きなマップを生成するにはこれを行う必要があることは明らかです。



まず、地域マップの「世界」は現在、単位正方形内で生成されています。 各地域マップには（-0.5、-0.5）から（0.5、0.5）までの座標があり、原点（0,0）は地域の中央にあります。









ここで奇妙な点の1つは、Y軸が学校のジオメトリで調査したものと比較して反転していることです。 -0.5はマップの上部にあり、0.5は下部にあります。 コンピュータグラフィックスでは、Y軸はしばしば反転します。 これは、最初のモニター（TV）が上から下へスキャンを実行する方法、つまり、最初のスキャンラインが上、そのすぐ下にあるなど、つまり、スキャンラインのインデックスYが上でゼロからある正の数に変わった方法によって説明されると聞きました下に。 SVG（Scalable Vector Graphics）形式でも同じ座標系が使用されているため、 Dragons Aboundも使用されています。



この座標系は、マップの表示方法とは無関係です。 これは、世界を作成するための無次元のシステムです。都市は（0.12875、-0.223）に位置し、境界は（0.337、0.010）から（0.333、0.017）に移動します。 また、私の現在の地域マップは0.5〜-0.5の範囲に制限されていますが、これは座標系の制限ではありません。 これらの境界を越えて世界を作ることができます。



次の座標系は、SVGがビューボックスと呼ぶものです。 グラフィックの描画に使用される真の座標を設定します。 たとえば、最初のDragons Aboundはビューボックスを座標（-500、-500）に設定し、幅が1000、高さが1000です。









（写真にタイプミスがあります。Y軸の上部は-500である必要があります。申し訳ありません。）



この場合、1番目と2番目の座標系の間の変換は、すべてに1000を掛けるだけであることに気付くかもしれません。 何かを描画するために、ゲームはこのオブジェクトの座標を見つけ、それらに1000を掛け、これらの座標にSVGを描画します。



つまり、ビューボックスの座標を使用して、（0、0）から（250、250）に線を引くことができます。 しかし実際には、コンピューター画面に（0、0）から（250、250）に線を引きたくありません。 これは、画面上の別のポイントで地図を表示したい場合、すべての地図オブジェクトの座標を変更して再描画する必要があることを意味します。 それは大きな仕事です。



画面にグラフィックを表示する座標を制御するために、SVGにはビューポートと呼ばれる3番目の座標系があります。 ビューポートは、グラフィックを描画するページの一部です（Webページでは、これは<svg>要素です）。 幅、高さ、場所があります。 場所は、ビューポートの左上隅の座標です。 つまり、高さおよび幅が800の座標（30、100）でビューポートにマップを表示すると、ビューポート座標系は次のようになります。









SVGでは、座標系のビューボックスとビューポートは互いに接続されており、SVG自体がそれらの間の遷移を処理します。 ビューボックス座標系で描画するだけで、レンダリングされたすべてが対応するビューポートの場所に表示されます。 （異なるアスペクト比でビューボックスとビューポートを作成すると、いくつかの問題が発生します。その後、 preserveAspectRatio



属性の値に応じて、オブジェクトが切り取られるか引き伸ばさpreserveAspectRatio



ます。これをまったく行わないことをお勧めします。）



要約すると、世界座標（0.10、0.33）にある都市は、座標（100、330）で描画され、（110、764）で画面に表示されます。



これでなぜ混乱するのか理解できるようになりました！



これらの各座標系を変更するとどうなりますか？ 最初の座標系で、各軸に-0.25から0.25の範囲の世界を生成するとします。 次に、結果の世界は通常の世界の4倍小さくなり、ビューポートの中央部分のみを埋めます。









（通常は非表示になっているエッジのアーティファクトも確認できます。）同様に、最初の座標系（SK）のサイズを2倍にすると、ビューポートのエッジの外側にあるため、ほとんどのマップは表示されません。



ビューボックスのサイズを2倍にするとどうなりますか？ まあ、最初のSCとビューボックスの比率を2倍にした場合（1000から2000）、何も変わりません。 比率が1000のままである場合、マップは再び半分になります。









ただし、今回のカードの初期領域は1x1です。 ここでも、通常は隠れているエッジ（たとえば、森林の凸部）にアーティファクトが見られます。 また、海洋のパターンが間違っていることもわかります。ビューボックスのサイズについて、いくつかの前提を固定しておく必要があります。 さらに、コンパスはマップの角ではなく、ビューボックスの角にあるようです。



逆に、ビューボックスのサイズを半分に減らすと、マップズーム効果が作成されます。









ここでは、マップの中央四半期のみが表示されます。 これはズームするのにあまり便利な方法ではありません。マップの半分だけに問題が表示されるためです。たとえば、都市マーカー「South Owenson」が画面を超えています。 さらに、フォントや私が必要としない他のもののサイズを2倍にします。



ビューボックスのより便利な側面は、原点の変更です。 これまで、ビューボックスはマップの中央に配置されていましたが、これは必須ではありません。 たとえば、マップの左側のポイントにビューボックスの中心を置くことで、マップを右に移動できます。









境界線やその他の問題への影響に再び気付くことができますが、本質的にマップは右に移動しました。 これの有用性は明らかではないかもしれませんが、幅が通常のマップの幅の2倍であるマップを生成すると想像してください。 デフォルトでは、次のようになります。









他の地図のように見えますが、実際には大きな地図の中心部分にすぎません。 つまり、ビューボックスを変更して、マップの他の部分を概要ウィンドウに転送できます。









ここでは、視点を左に移動したため、元のビューの東の世界の一部が表示されます。 Dragons Aboundは、表示されているかどうかに基づいて特定の機能（たとえば、オブジェクトに名前を付ける）を実行するため、マップ上の一部の名前が変更されています。 ビューボックスを移動するときにマップが一定になるように、これを変更する必要があります。 ただし、後で大きなマップでビューボックスを移動し、必要なエリアの地域マップを生成できます。 つまり、大陸のサイズの大きな地図を生成して表示できますが、大きな地図内の地域の地域地図も生成できます。



要約すると、ゲームは3つの座標系を使用します。 1つは、世界のオブジェクトの抽象SCです。 2つ目はビューボックスで、世界の可視領域を定義します。 3番目はビューポートであり、画面上のどこにマップを描画するかを制御します。 より大きな世界を描くには、最初のSCを拡張する必要があります。 画面にさらに表示するには、ビューボックスを展開する必要があります。 ビューボックスを移動して、大きな世界のさまざまな部分を表示することもできます。

パート2.カードを永続的にする

前のパートでは、座標系を調査し、ビューポートSVGを移動して大きな世界の個々の部分のみを表示する方法を学びました。 ただし、このアプローチにはいくつかの問題があります。以前私は、目に見えないものはすべて重要ではないと考えていたためです。 このパートでは、これらの前提を排除して、不変の大きなマップのさまざまな部分を生成および表示できるようにします。



前のパートで説明した名前の配置の問題は、明らかに次の2つのタイプの1つのカードで顕著です。









同じ世界がありますが、ビューだけが左にシフトされています。









地理は同じですが、多くの名前が変更されていることに気付くかもしれません。 2つのタイプでは異なるオブジェクトが表示され、名前の作成プロセスは乱数によって制御されるため、異なる名前が取得されます。



コードを見ると、可視性に応じてほとんどすべてのオブジェクトに名前が付けられていることがわかりました。 ただし、後続のすべてのオブジェクトに名前を付けることが困難になる例外は1つだけです。 私たちの場合、例外はDragons Aboundが目に見える海岸線のみを生成することです。 この理由は非常に紛らわしいです。 実際、世界の端に沿って「海岸線」がありますが、この行を作成すると、プログラムロジックの一部が破壊されます。これは、世界全体を包含するためです。 これを避けるため、目に見える海岸線のみを生成しました。 マップがビューポートをはるかに超えて拡大できるようになったため、このソリューションは見栄えがよくありません。 代わりに、マップの実際の端に近づくと、海岸線の生成を停止する必要があります。 （まだ画面の外に出て、端の問題を隠します。）



この問題を解消した後、2枚のカードの名前は一定のままです。









そして：









将来の注意点： インタラクティブ機能を使用してマップオブジェクトの名前を変更した場合、この変更は現在の形式で再作成されず、おそらく再現できません。 検討する価値があります。



前のマップをよく見ると、マップの中央下部近くの海域には、「Meb Island」という垂れ下がったラベルが付いていることがわかります。 それは、 ドラゴンズアバウンドが実際に海の領域は島であると信じているために起こりました。 技術的な詳細は説明しませんが、地図を超えて島と湖を区別することは驚くほど困難です。 このアルゴリズムは、目に見えない海岸線の生成に加えた変更を混乱させます。このような問題を回避するには、修正する必要があります。



次に、マップのサイズを4倍にして、マップウィンドウにその4分の1のみを表示します。









一般に、すべてがきれいに見えます（マップ上に興味深い川のシステム、大きな湖がありますが、都市は非常にまれであることがわかります。 ドラゴンズアバウンドは10〜20の都市を生成するために発生しました。サイズが4倍大きい場合、世界の相対的なサイズに応じて間隔を変更する必要があり、おそらく複数の場所で行う必要があります。



問題を修正した後の同じカードを次に示します。









マップ上には、より論理的な数の都市および町がありますが、これは別の問題を示しています。 マップの端には、左下隅にあるNanmrummombrook、Marwynnley、Noyewoodなど、多くの余分な名前が表示されます。 これは、配置コードメソッドが表示されている場所に配置しようとするために発生します。 以前は、この手順では、画面の外側のラベルについて心配する必要はありませんでした。これは、地域サイズのマップでは通常、全世界が表示されるためです。 しかし、現在では、画面外に都市やその他のオブジェクトが配置されている場合があります。 したがって、不可視マップオブジェクトのラベルを作成しようとしないロジックをラベル配置プロシージャに追加する必要があります。









今、絵はより論理的です。 右側では、Cumdenはマップ上でほとんど見えませんが、ラベルは表示されている場所にあります。



大きな地図ではすぐに気付かない側面が1つあります。世界の場所の数は変更されていません。 マップは（ある意味では）4倍大きくなりましたが、その合計面積は同じ数の場所によって制限されています。 マップ生成の初期段階は、一定数のロケーションを持つボロノイ図で世界をカバーすることでした。 つまり、マップが大きくなると、ボロノイのセルも大きくなります。



マップサイズに応じてロケーションの数をスケーリングすることは論理的ですが、残念ながら、 ドラゴンズアバウンドの実行速度のロケーション数への依存性は線形よりもはるかに悪いです。つまり、多数のロケーションを持つマップの生成には多くの時間がかかる可能性があります。 以下は、クアッド解像度（場所の数）のカードの例です。









追加された場所は生成プロセスを変更するため、地形は上記のマップとは異なりますが、海岸では追加された詳細を確認できます。



幸いなことに、大きなカードを生成するパフォーマンスをプロファイリングするとき、プロセッサ時間のほとんどが明らかな問題に費やされていることに気付きました。 デバッグ後、私は最も邪魔なものを削除しました。これにより、マップをさらに作成することができました。 これが4xカード全体です。









ズームは25％です。 Chromeが表示できるおおよその最大マップサイズのように見えます。 ワールド生成手順では、より大きなマップを処理できますが、それらを表示しようとすると、ブラウザーがクラッシュします。 この意味で、Firefoxはより機能的なようです。 元のサイズの9倍のサイズのカードを表示できます。 ここにそのようなカードの一部があります-私はフルサイズのままにしたので、サイズと詳細をよりよく理解するために別のウィンドウで開くことができます。









Firefoxはこのサイズのマップを生成できますが、スクリーンショットはブラウザーウィンドウの最大サイズでしか撮影できません。 マップをPNGファイルとして保存する機能がありますが、マップの表示された部分のみを保存できます。 マップをスクロールし、個々の画面をキャプチャしてそれらを接続することはできると思いますが、時間がかかります。



最良の解決策は、SVG自体を保存して、Inkscapeなどのプログラムで開くことができるようにすることです。



以前はSVGマップをInkscapeにカットアンドペーストできましたが、世界地図用のSVGは非常に大きいため、ブラウザをカットしようとするとクラッシュします。 幸いなことに、 FileSaver.jsを見つけたので 、それを使用してSVGを直接ファイルに保存してからInkscapeで開くと、非常に大きな画像が作成されます。



少なくとも理論的には。 Inkscapeでこれらのマップを開こうとすると、いくつかの問題が発生します。



最初の問題は、SVGを開く方法において、Inkscapeの前提がChromeおよびFirefoxの前提と異なることです。 特に、パスで塗りつぶしの色が指定されていない場合、ブラウザは塗りつぶしがないと見なします。 Inkscapeは、アウトラインが黒で塗りつぶされていると想定しています。 したがって、保存したSVGをInkscapeで開くと、マップの最上層に塗りつぶしの色が含まれていないため、ほとんど完全に黒になります。 これは、ブラウザとInkscapeの両方でアウトラインが等しく表示されるように、必要な場所に「fill：none」を指定することで修正できます。



2番目の問題は、Inkscapeのマスク処理でエラーが発生することです。 Inkscapeは1つの要素のみでマスクを作成するようであり、複数の要素を持つマスクを適切に処理しません。 Dragons Aboundは、いくつかの要素を持つ多くのマスクを作成します。 この問題を回避するには、各ゲームマスクのすべての要素を1つの（オプションの）グループ要素にグループ化します。



3番目の問題は、画像やその他のダウンロード可能なリソースに関連しています。 元のSVGでは、それらへの参照は、「images / background0.png」などの相対形式で示されます。 私のソースは、 使用する別のWebサーバーが指定された場所でこれらのリソースを見つけることができるように配置されています。 同じSVGを取得してInkscapeで開くと、これらの相対パスはURL「file：」として扱われ、InkscapeはSVGが保存されたフォルダーに関連するリソースを検索します。 この問題は、適切な場所に既にリソースがあるフォルダーにSVGを保存することで簡単に回避できます。 Webサーバーが使用するのと同じルートフォルダーでも、同じ（相対）パスに沿ってリソースのコピーがある別の場所でもかまいません。



4番目の問題はフォントです。 Dragons Aboundは、Webフォントとローカルに保存されたフォントの両方を使用します。 両方ともWOFF2形式です。 ブラウザでは、CSSフォントファミリスタイルを使用してテキストに適用され、マップを生成する前に、使用可能なすべてのフォントがWebページにアップロードされます。 ゲームで同じファイルを開くと、システムフォントディレクトリでフォントが検索され、別のフォントディレクトリを指定することはできません。 （少なくとも私が開発しているマシンでは）簡単な解決策は、ゲームで使用されるフォントをシステムフォントディレクトリにインストールすることです。 ただし、フォント名は一致する必要があるため、見た目ほど単純ではありません。Windowsでは、フォント名を変更する簡単な方法はありません。 ただし、もちろん、このようなスキームは、必要なフォントがすべてインストールされていないコンピューターでは機能しません。 よりポータブルなソリューションは、マップにSVGフォントを埋め込むことです。 これは私のTODOリストに載ります。



最終的に、私はこのマップ生成インターフェースに来ました：









エクステント入力フィールドは、ワールドの合計サイズを指定します。1x1はソースマップのサイズです。 vbx（ビューボックス）のサイズは、マップに表示される世界の断片のサイズを決定します。 スクリーンショットでは、1x1の値も持っています。つまり、マップは全世界を表示します。 vbx centerフィールドは、世界のマップセンターの位置を指定します。 0、0は世界の中心です。 最後に、SVGオプションは、1ビューボックスサイズ単位あたりの画面ピクセル数を指定します。 値が775の場合、1x1マップが775x775ピクセルの量で画面に表示されます。 これは、非常に大きなマップを作成するときに便利です。 パラメーターを低い値（たとえば、150ピクセル）に設定することで、画面全体に大きなマップを収めることができます。



これらの6つのパラメーターを変更することで、世界のサイズと、地図に表示される世界の一部を制御できます。 [生成]ボタンは、予想どおりに機能します。 表示ボタンは、単に世界の一部を表示します。つまり、世界を生成し、その個々の部分を表示して、世界を再生成することなくビューボックスパラメータを変更できます。 （プログラマは、これをスケーリングとスクロールとして実装する方が適切です。）[PNGを保存]ボタンは、表示可能なマップをPNGファイルとして保存します。 [SVGの保存]ボタンは、マップ全体のSVGファイルを保存します。 Test Itボタンは、さまざまな機能の開発中に変更されるテストコードを実行するために使用されます。



大きな世界のすべての部分を生成して反映できるようになったので、次に、地形をより大きな地図に適合させることに進みます。

パート3.寿司フォーム

前の部分でさまざまな変更を行ったので、前の世界よりもはるかに大きい世界（最大8倍）を生成し、大きなグラフィックイメージとして保存できるようになりました。





（Flickrで最大解像度4800x2400でマップを表示するには、別のウィンドウで画像を開きます。）



地域マップを作成したのと同じ手順生成を使用して、これらのマップを生成します。 上に示した地図は、かなり規則的な大陸の形といくつかの興味深い外島を持っています。 ただし、それはほとんど運に依存します。 別のマップを次に示します。





このカードは、島々とスイスの寿司チーズの混です。



もう1つの例は、前の2枚のカードの間にあるものです。 それは完全に現実的ではありませんが、幻想的な環境にとって興味深いかもしれません：





これは大陸の巨大な土地ですが、奇妙な形の土地がかなりあり、一般的に世界はまったく「リアル」に見えません。 （誰かにとって、そのような世界はファンタジーに非常に適しているように思えます。）では、世界地図にはどのような形が必要でしょうか？



私が見た空想の世界地図のほとんどは、たとえば次のアンデレン地図のような大きな島の大陸（小さな島の周り）を表しています：









または、このアンゴルンの地図のように、大陸の半島：









時々、マップは完全に土地またはいくつかの島大陸で構成されますが、それらはルールの例外である可能性が高くなります。



はじめに、「島」大陸の世代を把握しましょう。 私のゲームで判明したように、マップのサイズを考慮してマップ上に大きな中央の島を生成する機能が既にあったため、大陸の主要な形状を生成するのに適しているはずです。 ノイズと追加の島々が残りを処理します。









この地図では大きな中央の海は予想していませんでしたが、これは嬉しい驚きです。 別の例を次に示します。









中央の島の機能の問題は、私が示した正方形の地図には適しているが、長方形の地図にはあまり良くない円で始まることです。 （以下は、基本的なフォームがより明確に見えるように、歪みが少ない例です。）









これは、地図のサイズに応じて撮影された、楕円形の（歪んだ）円の代わりに寿司をマスクすることで簡単に修正できます。









これらの中央の島は地図を埋めるために拡大縮小されますが、大陸の地図の多くの場合、大陸の周りに「境界」を残す必要があります。 2つのパラメーターは、X軸とY軸に沿って島を埋めるマップのサイズを制御します。









以下に、より論理的な歪みがある同じ境界管理システムを示します。





地図の東部と西部が海のままであることがわかります。 （別のウィンドウでマップを開いて、より注意深く調べることができます。）これは、マップが全世界（およびその右端と左端を接続できる）または対応する端から海がある別のマップに接続できる世界の一部を表示することを意味します。



前の地図を研究した熱心な読者は、海と陸地のパターンが地図の中央で止まっていることに気づいたかもしれません。以前は、サイズが1x1のマップしかなかったため、海と陸のパターンのサイズはこれらのマップに適合していました。大きなマップでは、マップ上にパターンを手動で並べる必要があるため、この機能を追加しました。 （SVGにはパターンタイルを実行する方法がありますが、Chromeにはバグが含まれているため、使用できません。）これは、自動的にタイル表示されるより小さな陸と海のパターンを使用できるため、優れた機能です。なぜ気付かなかったのか分かりません！



それで、今では島の大陸はうまく機能しているので、「半島」大陸の実装に移ります-大陸がその端から地図上に現れる地図です。









この場合、大陸は3つの端で崩壊することはできません。しかし、そのような地図の主な特徴は、地図上に表示されている大陸と地図外の土地との間に重要な土地接続があることです。



マップ外でこのような接続を提供する最も簡単な方法は、生成中に低い海面を設定することです。そのため、マップに表示される土地の面積を増やします。これにより、マップの端に沿って土地が大きくなり、（海ではなく）土地が出現する可能性が高くなります。









もちろん、これは土地の質量が非常に興味深いことを保証するものではなく、実際に統一されます：









単一の大陸の類似性は、同じ世代の島大陸を使用して作成できますが、同時に島をマップの端に移動します。次のようなものが得られます。









大陸（主に）は中央の島であり、右上に移動していることがわかります。これは大陸であり、厳密な島の形状を維持する必要がないため、形状に歪みを追加できます。









明らかに、救援の生成には他にも多くのアプローチがありますが、少なくともこの2つは、大陸規模で最も一般的な形態の土地を生成する機会を与えてくれます。



気配りのある読者は、大陸の多くの地図上にストライプの形で奇妙な形の森林に気付くことができます。次回は、これらの奇妙な現象を引き起こす風モデルとバイオームの問題に取り組み始めます。

パート4.風モデル

前述のように、ドラゴンズアバウンドマップ上の大陸のサイズは、天候とバイオームの非現実的なパターンを示し始めました。この例では、森林が一般的な風向に沿って並んでいることがわかります。









理由は壊れたコードではありません。むしろ、天気とバイオームのモデルは単純すぎて、大規模にこれが明らかになります。これらの問題に対処するために、風モデルを改訂することから始めました。



私の風モデルは、地球の風の力学をよりよく反映したいものです。ハドレー細胞、貿易風などです。このようなダイナミクスは、大陸の地図上の奇妙な気象パターンを取り除くのに役立ちます。しかし、それらが追加されたときに、ドラゴンズアバウンドの風モデルに対する苦痛な不満が示されました。 （風モデルの初期実装については、こちらをご覧ください。。）数日間これについて考えた後、私はゲームマップがボロノイ図として表示されるという事実に問題のほとんどが要約されると決めました。 （むしろ、ボロノイ図のドロネー三角形分割。）地形を生成する際に多くの利点があります。ノイズと組み合わせて、自然に見える陸地を作成できます。それが救済を生み出すために頻繁に使用される理由です。ただし、個々の三角形のサイズと向きは異なるため、隣接するセルを使用する風モデルなどの計算は非常に複雑になります。等間隔の同一エリアのグリッドを介して風をモデリングする方がはるかに簡単です。さらに、風モデルはほとんどの場合、土地ほど詳細である必要はありません。



しかし、ドラゴンズアバウンドの根底にあるボロノイ図を完全に放棄したくありません。 （少なくとも、これはプログラムのほぼ全体を書き換える必要があります！）その代わりに、マップを均一なグリッドにバインドし、その中で風モデルを実行してから、逆バインドを実行したいと思います。前後にコピーする際の損失が大きすぎない場合、これにより風モデルがより速く簡単になります。



どのグリッドを使用する必要がありますか？理想的には、グリッドは隣接するグリッドから等距離にある等しい面積で構成する必要があります。そして、この説明は六角形のグリッドのようなものです。









実際、六角形のグリッドは、平らな面を等しい面積に分割する最良の方法です。



次のステップは、プログラムで六角形のグリッドをどのように表現するかを決定することです。手がかりを求めてネットワーク上で少し検索すると、各リンクからアミットパテルの六角形のグリッドに関するページに戻りました（Habréでの翻訳）。おそらく、それから始める必要があります。また、ゲームメカニクスの実装に関する情報を探している場合は、最初にRed Blob Games Webサイトを探索することをお勧めします。アミットは私よりもうまく説明しているので、何かはっきりしないことがあれば、彼のページを読んでください。



最初に行うべき選択は、六角形のグリッドを保存する方法です。最も簡単な方法は、2次元配列として保存することです。その後、グリッドセルを配列にバインドする機能が必要です。ここには多くのオプションがあります（Amitのページを読んでください）が、彼が奇数rと呼ぶものを使用します。









各セルの数値は、2次元配列のセルのインデックスです。（画像はAmitのページから盗まれています。彼のページではインタラクティブなので、実験してみることをお勧めします。）



選択したら、六角形のグリッドにインデックスを付ける方法を学ぶ必要があります。たとえば、六角形のセル（3、3）を探している場合、その近傍はどうなりますか？各セルの幅が5ピクセルの場合、セルの中心の座標（3、3）はどうなりますか？などなど。これに対処するのは難しい場合があるので、Amitが私のためにそれをしてくれてうれしいです。



Amitから必要なものをすべて盗むことができると仮定すると、まず、マップ上に六角形を配置する方法を理解する必要があります。この段階では、配列はまだ必要ありません。配列のふりをして、六角形がどこにあるかを確認できます。六角形の位置がわかっている場合は、単にマップの幅をそれらの間の水平距離で除算して列の数を取得し、同じことを垂直に実行して行の数を取得し、各場所に六角形を描画します：









これらの六角形は、風モデルに使用するものよりもはるかに大きいですが、すべてが正しく配置されていることがわかります。



ここでは、マップの端を開き、中央の六角形と境界のみを描画して、マップ全体を本当に閉じているかどうかを確認しました。









上部と下部はマップの外側にありますが、マップの一部を見逃さない限り、海外のいくつかのセルの存在は重要ではありません。



次のステップでは、六角形のグリッドの配列を作成し、すべてのドロネー三角形を対応する六角形にスナップします。 Javascriptは負の配列インデックスをサポートしていないため、セル（0、0）をマップの中央から右上隅に移動する必要があります。これを行った後、すべてのドロネー三角形を一周し、六角形グリッドの対応するセルに追加します。これを確認するには、土地を含む六角形に色を付けます。









セルが土地かどうかを判断するために、このセルに入るすべての場所の高さを平均します。一部の沿岸六角形では、土地がある場合でも平均がゼロ未満であることに気付くかもしれません。六角形のすべての場所の最大高さを使用することもできます。









この場合、検索は反対方向に行われます-六角形に土地がある場合、その六角形は土地としてマークされます。どちらが良いかは、必要なものに依存します。



いずれにしても、六角形のサイズを小さくすることで精度を上げることができます。









海岸ははるかに良くなったが、新たな問題が生じた-土地とはみなされない多くの内部六角形。これは、六角形が十分に小さくなると、六角形の中にはドローネ三角形がまったくないために起こります。したがって、それらには「高さ」はありません。 （これは、ドローネ三角形の不均一性も示しています。）



この解決策を使用できます-不足している三角形の高さを、隣接の平均として、または隣接の最大として取得します。









一般に、六角形と場所の間の結合が1対1でない場合、不足している情報を埋めるために修正が必要です。



マップ上に六角形のグリッドを配置したので、風モデルの実装を開始できます。風モデルの主なアイデアは、いくつかの風（貿易風）をシミュレートし、それらが不動状態に達するまでマップ全体に分布させることです。六角形のレベル（またはドローネ三角形で行う場合は場所のレベル）には、2つの段階が含まれます：（1）現在の六角形に入るすべての風を要約し、（2）合計された風が六角形から出る方法を決定します。



最初の段階は非常に簡単です。各六角形には6つの隣接があり、これらの各六角形が寄与しています。六角形に入る各風をベクトルと考えると、セル内の風の合計はこれらのベクトルの合計になります。同じ力の厳密に反対の2つの風は互いに無効にします。



2番目の段階（総風がどのように六角形から出るかを決定する）は、考える必要があります。最も単純なケースは、六角形を直接通る風です：









この場合、風は変化せずに次のセルに移動することが予想されます。（ここで、赤いベクトルはソース風であり、青いベクトルは伝播する風のベクトルです。）



しかし、風が隣接するセルに直接吹かない場合はどうでしょうか。









この場合、風の一部はその直上の六角形に吹き込み、他の部分はこれから反時計回りに位置するセルに吹き込み、比率は矢印が指す方向に依存する必要があると考えられます。この場合、風の主要部分は上部のセルに移動し、隣接するセルには移動しません。



また、風の広がりの方向を決定する必要があります。1つのオプションは、元の風の方向を維持することです。









これが最も現実的なオプションのようですが、別のオプションがあります-交差する六角形のエッジに従って風の方向を変える：









このアプローチの精度は劣りますが、利点があります。入ってくる風は常に6方向のいずれかであるため、計算が簡単になります。



地形を考慮すると、別の困難が生じます。山が風に吹かれたらどうなりますか？









この場合、風の一部は山の上を通過しますが（降水を引き起こす可能性があります）、風の一部は側面に向きを変えます。









したがって、風が六角形からどのように出るかは、その方向と、隣接するセルの緩和に依存します。



次に、ベクトルの表現方法について説明します。主に2つのオプションがあります。まず、ベクトルはX値とY値として表すことができます。たとえば、次のようになります。









（0、0）から始まるベクトルを描く場合、（X、Y）は終点の座標です。このようなレコードにより、ベクトルの合計が非常に簡単になります。すべての値（X、Y）を合計して、新しいベクトルを取得します。









別のオプションは、ベクトルの角度と長さを使用することです：









この形式では、ベクトルの回転や長さの変更などの操作を簡単に実行できます。

風モデルで必要とされるほとんどの操作では、最初のオプションの方が優れていますが、場合によっては2番目のオプションの方が優れているため、必要に応じて切り替えておくと便利です。車輪を再発明しないために、Javascriptのベクターライブラリを探し、Victor.jsが完全に登場したので、それを利用しました。



まず、各六角形に風のベクトルを追加し、視覚化できるかどうかを確認します。









これまでのところよさそうだ。



次のステップは、風ベクトルを正しく分割して次のセルに分配できるかどうかを確認することです。最初に、他のセルにつながる角度を計算する必要があります。私はアミットのページで再び答えを見つけました：









つまり、0度のベクトルは右の六角形を指し、60度のベクトルは右下の六角形を指します。これらの2つの方向を指すベクトルは、2つのセルに比例して分割されます。つまり、30度の角度のベクトルは、右のセルと下から右のセルに均等に分割されます。各ベクトルは、2つの隣接するセルの面の角の間のどこかにあるため、風のベクトルの角度を見て、2つの六角形の中央の角の間にあることを確認し、これらの2つの六角形の間で比例的に分割します。



たとえば、風のベクトルの角度が22度の場合：









次に、値の38/60が右側のセルに伝播し、ベクトル値の22/60が右下のセルに伝播します。ベクトルがXとYの値のペアとして表示される場合、元のベクトルの各値に分数（たとえば、22/60）を掛けてから、新しい六角形の風ベクトルに追加することにより、それらを分配できます。



これをテストするために、風をさまざまな方向に配置し、それらをマップの上部と側面に配置して、それらがマップ上で正しく広がるかどうかを確認します。風が衝突する場合、それらを組み合わせて、速度を上げて平均的な方向を選択する必要があります。









ここでは、風が対角線に沿って集まり、結合して下隅に向かって吹くことがわかります。



次のステップは、風に対する土地の影響を考慮することです。もちろん、実際の風のモデルは非常に複雑ですが、私は主に土地の地理が地表風にどのように影響するかに興味があります。最も単純なレベルでは、これは風の方向と速度に対する土地の高さと低地の影響です。私は多くの異なるアプローチを試しましたが、その結果、2つの簡単なルールに落ち着きました。

1. 風は障害物から遠ざかる。
2. 風は上昇すると減速し、加速して下降します。

障害物は、高さが高いセル、たとえば山のあるセルに風が吹くと発生します。この場合、風が吹く2つのセルを見て、風の角度を変更して、2つの六角形の低い方を指すようにします。角度の変化の大きさは2つのセルの高さの違いに依存するため、風が山のある2つの隣接するセルに吹き込むとき、その方向はほとんど変化しませんが、山のあるセルと平野のあるセルに吹き込むと、空のセルに向かってより多くなります：









風の強さを調整できます。上記のマップでは、彼は強すぎて、多くの非現実的なバイオームの出現につながります。より論理的な意味は次のとおりです。









起伏によって引き起こされる風の動きの大部分は依然として残っていますが、強風の大きな隙間と谷は小さくなっています。



リアリズムを強化する別の機能は、風の分散です。たとえば、上の地図は、ブリーチの街の真上で風が西に吹いていることを示しています。長い距離を吹き飛ばしますが、予想どおりに消散することはありません。吹いている風が別の空気と出会うと、通常は風も一緒に引っ張ります。これをシミュレートするために、各六角形に吹く風の小さな部分を取り、それをすべての隣接するセルに再分配できます。上記の小さな散布図のマップは次のようになります。









ご覧のとおり、Breechesの風がやや消散し始めています。



この操作により、風向の大部分が決まります。 2番目の部分は、上昇時の風の減速と下降時の加速です。これは、風が来るセルの相対的な高さと、風が吹くセルの高さを見て、必要に応じて加速/減速することで実現できます。



すべての外観は次のとおりです。









島の中央部の高い山々を吹き抜ける風の一部が遮断されたことがわかります。そしてその逆-いくつかの新しい風が島の西部に現れ、そこで空気は比較的高い土地から海に移動します。 （これは沿岸の微風です！実際にはそうではありませんが、メカニズムはそこでは異なります。）



これで、既存の降水アルゴリズムに新しい風を代入できます。以下に比較を示します（左側に古い風、右側に新しい風）：





（画像をクリックすると、拡大版が表示されます。）明らかに、風のモデルには違いがあります。両方のマップで、風は東から吹いています。地図の中央付近の山々は風を南に向け、大雨を引き起こし、山の南に沼地と森林を作ります。下部では、干渉なしに風が吹き、島の東半分に沿って森林が形成されます。元の風モデルでは、島の西部に森を作るのに十分な風が中央の山と沼地を通過しました。新しいモデルでは、風のほとんどが遮断され、草が茂ったバイオームが山の向こう側に形成されます。



古いモデルには、ランダムパラメーターの変動性（一定の間隔内）があり、これらのパラメーターのいくつかの組み合わせにより、新しいマップのような写真が得られる可能性があります。しかし、実際には、古いモデルの正確な動作を再現する必要はありません。説得力のある結果を作成するモデルだけです。



このすべてのポイントは、新しい風の振る舞いを大陸の地図に追加できるように、風の生成を加速して単純化することです。しましたか？元の風モデルと新しい六角形ベースのモデルのプロファイルを作成しました。新しいモデルは、元のモデルよりも15〜20倍高速であることが判明しました（！）。これは非常に重要な加速であり、カードにはほとんど影響しません。この実験は、モデルが六角形のサイズに特に敏感ではないことを明らかにしているため、必要に応じて、セルのサイズを大きくすることでアルゴリズムをさらに高速化できます。



次回は、新しい風モデルを使用して大陸規模の風パターンを実装し、それらを降水モデルとバイオームに接続する作業に取り組みます。