タグ付けされた質問 「grid」

8方向のいずれかの動きがまったく同じターン（チェスボードスタイルの規則）を要するタイルグリッドで、斜めの動きが直交する動きよりも多くの新しいタイルを表示するのを防ぐことができますか？ たとえば、次の画像の赤いボックスです。緑色のセルが現在表示されています（正方形の視野）。8方向のいずれかに1タイルの距離を移動できます。 北東に移動すると、13の新しいタイル（青で表示）を探索します。代わりに南に移動する場合、7つの新しいタイル（紫色で表示）のみを探索します。 各方向への旅行を探索に等しく有利にするにはどうすればよいですか？

57 movement  grid  line-of-sight 

六角形タイルが正方形タイルよりも優れていることを理解しています。しかし、なぜ八角形が代わりに使用されないのですか？私は、それらが8方向のより良い、より自然な動きを提供すると思うでしょう。 私はいくつかのゲームでそのようなマップを使用することを考えていましたが、それを使用しているゲームを見たことがないので、使用するのに明らかに欠陥があるものを見逃したのでしょうか？

42 grid  level-design  hexagonal-grid 

XNAゲームには2Dグリッドベースの水システムがあり、セルオートマトンを使用して水の落下と広がりをシミュレートする方法があります。 斜面を流れる水の例： 各タイルには、0〜255の値の液体を1バイトで格納できます。私が使用していfloatsた古い水道システムは使用しませんが、複雑さを増し、パフォーマンスに打撃を与えました。 各水タイルは、単純なルールセットで自動的に更新されます。 下のタイルにスペースがある場合は、可能な限り現在のタイルから下のタイルに移動します（フローダウン） 2つの側面が同じでなく、ゼロでなく、両方とも通過可能である場合、3つのタイルの合計（左+現在+右）を取得し、3で除算して残りを中央（現在の）タイルに残します 上記のルールが合計として2の数を与えた場合、タイルを2つの側面（1、0、1）に分割する必要があります ルール2が合計として1を与えた場合、流入するランダムな側を選択します ルール2が失敗した場合、一方が合格でもう一方が合格でないかどうかを確認する必要があります。それが当てはまる場合、2つのタイルに対して現在のタイルを半分に分割します このロジックを拡張してプレッシャーを含めるにはどうすればよいですか？圧力がかかると、液体が「Uベンド」を超えて上昇し、エアポケットが満たされます。 これが現在どのように失敗するかの例： 水はUベンドの両側で流れ、均等化されるはずです。さらに、ウォーターブロックがどれくらい下にあるか、したがってどの程度の圧力が発生しているかを調べるためのメソッドを作成しました。ここで、これらの数値を取得して他の領域に適用し、圧力を均等化できるようにする必要があります。

30 xna  c#  physics  grid  water 

この投稿のおかげで：六角形のタイルとそれらの隣接する隣人を見つける、私は与えられたタイルに隣接するタイルを収集することができます。しかし、オフセットで指定されたタイルの「リング」のみを提供するアルゴリズムにかなりこだわっています。そのStack Overflowポストで与えられたアルゴリズムは、タイルを収集する順序を正確に気にしません。 オフセットごとに6タイルが追加されることを知っています。 オフセット1は、6つのタイル（最初の隣接タイル）を提供します。 オフセット2は12です。 オフセット3は18などです。 オフセットごとに6の一定の成長があります。したがって、これらのオフセットに適応するルールがあるはずだと思います。これを正確に把握することはできません。誰でも？

17 algorithm  grid  hexagonal-grid 

2つの要素、2Dポイントと長方形の領域があります。ポイントはそのエリアの中央を表します。その領域の幅と高さも知っています。そして、エリアはグリッドに対して40°傾斜しています。 次に、このデータのみを使用して、その傾斜領域の各コーナーマークの絶対位置を計算します。それは可能ですか？

17 2d  rotation  grid  computational-geometry 

ゲーム開発業界で3Dユニバースをレンダリングするためのベストプラクティスは何ですか？ 具体的には： データポイントが与えられ、静的です。各ポイントには位置、色、サイズがあります。 データセット全体は、使用可能なメモリよりもはるかに大きくなります。 ユーザーは、より大きな画像を一度に「ズームアウト」できる必要があります。 最も素朴なアプローチは、ユニバースをキューブに分割し、目に見えるものだけをレンダリングすることです。このシナリオで「ズームアウト」をどのように実装する必要があるのか​​わかりません。可能なズームレベルごとにキューブを事前に計算する必要がありますか？または、より良いアプローチがありますか？ テクノロジーにとらわれないソリューションを探しています。

15 graphics  algorithm  grid 

エージェントが土地のために戦っているゲーム/シミュレーションを開発しています。私は次の図に示すような状況にあります。 これらのクリーチャーは歩き回っており、自由な場合は踏む土地を占有します。これをさらに面白くするために、エージェントが実際に土地を歩き回り、侵入者からパトロールするように「巡回」行動を導入したいと思います。 技術的な面では、各正方形はx,y位置として、またその辺の長さを表す寸法として表されます。また、誰が広場を占有しているかに関する情報も含まれています。すべての正方形はに保存されますArrayList。 パトロール動作を導入するにはどうすればよいですか？私が望んでいるのは、各エージェントがエリアの特定の部分をパトロールすることです（彼らはパトロールするエリアを自分たちの間で分割します）。私が見つけた主な問題は次のとおりです。 写真に見られるように、土地の面積は非常にランダムです。各方向の境界がどこにあるかを理解するのはかなり困難です。 エージェントはどのように地域をパトロールする必要がありますか？ 敵チームは中央から領土を奪う可能性があるため、土地のエリアはばらばらになる可能性があります。 私は、各方向に最も遠い正方形を取り、それらをエリアの境界として扱い、それらの境界に基づいて領域を分割するというアイデアを思いつきましたが、これには多くの無関係な土地が含まれる場合があります。 この問題にどのように取り組むべきですか？

14 java  ai  grid 

この質問が初めての場合は、以下の更新前の部分を最初に読んでから、この部分を読むことをお勧めします。 ただし、問題の統合は次のとおりです。 基本的に、衝突の順序と衝突グループが重要なグリッド空間分割システムを備えた衝突検出および解決エンジンがあります。一度に1つのボディを移動し、衝突を検出してから衝突を解決する必要があります。すべてのボディを一度に移動し、可能な衝突ペアを生成すると、明らかに高速になりますが、衝突の順序が尊重されないため、解像度が壊れます。一度に1つのボディを動かすと、ボディに衝突をチェックさせなければならず、^ 2の問題になります。グループをミックスに入れると、多くのボディで非常に速く非常に遅くなる理由を想像できます。 更新：私はこれに本当に一生懸命取り組みましたが、何も最適化することができませんでした。 Willによって記述された「ペインティング」の実装に成功し、グループをビットセットに変更しましたが、非常に小さなスピードアップです。 また、大きな問題を発見しました。私のエンジンは衝突順序に依存しています。 私はユニークな衝突ペア生成の実装を試みました。これは間違いなくすべてを高速化しますが、衝突の順序を破りました。 説明させてください： 私の元の設計（ペアを生成しない）で、これが起こります： 単一の体が動く 移動した後、セルを更新し、衝突したボディを取得します それが解決する必要があるボディとオーバーラップする場合、衝突を解決する つまり、ボディが移動して壁（または他のボディ）にぶつかった場合、移動したボディのみが衝突を解決し、他のボディは影響を受けません。 これが私が望む行動です。 物理エンジンでは一般的ではないことを理解していますが、レトロスタイルのゲームでは多くの利点があります。 通常のグリッド設計（一意のペアを生成）では、これが起こります： すべての体が動く すべてのボディが移動した後、すべてのセルを更新します 一意の衝突ペアを生成する 各ペアについて、衝突の検出と解決を処理します この場合、同時移動により2つのボディがオーバーラップする可能性があり、それらは同時に解決します。これにより、ボディは事実上「互いに押し合い」、複数のボディとの衝突安定性が損なわれます。 この動作は物理エンジンでは一般的ですが、私の場合は受け入れられません。 また、別の問題も発見しました。これは重大です（実際の状況では起こりそうにない場合でも）。 グループA、B、Wのボディを検討する AはWとAに衝突して解決します BはWとBに対して衝突して解決します AはBに対して何もしません BはAに対して何もしません 多くのAボディとBボディが同じセルを占有する場合があります-その場合、ボディ間で不必要な反復が多く、相互に反応してはなりません（または衝突を検出するだけで解決しない） 。 同じセルを占める100体の場合、100 ^ 100回の反復です！これは、一意のペアが生成されていないために発生しますが、一意のペアを生成できません。そうしないと、望ましくない動作が発生します。 この種の衝突エンジンを最適化する方法はありますか？ これらは尊重されなければならないガイドラインです： 衝突の順序は非常に重要です！ ボディは一度に1つずつ移動し、次に衝突を1つずつ確認し、移動後に1つずつ解決する必要があります。 ボディには3つのグループビットセットが必要です グループ：ボディが属するグループ GroupsToCheck：ボディが衝突を検出する必要があるグループ GroupsNoResolve：ボディが衝突を解決してはならないグループ 衝突を検出するだけで解決しない場合があります 事前更新： はじめに：このボトルネックを最適化する必要はないことを認識しています-エンジンは既に非常に高速です。しかし、楽しくて教育的な目的で、エンジンをさらに高速にする方法を見つけたいと思っています。 柔軟性と速度に重点を置いて、汎用C ++ 2D衝突検出/応答エンジンを作成しています。 そのアーキテクチャの非常に基本的な図を次に示します。 基本的には、メインクラスWorld所有している、の（メモリ管理）ResolverBase*、SpatialBase*およびvector<Body*>。 …

14 c++  collision-detection  performance  optimization  grid 

私は2つのことを組み合わせようとしています。私はゲームを書いていますが、浮動小数点の端点を持つ線上にあるグリッドの正方形を決定する必要があります。 さらに、接触するすべてのグリッド正方形（つまり、ブレゼンハムの線だけでなく、青の線）を含める必要があります。 誰かが私にそれを行う方法に関する洞察を提供できますか？明白な解決策は、単純なラインアルゴリズムを使用することですが、より最適化された（高速な）ものはありますか？

12 c#  algorithm  grid  interpolation  floating-point 

これは初心者の質問ですが、ここにそれがあります： 私のマップは2Dグリッドであり、道路と川を生成したいです。開始点から終了点までのルートは、タイル数で最適なルートであってはなりません。代わりに、一定レベルのランダム性（ターン）が必要です。 この種のものに標準的なアルゴリズムはありますか？ 乾杯！ 更新： これは、グリッド上の重みで遊んで、jgraphtライブラリを使用して最短経路アルゴリズム（Bellman-Ford）を適用した結果です。結局、ドーナツの答えに行きました。 http://pastebin.com/AGQGK5ik

12 algorithm  maps  tilemap  grid  content-generation 

画像が許可されました。下のゲームの画像は、「T」字型の一部として認識されている、いくつかの暗いブロックを示しています。ご覧のように、コードは赤い点でブロックを暗くしており、緑色の輪郭を持つ "T"形状は見ていません。 私のコードは、x / yをループし、ブロックを使用済みとしてマークし、形状を回転させ、繰り返し、色を変更し、繰り返します。 私はこのチェックを大きな不安で修正しようと試み始めました。現在のアイデアは： グリッドをループしてすべてのパターンオカレンス（使用済みとしてブロックをマークしない）をメモし、これらを配列に書き込みます もう一度グリッドをループします。今度は、どのブロックがどのパターンで占められているか、したがって、どのブロックが複数のパターンで占められているかに注目します。 もう一度グリッドをループします。今回は、どのパターンがどのパターンを妨げているかに注目します それだけでいいと思います。 私はしなければならないと思う 最初に他のほとんどのパターンを妨害するものから始めて、矛盾する形状のさまざまな組み合わせを試してください。これにどのようにアプローチしますか？ 8つのブロックを占有する3つの競合する形状があり、形状はそれぞれ4ブロックであるため、最大2つの形状しか持てないという有理数を使用します。 （私は他の形状も組み込むつもりであり、競合する形状を通過するときに考慮する必要があるスコアの重み付けがおそらくありますが、それは別の日になる可能性があります） 箱詰めの問題ではないと思いますが、何を調べればよいかわかりません。あなたの助けに感謝して、それが理にかなっていると思います 編集質問の明快さにもかかわらず、誰もが理解しているようです、はい、 各色の中で最大の「T」字を見つけたい （もし私があなたに2つのポイントを与えて、あなたが3つを作ったなら、あなたは少しイライラするでしょう）

11 algorithm  grid  puzzle  patterns 

私は現在、テトリスのような単純なゲームを持っていて、解決できない問題に遭遇しました。 テトリスとは異なりがある場合、単一の落下形状は、I落下する必要のある複数の、潜在的に連動形状を有しています。最終的な位置を計算する必要があります。以下を検討してください。 緑の形状の最終的な位置を計算するには、別の正方形またはボードの端に当たるまで、すべての正方形をスキャンします。できた 複数の単純な形状の場合は、ボードを上に向かって作業します。したがって、赤は移動する必要がないことがわかり、オレンジは1つ下がり、緑は3つ下がります。できた 連動する緑と赤の形の扱い方がわかりません。＃2のロジックを使用すると、空中で「スタック」してしまいます。緑の形状を下にスキャンすると、赤に遭遇して移動しません。赤の場合も同様です。解決策は、2つの形状を1つとして扱うことです。 ＃3と同様に、このシナリオでは、オブジェクトを1つとして扱うことで成功させることもできます。 ＃3や＃4とは異なり、オレンジのシェイプは1スクエアの高さに浮き上がるため、シェイプを1つとして扱うことができませんでした... 問題＃6の別のバリエーション。 ますます複雑なシナリオで織り交ぜる多くの図形がある他のシナリオも考えられますが、上記で問題の最も基本的な部分がカバーされていると思います。 私がまだ出会っていない/考えていないエレガントな解決策があるように感じます。洞察、アイデア、またはリソースに非常に感謝します。 解決 私が思いついた解決策は確かにエレガントです、以下の@ user35958の答えに基づいて、次の再帰関数（疑似コード）を作成しました function stop(square1, square2){ // Skip if we're already stopped if(square1.stopped){ return; } // Are we comparing squares? if(!square2){ // We are NOT comparing squares, simply stop. square1.stopped = true; } else { // Stop IF // square1 …

10 2d  collision-detection  grid 

Unity3D用の小さな六角グリッドフレームワークを作成していて、次のジレンマに直面しています。これは私の座標系です（ここから取得）： 保存方法がわからないという事実を除けば、すべてうまくいきます。私は当初、これを2D配列に格納し、画像を使用してマップを生成することを意図していました。 1つの問題は、負の値があったことです（これは、座標を少しオフセットすることで簡単に修正されました）。 ただし、この座標系により、そのような画像やビットマップは菱形にする必要があります。これらの構造は四角形であるため、何かをハッキングしても、多くの頭痛の種を引き起こします。これを修正できる欠けているものはありますか？ユニティフォーラムでこれに関するフォーラムの投稿を見たのを覚えていますが、リンクが見つかりません。 座標変換器のセットを書くことがここでの最良の解決策ですか？ 皆さんがそれが役立つと思うなら、私の問題のコードと画像を投稿できます。

10 image  grid  hexagonal-grid  storage 

グリッド上のタイルのセットを前提として、以下を決定します。 タイルが囲まれた図を作る場合 ボードの側面を図の端として数えたときにタイルが囲まれた図を作る場合 前の2つのステートメントのいずれかがtrueの場合、追加のタイルが囲まれた図の内側に入ると、最初のタイルが形成されます。 プレーヤーは、1つのタイルを押し下げてから、指を他のタイルにドラッグして、同じ色のタイルのチェーンを作成します。次のタイルが有効であるかどうかを確認するために行くときに確認します。例 プレーヤーが赤いタイルから始めた場合、次に有効なのは隣接する赤いタイルへの移動のみです（対角線はカウントされます）。ユーザーが指を離したときに、上記の3つの項目を確認できるようにする必要があります。 ですから、私の最初の考えは、行くたびにチェーンの有効性をチェックしているので、プレーヤーが指を離したときに、最初と最後のタイルが隣接しているかどうかを確認できるということでした。（同じ色だとわかっています。）隣接している場合は、囲まれた図を作成するという予感がありました。ここに来て、大きなものが足りないかどうかを確認しました。私の直感が正しかったことのある種の論理的/数学的な証明（またはそれが正しくないことを証明する例） しかし、そのときは、アイテム番号2について考えました。ボードの端を囲まれた図の側面として使用するチェーンも考慮する必要があります。その場合、チェーンの最初と最後のアイテムは隣接しませんが、囲まれた図がまだあります。さて、私は少し正方形に戻りました。 このグリッド座標のチェーンを使用して、囲まれた図を作成するかどうかを判断するにはどうすればよいですか？私は一度、ん、私は囲まれた数字を持って知って、その境界内に入る全てのタイルの追加のリストを取得するための最良の方法は何ですか？ 上記では、このテストの4つの可能な結果が期待できるものの絵を描きました。 チェーンは同封の図を作りません。 チェーンは囲まれた図を作ります。 ボードの側面を図のエッジ（または複数のエッジ）として数えると、チェーンは囲まれた図になります。 チェーンは囲まれた図を作成しますが、作成された図の一部ではない余分なデータポイント（チェーンの一部としてユーザーが有効に選択したもの）があります。 ケース4は、「余分な」チェーンリンクを抽出して、囲まれた図形とその中にある部分を見つける必要があるためです（ただし、「閉じられていない」領域の周りではありません）。 だから...誰もがこれを解決する良い方法のアイデアを持っていますか、それとも私のための出発点ですか？この時点で私は一種の円を描いており、別の目を使用できます。

10 algorithm  grid  graph 

興味深い問題にぶつかった。見通し線をシミュレートする方法を理解する必要があります-障害物がある2Dグリッド上で十分に単純です。グリッドセルが表示されているか、表示されていません。 プレイヤーからn個のスペースを広げたり、隣接する障害物が検出されたときに水平方向の伝播をブロックしたりするなど、本当に初歩的なものを得ることができますが、それを我慢することはできません。他の多くのアプリは、隅などの視線を傾斜させるより洗練された方法を使用しており、私は標準に近づきたいと思っています。 これまでのところ、困惑したときのDCSSは私のインスピレーションの源でした。私は彼らが持っているものに近いものを手に入れたいと思っています：http : //crawl.sz.org/。 どんな洞察もいただければ幸いです-助けてくれてありがとう！ （これが恥ずかしいほどにうるさい場合は許してください-数週間前にゲーム開発を始めただけで、追いつくように頑張っています。）

10 2d  grid  line-of-sight