（その３）では「少数群 vs 少数群」、（その４）では「多数群 vs 多数群」でトレーニングを行いました。その結果、それぞれにおいて、各エージェントは、ある程度の汎化能力を有する少数群戦闘エキスパート、多数群戦闘エキスパートのように学習できることが判りました。また、それらをセレクタを用いて、Subsumption architectureのような構造で組み合わせて用いる案を示しました。
トレーニング時に、25イテレーションごとに100回テストを行って Red team と Blue team の残存エージェント数（残存群数）を評価しました。学習が進むと、Blue team の残存エージェント数が０となり、Blue team をほぼ壊滅できるようになっています。また、Red team エージェント数は [7, 8] で乱択しているので、学習が進んだ時の平均残存数=5 ~ 6 は、1~ 2 エージェントが戦闘で消耗することを意味します。
Blue team の残存エージェント数や残存兵力を完全に０にはできていませんが、学習は進んでいるので、手法としてはトレーニング時の群数のダイナミックレンジを拡げても本手法は機能すると考えられます。ただし、評価結果が安定し始めたぐらいの感じがするので、もう少しトレーニングは長くやった方がよさそうです。
Blue teamの残存兵力はかなり小さくできているので、Red teamのエージェントは、彼我の群数が大きく変動しても戦えるような戦術を学習していることが判ります。
図を見ると戦術全体のバランスは悪くはないのですが、特に、少ないエージェント（群）で構成された Blue team に、多数のエージェント（群）で構成された Red team で攻撃するようなシナリオになると、性能が少し劣化しています。やはり、巨大な兵力の群に、小分けにされた小さな兵力の多数の群で戦闘するシナリオほど、学習が困難なようです。
正規化した残存兵力（Blue team）
この時の red teamの残存兵力は下図になります。red_force_ratio は以下で定義しています。左図のバーグラフの縦軸が red_force_ratioです。巨大な兵力の群に、小分けにされた小さな兵力の多数の群で戦闘するケースでは、残存兵力が僅かになっています。
これは学習時よりも多い red team のエージェント数での戦闘シナリオです。群数が外挿方向に増えても、"mass" 重視の戦術が生成出来ています。
特にこのシナリオでは、Blue teamは巨大な兵力を持った1つの群となっていて、これを撃破するための Red team が採り得る唯一の戦術は、Red team のエージェントが1つの塊となってから初めて Blue team のエージェントがいるグリッドに進出することです。この戦術が生成されていることが判ります。
Red team = 1 swarm vs Blue team = 10 swarms
これは学習時よりも多い blue team のエージェント数での戦闘シナリオです。巨大な兵力で、弱小な敵を順に撃破していく必要があります。群数が外挿方向に増えても、敵を順に撃破していく戦術が生成できているのが判ります。
しかしながら、特に、少ないエージェント（群）で構成された Blue team に、多数のエージェント（群）で構成された Red team で当たるようなシナリオになるほど、性能が劣化し学習が不十分になっていることが判りました。巨大な兵力の群に、小分けにされた小さな兵力の多数の群で戦闘することほど、学習が困難なようです。ここは、少ないエージェント（群）で構成された Blue team に対する戦闘は（その３）でトレーニングした少数群戦闘エキスパートに任せた方がよさそうです。
Red team の初期エージェント数（群数）を [1, 8]、Blue team の初期エージェント数（群数）を [1, 7] として、ネットワークをトレーニングし、その性能を評価しました。トレーニングに使用した条件下であれば、各エージェントは、完璧ではありませんが、"mass" を構成して戦う戦術を学習でき、上手く戦況をハンドリングできている（ほとんどいつも Blue team を殲滅できる）ことが判りました。
トレーニング時に、25イテレーションごとに100回テストを行って Red team と Blue team の残存エージェント数（残存群数）を評価しました。途中の段差は、GCPのpreemptiveの継続に依るものですので、無視してください。学習が進むと、Blue team の残存エージェント数が０となり、Blue team をほぼ壊滅できるようになっています。また、Red team エージェント数は [7, 8] で乱択しているので、学習が進んだ時の平均残存数=5 ~ 6 は、1~ 2 個のエージェントが戦闘で消耗することを意味します。
残存兵力（Force）の評価履歴は下記となりました。Blue team の残存兵力は0に近くなっていて、Red team の各エージェントは、上手く戦える戦術を生成し実行していることが分かります。ただ、「少数群 vs 少数群」でトレーニングした時の様に、Blue team の残存兵力を完全に０にはできていないので、もう少しトレーニングを続けた方がよさそうです。
Blue team の残存兵力を0にできたエピソードを success、逆に Red team の残存兵力が0になってしまったエピソードを fail、どちらの兵力も0とはならなかったエピソードを draw と定義して、これらを100回のエピソードから算出したのが下図です。学習が進むと、success=100%、つまり、Blue team の残存兵力を0に近づけられることが判ります。
red.alive_ratio：（エピソード終了時点での red team エージェント数）÷（初期 red team エージェント数）
blue.alive_ratio：（エピソード終了時点での blue team エージェント数）÷（初期 blue team エージェント数）
red.force_ratio：（エピソード終了時点での red team 兵力合計）÷（初期 red team 兵力合計）
blue.force_ratio：（エピソード終了時点での blue team 兵力合計）÷（初期 blue team 兵力合計）
です。red team の残存エージェント数は74~80％と割と多いのですが、残存兵力は25%程度になっています。もし、red team の各エージェントが、完全に一丸となって戦うことを学んでいれば、少なくとも「少数群 vs 少数群」の時と同程度の30%以上のred team残存兵力になるはずですので、完全に一丸となって戦っているとまでは言えないようです。（時間の都合で、Blue agent 数=7の場合だけを計算しています）。
NUM_BLUE=7
NUM_RED
episode_length
red.alive_ratio
blue.alive_ratio
red.force_ratio
blue.force_ratio
7
14.15
0.80
0.00
0.26
0.00
8
14.99
0.74
0.00
0.25
0.00
この点に注意しながら、生成された戦術を見てみます。動画の見方は、（その３）と同様です。
生成された戦術
下図（左）は、戦闘状況を示します。赤い正方形が Red team のエージェント（群）、青い正方形が Blue team のエージェント（群）を示します。画面左上の座標値は、red team の０番目のエージェント（ "red_0" と呼称）の位置を示します。また、色の濃さが戦闘力（Force）の大きさを表し、色が濃いほど大きな戦闘力であることを示します。したがって、戦闘が進むに連れ、戦闘力は消耗して色が薄くなってゆきます。また、同一グリッドに Red team と Blue team が混在する場合は、チームの戦闘力の差を表していますので、色が薄いほど拮抗した戦闘がそのグリッドで行われていることになります。戦闘が進んだ時に色が濃くなるのは、それだけその色のチームの戦闘力が相対的に優位になったことを表しています。
下図（右）の赤、青三角は、夫々 Red team, Blue team の残存戦闘力（群の構成メンバー数）を示します。
Red teamの各エージェントは、勝率 100% ですが、完全に一つの塊となって 'mass' 重視の戦闘をする訳ではありませんでした。ここは、もう少しトレーニングを継続すると改善するのかもしれません。（やっていないので分かりません）。
ここでは、エージェント数を Red team = [1, 10], Blue team = [1, 9] の範囲で振ってみて、トレーニング時には全く未経験の戦況にどこまで対応できるのか測って見ました。（トレーニング時のエージェント数は Red team = [7, 8], Blue team = [6, 7] です）。
初期エージェント数が Red team = [1, 6], Blue team = [1, 5] のようなケースでは、初期マップはトレーニング時に見たことが無いような、エージェントが少ない疎なマップになります。
Red team の初期エージェント数（群数）を [7, 8]、Blue team の初期エージェント数（群数）を [6, 7] として、多数群 vs 多数群の設定でネットワークをトレーニングし、その性能を評価しました。トレーニングに使用した条件下であれば、各エージェントは、完璧ではありませんが、"mass" を構成して戦う戦術を学習でき、上手く戦況をハンドリングできている（ほとんどいつも Blue team を殲滅できる）ことが判りました。
各チームの初期エージェント数（群数）：各エピソードの初めに、Red team のエージェント数（群数）を [1,3] から、Blue team のエージェント数（群数）を [1,2] から乱択します。
Initial Force（初期兵力）：各エピソードの始めに、両チームともに、ランダムに Force をチームのエージェントに配分します。エージェントの Force の最小値は 50 とします。Red team の Initial Force の合計は 500、Blue team は 490 としました。したがって、Red team の最大エージェント数（群数）は 10、Blue team は 9 になります。また、エージェント数が増えるほど、ほぼ同じForceの群となっていきます。この辺りは、将来もう少し工夫したいと思っています。
トレーニング時に、25イテレーションごとに100回テストを行って Red team と Blue team の残存エージェント数（残存群数）を評価しました。学習が進むと、Blue team の残存エージェント数が０となり、Blue team をほぼ壊滅できるようになっています。また、Red team エージェント数は [1, 3] で乱択しているので、学習が進んだ時の平均残存数=2 は、ほとんどの場合、全エージェントが残存していることを意味します。
これを平均残存兵力で見たのか下図です。Blue team の残存兵力はほぼ0になっています。Red team の残存兵力は 110 程度です。この最適解は、Red team が一丸となって、順に分割戦略で Blue team にあたった時の Lanchester model の残存兵力に近いものになっているはずです。エネルギー不足で、この計算は省略しました。いろいろ、省略が多くてゴメンナサイ。
Blue team の残存兵力を0にできたエピソードを success、逆に Red team の残存兵力が0になってしまったエピソードを fail、どちらの兵力も0とはならなかったエピソードを draw と定義して、これらを100回のエピソードから算出したのが下図です。学習が進むと、ほぼ確実に success=100%、つまり、Blue team の残存兵力を0にできることが判ります。
red.alive_ratio：（エピソード終了時点での red team エージェント数）÷（初期 red team エージェント数）
blue.alive_ratio：（エピソード終了時点での blue team エージェント数）÷（初期 blue team エージェント数）
red.force_ratio：（エピソード終了時点での red team 兵力合計）÷（初期 red team 兵力合計）
blue.force_ratio：（エピソード終了時点での blue team 兵力合計）÷（初期 blue team 兵力合計）
Blue team 初期エージェント数 = 1 の場合の結果は下表です。確実に、Blue team を撃破できる戦術を獲得していることが判ります。
BLUE Team Swarm 数 = 1
NUM_RED
episode_length
red.alive_ratio
blue.alive_ratio
red.force_ratio
blue.force_ratio
1
9.56
1.00
0.00
0.09
0.00
2
11.66
1.00
0.00
0.09
0.00
3
12.62
0.97
0.01
0.09
0.00
Blue team 初期エージェント数 = 2 の場合の結果は下表です。ここでも、確実に、Blue team を撃破できる戦術を獲得していることが判ります。また、Blue team が小分けになったことにより、Red team の残存兵力（red.force_ratio）が、上記 Table よりも大きくなっています。この残存兵力（red.force_ratio）が、0.33~0.36 とほぼ一定になっているので、Red team はエージェント数（群数）が多くても、"mass" を活かした戦術が生成できているのではないかと期待できます。
BLUE Team Swarm数 = 2
NUM_RED
episode_length
red.alive_ratio
blue.alive_ratio
red.force_ratio
blue.force_ratio
1
10.99
1.00
0.00
0.34
0.00
2
13.15
1.00
0.00
0.36
0.00
3
14.20
0.98
0.01
0.33
0.00
生成された戦術
１ swarm vs 1 swarm
下図（左）は、戦闘状況を示します。赤い正方形が Red team のエージェント（群）、青い正方形が Blue team のエージェント（群）を示します。画面左上の座標値は、red team の０番目のエージェント（ "red_0" と呼称）の位置を示します。また、色の濃さが戦闘力（Force）の大きさを表し、色が濃いほど大きな戦闘力であることを示します。したがって、戦闘が進むに連れ、戦闘力は消耗して色が薄くなってゆきます。また、同一グリッドに Red team と Blue team が混在する場合は、チームの戦闘力の差を表していますので、色が薄いほど拮抗した戦闘がそのグリッドで行われていることになります。戦闘が進んだ時に色が濃くなるのは、それだけその色のチームの戦闘力が相対的に優位になったことを表しています。
下図（右）の赤、青三角は、夫々 Red team, Blue team の残存戦闘力（群の構成メンバー数）を示します。
Red team のエージェントは、敵（Blue team のエージェント）の位置を認識し、そのマスへ最短経路で移動し、敵が消耗して殲滅するまで敵と同じマスにとどまる戦術を学習しています。
但し、ごく稀ですが、１タイムステップの遠回り経路をとることが有りました。
Red team = 1 swarm, Blue team = 1 swarm
2 swarm vs 1 swarm
Red team のエージェントは、一丸となって巨大な Blue Team のエージェントに当たる必要があるシナリオです。
このシナリオでは、２通りの戦術が生成されました。
１つめの戦術は、まず２つの swarm が一体化して巨大な戦闘力を有する１つの swarm になった後、初めて Blue team の swarm に攻撃を加える戦術です。
２つ目の戦術は、２手に分かれている Red team の swarm が、別々の方向から同じタイミングで Blue team の swarm に同時攻撃をかける戦術です。実際の戦闘では、このような挟撃戦術は、より効果があると思うのですが、Lanchester モデルは挟撃の効果をモデル化していないため、学習したエージェントが常にこの戦法をとるとは限りません。この辺りは、強化学習の問題ではなく、モデル化の問題です。
ここでは、エージェント数を Red team = [1, 10], Blue team = [1, 9] として、トレーニング時には全く未経験の戦況にどこまで対応できるのか測って見ました。（トレーニング時のエージェント数は Red team = [1,3], Blue team = [1,2] です）。
blue_alive_ratio = Blue team残存エージェント数／Blue team初期エージェント数
= Blue team残存群数／Blue team初期群数
正規化した残存エージェント数（Blue team）
Red team については、下図になります。red_alive_ratio は以下で定義しました。
red_alive_ratio = Red team残存エージェント数／Red team初期エージェント数
= Red team残存群数／Red team初期群数
正規化した残存兵力数（Red team）
以上から、以下を読み取ることができます。
Brue team のエージェント数 = 1 の時、つまり、Blue team が巨大な兵力を持った１つの群だけで構成されている場合、Red team のエージェント数がトレーニング時よりも増えると、Blue team の残存兵力は急激に大きくなる。この時の、Red team の残存兵力は僅かである。したがって、Red team は、外挿に耐えうるほどは "mass" 重視の戦術を学習しきれていない。
Brue team、Red team のエージェント数が増えるほど、（外挿方向なので、当然ですが）、Brue team の残存兵力は増える。この時の Red team には、かなりの兵力が残存している。したがって、エージェント数が増えるほど、未知の環境に右往左往してしまい上手く戦いきれていない。
上記をもう少し分析します。成功率、引き分け率を以下で定義することにします。
success = Blue team の残存兵力=0となったエピソード数／全エピソード数
draw = どちらの tem の残存兵力も0にならなかったエピソード数／全エピソード数
これらをバーグラフと heatmap にしたのが下図です。
ミッション成功率 [%]
ミッション引き分け率 [%]
Brue team のエージェント数 = 1 の場合、Red team が小分けになるほど急速に成功率が減少します。
戦域に小分けになって散開した Red teamが、１つの巨大な戦闘力を有する Blue team と戦うシナリオです。Red team の各エージェントは、mass を重視した大きな戦闘力となるよう自律的に集合して来るのですが、後一歩タイミングを揃えることがでないために、わずかの差で Blue team に撃破されます。他のケースも、いくつか調べたのですが、同様の傾向が見られました。
多くの場合、上手くは行かず、Red team のエージェントは、時間切れになるまで右往左往します。途中までは、上手く戦っているのに、途中から右往左往してしまいます。この段階で、Red team の戦闘力は、Blue team よりも高く、Red team = 2, Blue team=4 という戦闘様相になっているので戦えないことはないと思うのですが・・・。ここは、もう少し分析すると改善点がでてくる気がします。
Read_team = 10 swarms, Blue team = 10 swarms
Red team=1 swarm vs Blue tem=10 swarms
小分けになった Blue team を強大な Red team の swarm が順番に撃破していくケースで、「敵を撃破する」というコンセプトは、きちんと学習できていることを確認しました。
一つの mass とまでは行きませんが、上手く戦うことができます。初期マップで Red team が ７ エージェントになっていますが、これは同一マスに２エージェントが居るためです。
Read_team = 8 swarms, Blue team = 7 swarms
まとめ
Red team の初期エージェント数（群数）を [1, 3]、Blue team の初期エージェント数（群数）を [1, 2] として、少数群 vs 少数群の設定でネットワークをトレーニングし、その性能を評価しました。トレーニングに使用した条件下であれば、各エージェントは、"mass"を構成して戦う戦術を学習できていることが判りました。
Red teamのエージェントは、彼我のエージェント数がトレーニング時の2倍強程度までの外挿であれば、問題なく "mass" を活かした戦術で戦うことができました。
「１０ read team swarm vs 1 blue team swarm」のように、巨大な兵力の Blue team に対し、小分けされる方向に外挿された状況では、Red team のエージェントは、タイミングコントロールが後一歩及ばないため、”mass"を活かした戦術で戦うことができなくなりました。
「１０ read team swarm vs 10 blue team swarm」のように、彼我のエージェント数がトレーニング時よりも遥かに増えると、Red team のエージェントは右往左往し始め、上手く戦うことができませんでした。
次回記事では、今回とは逆に、Red team, Blue team のトレーニングを多数群 vs 多数群で行い、少ないエージェント数に対するロバスト性（汎化能力）を図ってみたいと思います。
for i in range(env.num_red): if env.red.alive[i]: my_matrix = np.zeros((env.grid_size, env.grid_size)) teammate_matrix = np.zeros((env.grid_size, env.grid_size)) adversarial_matrix = np.zeros((env.grid_size, env.grid_size))
# my position & force map my_matrix_pos[env.red.pos[i][0], env.red.pos[i][1]] += 1 my_matrix[env.red.pos[i][0], env.red.pos[i][1]] += env.red.force[i]
# teammate position & force map teammate_id = [j for j in range(env.num_red) if j != i] for j in teammate_id: if env.red.alive[j]: teammate_matrix_pos[env.red.pos[j][0], env.red.pos[j][1]] += 1 teammate_matrix[env.red.pos[j][0], env.red.pos[j][1]] += env.red.force[j] # Don't care because env.red.force[j]=0 if not env.red.alive[j] # adversarial position & force map for j in range(env.num_blue): if env.blue.alive[j]: adversarial_matrix_pos[env.blue.pos[j][0], env.blue.pos[j][1]] += 1 adversarial_matrix[env.blue.pos[j][0], env.blue.pos[j][1]] += env.blue.force[j] # Don't care because env.blue.force[j]=0 if not env.blue.alive[j] # stack the maps my_matrix_pos = np.expand_dims(my_matrix_pos, axis=2) my_matrix = np.expand_dims(my_matrix, axis=2) teammate_matrix_pos = np.expand_dims(teammate_matrix_pos, axis=2) teammate_matrix = np.expand_dims(teammate_matrix, axis=2) adversarial_matrix_pos = np.expand_dims(adversarial_matrix_pos, axis=2) adversarial_matrix = np.expand_dims(adversarial_matrix, axis=2)
# Normalize teammate_matrix_pos & adversarial_matrix_pos by current number of agents teammate_matrix_pos = teammate_matrix_pos / np.sum(env.red.alive) adversarial_matrix_pos = adversarial_matrix_pos / np.sum(env.blue.alive)
具体的には、タイムステップ t で、以下の式でグリッド (i, j) に位置するRed teamエージェントに報酬を与えました。"＊100"は、報酬の大きさが適当になるように設定した係数です。（もう少し、小さいほうが良かったかもしれません）。
where
BID(i, j)：グリッド (i, j) に位置する Blue team のエージェントの ID
RID(i, j)：グリッド (i, j) に位置する Red team のエージェントの ID
Bk: Blue team のエージェント k の force
bk: Blue team のエージェント k の efficiency
Rl: Red team のエージェント l の force
rl: Red team のエージェント l の efficiency
Bmax: Blue team のエージェントの初期 force の合計
Rmax: Red team のエージェントの初期 force の合計
上式右辺で、
が、グリッド (i, j) に位置する Blue team エージェントの戦闘力（'mass'）= 兵力 x 武器性能 = force x efficiency の合計、
が、グリッド (i, j) に位置する Red team エージェント 闘力（'mass'）= 兵力 x 武器性能 = force x efficiency の合計に対応します。また、戦闘に参加したエージェントへの報酬配分は、
に従って与えます。これは、グリッド (i, j) での戦闘に参加した Red team エージェントの戦闘力 （'mass'）に比例して報酬配分していることになります。したがって、大きな 戦闘力（'mass'） を提供するエージェントほど大きな報酬を受け取りますが、小さな戦闘力（'mass'）しか提供しないエージェントでも、戦闘力を提供する限りは応分の報酬を受け取ることになります。
本記事では、これらの戦場に散開した自律的な中隊や小隊レベルの「複数群 vs 複数群」の戦闘を考え、マルチエージェント強化学習を使って効果的な「自律群間の協調戦闘戦術」を生成することを試みます。もう少し軍隊風に言えば、敵を殲滅するために、戦域に展開した自律的な中隊や小隊の動き方を生成することを試みます。マルチエージェントの枠組みで考えますので、戦術を中隊や小隊に与えて、それに従って動かすのではなく、中隊や小隊が自律的に決心した結果として戦術が創発します。
Dota IIでは、5つのキャラクター（エージェント）を選択し、これらのエージェントをマルチエージェント強化学習することで、ゲーマーのグランドマスター・レベルの性能を達成しています。学習にはDPPO（Distributed PPO）を使っています。実験では、５つのAI vs ５つのAI, ５つのAI vs 5人のゲーマー、AIとゲーマーの混合チーム vs AIとゲーマーの混合チームの対戦を行っています。興味深いのは、 AIとゲーマーの混合チームの対戦において、ゲーマーが「AIの方が人間よりも協力的だった」とコメントしていることです。
Hide and Seekでは、任意のマップにおける複数の自律エージェントの協調制御をマルチエージェント強化学習しています。これも学習にはDPPO（Distributed PPO）を使っています。これはエージェントがとてもキュートです。エージェントのアーキテクチャには、Transformer ですっかり有名になったアテンション機構が空間的に使われていて勉強になりました。ただし、エージェント数は 2 vs 2 なので、多数とまでは言えません。
また、マルチエージェント強化学習のフレームワークとすることで扱える群の数も任意数となりました。解こうとしている最終的な問題環境、自群、友群、敵群の各種情報が、2次元地図（n x nでグリッド化）に表現されているものとします。群の一番判りやすいイメージは、海兵隊の研究で使われている中隊、小隊です。以下では、「我」を Red team、「彼」を Blue teamとし、各チームは大きさ（構成メンバー数）と保有する武器が異なる複数の群で構成されているものとします。
また、便宜上、各群をエージェントと呼ぶことにします。したがって、Red team, Blue teamは夫々複数のエージェントの集合体になります。
群 vs 群の戦闘モデルとしては、海兵隊の研究と同様にランチェスターモデルを用います。このモデルは決定論的（Deterministic）ですが、海兵隊の研究では確率論的（Stochastic）なモデルも検討されています。今回は、問題をシンプルにするために、オリジナルの決定論的なランチェスター・モデルを用います。
これは、戦闘力が小さな軍隊でも、何らかの方法で敵を分割することが出来た場合は、順繰りに敵を個別撃破していくことで、最終的に勝利を収めることが出来るというものです。これは、海兵隊の "mass" と "economy of force" の基になっている考え方です（と教本に書いてあったと記憶しています）。
下図に、シミュレーションの結果を示します。横軸が戦闘開始からの経過時間、縦軸が各 team の残存兵力です。青ラインが Blue team の残存兵力、橙ラインが red team の残存兵力の遷移を示します。red team の初期兵力は 400、blue team の初期兵力は 500 としています。彼我の武器性能 （efficiency=0.7） は同一としています。したがって、１対１のガチンコ勝負の場合、red team に勝ち目はありません。
しかしながら、red team が何らかの方法により、blue team を (250,250) の群に2分割できた場合、これらに順繰りに（シーケンシャルに）対処していくことで red team は勝利することが出来ます。シミュレーションは、戦闘中の敵群兵力が消滅したら、次の敵群と戦うと仮定して計算しています。
この効果は、blue team を小さな多数群に分割できた場合ほど大きくなります。例えば、blue team の兵力を (100, 100, 100, 100, 100) と5つの小群に分割できたような場合、初期兵力では劣っていた red team が、想像以上の圧勝を得ることになります。
これから、小出しに戦力投入することがいかに不利で、海兵隊が重要視する "mass（consolidation of force）" がいかに重要かが判ります。
以上から、戦場に様々な兵力や戦闘効率のエージェント（群）が散開している場合、勝利を収めるためには、散開した様々な戦力のエージェントは、陽には与えられていないランチェスターモデルを理解し、自己、友群、敵群、環境状況、残存兵力、戦闘効率等をマップから認知・識別し、彼我の動きを阿吽の呼吸で予測して、適切な "Mass" と "Economy of force" を得ることが出来る協調戦術に変換し、各自のアクションとして自律的に実行することを学習しなければならないことが判ります。
red team の全エージェントは、同じ一つのニューラル・ネットをブロードキャストしたコピーを持ちます。これは、少し見方を変えると、全エージェントが１つのニューラルネットを共有していることになります。環境とのインタラクション（ロールアウト）時には他のエージェントは環境の一部とみなします。そして、全エージェントが、ロールアウトして収集した遷移情報を使って、確率的勾配法でこの共有しているネットを更新することで学習を進めます。バッチ分のデータを使った更新が終わると、新しいネットのコピーを各エージェントにブロードキャストし、次のサイクルに入ります。
