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

アルゴリズムは、計算、データ処理、および自動推論に使用されます。より正確には、アルゴリズムは、関数を計算するための明確に定義された命令の有限リストとして表現される効果的な方法です。

9
タワーディフェンスゲームのダイナミックパスアルゴリズム
私はタワーディフェンスを作っていますが、それには良いパスアルゴリズムが必要です。 私はダイクストラについて考えましたが、ダイナミックなものが必要です。1つのエッジが完全に再計算されずに削除または追加されたときに、それ自体を更新できる必要があります。 役立つ場合は、C#でコーディングしています。

2
3人以上のプレーヤーでEloを使用したプレーヤーのランキング
Eloを使用して、特定のゲームの試合間のプレイヤーランキングを追跡したいと思いますが、ゲームは1つの試合で最大4人のプレイヤーでプレイできます。CarcassonneのようなゲームでEloを使用し、2人以上のプレイヤーがプレイしているのを見てきましたが、1対1のマッチアップ以外ではEloに慣れていません。 ウィキペディアの記事から、拡張したい2人のプレーヤーの方程式は次のとおりです。 E a = 1 /(1 + 10 (R b -R a)/ 400) E b = 1 /(1 + 10 (R a -R b)/ 400) R x new = R x old + 32 *(W – E x)、Xが勝った場合はW = 1、Xが負けた場合はW = 0。 3人以上のプレイヤーがいる場合、E xとWの計算はどのように変わりますか?

1
流れるGPU計算水
私は土木工学のバックグラウンドを持ち、水理および水文解析を定期的に実行しています。彼らはそのようなことのために学位を売りますが、それは実際にロケット科学ではありません。私は最近、GPUの地形に水文および油圧プロセス全体を実装することを思いつきました。コンピューティングシェーダーを習ったのはごく最近のことなので、現在、並列GPUワークフローを設計するよりも、エンジニアリングの方が優れていることにこだわっています。 次の式を使用して、降雨イベント中に生成された水の量を計算できます。 Q (CF/S) = c * I (in/hr) * A (acres) 私は、最初の領域の「面積」の計算を超えて移動するのが困難です。 現在の実装の概要: 地形は、1ユニット間隔の頂点の規則的なグリッドです ハイトマップには、頂点ごとに1つのR32高さ値が含まれます 現在、私は4つの基本方向(対角線なし)のフローのみを許可しています Texture2D [int]を、既に分析した頂点のステンシルとして使用しています 現在のアルゴリズム: 地形ツールがアクティブで、現在はそうではないとき... 「ステンシル」をクリアします。 標高が最も低い地形全体をスキャンします。 その単一ポイントは、CS_Floodへの初期入力です。 CS_FloodはX軸パスを作成します。 各入力頂点は、X方向とX +方向の両方に最大2048回投影されます。 OOB座標で隣接する頂点を見つけると、この方向の地形のエッジが示されます。CurrentPointがBoundaryPointsバッファーに追加され、その方向の投影ループが終了します。これは簡単で、毎回うまく機能しました。 高さ> =現在の頂点の高さを持つ隣接する頂点は、ステンシルでマークされ、NextPassバッファーに追加されます。 高さ<現在の頂点の高さを持つ隣接する頂点は、リッジのピークを示し、投影ループを終了します。塗りつぶしの将来の反復があります、それの「裏」側まで、尾根のベースの周りに流れ、同じ尾根をもう一度検出します。 この目的のために、複数回検出されたピーク/リッジポイントはBoundaryPointにはなりません。 一度だけ検出されたピーク/リッジポイントはBoundaryPointsに追加され、その方向の投影ループは終了します。 CS_Floodは、X軸パスによって生成されたポイントを入力として使用して、同じコードでZ軸パスを作成します。 現在、CS_Floodは2つの方向を無期限に交互に継続します。最終的に、CS_Floodが完了し、NextPassバッファーが空になるたびに、ループ全体を終了します。 理想的には、その時点で、BoundaryPointsには、自然の排水分割で発生する各頂点が含まれます。境界内に着弾した水滴は、最終的に同じ低地点に流れます。水滴が着地すると、境界は「どこか他の場所」に移動します。 次に: ステンシルをクリアせずに、地形を再スキャンして、ステンシルのない最も低い頂点を探します。 CS_Floodを繰り返します。 ステンシルがいっぱいになるまで(または同様の)を繰り返します。 3Dはこれらの色を認識するのが困難です。これは、積分高度で等高線を示します :(エッジ近くのバームに囲まれた穴) 頂点を越えて排出する約10のユニークな方法があります。それぞれにユニークな色を与えます:( 目に見える円形のツールマーク、「リッジ」がきれいに表示されます) これは、CS_Flood、境界、またはそれ以外で生成されたすべてのポイントをPOINTLISTとして表示します。 アルゴリズムは常に ほとんど機能します。時には、それも正しく動作します。その他の場合、アルゴリズムは正しい形状に明確に含まれていますが、無期限にポイントを出力し続けます。3番目のスクリーンショットに見られるように、時々混乱します。私が見落としていた別の状況/要因がなければなりません。私の見落としや、問題を攻撃するためのより簡単な方法および/またはよりエレガントな方法の提案を見つけるのに役立つことを感謝します。 MissingPoint!検出されたすべての新しいBoundaryPointをNextPassバッファーに追加するアルゴリズムを帯域支援することで含めることができます。次のパスでは、そのバンドエイドによって生成されたポイントの99%がわずかなGPU時間を浪費し、どこにも行けず何もしないと判断します。最初のパスでは、LowestPointを他のNextPassポイントと一緒に送信することも、この特定のシナリオを処理します。 私はそれがもっともらしいことを知っています、そして、十分な時間を与えられれば、私が望むことをするのに十分それをバンドエイドすることができます。できれば、より良く、よりスマートに、より速くそれをしたいのですが、まだ十分な経験がありません。

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

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

3
カスタム形状の宇宙船を動かすAI(動きの動作に影響を与える形状)
ネットワークターンベースの3D-6DOF宇宙艦隊戦闘戦略ゲームを設計しています。これは、船のカスタマイズに大きく依存しています。質問を設定するにはゲームについて少し知る必要があるので、ゲームについて少し説明しましょう。 私が目指しているのは、カスタムシェイプと付属モジュール(プロペラ、トラクタービームなど)を備えた独自の艦隊を作成する能力です。これにより、各艦に長所と短所が与えられるため、艦隊の分布が多数あります。たとえば、側面に2つのプロペラを備えた長い船は、その飛行機の周りを簡単に回転し、後方に多くのプロペラを置かない限り、大きな船はゆっくりと動きます(したがって、移動するときに「建設」ポイントとエネルギーを多く消費し、その方向に向かって速く移動するだけです。)この機能を中心にすべてのゲームのバランスをとる予定です。 ゲームは、注文と戦闘の2つのフェーズを中心に展開します。注文フェーズでは、さまざまな船を指揮します。すべてのプレイヤーが注文フェーズを完了すると、戦闘フェーズが開始され、船の注文がリアルタイムでしばらくの間解決され、その後アクションが一時停止し、新しい注文フェーズがあります。 問題は、プレイヤーの入力について考えるときに発生します。船を動かすには、操縦、前進、ブレーキ、定位置で回転したい場合、異なるプロペラをオンまたはオフにする必要があります...これらのプロペラは全力で動作する必要がないため、より多くの動きを実現できますより少ないプロペラとの組み合わせ。 このアプローチは少し退屈だと思います。プレイヤーはモーターなどをいじりたくありません。ただ移動して殺したいだけです。私がプレイヤーにこれらの船に命令を与える方法は、目的地と回転によるもので、AIは正しいプロペラ力を計算してその運動と回転を実現します。ターン計算全体を通して推進力が同じである必要はないため(注文が与えられた後)、船が移動するときに反応し、必要に応じてプロペラの出力を動的に調整する場合はクールになりますが、実装するのが難しすぎて、ゲームが機能するために実際には必要ありません。 どちらの場合でも、AIはどのプロペラをアクティブにして最適な(または少なくとも最悪ではない)軌道を達成するかをどのように決定しますか? 私はいくつかのアプローチについて: AIの学習:船の種類は試行錯誤によって動きを学習し、より多くの用途で動作を調整し、最終的に「スマート」になります。AIコーディングにこれほど関与したくはありませんし、プレーヤーにとってはイライラすることになると思います(プレイしなくても学習させることができたとしても)。 事前に計算されたタイムステップの動き:船の作成時に、特定のデルタ時間の各プロペラ構成と出力について、考えられるすべての動きが計算されます。メモリ集約型、,い、悪い。 事前計算された軌跡:上記と同じですが、各デルタ時間ではなく、軌跡全体が可能な限り適合します。戦闘フェーズ全体でプロペラの構成を固定する必要がありますが、それでもメモリを大量に消費し、ugくて悪いです。 継続的なブルートフォース: AIは、戦闘フェーズ全体で可能なすべてのプロペラ構成を継続的にチェックし、いくつかのタイムステップを事前計算し、それに基づいて最適なプロペラを決定します。短所:今は良いことは後でそれほど良くないかもしれませんし、CPUに過度に負荷がかかり、見苦しく、悪いです。 単一のブルートフォーシング:上記と同じですが、シミュレーションの開始時にブルートフォーシングのみが行われるため、戦闘フェーズ全体で一定のプロペラ構成が必要です。 連続角度チェック:これは完全な移動方法ではありませんが、「愚かな」プロペラ構成を破棄する方法かもしれません。現在のプロペラの法線ベクトルと最後のベクトルを考えると、角度に基づいてプロペラに必要なパワーを概算できます。これは、戦闘フェーズ全体を通して継続的に行わなければなりません。私は最近、これを考え出したので、あまり考えませんでした。先験的に、それは「今は良いことは後で良くないかもしれない」という欠点もあり、より良い推進構成を作るために一緒に行動する他のプロペラを気にしません。 私は本当にここで立ち往生しています。何か案は?

3
高粘度液体としての固体
私の友人と私は、世界の材料を非常に断片的な方法で破壊できるようにするための異なるアイデアを議論しており、彼は固体を非常に可視的な流体として表現するというアイデアを提案しました。私の直感では、これは次のいずれかになるということです。A)非常に難しい、またはB)非常にリソースを集中的に使用しますが、私にはわかりません。 このようなモデルは、RPG /アドベンチャーRPG / FPSに適していますか? edit:明確化:アイデアは、衝突とオブジェクトの破壊をこのシステムで処理することです。基本的に、このように処理されたオブジェクトは、スクリプト化された破壊可能なオブジェクトではなく、破壊可能になります。



4
隣接する三角形を作成するためのアルゴリズム
一度クリックしてシーンにノードを配置できるシステムがあります。3つのノードを配置すると、三角形が形成されます。将来のノードを配置すると、そのノードを2つの最も近い既存のノードに結合することにより、新しい三角形が作成されます。 これはほとんどの場合正常に機能しますが、2つの最も近いノードの1つは多くの場合使用すべきものではないため、非常に鋭角な三角形の近くで使用すると欠陥があります。 たとえば、次の画像を参照してください。マゼンタの三角形が最初に配置されます。次に、Xとマークされた位置をクリックすると、青いオーバーレイがある新しい三角形が表示されます。私が欲しいのは、緑のオーバーレイがある新しい三角形です。(つまり、この例では、マゼンタの三角形と対称です。明確化:緑とマゼンタの三角形は重なりません-緑の三角形は青の三角形の下で左端のノードまで延びています) 三角形がこのように重ならないように、新しい三角形を作成するときに使用する既存の2つの頂点を決定するにはどうすればよいですか? 編集:最も近いエッジを検索すると、より良い結果が得られますが、完璧な結果は得られません。この状況を考慮してください: 「最近傍」テストはあいまいで、ABまたはACを返すことができます(両方のXに最も近い点がAにあるため)。望ましい結果はACになり、エッジが重ならないACX三角形を形成します。この結果をどのように確認できますか?(可能な場合、浮動小数点の精度の問題を考えると、最も近いエッジテストでは必ずしも2つが正確に等距離にあるとは限らないので、タイブレーカーとして個々のエッジオーバーラップテストを実行する必要はありません。)

1
ボロノイ粉砕の長所と短所は何ですか?
Youtubeでボロノイ粉砕ビデオを見ました。 それについてのあなたの経験は何ですか? 時間の複雑さ、リソースの複雑さ、実装の難しさの長所と短所は何ですか? 実際の素材がどのように反応するかをエミュレートしますか?
14 algorithm 

2
Painterのアルゴリズムで正確な結果を得る方法
少し前に、顔が別の顔と重なっていることを判断する方法を尋ねました。アドバイスは、Zバッファを使用することでした。 ただし、現在のプロジェクトではZバッファを使用できないため、Painterのアルゴリズムを使用したいと考えています。しかし、表面がいつ他の表面の後ろまたは前にあるかについての良い手がかりはありません。私は数多くの方法を試しましたが、それらはすべてエッジケースで失敗するか、一般的なケースでも失敗します。 これは私が今まで試したソート方法のリストです: 各面の中点までの距離 各面の各頂点までの平均距離 各頂点の平均z値 各面の頂点のz値を最大化し、それらを最初に描画します 各面の頂点の最小z値とそれらを最後に描画 問題は、顔の距離は近いかもしれませんが、それでも遠いということです。これらの方法はすべて信頼できないようです。 編集:たとえば、次の画像では、青い点がより近いため、青い点を中点とするサーフェスが赤い点を中点とするサーフェス上にペイントされます。ただし、これは、赤い点の表面が大きく、中間点がさらに離れているためです。赤い点のある面は青い点よりも上にペイントする必要があります。なぜなら、中間点の距離は反対であるため、より近いためです。 オブジェクトを描画する順序を決定するために、Painterのアルゴリズムで正確に使用されているものは何ですか?
14 3d  algorithm  objects  face 

5
動作中にさまざまな機器を大量に使用できるように2Dキャラクターを作成するための最良のアプローチはどれですか?
2Dゲームを作成したいのですが、RPGなどのさまざまな組み合わせで、さまざまな装備を大量に身に付けるキャラクターを作りたいです。 したがって、ユーザーが肩とズボンを変更するとします。これはプレーヤーに表示され、これらのさまざまな装備はすべて、異なるキャラクターのアクション(ヒット、ヒット、魔法のスペルなど)に従う必要があります。 解決するのに最適なアプローチ/アルゴリズム/アーキテクチャを知りたい問題がいくつかあります。 1-スプライトまたはアニメーション 各アクションアニメーションの各機器に異なるスプライトを作成する必要がありますか? 機器のスプライトを持ち、回転や平行移動などのコードで直接アニメーション化する方が良いでしょうか(Flashのトゥイーンのようなものを使用)。 他のより良いオプションはありますか?(私は上記のアイデアが本当に好きではありません) 2-ポジション キャラクターの動きの1つで、プレイヤーの視界の真正面を見るようになりましたが、プレイヤーの右側を示す動きを終了したとします(剣を片方からもう片方に振った場合など)。 たとえば、ユーザーの頭のように、ユーザーの一部を考えると、それは前から始まり、左に曲がります。 各ヘッド装備(ヘルメット、キャップなど)ごとに少なくとも3つの異なる位置を意味します。 これは間違いなく#1の質問の答えに影響します。それを達成する最良の方法はどのようなものですか? 3-レイヤー 腕を開いた状態で360度回転するキャラクターの動きを考えてみましょう。アニメーションの開始時には、彼の右手はユーザーの視界に近く、動きの途中では、おそらくアニメーションのキャラクターの体の後ろにあります。 #1の質問のオプションが何であれ、このスプライトまたはアニメーションをプレーヤーのビューに近づけて、後でプレーヤーのビューから遠くに変更するには、何らかのレイヤーモデルを使用する必要があります。 それを行う良い方法はありますか? 質問は非常に長く、理解するのが難しいことを知っています。図面を用意して、どれを説明しようとする方が良いと思うか教えてください。

1
2Dタイルマップで「ビジョンコーン」を計算する効率的な方法は?
特定のユニットがタイルマップ上の特定の方向を向いている場合(特定の範囲と向きの角度内)に、どのタイルが「見える」かを計算しようとしています。最も簡単な方法は、一定数のタイルを外側に描画し、各タイルにレイキャストすることです。ただし、もう少し効率的なものを望んでいます。写真は千の言葉を言う: 赤い点はユニット(上向き)です。私の目標は、黄色のタイルを計算することです。緑のブロックは壁です(壁はタイルの間にあり、2つのタイルの間を通過できるかどうかを簡単に確認できます)。青い線は、私が話していた「レイキャスティング」方法のようなものを表していますが、これを行う必要はありません。 編集:ユニットは北/南/東/西(0、90、180、または270度)にのみ向くことができ、FoVは常に90度です。一部の計算を簡素化する必要があります。ある種の再帰的/スタックベース/キューベースのアルゴリズムがあると考えていますが、それを理解することはできません。 ありがとう!
13 2d  algorithm  tilemap 

2
2つのツリー構造の比較
私はこれを正しい用語で説明しようとするのに苦労しているので、できるだけ多くの詳細を提供し、誰かが私がやろうとしていることを知っていることを願っています=-) 2つのノードツリーを比較して、それらが構造的に類似/異なるかどうかを判断しようとしています。以下の図では、両方の例に同じ数の子、孫などがあります。例1では、Rootには2つの子を持つ子がありますが、例2では、​​rootにはありません。 再帰的にループする方法を見つけて、各レベルの数を数え、それを比較して、ツリーがどれほど似ているかを知ることができますが、それだけで同じように見えますが、実際にはそうではありません。 誰でもこれについて知っていますか?それとも、これが何であるかを表す専門用語ですか? 編集:また、これはC#であり、これらのオブジェクトとその子を保存するためにリストを使用しています。 例1 例2

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.