Stima dei costi in un sistema GOAP


9

Attualmente sto sviluppando un sistema GOAP in Java. Una spiegazione di GOAP è disponibile all'indirizzo http://web.media.mit.edu/~jorkin/goap.html . In sostanza, sta usando A * per tracciare tra le Azioni che mutano lo stato mondiale.

Per fornire una buona opportunità per tutte le azioni e gli obiettivi da eseguire, sto usando una funzione euristica per stimare il costo di fare qualcosa. Qual è il modo migliore per stimare questo costo in modo che sia comparabile a tutti gli altri costi?

Ad esempio, stimando il costo di scappare da un nemico invece di attaccarlo - come dovrebbe essere calcolato il costo per essere comparabile?


Stiamo usando GOAP per il nostro gioco RTS e pubblicheremo presto altri tutorial come questo: indiedb.com/games/attack-of-the-gelatinous-blob/news/…
Erlend,

Risposte:


4

Per rendere comparabili tutti i costi, è necessario utilizzare la stessa euristica per tutte le azioni. Ad esempio, tutte le azioni hanno un elenco di risultati potenziali e tutti i risultati hanno un certo valore per l'entità.

Ad esempio, c'è una pozza profonda con acqua e l'entità ha sete. Quindi guardiamo un'azione che il pool ha a disposizione per soddisfare tale esigenza:

Innanzitutto le priorità delle entità associate a questi luoghi, potresti chiamarli modificatori. Alcuni di questi cambieranno nel tempo e dipenderanno dall'entità. Ad esempio una formica potrebbe preoccuparsi meno di rimanere in vita e di più riguardo alle preoccupazioni delle colonie. O se un'entità è rimasta per un po 'senza bere, la priorità della sete soddisfacente può prevalere sugli altri.

Priorità delle entità :

Soddisfa la sete: 40
Resta asciutto: 10
Resta vivo: 100

Quindi cosa rappresenta la posizione:

Località : Pool
Azione : Raccogliere acqua
* Risultati potenziali: * :
Soddisfare la sete - (-95) Bagnarsi
- 10
Annegare - 1

Quindi potremmo calcolare quel costo di azione a: (40 * -95) + (10 * 10) + (100 * 1) = -3600

Dove la raccolta dell'acqua da un fiume in tempesta potrebbe apparire come:

Ubicazione : Fiume in tempesta
Azione : Raccogliere acqua
* Risultati potenziali: * :
Sete soddisfatta - (-95) Bagnati
- 90
Annegati - 60

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

Quindi è chiaramente una scelta migliore per raccogliere l'acqua dalla piscina. Forse se il fiume infuriato fosse l'unica scelta che l'entità aspetterebbe fino a quando la sua priorità di sete soddisfacente diventasse molto alta prima di provare il fiume.

Potresti voler semplificare le cose all'inizio. Basta avere alcune variabili che possono essere applicate in modo più globale. Come rimanere vivi, soddisfare i bisogni. Nel tuo esempio di combattimento o di volo, dovresti assegnare a ciascuna entità un punteggio di combattimento, in modo che possano effettivamente posizionarsi contro l'altra entità ai fini del punteggio.


Molte grazie! Predicare su tutti i potenziali risultati sembra un'idea migliore di quella che avevo.
fullwall l'

0

Lo so, lo so, è passato parecchio tempo.

Infatti, in GOAP come implementato nel 2005 da Jeff Orkin in FEAR (e riutilizzato nei sequel, estensione e ... Shadow Of Mordor), le azioni hanno costi fissi, che vanno da 0,5 a 8. In generale, il costo dell'attacco è molto più costoso del costo di difesa. Questi costi sono accessibili nel database di gioco di Free FEAR SDK (2008); Eccoli:


{{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,}, {AttackMelee, 3, 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}, GostTarget , 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}, LongRecoil {LookAtDisturbance, 1.5}, {LookAtDisturbanceFromView, 3}, {LopeToTargetUncloaked, 1}, {MountNodeUncloaked, 1}, {MountVehicle, 1}, {ReactToDanger, 1}, {Reload, 5}, {ReloadCovered, 1}, , 5}, {ShortRecoilMelee, 4}, {Stunned, 1}, {SuppressionFire, 2}, {SuppressionFireFromCover, 1}, {SurveyArea, 1},{TraverseBlockedDoor, 1}, {TraverseLink, 2}, {TraverseLinkUncloaked, 1}, {Uncover, 1}, {UseSmartObjectNode, 3}, {UseSmartObjectNodeMounted, 1}}


Ma non è il caso di tutte le implementazioni GOAP e, ad esempio, i Tomb Raiders hanno costi variabili (ad es. La distanza per un'azione Goto).

Le azioni hanno anche delle condizioni preliminari e alcune azioni devono essere giocate nonostante l'architettura GOAP (ad esempio, giocare un'animazione "sbalordita" in reazione che diminuisce rapidamente la salute - nonostante l'obiettivo "Uccidi il nemico" e il piano che GOAP ritorna per soddisfarlo). Nel tuo esempio, ovvero scappare contro attaccare, il livello di salute può essere un prerequisito (e non è necessario avere costi variabili).

Oppure una funzione membro Check_Costs () viene eseguita prima di ogni altra cosa, in base alle priorità di Michael, e restituisce il costo dinamico.

Ora, tieni presente che in Shadow Of Mordor gli sviluppatori del gioco hanno provato a giocare con i costi delle azioni per influenzare ciò che sarebbe stato eseguito sullo schermo. Si scopre che non è così facile e nemmeno l'azione a buon mercato non si presenta così spesso: l'IA in un gioco supporta il giocatore; se il giocatore non fa ciò che è previsto, l'IA lo supporterà e ... ciò che apparirà sullo schermo non sarà quello che il design del gioco si aspettava.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.