Dwarf Fortressは、パフォーマンスを失うことなく、どのように多くのエンティティを追跡しますか？

ドワーフ要塞では、数百のドワーフ、動物、ゴブリンなどを一度にゲームに入れることができ、それぞれに独自の複雑なAIと経路探索ルーチンがあります。私の質問は、これがどのように顕著な減速を引き起こさないのですか？各Dwarfは独自のスレッドで実行されますか？

非常に多くのキャラクターのそれぞれにスレッドを持っているシステムは、リソースをすぐに使い果たしてしまいます。スレッドを使用すると、追加のプロセッサコアにアクセスできますが、本質的に効率が上がるわけではなく、オーバーヘッドが発生します。

簡単な答えは、ゲーム内の各エンティティの処理について効率的にすることです。

• フレームごとにすべてのエンティティを処理しないでください。
• 処理を頻繁に行う必要があるものと頻繁に行う必要のないものに分けます。
• 長時間実行アルゴリズムを複数のフレームに分散して、他のシステムでの処理をブロックしないようにします。
• 効率的なアルゴリズムとデータ構造が使用されていることを確認してください。
• 再び使用される可能性が高い場合、高価な計算の結果をキャッシュします。

Dwarf Fortressはオープンソースではありません。すべてがどのように機能するかを推測できる多くの推測とリバースエンジニアリングがありますが、代わりに、3D（3Dグラフィックス、3Dワールドではない）ローグライク同じタイプ。

すべてのビデオゲームの場合と同様に、単純なルールとシステムから複雑さの錯覚を作り出している煙と鏡がたくさんあります。これらは、目的のない移動のための単純な乱数の使用から、経路探索のためのノードの高レベルメッシュのプリベーキングまで、さまざまです。

移動

経路探索といえば、これは多くの場合、DFマップ（768 x 768 x 64 IIRC）のような大きなスペースに対して解決するのが非常に難しい問題になる可能性がありますが、次の方法で問題を簡素化および高速化できます：

• プリベイクドノードネットワーク：マップを作成すると、ワールドをチャンクに分割でき、各チャンクの出口と入口をマッピングできます。壁が構築されるときなど、チャンクが更新されるとき、そのチャンクのネットワークのみを更新する必要があります。
• 段階的パス検索：セルごとにマップ全体でパスを実行するには時間がかかりますが、代わりに、チャンク間のすべての接続をマップするより大きなチャンクネットワークでパス検索を行い、次の場合にのみチャンク内パスを実行しますチャンクからチャンクへの移動。これは2つのことを行います。多数の小さなピースに分割することでパスファインディングを高速化し、また、チャンクが更新されたときにユニットがパスに沿って途中で方向を変更できるようにします。クロス更新が必要なノードのいずれかがある場合、大規模ネットワーク全体に再パスします。
• ランダムステアリング：ゴールに移動していないとき、ユニットはあてもなく歩くだけで済みます。多くのローグライクはユニットをランダムな方向に動かすだけで、不自然に感じます。さまざまなステアリング技術を使用できますが、単純なものは直線で移動することを好み、後方に放射する方向に移動する機会がますます少なくなります。したがって、ユニットは完全に逆方向になることがありますが、まれにしかありません。

経路探索の基本については説明しません。ほとんどのローグライクはA *を使用しますが、猫の皮を剥ぐ方法は他にもあります。Mmmm Catレザー

個人的なタスク

DFユニットをポップにして生き生きとさせる主なものの1つは、個人的な目標リストです。実際、多くのローグライクゲームはこれを基本レベルで持っています。基本的に、各ユニットには欲求のリストがあり（そして、あなたのドルのために、あなたがやろうとしていることを彼らが拾うかもしれないタスク）、彼らは彼らの性格（統計）に基づいて彼らから選ぶでしょう

一部のタスクには要件があります。革のスカートを作るには、ドルフがX個のアイテムを持っているそのような店にいる必要があります。したがって、それらはすべてチェックされ、タスクとしてリストに追加されます。そのような単純な。

ほとんどの場合、ユニットは輸送中であるため、ユニットが実行していることのチェックは非常に高速であり、任意の瞬間に少数のユニットのみが選択を行うため、全体として何百または数千単位。そして、DFでは、ミツバチから隠者に至るまで、木々はすべてユニットであることを忘れないでください。

いくつかの追加の研究を行う中で、DFが陽気に、一般的に経路探索の恐ろしい仕事をしていることは明らかです。マップをチャンクに分割するのではなく、接続されているセグメントまたはエリアにマップを分割するので（確かに何もないよりはましです）、上記の評価はDFがどのように機能するかの例よりもさらに少ないと思っています。:)これは、DFが他の数百万の理由で驚くほどではないということではありません。

ゲームで重要なのはゲームプレイであることを示しています。グラフィックスでも、素晴らしいプログラミングでも、素晴らしい文章でも、素晴らしい音楽でも、インターフェースでもありません。ゲーム自体ほど重要なものは1％でもありません。

このページから：

さて、[パスファインディング]は、数トンのキャラクターがすべて一度にそれをやっているので、私の終わりからすばらしく見えます。

TA：ドワーフ自体はほとんどがA *で動き回っていますが、通常の古い通りの距離はヒューリスティックです。トリッキーな部分は、事前にそこに到達できることを知らない場合、実際にA *を呼び出せないことです。

これが間違いなく「マップのフラッディング」を防ぐ方法であるかどうかはわかりませんが、ゲームでこれを行う通常の方法は、A *の変更を使用してHierarchical Path-Finding A *またはHPA * と呼びます。この考え方は、グリッドをより少数ではあるがより大きなチャンクに分割し、A *を使用して各チャンクからその隣接チャンクへの最適なパスを見つけることです。これを使用して、ユニットごとにA *を実行する非常に小さなグラフを作成できます。

これらのチャンクをさらに大きなチャンクにグループ化することもできます。これが「階層」の由来です。

このアルゴリズムは最適に近いパスのみを検出しますが、Dwarf-Fortressのようなゲームでは通常は大丈夫です。パスが存在する場合、パスを見つけることが保証されています。パスが存在しない場合は、小さなグラフのみが塗りつぶされ、膨大な時間が節約されます。

HPA *の抽象化もあり、一部の地形を通過できるが他の地形は通過できないユニット（航空ユニットは通過できるが地上ユニットは通過できない崖など）を扱います。これはHAA *と呼ばれ、非常にアクセスしやすい記事でここに説明されています。

さまざまな経路探索アルゴリズムの詳細については、こちらをご覧ください。

どちらかといえば、それは反対です-すべてが1つのスレッドで実行され、それがブロック要因になっているポイントに到達しています（前回チェックしました！）

高速である理由は、派手なグラフィックがないことです。それは欺 '的ですが、物事を遅くする主なものは物を描くことです（AAAタイトルのフレームの3分の2以上を考えてください）。ドワーフ要塞は非常に基本的なものであるため、その時間の残りは興味深いことをすることに専念します。

私はDFを符号化する方法を知りませんが、AIの量は、実際に人々はしばしばあること、それを監督何ので、私は感動しないAIは精度を必要としません。ほとんどのことを数秒ごとに行うことは完全に実行可能です。不正確な計算を使用することも実行可能です。不完全さは多くのパフォーマンスを節約します。100ミリ秒ごとに100単位の意思決定ルーチンを実行できます。または、毎秒1000単位で実行することもできます。同じCPU時間がかかりますが、10倍の単位があります。

これは、ロット単位をどのように処理できるかを示す簡単な例です。

int curUnit;
Array<Unit> units;
[...]
while([...]) // Game Loop
{
  [...game logic...]
  // process 10 AIs per Frame
  for(int i=0; i++; i<10)
  {
    curUnit++
    if(curUnit == units.length()) curUnit=0;
    if(curUnit < units.length())
      units[curUnit].processAI();
  }

  // Update the position of all units, this should be as optimized as possible
  foreach(Unit& unit in units){ unit.move(); };

  [...graphics...]
}

AIが存在するほどAIの応答性は低下しますが、プレイヤーはおそらく極端な場合にのみそれに気付くでしょう。