タグ付けされた質問 「procedural-generation」

最初は宇宙全体が空白の平らな宇宙を作りたいです。 これは、視差スクロール星雲の背景画像によって表されます。 私がやりたいのは、惑星を宇宙の円盤状のオブジェクトとして表現することです。サイズはさまざまです。 ディスクの内側は陸地で構成され、外側は水の塊であり、その後は空気です。 たとえば、空気はさまざまなガスやさまざまな鉱物や資源の土地で構成されているため、これらのタイルを手続き的に作成する最善の方法は何でしょうか。 私の最初の考えは、テクスチャ画像を作成し、それらのテクスチャから円を打ち抜くことですが、問題はそれらのテクスチャが水平および垂直にラップする必要があることです。これを行うための完全な手続き型の方法はありますか？

16 procedural-generation  terrain 

やあみんな、私はコードでタイル化可能なフラクタルを生成する方法を見つけようとしています（ゲームマップ用ですが、それは無関係です）私はGIMPに同梱されているSolid Noiseプラグインを変更しようとしています（方法は非常に限られていますがコードは動作します）が、正しく動作させることはできません。 これまでに修正したコード（Java） （C）からコードを作成しているGIMPのソリッドノイズモジュール これは私が達成しようとしているものですが、 これは私が得ているものです だから誰かが私が間違ったことを見ることができるか、または私がそれを別のやり方で行う方法を提案しているなら、私はそれを大いに感謝します。前もって感謝します。 そして、もし私が多くのことを求めているのなら、あるいは単に人生で大きな失敗をしているのなら、私は謝罪します。

16 java  procedural-generation  maps 

無限の2Dレベルを手続き的に生成するための良いアプローチは何ですか？レベルはどちらかの次元で制約される可能性がありますが、必ずしもそうではありません。 これまでのところ、私にとって最も意味のあるアプローチは、グリッドベースの半径を使用することです。たとえば、プレイエリアを特定のサイズの正方形のグリッドに分割し、プレーヤーの周囲の半径にX個の正方形をロードします。その後、プレーヤーが別の正方形に移動すると、次のセットが構築され、さらに遠くにドロップされます（探索された領域を永続化する必要はありません）。オブジェクトが正方形の外側のリングを離れると、それらは世界から削除されます。より良い方法または別の方法がありますか？または、これが適切なアプローチである場合、潜在的な問題は何ですか？ 議論のために、レベルはトップダウンの小惑星フィールドであり、パワーアップなどが散在していると考えることができます。

16 2d  procedural-generation 

私は現在、Terrariaに似たタイルベースの2Dプラットフォーマーにいくつかの点で取り組んでいますが、地形の生成に苦労しています。基本的なことはいくつか済ませていますが、有用なものとしては出ていません。 Perlin Noiseのようないくつかの異なる手法を試してみて、Midpoint Displacementなどの他のいくつかについて読んでみましたが、どれが最適か、または異なる領域を生成するための異なる手法の組み合わせについてはわかりません。（地形の一般的な形状の場合は中点変位、洞窟の場合はパーリンノイズなど） Accidental Noise LibraryでC ++になっているにもかかわらず、どのようにレイヤー化できるかについての優れた説明を見つけました。また、C＃から使用できるDLLにコンパイルするのに十分なC ++がわかりません。私はこれをC＃でコピーしようとしましたが、2つの効果（一般的なベースの勾配、次に詳細なフラクタル）を一緒にマージする方法はわかりません。 現在、私はプラズマフラクタルを使用しており、結果は非常に多様です。たとえば、表面がほとんどない地形を生成したり、表面がまったくない地形を生成したりできます。 ただし、大丈夫なマップの例では、さらに改善することで改善されます。（黒は固体、白は空気）： ひどい地図の例。（黒は固体、白は空気）： 基本的に、私が求めているのは、地形を生成するためのより良い方法であるか、生成時間を可能な限り速くして、合理的な量の表面積があることを確認することです。または、偶然のノイズライブラリと同じ結果をC＃で実現する方法もあります。 どんな例でも大歓迎です。

15 xna  2d  procedural-generation  terrain 

私とチームは、ゲームの開始時にプレイヤーにランダムなファクトリーを提供するファクトリービルダーゲームに取り組んでいます。「公平性」の感覚を確保するために、ランダムに生成されたファクトリーは、（プレースホルダー値）30の数単位以内の領域を持つことが理想です。 これらの仕様を満たすために基本的なランダム長方形ジェネレーターを書くのは比較的簡単ですが、私たちの目標は、おそらく2、3、または4つの交差する長方形で構成される工場をより複雑にし、より複雑な形状を生成することです（L U、およびO形の建物）。 ランダムな長方形を生成し、基本的な代数を使用して2番目の長方形を埋めようとしましたが、これまでのところ2つ以上の長方形を実装することはできませんでしたが、それでも2つの長方形のデザインの結果に満足できませんでした。 より関連性の高い情報：2Dトップダウンメカニックの一部はファクトリースタイルであるため、部屋には適切な長さと幅を持たせて、現在JavaとLuaで使用できるようにします（必要に応じて、いずれかの組み込みライブラリを使用できます） 前もって感謝します！ 編集：「良い」または「悪い」出力を言うと、悪い出力は、プレーヤーが使用できないスペースがある出力になります。工場の形状は、プレーヤーがコンベアベルトなどの工場の機械を配置できる場所を制限します。理想的には、工場には幅が1〜2ブロックしかない領域はなく、形状は1〜2ブロックの線が1辺に「垂れ下がる」1つまたは2つの大きな長方形であってはなりません。適切な出力は、すべての床面積が「実行可能」であるため、すべての領域が少なくとも3〜4ブロック幅です。優れた出力は必ずしも複雑である必要はありません（1つまたは2つの長方形でも構いません）が、1-2を超える長方形で構成される場合は、かなりのチャンスがあるはずです。

15 java  2d  procedural-generation  geometry  lua 

動的に生成されるゲームのことを考えるとき、ランダムに生成されるレベルを持つディアブロのようなものを考えます。手続き的に生成されたゲームを考えるとき、私はゆるい鳥や他の無限のランナーのようなものを考えます。 しかし、これらは両方ともレベルをランダム化するだけです。手続き的に生成されたゲームは常に生成されており、動的に生成されたゲームはすべて前もって生成されているのでしょうか？または、これらの用語は交換可能ですか？ 動的に生成されるゲームと手続き的に生成されるゲームの違いは何ですか？

15 procedural-generation  random  terminology 

ゲームの開始時に作成された手続き的に生成された世界でゲームを作成しています。グリッドで表されるいくつかの領域で構成されています（8x8、9x6、サイズは理想的には任意です）。これらの領域は、依存関係リストを介して互いに接続されることになっています。 そのグリッドの少なくとも3つのスペースがこれらの2つの領域の間に露出している場合、接続が存在します。その3つのスペース接続エリアの中央のセルには、エリア間の出入り口があります。 私はそれらを接続する方法を見つけようとしてきましたが、同時に考慮する必要のある領域が増えるにつれて、ますます複雑になります。 ペーパープロトタイピングをいくつか試しましたが、視覚的に行うのは非常に簡単なプロセスですが、コードによって同じ効率で部屋を配置できる優れた数式のセットは見つかりませんでした。 これが私が今苦労している「単純な」例です： エリア「a」は「b」および「c」に接続する必要があります エリア「b」は「a」と「d」に接続する必要があります エリア「c」は「a」と「d」に接続する必要があります エリア「d」は「b」および「c」に接続する必要があります 簡単にするために、リストに表示される順番で部屋を配置していることを考えてみましょう（他の人も試しました）。そこで、標準の手続き型ダンジョン生成アルゴリズムとしてこれにアプローチしています。 最初の領域なので、ボード上の任意の場所に「a」を配置します。次に、壁をランダムに選択します。その壁には何も接続されていないため、そこに「b」を配置できます。 ここで「c」を配置する必要がありますが、「a」はすでにボード上にあり、壁が占有されているため、別の壁に配置することにします。しかし、「d」が表示され、「b」と「c」にも接続する必要があるため、すべてのプレースメントが実行されるわけではありません。 同じ依存関係を持つ2つの部屋を反対側の壁に置くことはできないという制限を試みましたが、それでも成功を保証するものではありません。 また、エリアのサイズが異なる他のケースでは、反対側の壁にいるとうまくいきます。 また、有効なソリューションを除外するため、使用済みの壁を考慮しないことは欠陥のある仮定です。 Optimal Rectangle PackingやGraph Layoutアルゴリズムなど、他の手続き生成アルゴリズムなどの研究を調べてみましたが、通常、これらのアルゴリズムはこの問題のすべての制約を考慮しておらず、一緒に混ぜることは困難です。 適切な配置が見つかるまで領域とバックトラックを配置するなど、たくさんのアプローチを考えましたが、それらは試行錯誤に非常に依存しており、計算の面でコストがかかるようです。しかし、私が言及した最後の2つの問題に関する広範な研究を考えると、それが唯一/最良の解決策かもしれませんか？ 私はちょうど誰かが過去に同様の問題を抱えていたか、またはこれを理解し、アルゴリズムをどこから始めるべきかについていくつかの指針を与えてくれるかどうかを見たかっただけです。または、失敗した場合は、設定した制約を緩めることを検討する必要があります。

15 procedural-generation 

単純な16進グリッドベースのゲームを作成していますが、マップをプレーヤー間で均等に分割する必要があります。マップはランダムに作成され、プレイヤーに比較的小さなエリアでほぼ同じ量のセルを持たせたいです。たとえば、マップに4人のプレーヤーと80個のセルがある場合、各プレーヤーには約20個のセルがあります（スポットオンである必要はありません）。また、各プレイヤーは、隣接するセルを4つ以下にする必要があります。つまり、マップが生成されるとき、最大の「チャンク」はそれぞれ4セルを超えることはできません。 これは2人または3人のプレイヤーにとって常に可能ではないことを知っています（これは「マップの色付け」問題に似ているため）。しかし、4〜8人のプレイヤーの場合、この問題にどのように対処できますか？

15 algorithm  procedural-generation  maps  random  hexagonal-grid 

私は、手続き的に生成された世界を持つゲームに取り組んでいます。理想的には、Minecraftの世界と同じくらい美しい風景を生成したいと思います。Minecraftには、割れ目、滝、山、なだらかな丘、海などがあります。しかし、これはトップダウン（実際には3/4の視点）ゲームになるため、そのほとんどは可能だとは思いません。主な理由は、この視点で高さを表現しようとするのがどれほど難しいかです。ゼルダ：過去へのリンクは高さの錯覚をうまく作り出しましたが、これは手続き的に再現するのが非常に難しく、また、最も高い構造が地図の最上部になければならないという事実などのいくつかの問題をもたらします。 ですから、3次元を偽造することなく、トップダウン形式でランドスケープを面白くするためのテクニックをいくつか知りたいと思います。（このゲームでは地形を作成したり破壊したりすることはできません。そのため、もう少し柔軟性が得られます。） 編集：物事をもう少し明確にするために、3次元を必要とする機能を持つ世界を避けようとしています。たとえば、なだらかな丘や山はありません。3次元を偽造する必要がないランドスケープ機能を追加できますか？1つの答えは川を追加することかもしれませんが、それは明らかなものです。

15 2d  procedural-generation 

スターフィールドを手続き的に生成するコードを知っている人はいますか？ 理想的には、物理​​学に基づいて、現実的な惑星と月を手に入れることができます。最良の方法は、C ++、オープンソース、およびOgre3dで動作することです。 利用できるものがなければ、大学の論文から何かをコーディングすることを恐れません。

15 c++  ogre  procedural-generation 

そのため、Googleを介して、またはここで銀河全体を手続き的に生成する方法に関する検索を使用して見つけることができるリソースがたくさんあります。しかし、これらの基準に従う惑星システムを生成する方法に関する良いリソースを見つけることができませんでした： システムは軌道の正確なシミュレーションである必要はありませんが、もっともらしい軌道に近いはずです。私は、システムが20万年後にどのように見えるかを気にするシミュレーションを気にしません。軌道は堅実かもしれません。私が直面している主な問題は、もっともらしいと思われるシステムをランダムに生成する方法です。これは、バイナリスターを備えたシステムがある場合に特に興味深いものになります。 軌道をランダムに作成するだけでは、妥当なシステムを構成することはできず、明らかに機能しない軌道になってしまいます。はい、私はN体の問題を知っています:)しかし、これは、少なくとも私は、もっともらしいシステム手続きを生成する問題を解決するのに私を助けませんか？ 軌道上でランダムに惑星を生成し、それらに質量を与えてから、N体数学を使用して、それらが多かれ少なかれ有効かどうかを計算し、最初からやり直さなければ、一致するものを得るまでランダムに新しい軌道を生成できると思います、しかしこれは非常に非効率的です。

14 procedural-generation 

私は、部分的に惑星探査で構成されるゲームを設計しています。疑似ランダム生成を使用して、すべての詳細を保存するのではなく、ロードする必要があるときに定義済みのシードから再生成します。これは重すぎます。そのため、プレイヤーが行ったランダムシードと変更をファイルに保存します。 プレイヤーは、軌道から惑星を見ることができる必要があります（非常に低いレベルの詳細で、その後地面に降り、着陸している地域の詳細レベルをゆっくりと上げ、反対側にあるものを降ろします）プレイヤーの視界の外に出る惑星の 平面の地面でそれをしなければならなかった場合、正方形のチャンクシステムで簡単にできます。しかし、ここでの問題は、惑星が-ほとんど-球体であるということです。 それでは、正確なポイントの周りに地面の詳細（レリーフおよび接地されたオブジェクト）をロードする最良の方法は何でしょうか？ 私はすでに2つの解決策に取り組んでいますが、どちらにも弱点があります： 1.球体を正方形の塊に切断します。 プレーヤーが地面に十分に近づいたら、彼/彼女の位置から最も近い正方形の詳細を改善する必要があります。 十分でない場合でも、プレイヤーが地面にいるときや地面に本当に近づいているときに読み込むために、各正方形をサブ正方形にカットできます。 しかし、写真でわかるように、プレイヤーがポールに着地しようとすると問題があります：正方形は非常に細い長方形になり、最後の行では三角形になり、さらに多くの読み込みが必要になるという事実に加えて、世代が歪んで表示されます。 2.二十面体から始めます。 ここでは、プレイヤーが近づいているときに、プレイヤーの位置の周りの三角形のテッセレーションを増やすことができます。 しかし、私はプレイヤーの位置よりも近くに三角形を見つける方法を知りません。その場合、デカルト座標が役立つ可能性があると聞きましたが、使用方法はわかりません。 私はそのためにC ++ / OpenGLを使用しているので、ここで生成およびロードする主なものは、表面のレリーフと色/テクスチャを表す頂点です。

14 opengl  c++  procedural-generation  optimization  sphere 

最近、手続き的に生成された太陽系で行われるゲームに取り組み始めました。少し習熟した後（Scala、OpenGL 2 ES、Libgdxのいずれとも動作していなかった）、基本的な技術デモを行って、プロシージャルにテクスチャリングされた単一の惑星を回ります。 私が直面している問題は、テクスチャ生成のパフォーマンスです。私がやっていることの簡単な概要：惑星は球体に変形された立方体です。各側にanxn（たとえば256 x 256）テクスチャが適用され、フラグメントシェーダーに送信される1つの8n xnテクスチャにバンドルされます。最後の2つのスペースは使用されず、幅が2の累乗であることを確認するためにのみ存在します。テクスチャは現在、ペーパー「Simplex」にリンクされた2012年版のシンプレックスノイズアルゴリズムの更新を使用してCPU上で生成されていますノイズを分かりやすくする。アルゴリズムのテストに使用しているシーンには、惑星と背景の2つの球体が含まれています。どちらも6オクターブの3Dシンプレックスノイズで構成されるグレースケールテクスチャを使用するため、たとえばテクスチャサイズとして128x128を選択した場合、ノイズ関数の呼び出しは128 x 128 x 6 x 2 x 6 =約120万回になります。 地球に最も近いのは、スクリーンショットに表示されているものです。ゲームの目標解像度は1280x720であるため、512x512のテクスチャを使用することを好みます。もちろん、実際のテクスチャは基本的なノイズよりも複雑になります（日光に基づいたフラグメントシェーダとスペキュラマスクにブレンドされた昼と夜のテクスチャがあります。大陸のノイズ、地形の色の変化が必要です。 、雲、街の明かりなど）そして、我々は512 x 512 x 6 x 3 x 15 = 7000万のノイズが惑星だけを呼び出すようなものを見ている。最後のゲームでは、惑星間を移動するときにアクティビティが発生するため、移動中にバックグラウンドでテクスチャを計算できるため、5秒または10秒、場合によっては20秒の待機が許容されます。 テストシーンに戻ると、PCのパフォーマンスはそれほど悪くはありませんが、最終結果が約60倍悪化することを考えると、依然として遅すぎます。 128x128 : 0.1s 256x256 : 0.4s 512x512 : 1.7s これは、パフォーマンスに重要なすべてのコードをJavaに移動した後です。Scalaでそうするのはずっと悪かったからです。ただし、携帯電話（Samsung Galaxy S3）でこれを実行すると、より問題のある結果が生成されます。 128x128 : 2s 256x256 : 7s 512x512 : 29s …

14 textures  performance  procedural-generation  perlin-noise 

この問題は、問題を解明するために数時間を費やした後、主に全くの絶望から生じました。 上の図に目を向けると、中点変位アルゴリズムアルゴリズムが（ある程度）正常に機能していることがわかります。ある程度コヒーレントなノイズパターンを生成します。 ただし、画像上に黒い点線のグリッドが残っているため、その理由はわかりません。私はこれが数学の問題であることを予見できますが、私はそれを見ることができません。また、オンラインリソースでこれが問題の可能性として指摘されていませんでした。そのため、このバグを追跡するための助けをいただければ幸いです。 unsigned char** mdp(unsigned char** base, unsigned base_n, unsigned char r) { size_t n = (2 * base_n) - 1; unsigned char** map = new unsigned char*[n]; for (unsigned i = 0; i < n; ++i) map[i] = new unsigned char[n]; // Resize // 1 0 1 // …

14 c++  procedural-generation  terrain 

Unityでゲームオブジェクトを移動するために必要な変換を計算する次のコードがありますLateUpdate。これはで呼び出されます。私が理解していることから、私の使用はTime.deltaTime最終的な翻訳フレームレートを独立させるべきCollisionDetection.Move()です（ただレイキャストを実行することに注意してください）。 public IMovementModel Move(IMovementModel model) { this.model = model; targetSpeed = (model.HorizontalInput + model.VerticalInput) * model.Speed; model.CurrentSpeed = accelerateSpeed(model.CurrentSpeed, targetSpeed, model.Accel); if (model.IsJumping) { model.AmountToMove = new Vector3(model.AmountToMove.x, model.AmountToMove.y); } else if (CollisionDetection.OnGround) { model.AmountToMove = new Vector3(model.AmountToMove.x, 0); } model.FlipAnim = flipAnimation(targetSpeed); // If we're ignoring gravity, then just …

13 unity  movement  frame-rate  timestep  collision-detection  unity  physics  opengl  libgdx  textures  graphics  c#  unity  vector  sfml  c  opengl  gui  multithreading  unity  mathematics  projection  mesh  unity  rigid-body-dynamics  rigidbody  c#  unity  2d  path-finding  procedural-generation  navmesh  unity  textures  maya  rigging  copyright  transformation  skeletal-animation  assimp  model-loader