Estimation des coûts dans un système GOAP

Je développe actuellement un système GOAP en Java. Une explication de GOAP peut être trouvée à http://web.media.mit.edu/~jorkin/goap.html . Essentiellement, il utilise A * pour tracer entre des actions qui mutent l'état du monde.

Pour fournir une chance équitable à toutes les actions et tous les objectifs de s'exécuter, j'utilise une fonction heuristique pour estimer le coût de quelque chose. Quelle est la meilleure façon d'estimer ce coût pour qu'il soit comparable à tous les autres coûts?

Par exemple, estimer le coût de la fuite d'un ennemi par rapport à son attaque - comment le coût devrait-il être calculé pour être comparable?

Pour rendre tous les coûts comparables, il vous suffit d'utiliser la même heuristique pour toutes les actions. Par exemple, toutes les actions ont une liste de résultats potentiels et tous les résultats ont une certaine valeur pour l'entité.

Par exemple, il y a une piscine profonde avec de l'eau et l'entité a soif. Nous examinons donc une action dont dispose le pool pour répondre à ce besoin:

D'abord les priorités d'entité associées à ces endroits, vous pouvez les appeler les modificateurs. Certains d'entre eux changeront avec le temps et dépendront de l'entité. Par exemple, une fourmi pourrait se soucier moins de rester en vie et davantage des préoccupations de la colonie. Ou si une entité est restée un certain temps sans boire, la priorité Satisfaire la soif peut l'emporter sur les autres.

Priorités des entités :

Satisfaire la soif: 40
Rester au sec: 10
Rester en vie: 100

Ensuite, ce que l'emplacement représente:

Lieu : piscine
Action : recueillir de l'eau
* résultats potentiels: * :
satisfaire la soif - (-95) se
mouiller - 10 se
noyer - 1

Nous pourrions donc calculer ce coût d'action à: (40 * -95) + (10 * 10) + (100 * 1) = -3600

À quoi pourrait ressembler la collecte de l'eau d'une rivière en furie:

Lieu : Rivière déchaînée
Action : Récupérer de l'eau
* Résultats potentiels: * :
Satisfaire la soif - (-95)
Se mouiller - 90 Se
noyer - 60

(40 * -95) + (10 * 90) + (100 * 60) = 3100

C'est donc clairement un meilleur choix pour collecter l'eau de la piscine. Peut-être que si la rivière déchaînée était le seul choix, l'entité attendrait que sa priorité de satisfaire sa soif soit très élevée avant d'essayer la rivière.

Vous voudrez peut-être simplifier les choses au début. Ayez juste quelques variables qui peuvent s'appliquer plus globalement. Comme rester en vie, satisfaire les besoins. Dans votre exemple de combat ou de vol, vous devez attribuer une note de combat à chaque entité, afin qu'elle puisse se classer efficacement contre l'autre entité à des fins de score.

Je sais, je sais, ça fait longtemps.

En effet, dans GOAP tel qu'implémenté en 2005 par Jeff Orkin dans FEAR (et réutilisé dans les suites, l'extension et ... Shadow Of Mordor), les actions ont des coûts fixes, variant de 0,5 à 8. En général, le coût de l'attaque est beaucoup plus cher que le coût de la défense. Ces coûts sont accessibles dans la base de données de jeu du SDK FEAR gratuit (2008); Les voici:

{{Animate, 1}, {Attack, 6}, {AttackBurstLimited, 5}, {AttackCrouch, 5}, {AttackFromAmbush, 4}, {AttackFromArmored, 4}, {AttackFromArmoredBounded, 4}, {AttackFromCover, 4}, { AttackFromVehicle, 1}, {AttackFromView, 4.5}, {AttackGrenadeFromCover, 2}, {AttackLunge3D, 1}, {AttackLungeMelee, 1}, {AttackLungeSuicide, 1}, {AttackLungeUncloaked, 1}, {AttackMelee, 3}, {Attaque 1}, {AttackMeleeUncloaked, 3}, {AttackReady, 7}, {AttackTurret, 6}, {AttackTurretCeiling, 6}, {BlindFireFromCover, 2}, {Charge, 1}, {DeathOnVehicle, 1}, {DismountNodeUncloaked, 1} , {DismountVehicle, 1}, {DodgeCovered, 1}, {DodgeOnVehicle, 1}, {DodgeRoll, 2}, {DodgeRollParanoid, 2}, {DodgeShuffle, 3}, {DrawWeapon, 1}, {EscapeDanger, 0,5}, { FaceNode, 1}, {FlushOutWithGrenade, 3}, {Follow, 3}, {FollowHeavyArmor, 2}, {FollowPlayer, 2}, {FollowPlayerFidget, 1.8},{FollowWaitAtNode, 4}, {GetOutOfTheWay, 1}, {GotoNode, 1}, {GotoNode3D, 1}, {GotoNodeDirect, 1}, {GotoNodeOfType, 1}, {GotoTarget, 4}, {GotoTarget3D, 4}, {GotoTargetLost , 8}, {GotoValidPosition, 1}, {HolsterWeapon, 1}, {Idle, 2}, {IdleFidget, 1}, {IdleOnVehicle, 1}, {IdleTurret, 2}, {InspectDisturbance, 2}, {InstantDeath, 1 }, {InstantDeathKnockDown, 1}, {KnockDownBullet, 2}, {KnockDownExplosive, 2}, {KnockDownMelee, 2}, {LongRecoilBullet, 3}, {LongRecoilExplosive, 3}, {LongRecoilHelmetPiercing, 3}, {LongRecoilMel, {LookAtDisturbance, 1.5}, {LookAtDisturbanceFromView, 3}, {LopeToTargetUncloaked, 1}, {MountNodeUncloaked, 1}, {MountVehicle, 1}, {ReactToDanger, 1}, {Reload, 5}, {ReloadCovered, 1}, {ReloadC , 5}, {ShortRecoilMelee, 4}, {Stunned, 1}, {SuppressionFire, 2}, {SuppressionFireFromCover, 1}, {SurveyArea, 1},{TraverseBlockedDoor, 1}, {TraverseLink, 2}, {TraverseLinkUncloaked, 1}, {Uncover, 1}, {UseSmartObjectNode, 3}, {UseSmartObjectNodeMounted, 1}}

Mais ce n'est pas le cas dans toutes les implémentations GOAP et, par exemple, les Tomb Raiders ont des coûts variables (par exemple la distance pour une action Goto).

Les actions ont également des conditions préalables et certaines actions doivent être jouées malgré l'architecture GOAP (par exemple, jouer une animation "stupéfaite" en réaction diminuant rapidement la santé - malgré l'objectif "Kill Enemy" et le plan que GOAP retourne pour satisfaire cet objectif). Dans votre exemple, à savoir fuir ou attaquer, le niveau de santé peut être une condition préalable (et pas besoin d'avoir des coûts variables).

Ou une fonction membre Check_Costs () est exécutée avant toute autre chose, en fonction des priorités de Michael, et renvoie le coût dynamique.

Maintenant, veuillez noter que dans Shadow Of Mordor, les développeurs de jeux ont essayé de jouer avec les coûts des actions afin d'influencer ce qui serait exécuté à l'écran. Il s'avère que ce n'est pas si facile et même une action bon marché n'apparaît pas si souvent: l'IA dans un jeu prend en charge le joueur; si le joueur ne fait pas ce qui est attendu, l'IA le supportera juste et ... ce qui apparaîtra à l'écran ne sera pas ce que le design du jeu attend.