🤺 🏢 👨🏾‍🚒 Node.jsでのターンベースゲームのAI開発（パート2） 🤙🏿 🙌🏼 🏖️

こんにちは、友人たち！

少し前まで、ボットアクションを選択する問題を解決するためにニューラルネットワークを使用した私の経験を共有しました。問題の本質について詳しくは、記事の最初の部分をご覧ください。

そして、次の作業段階についてお話しします！

決定木

ニューラルネットワークでの失敗した（しかし非常に有用な）経験の後、決定木とゲーム理論の研究を始めました。この問題を研究する過程で、私は多くのアイデアと概念を持ちましたが、次のことに決めました。

ボットには、ツリーの最初のレベルでよく知られたアクション（ノード）のセットがあります。これらは、ボットが現在のゲーム状況に最適なものを選択するアクションです。
ボットは各アクションの「シミュレーション」を行います。「心の中で」それをしようとしています。このアクションの結果は、ゲームの状況の変化、つまり環境の別の状態への移行になります。
新しい状態は、状況を評価する機能に転送され、その結果は特定の値、つまりアクションのスコアになります。
スコアを計算した後、ボットは新しい仮想状況からすでに実行できるアクションのリストを生成します。次に、ボットが移動を完了する以外のことができるようになるまで、ステップ2と3を再帰的に繰り返します。
同じツリーレベルのすべてのアクションのポイントが計算されると、最大スコアはツリーの親レベルに戻り、アクションの子リストを生成したアクションのスコア値に加算されます。したがって、 スコア値は、ツリーの極端な枝から根まで「ポップアップ」するように見えます。
ツリーの通過が完了すると、その時点でボットが実行できる各アクションにスコアが付けられます。ここで、最大スコアのアクションを選択して適用するだけです。

以下は、このアルゴリズムを説明する再帰関数です。

たくさんのコード

function buildActionBranch (situation) { var actionList = createActionList(situation); /*  createActionList   ,              .    actionList            (newSituation). */ for(var i = 0; i < actionList.length; i++){ if(actionList[i].type !== "endTurn") { /*       ,      */ actionList[i].branch = buildActionBranch(actionList[i].newSituation); /*  selfScore -       ,   score     ,            */ actionList[i].score = actionList[i].selfScore + actionList[i].branch[0].score; /* actionList[i].branch[0] -      score    */ } else { actionList[i].score = actionList[i].selfScore; } } /*     score   */ actionList.sort(function (a, b) { if (a.score <= b.score) { return 1; } else if (a.score > b.score) { return -1; } }); /*  actionList    branch   ,      */ return actionList; }

これは、再帰関数の概略図にすぎません。実際、ツリーの構築には微妙な違いがあります。これについては後で説明します。また、決定木に関するデータをファイルに書き込むための関数も実装しました。これにより、後でどのように見えるかを明確に確認できます。

デシジョンツリー（JSONファイルサイズ：4kb）

このツリーは移動用に構築されており、キャラクターはすでに少しエネルギーを消費しており、選択できるオプションは5つだけです。「光を当てる」機能を使用して移動を完了すると、3つの隣接セルに移動します。各ノードで、アクションの名前、 スコア （上の図）およびselfScore（下の図）を確認できます。ルートレベルでスコアがどのように形成されるかを簡単に追跡できます。すべての配列がscoreでソートされているという事実により、最適なソリューションは常に一番上にあります。別のツリーを検討してください。

最適なソリューションを開いたツリー（JSONファイルサイズ：169kb）

残念ながら、高さ約80,000ピクセルかかるため、この場合の完全なツリーを表示することはできません。開いたブランチを右から左に見ていきましょう。

377（ターン終了）+ 378（移動）+ 373（Defender Of The Faithキャスト）+ 312（キャストPunishment Due）+ 218（移動）= 1658

移動アクションの場合、 スコア値は1660です。表示時の数字の整数値への丸めにより、差は2ポイントです。ツリーの最初のレベルのselfScore値を見てみましょう。selfScoreが218のmoveアクションは、近隣ノードの中で最大ではありません。このレベルでの最善のアクションは、Defender Of The Faith（ selfScore = 244）を使用することです。ただし、移動アクションの合計スコア（1660対1652）は依然として大きくなります。コース全体のアクションを考えなければ、この状況で能力を使用することはそれほど最適ではないことがわかります。

次に、このアルゴリズムのさまざまな側面を詳しく見てみましょう。

状況の評価

状況を評価するには、次の機能を使用します。

たくさんのコード

  function situationCost (activeChar, myTeam, enemyTeam, wallPositions){ var score = 0; var effectScores = 0; //     score += activeChar.curHealth / activeChar.maxHealth * 110; score += activeChar.curMana / activeChar.maxMana * 55; var positionWeights = arenaService.calculatePositionWeight(activeChar.position, activeChar, myTeam.characters, enemyTeam.characters, arenaService.getOptimalRange(activeChar), wallPositions); score += positionWeights[0] * 250 + Math.random(); score += positionWeights[1] * 125 + Math.random(); for(var j = 0; j < activeChar.buffs.length; j++){ if(activeChar.buffs[j].score) { effectScores = activeChar.buffs[j].score(activeChar, myTeam.characters, enemyTeam.characters, wallPositions); score += this.calculateEffectScore(effectScores, activeChar.buffs[j].name); } } for(j = 0; j < activeChar.debuffs.length; j++){ if(activeChar.debuffs[j].score) { effectScores = activeChar.debuffs[j].score(activeChar, myTeam.characters, enemyTeam.characters, wallPositions); score -= this.calculateEffectScore(effectScores, activeChar.debuffs[j].name); } } //myTeam -    for(var i = 0; i < myTeam.characters.length; i++){ if(myTeam.characters[i].id !== activeChar.id) { var ally = myTeam.characters[i]; score += ally.curHealth / ally.maxHealth * 100; score += ally.curMana / ally.maxMana * 50; for(j = 0; j < ally.buffs.length; j++){ if(ally.buffs[j].score) { effectScores = ally.buffs[j].score(ally, myTeam.characters, enemyTeam.characters, wallPositions); score += this.calculateEffectScore(effectScores, ally.buffs[j].name); } } for(j = 0; j < ally.debuffs.length; j++){ if(ally.debuffs[j].score) { effectScores = ally.debuffs[j].score(ally, myTeam.characters, enemyTeam.characters, wallPositions); score -= this.calculateEffectScore(effectScores, ally.debuffs[j].name); } } } } //enemyTeam -  for(i = 0; i < enemyTeam.characters.length; i++){ var enemy = enemyTeam.characters[i]; score -= Math.exp(enemy.curHealth / enemy.maxHealth * 3) * 15 - 200; score -= enemy.curMana / enemy.maxMana * 50; for(j = 0; j < enemy.buffs.length; j++){ if(enemy.buffs[j].score) { effectScores = enemy.buffs[j].score(enemy, enemyTeam.characters, myTeam.characters, wallPositions); score -= this.calculateEffectScore(effectScores, enemy.buffs[j].name); } } for(j = 0; j < enemy.debuffs.length; j++){ if(enemy.debuffs[j].score) { effectScores = enemy.debuffs[j].score(enemy, enemyTeam.characters, myTeam.characters, wallPositions); score += this.calculateEffectScore(effectScores, enemy.debuffs[j].name); } } } return score; }

このメソッドは、戦闘に関与するすべてのキャラクターを実行し、さまざまなパラメーターに対して一定のポイントを獲得します。

健康味方のヘルス率が高いほど、ポイントが多くなります。さらに、依存関係は線形です。
```
  score += activeChar.curHealth / activeChar.maxHealth * 110;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
ただし、敵のキャラクターの健康状態を評価する場合、ポイントは次の式を使用して付与されます。
```
  score -= Math.exp(enemy.curHealth / enemy.maxHealth * 3) * 15 - 200;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
現在の健康の軸に沿った0から1の範囲の上記関数のグラフ

対戦相手が完全な健康状態にある場合、ほぼ同じ値が味方に追加される合計ポイント数から差し引かれます。ただし、特定のキャラクターの健康状態が低いほど、この状況で得られるポイントが多くなります。健康状態が悪いと、ポイントは差し引かれずに加算されます。これは、ボットが敵チームへのダメージを「スミアリング」するのではなく、1つのターゲットを破壊することに努力を集中させるために行われます。
マナ（能力を使用するためのリソース）。 複雑な機能はすでに存在せず、味方と敵の両方にとってすべてが線形です。
位置。 戦場でのキャラクターの位置の評価に合格する際に、すでに言及しました。

これは、攻撃的と防御的な2つの部分で構成されています。最適な攻撃位置は、視界内で攻撃に最適な距離にいる3人の敵キャラクターです。最良の防御陣地は、視界内にあり、支援能力を適用するための最適な距離にいる2人の味方です。他のキャラクターの位置を変更しても、アクティブなキャラクターの対応するインジケーターの値に影響するため、ポジショニングのポイントはアクティブなキャラクターに対してのみ付与されます。
エフェクト。 評価関数の最も難しい部分。ボットが決定する必要がある

キャラクターに1つのエフェクトがどの程度重なっているかが、他のエフェクトよりも重要です。このため、各効果にはスコア関数があります。たとえば、buff（バフ）

焼izationは徐々にキャラクターの健康を回復させますが、マナを燃やします。この効果の場合、 スコア関数は次のとおりです。
たくさんのコード
```
  score: function(owner, myTeam, enemyTeam, walls) { var buffer = {}; /* buffer - ,     */ for (var i = 0; i < myTeam.length; i++) { if (myTeam[i].id === this.casterId) buffer = myTeam[i]; } /*     */ var heal = (this.variant * 80) * (1 + buffer.spellPower); /*       ,    */ heal = arenaService.calculateExpectedHeal(heal, buffer); /*      */ var positionWeights = arenaService.calculatePositionWeight(owner.position, owner, myTeam, enemyTeam, arenaService.getOptimalRange(owner), walls); return { effectScore: heal / 10, leftScore: this.left * 5, offensivePositionScore: 0, defensivePositionScore: - positionWeights[1] * 25, healthScore: - owner.curHealth / owner.maxHealth * 25, manaScore: owner.curMana / owner.maxMana * 15 }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
したがって、エフェクトのスコア関数は、6つのプロパティを持つオブジェクトを返します。
- effectScore。 効果自体の数値インジケータの修飾子：与えられたダメージの大きさ、受けた治癒、特性の増加または減少など。
- leftScore。 エフェクトの継続時間修飾子。
- offensivePositionScore。 攻撃位置の修飾子。
- defensivePositionScore。 守備位置の修飾子。
- healthScore。 エフェクトの所有者のヘルス量の修飾子。
- manaScore。 エフェクトの所有者のマナの量の修飾子。
状況評価機能では、これらのすべての修飾子が加算されます。この量は、この効果の「品質」の指標になります。

「焼uter」の効果に関するこれらすべての修飾子について、次の結論を導き出すことができます。
- 健康が回復すればするほど、その量は増えます。
- 彼がキャラクターにとどまるほど、金額は高くなります。
- 対戦相手の場所は金額に影響しません。
- 味方から遠ざかるほど、量は増えます。なぜなら信頼できる人はいないので、安全にプレイすることをお勧めします。
- キャラクターのヘルスが少ないほど、量が多くなります。
- キャラクターが残したマナが多いほど、量が多くなります。結局のところ、この効果がマナなしで完全に私たちを去るのは望ましくありません。

アクションシミュレーション

ボットアクションの結果を評価するには：

環境の状態を完全にコピーして、それ以降のすべてのアクションが元の状態に変化しないようにします
アクション（能力の移動または使用）のシミュレーションを実行します
評価関数を使用して環境の新しい状態を評価します

あとでコピーに戻りますが、ここでは、ゲームで最も単純なメカニズムの1つである「Die By The Sword」の例に基づいて、シミュレーションが何であるかを詳しく見ていきます。

ゲーム内の各能力には、ダメージを与えたり、回復したり、効果を適用したりするキャスト機能があります。 「Die By The Sword」のキャスト関数を見てみましょう。

たくさんのコード

  cast : function (caster, target, myTeam, enemyTeam, walls) { /*       */ caster.spendEnergy(this.energyCost()); caster.spendMana(this.manaCost()); /* ,           */ this.cd = this.cooldown(); /*     */ if(caster.checkHit()){ /*             */ var physDamage = randomService.randomInt(caster.minDamage * (1 + this.variant * 0.35), caster.maxDamage * (1 + this.variant * 0.35)); /*      */ var critical = caster.checkCrit(); if(critical){ physDamage = caster.applyCrit(physDamage); } /*         */ physDamage = target.applyResistance(physDamage, false); /*      ,      */ caster.soundBuffer.push(this.name); /*      physDamage */ target.takeDamage(physDamage, caster, {name: this.name, icon: this.icon(), role: this.role()}, true, true, critical, myTeam, enemyTeam); } else { /*      ,     */ caster.afterMiss(target.charName, {name: this.name, icon: this.icon(), role: this.role()}, myTeam, enemyTeam); } /*       ,     */ caster.afterCast(this.name, myTeam, enemyTeam); }

この関数内には、ランダムな性質の少なくとも3つの操作（損傷の判定、ヒットの判定、クリティカルヒットの判定）、およびクライアントで再生するサウンドの追加などの実用的な方法があることがわかります。当然、結果を予測することになると、この関数を使用できません。したがって、 キャスト関数に加えて、各能力にはcastSimulationもあります。

  /*       */ caster.spendEnergy(this.energyCost()); caster.spendMana(this.manaCost()); /* ,           */ this.cd = this.cooldown(); /*    -         */ var physDamage = (caster.minDamage * (1 + this.variant * 0.35) + caster.maxDamage * (1 + this.variant * 0.35)) / 2; /*            */ physDamage = caster.hitChance * ((1 - caster.critChance) * physDamage + caster.critChance * (1.5 + caster.critChance) * physDamage); physDamage = target.applyResistance(physDamage, false); /*      ""   */ target.takeDamageSimulation(physDamage, caster, true, true, myTeam, enemyTeam); caster.afterCastSimulation(this.name);

同じ方法が動きの動作をシミュレートするために使用されます-単に不必要なものを切り取り、ランダムな方法を数学的期待に置き換えます。

最適化

基本的なアルゴリズムが構築された後、私は最初にボットが移動を検討し、行動を起こすことを見ました。特定の状況で何をすべきかを自分たちがどのように決定するかを見るのはとてもクールでした。しかし、その後、次の問題が突然浮上しました-時々彼らはすっごく長いと思う Node.jsツリーの計算が忙しいためにpingイベントが発生しないため、 Socket.ioがクラッシュします。最適化を行う時間です。

1）フローリリース

私が最初に思いついたのは、ツリーの構築を非同期にすることでした。 非同期ライブラリとeachOfメソッドを使用して、アクションリストを通過するすべてのパスを非同期に変換し、すべてのコールバックに戻ります。しかし、それは悪化しただけです:(ツリーはより遅く、半分の時間で構築され、深いツリーの非同期構築のデバッグは別の探求です...

その後、 process.nextTickの実験を開始し、さまざまなコードをラップしようとしましたが、効果に気付きませんでした。

その結果、私は次のスキームに到達しました：

アクションの最初のリストについては、非同期的にブランチの構築を開始します。
すべてのネストされたブランチについて、ツリーの構築は同期的です。

たくさんのコード

  /*   -  " "     */ function buildActionBranchAsync(myTeam, enemyTeam, activeCharId, wallPositions, cb){ var self = this; /*   ,   */ var actionList = self.createActionList(myTeam, enemyTeam, activeCharId, wallPositions); async.eachOf(actionList, function(actionInList, index, cb){ /*        */ process.nextTick(function() { if(actionInList.type != "endTurn" ) { /*       */ actionInList.branch = self.buildActionBranchSync(actionInList.myTeamState, actionInList.enemyTeamState, actionInList.activeCharId, wallPositions); if(actionInList.branch && actionInList.branch[0]) { actionInList.score = actionInList.selfScore + actionInList.branch[0].score; } else { actionInList.score = actionInList.selfScore; } } else { actionInList.score = actionInList.selfScore; } cb(null, null); }); }, function(err, temp){ if(err){ return console.error(err); } actionList.sort(function (a, b) { if (a.score <= b.score) { return 1; } else if (a.score > b.score) { return -1; } }); cb(actionList); }) }

このソリューションは、私がレビューしたものの中で最高のものであることが判明しましたが、依然としてブロックされています。ソケットは移動の長い「熟考」で落下し続けます。ツリーを構築し、 process.nextTickを使用するアーキテクチャの変更に関するアイデアをお持ちの方がいれば、喜んでお手伝いします）

2）メモリを解放する

別の問題は、ボットが長い間考えていたため、 JavaScriptヒープの種類のエラーがメモリ不足になることでした。デシジョンツリーがデフォルトの512 MBのメモリスペースに収まらないため、RAMのオーバーフローがあることは明らかです。もちろん、割り当てられたスペースを拡張することもできますが、これはまだ間違っています。最小限に抑えるようにしてください。私のアーキテクチャの弱点は、ツリーが構築されたときのすべての戦闘状況の状態を保存しなければならなかったことです。また、オブジェクトはシミュレーションの前に完全にコピーされるため、メモリは単に詰まっています。私が最初にしたことは、ツリーを構築する前にオブジェクトの重量を減らすことでした。そのため、たとえば、シミュレーションにまったく関係しないCharacterオブジェクトのプロパティがいくつかあります。インベントリ、ログへのメッセージの配列、再生するサウンドの配列、キャラクターのフレームの色などです。これで、ツリーを構築する前に、キャラクターオブジェクトが次のように解放されます。

たくさんのコード

  function lightWeightTeamBeforeSimulation(team){ delete team.teamName; delete team.lead; for(var i = 0; i < team.characters.length; i++){ var char = team.characters[i]; delete char.battleTextBuffer; delete char.logBuffer; delete char.soundBuffer; delete char.battleColor; delete char.charName; delete char.gender; delete char.isBot; delete char.portrait; delete char.race; delete char.role; delete char.state; delete char.calcParamsByPoint; delete char.calcItem; delete char.updateMods; delete char.removeRandomBuff; delete char.removeRandomDebuff; delete char.removeAllDebuffs; delete char.removeRandomDOT; delete char.stealRandomBuff; delete char.afterDealingDamage; delete char.afterDamageTaken; delete char.afterMiss; delete char.removeImmobilization; delete char.afterCast; delete char.getSize; for(var j = 0; j < char.abilities.length; j++){ var ability = char.abilities[j]; delete ability.cast; delete ability.icon; delete ability.role; } for(j = 0; j < char.buffs.length; j++){ var effect = char.buffs[j]; delete effect.icon; delete effect.role; delete effect.apply; } for(j = 0; j < char.debuffs.length; j++){ var effect = char.debuffs[j]; delete effect.icon; delete effect.role; delete effect.apply; } } return team; }

したがって、各文字のオブジェクトのサイズを40％以上削減することができました。しかし、これでも私を完全な記憶から救いませんでした。この問題について同僚と話し合ったところ、ブランチをメモリに保存してもアクションのリストが返された後は意味がないことがわかりました。結局のところ、私たちは最も成功したソリューションにのみ興味があり、残りは不要です。これで、結果を返した直後に、ブランチが削除されます：

たくさんのコード

  function buildActionBranchSync: function(myTeam, enemyTeam, activeCharId, wallPositions){ var actionList = this.createActionList(myTeam, enemyTeam, activeCharId, wallPositions); for(var z = 0; z < actionList.length; z++){ /* ... */ actionList[z].branch = this.buildActionBranchSync(actionList[z].myTeamState, actionList[z].enemyTeamState, actionList[z].activeCharId, wallPositions); actionList[z].score = actionList[z].selfScore + actionList[z].branch[0].score; delete actionList[z].branch; /*     */ /* ... */ } /* sort actionList */ return actionList; }

その後、メモリオーバーフローを永遠に忘れていました。

3）アクションのリストを短縮する

以前のすべての最適化にもかかわらず、移動について考えることはまだ約30秒かかりました:(次のステップは、状況に応じて使用の許容性を説明する各能力に追加のusageLogic関数を追加することでした 。この機能を含むアクションのリストを作成する前に、次のテストを実行します。

  usageLogic: function(target) { /*     60% */ return target.curHealth < target.maxHealth * 0.6; }

したがって、ボットはよりスマートになり、選択するアクションの数が大幅に削減されました。それにもかかわらず、多数のアクションを生成する1つの能力がありました。

「スピードオブライト」機能を使用すると、キャラクターを周囲6セルの半径内の位置に加熱できます。

最悪の場合、この機能によって35のアクションが生成されることがわかります。ここでの決定木は非常に広いです。ソリューションは、能力のusageLogic関数の実装を終えた後、自然に生まれました。実際、移動に失敗したポイントを除外することもできます。位置の重みとcalculatePositionWeight関数についてはすでに述べました。したがって、移動可能なセルのリストを作成する段階で、それぞれの収益性を評価し、最も弱いポジションを除外できます。

たくさんのコード

  /* ... */ var bestMovePoints = []; /*    ,    */ var movePoints = arenaService.findMovePoints(myTeam, enemyTeam, activeChar, false, wallPositions); /*          */ for(var i = 0; i < movePoints.length; i++){ var weights = arenaService.calculatePositionWeight(movePoints[i], activeChar, myTeam.characters, enemyTeam.characters, arenaService.getOptimalRange(activeChar), wallPositions); /*       (weights[0])  ,        (weights[1]) */ bestMovePoints.push({ point: movePoints[i], weightScore: weights[0] * 6 + weights[1] * 4 }) } /*      */ bestMovePoints.sort(function (a, b) { if (a.weightScore <= b.weightScore) { return 1; } else if (a.weightScore > b.weightScore) { return -1; } }); /*    3  */ bestMovePoints = bestMovePoints.slice(0, 3); for(j = 0; j < bestMovePoints.length; j++){ /*  */ }

私はこのアプローチを、通常の動きとキャラクターを動かす能力の両方に適用しました（ 「光の速度」 ）。

4）思考の閾値

この最適化を行っても、審議が遅れる場合があります。

「停止したくない」能力は、850ユニットのエネルギーを回復します。

この能力を使用する可能性は、思考時間を2倍、さらには3倍に増やします。何らかのアクションの後、エネルギーをほぼ完全に回復し、コースを改めて考えることができます。

このような「長い」審議を避けるために、ツリーを構築するためのしきい値時間を導入しました。現時点では3秒です。アクションのオプションを持つ新しいブランチを構築する前に、今回チェックします。それを超えた場合、さらにツリーを構築することはできず、ボットはすでにカウントしたものを考慮してアクションを選択するだけです。したがって、さまざまなプラットフォームでのパフォーマンスの問題も解決しました。ローカルマシンでツリーを構築する速度は1秒あたり約2000アクションであり、無料サブスクリプションのHerokuクラウドでは1秒あたり約700アクションです。プラットフォームが提供するコンピューティングリソースが多いほど、ボットは割り当てられた3秒で解決できるアクションが増えます。しかし、たとえできなくても、ボットはまだ動きを続けるため、プレイヤーにとっては気付かれずに残るでしょう。

おわりに

そのため、決定木を使用して問題を解決することができました。このアプローチの長所と短所を理解してみましょう。

利点：

ボットの「思考の流れ」全体を追跡し、エラーを見つけることができます
各能力、効果、状況評価ポイントを微調整することで、戦闘のバランスを制御できます
トレーニングサンプルのデータを収集したり、データベースにサンプルを保存したりする必要はありません。
データベースにニューラルネットワークモデルを保存する必要はありません
AIをそれらに適応させる必要なく、新しい能力を簡単に追加できます。

欠点：

各アクションについて、ツリーをゼロから構築する必要がありますが、これはサーバーリソースにとって非常に高価です
ボットは訓練されていません。彼らは同じ間違いを何度も繰り返します。
内部の意思決定アルゴリズムをデバッグおよび構成する必要があります

もちろん、学習不足は私を非常に怒らせます。ただし、ニューラルネットワークと組み合わせてデシジョンツリーを使用してAIを改善するアイデアがあります。現時点では、状況を評価する機能には、ゲーム状況の特定のプロパティのポイント数を決定する一定の値があります。たとえば、プレーヤーのヘルスユニット数のスコアポイント：

  score += activeChar.curHealth / activeChar.maxHealth * 110;

率直に言って、110という数字は天井から来たもので、他の定数とほぼバランスが取れていますが、それを変更してボットの動作がどのように変化するかを確認することを誰も禁じていません。意思決定機能からすべての定数を収集すると、その「ゲノム」を取得します。その後、さまざまな「ゲノム」で一連の実験を行い、ほとんどの戦闘で勝利するものを見つけるか、実際のプレイヤーとの戦闘結果に基づいて最適な「ゲノム」の選択を自動化することもできます。しかし、それはまったく異なる話になります。

これらの記事をマスターしていただき、ありがとうございます。私の経験が、プロジェクトに人工知能を持ち込みたい初心者のゲーム開発者に役立つことを願っています。

PS . , . , .

Node.jsでのターンベースゲームのAI開発（パート2）

決定木

状況の評価

アクションシミュレーション

最適化

1）フローリリース

2）メモリを解放する

3）アクションのリストを短縮する

4）思考の閾値

おわりに

More articles: