シームレスにループする2Dマルチプレイヤーレベルを作成しますか？

最近、ループレベルのデザインを持つことができる2D横スクロールマルチプレイヤーゲームを作成する方法について議論がありました（スターバウンドとその世界がどのようにループしているのかを考えてください）。

最も簡単な方法は、プレイヤーを一方から他方へテレポートできるトリガーゾーンを持つ長方形のマップを作成することだと思いました。しかし、このアプローチの明らかな問題は、マップの端に複数のプレイヤーが一度にいる場合です。プレイヤーをお互いの前にテレポートするだけでなく、他のプレイヤーが消えることなくプレイヤーを輸送する方法が必要になります。

このアイデアを追加して問題を解決するために、私は次のことを思いつきました。プレイヤーが「クローンゾーン」（緑の四角）を見ることができるトリガーゾーン（画像の赤の四角）を持っています。この緑色の正方形では、トリガーゾーンの反対側からのオブジェクトが対応するクローンゾーンにコピーされます（A＆Bシェイプで見ることができます）。プレイヤーが「クローンゾーン」の開始端に到達すると、マップの反対側にテレポートされます。

この例では、プレイヤー2はプレイヤー1を見ていると考えますが、実際には自分のクローンを見ているか、その逆です。

これは目前の問題にとっては少し極端で複雑に思えました。私の質問は、この解決策が問題に取り組むための良いアプローチであるかどうか、またはこの問題を解決するより簡単な方法があるかどうかを知ることです。

これらすべてのトリガーを備えたこのシステムは、少々複雑すぎてエラーが発生しやすくなっています。

次のようなモジュロを使用してプレーヤーの位置をラップできます playerPositionX = playerPositionX % mapWidth

このようにして、プレーヤーがに到達playerPosition == mapWidthするplayerPositionと0にリセットされます。

このソリューションは、レンダリングシステム全体で拡張できます。

正規の解決策は、ポータルを使用することです。この例では、左端と右端を接続するポータルがあることを除き、レベルは1つだけです。

そのポータルを移動するものはすべて、座標がポータルのもう一方の端に変換されます。そのため、何かがポータルを左に移動している場合、レベルの右側に再び表示されます。

カメラもポータルをサポートする必要があります。ポータルがカメラ内にある場合、ポータルの両側にレベルの一部をレンダリングする必要があります。シームレスなタイルグラフィックス用の画像エディターに精通している場合は、ここでも同じです。

退屈な部分は、距離やパスを扱うすべてのものが もポータルをサポートする必要があるということです。これには、AI、視線アルゴ、音響減衰などが含まれます。

ポータルの良いところは、非常に強力だということです。ビルドエンジンは、「真の」3Dエンジンではないにもかかわらず、それを使用して複数階のレベルをシミュレートしました。最新のエンジンの中には、ポータルを使用して非ユークリッド空間を作成するものもあります。PortalとAntichamberは、3Dの注目すべき例です。

画面に表示するものとメモリにあるものは、まったく異なるものであることを忘れないでください。世界に関するデータを入力する必要があるウィンドウがあるとします。ウィンドウを左から右に埋めていきます。世界を埋めるためにデータを解析している間に、世界の終わりに達した場合は、単にデータの先頭にループバックします。モジュロ演算を使用することが理想的です。あなたはすべてのためにこれを行う必要があることを忘れないでください。発射物、光線、プレイヤー、物理学; それらはすべて、世界の境界を越えるときに自分の位置をラップする必要があります。

各プレーヤーはデータを共有しますが、独自のデータの観点を持っています。それらの窓は、世界のどこに立っているかに応じて異なる方法で配置されます。

これは、クローンを作成したり、テレポートしたりする必要がないことを意味します。基本的に、お互いの画面にキャラクターをレンダリングするだけで、クローンを作成しています。

レンダリングを世界から切り離すと、クローンやテレポートアーティファクトに頼らずに、ラップアラウンドとレンダリングを修正できます。

まず、あなたの世界にはから0までの固定サイズの世界がありWidthます。オブジェクトが0未満になると、オブジェクトは最後までラップされ、オブジェクトがオーバーWidthラップされると常に最初までラップされます。これは、世界のすべての論理オブジェクトが常に範囲内にあることを意味します0...Width。

第二に、レンダリングのために、位置に対してモジュロを行います。したがって、画面の左側は「ベース」であり、右側は「ベース+サイズ」です。そのため、その範囲内で何かを探すためにあなたの世界を調べます。実際にモジュロ範囲を検索し、それをにマップします0...Width。

検索中のトリックは、オブジェクトの相対的な位置を返すことです Base、左側です。これは画面のローカル座標に変換されるため、レンダラー自体はモジュロを心配する必要がなく、ルックアップのみが心配です。

各レンダラーは1か所でオブジェクトを処理するだけなので、何も複製する必要はありません。

ワールドがセグメントで作成されている場合、または3D構造を使用している場合は、セグメントを作成する必要があります。したがって、これは1つの連続したブロックではありませんが、このレンダリングに合わせて移動できます。少なくとも2ブロックは必要ありません。

唯一の合理的なアプローチは、ラップされた世界を、ゲームとユーザーに対して完全に透過的な基礎となるデータ構造に実装することだと思います。いくつかの低レベルでは、実際の座標を基礎となるマップリソースにラップする関数mapCoordinate（）があります...

したがって、実際のワールドの幅が10ユニットしかない場合、プレイヤーとゲームはそれを知りません。プレイヤーにとって世界は無限です-そして、ゲームが位置15にあるものを尋ねる場合、基礎となる関数はこの要求をモジュロ10に変換し、位置5でアイテムをパックします。

そのため、ゲームロジック全体およびその他のすべてについて、無限の大きな世界があるように、すべてのコピーがたまたま存在します。

まったく同じではありませんが、ゲームジャムで似たようなものを実装しました。このゲームでは、プレイヤーが小さな円のレベルを移動し、プレイヤーがpiの「x」の位置に達したときにラップされました。レンダリングは簡単でした。すべてをレンダリングした後、オフセットカメラを回転させて、何が起こっているかを追跡するからです。上記で提案されているように、同様のものを実装できます。

• 描画するときは、カメラの位置と視野を考慮して、カメラの位置を確認し、描画する必要があるものを決定します。
• カメラが地図の「エッジ」を過ぎて見える場合、通常は位置のレベルの幅を加算または減算するだけで、世界の反対側から適切な量のコンテンツを選択してそのエッジを描画します。
• ゲームロジックは、この継ぎ目を認識し、他の回答で述べたように調整する必要があります。注意すべき特定のケースは、一方のオブジェクトが一方の側にあり、他方のオブジェクトと衝突する衝突です。