タスクの割り当て

壁の構築など、労働者が任務を負うRTSでは、労働者はどの壁を構築するかをどのように決定しますか？

プレイヤーは、どの壁をどこに構築するかを決定しますが、個々のワーカーを個々の壁の四角形に割り当てません。多くのRTSゲームでは、ワーカーは近くのタスクを実行するだけですが、RTSでは、特定の正方形で明示的なタスクを戦略的に実行することを主な戦略として使用したいので、どこかにクラスター化してタスクを残さないようにしたくありません。離れて行われません。

私は建物の壁の例を使用しています。それは鉱石、道を作ること、木を集めることなど何でもあり得ます。重要なのは、ユーザーがどこを選ぶかではなく、誰を選ぶかです。

ワーカーは、アクセス可能な正方形に隣接する正方形でのみ作業できます。彼らが自分たちで作業する正方形は、作業が完了するまで通行できない場合があります。

労働者1と2は、正方形A、B、C、Dを採掘するように指示されています。

ゲームティックごとに1マス移動でき、1マスのマイニングには10ティックかかります。

どの労働者がどのマスを採掘するかをどのように決定しますか？

1がAをマイニングし、2がCをマイニングする必要があることは自明のようです。

1はAから4マス離れているため、14ティックでマイニングが完了します。1は次にどこに行くべきですか、そしてなぜですか？

そして、Bの真上に採掘される別の正方形-E-があった場合はどうなりますか？

ワーカーが次に進むべき場所を決定するために使用するロジックは何ですか？

リソースノードをビジーとしてマークするか、ツリーが使用できるワーカーの数を制限します。働いた人が特定の時点で集まるよう割り当てられている場合、あなたが本当に彼らに伝えているのは、最も近い利用可能な木を収穫することです。

このための2つの主要なパス：現実的なアプローチは、リソースノエが到着する前に評価してマークすることです。奇妙なキューの問題を防ぐために、労働者に木を評価するための視野を与えます。これにより、ワーカーはパッチに移動しながら特定のリソースノードにアプローチできます。これにより、最適化に制限が生じます。

ただし、多くのRTS（SCおよびSC2）では、ワーカーが到着するまでノードを評価しません。これにより、リソースノードが見つかるまで、作業員がさまよっています。これにより、より多くのスキル/最適化の報酬が得られます（素晴らしいワーカーの分割をご覧になったことはありますか？）しかし、ほとんどのプレイヤーは、すべてを囲み、クリックして、最初に同じ場所に行くことにイライラします。

正確な実装は、リソースのグループ化方法によって異なります。AoEでは、木と魚は連続的な広がりを持っているため、ゲームの進行に伴い、採集者はかなり遠くにいる可能性があります。しかし、SCやRed Alertなどのゲームでは、リソースは個別のパッチに配置されています。したがって、ワーカーはその特定のパッチを見回すだけで済みます。

編集後の編集：ワーカーの非効率性を強調しすぎないでください。私が考えることができるどんなRTSでも労働者の非効率があります。ワーカーの分割などは、プレーヤーがゲームよりもワーカーの管理に優れているために発生します。デザイナーではなく、プログラマの視点で考えているのではないでしょうか。単一のティック左の問題は、数値を微調整し、ノードを個別のトリップで収集できるようにすることで回避できます。背後にあるシステムを知っているので、ワーカーの非効率性は明白です。ただし、プレイテスターが気付かない場合は、あまり長く滞在しないでください。

解決策と考え：

解決策：クリックすると、収集ノードをキューに配置し、ジョブがキューの一番上に移動したときに、ワーカーの重み付けされたタスクキュー値を見つけ、最も重み付けされたタスクキュー値を持つ最も近いネイバーを見つけます（キュー値）。

あなたの例では、最適なキューの値を0にすることができます（現在のタスクがないことを意味します）。移動する必要がある各正方形（移動時間）のキュー値に1を追加し、各タスク（タスクを実行する時間）に10を追加します。経過する時間単位ごとに、各ワーカーのキュー値から1を削除します（開始キュー値が10の場合、3時間単位の後、キュー値は7になります）。次に、最近傍（複数のワーカーに同等のキュー値がある場合）を見つけて、そのタスクを実行するワーカーを見つけます。

したがって、例として、収集ノードがタスクキューからアルファベット順（AD）でポップし、キューがポップしている間は移動しないと仮定します。

(values in format [total] = [preexisting value] + [current task distance])
A Pops: 
    queue value of 1: 4 = 0 + 4 
    queue value of 2: 19 = 0 + 19
    Assigned to 1.
B Pops:
    queue value of 1: 24 = 14 + 10 (distance to B from A) 
    queue value of 2: 9 = 0 + 9
    Assigned to 2.
C Pops:
    queue value of 1: 25 = 14 + 11
    queue value of 2: 20 = 19 + 1 
    Assigned to 2.
D Pops:
    queue value of 1: 36 = 25 + 11
    queue value of 2: 41 = 20 + 21
    Assigned to 1.

このようにすることの欠点：高度に計算。

思想：

あなたのゲームはリソースによってブロックされていることにどのように対処しますか？つまり、すべてのノードがリソースである4x4グリッドが存在する場合、ワーカーは内部の4つのノードを取得できますか？そうでない場合は、ワーカーがアイドル状態にならないようにして、別のタスクを割り当て、外側のノードが完了すると、外側のノードの1つを収集しているワーカーの1つを内側のワーカーに割り当てます（putワーカーのタスクキューにあります）。

いくつかのウェイトシステムを試してみてください。ツリーが収集されている場合は、ある種のスタッキングペナルティとある種の距離ボーナスを計算します。（木材を使用してポイントA-> Bから取得するのにどのくらい時間がかかるかなど。次に、最も近い木材をチェックし、その重量をチェックしてから、それがその後、最も重量の小さいものを使用します。

もちろん、これには微調整が必​​要です。しかし、考え方は簡単です。

各ジョブには、a）重要度b）割り当てステータス（割り当てられたワーカーの数）が必要です。

次に、労働者は、時間ごとに最も「報酬」を与える仕事を決めることができます。報酬は、重要度を割り当てられた労働者の数で割って、投資に必要な時間（ウォーキングと仕事）で割って計算されます。あなたの労働者が仕事（例えば、薪割り）に特化できる場合、彼らは実際に彼らが効率的に行うことができるタスクを好むでしょう。もちろん、ジョブは適切なタイミングで続行できる場合にのみ割り当てる必要があります（たとえば、必要なリソースが利用可能でなければなりません）。

一部のジョブが長時間実行されないようにするため（たとえば、遠く離れているため）。重要性は時間とともに増加するはずです。収穫の場合、重要性は、そのタイプのリソースが現時点でどれだけ利用可能/必要であるかにも依存する必要があります（たとえば、生成されたユニットを一定期間に要求されたユニットで割った値）。

労働者が仕事をすぐに変更しないようにするには、報酬が大幅に改善された場合（所定のしきい値）にのみ、現在の仕事を変更できるようにします。また、時間あたりの報酬を計算するときに、最初の歩行の2倍のコストをジョブに適用することもできます。さらに、同時にすべてではなく、ワーカーの最適なジョブを1つずつ再計算する必要があります。

さらに、計算された報酬にランダム性を追加します。これにより、さまざまなジョブへのワーカーの分散が改善されます（このようにして、「すべて」が同じジョブを実行するだけではありません）。ただし、この効果は、ワーカーの次の最適なジョブを逐次再計算し、すでに割り当てられているワーカーの数を調整することですでに減少しています（同じジョブのワーカーが増えると、期待される報酬が減少します）。

ジョブを1人のワーカーにしか割り当てることができない場合は、アルゴリズムを少し調整する必要があるかもしれません。これが事実である場合、次のことを行ってください：労働者は、時間あたりの報酬が最も高い仕事を選びます（重要度を必要な個々の時間で割ったもの）。別の労働者がより高い期待報酬で毎回同じ仕事を行うことができる場合、彼は現在割り当てられている労働者を開始します。次に、新しい「失業者」の労働者は別の仕事を見つけようとします。あなたの例では、これは次のようになります：

• 「C」は非常に重要です。そして、ワーカー1は自分自身を "C"に割り当てます。
• ワーカー2が次に割り当てられ、「C」（歩行が少ない）の時間あたりの報酬が高くなります。したがって、ワーカー1をジョブから外し、自分自身を「C」に割り当てました。同じシミュレーションタイムスライス内にいるため、これには時間はかかりませんでした。したがって、ユーザーにはこのジョブの再割り当ては表示されません。
• その後、ワーカー1は別のジョブを探しています。時間あたりの報酬が良くないため、ワーカー1は「C」からワーカー2を開始しません。したがって、彼は「A」または「B」に割り当てられます（重要度に応じて）。繰り返しますが、これは同じシミュレーションタイムスライス内にあります。