Ik kaam oer wat nijsgjirrich materiaal oer keunstmjittige yntelliginsje yn spultsjes. Mei in útlis fan basis dingen oer AI mei ienfâldige foarbylden, en binnen binne d'r in protte nuttige ark en metoaden foar har handige ûntwikkeling en ûntwerp. Hoe, wêr en wannear se te brûken is der ek.
De measte fan 'e foarbylden binne skreaun yn pseudokoade, dus gjin avansearre programmearring kennis is nedich. Under de knip sitte 35 tekstblêden mei plaatsjes en gifs, dus meitsje jo klear.
UPD. Ik ferûntskuldigje my, mar ik haw al myn eigen oersetting fan dit artikel op Habré dien . Jo kinne syn ferzje lêze , mar om ien of oare reden gie it artikel my foarby (ik brûkte it sykjen, mar der gie wat mis). En om't ik skriuw op in blog wijd oan spielûntwikkeling, besleat ik myn ferzje fan 'e oersetting te litten foar abonnees (guon punten binne oars opmakke, guon waarden bewust weglitten op advys fan 'e ûntwikkelders).
Wat is AI?
Game AI rjochtet him op hokker aksjes in objekt moat útfiere basearre op de betingsten wêryn it leit. Dit wurdt ornaris oantsjutten as "yntelligent agent" behear, wêrby't in agint in spilerkarakter, in auto, in bot, of soms wat abstrakter is: in hiele groep entiteiten of sels in beskaving. Yn elk gefal is it in ding dat syn omjouwing moat sjen, besluten nimme op basis dêrfan, en hannelje yn oerienstimming mei harren. Dit wurdt de Sense/Think/Act-syklus neamd:
- Sense: De agint fynt of ûntfangt ynformaasje oer dingen yn syn omjouwing dy't syn gedrach kinne beynfloedzje (bedrigingen yn 'e buert, items om te sammeljen, nijsgjirrige plakken om te ferkennen).
- Tink: de agint beslút hoe't er reagearret (beskôget oft it feilich genôch is om items te sammeljen of oft hy earst fjochtsje/ferbergje moat).
- Akte: de agint fiert aksjes út om it foarige beslút út te fieren (begjint te bewegen nei de fijân as objekt).
- ... no is de situaasje feroare troch de aksjes fan 'e personaazjes, sadat de syklus werhellet mei nije gegevens.
AI hat de neiging om te fokusjen op it Sense-diel fan 'e loop. Bygelyks, autonome auto's nimme foto's fan 'e dyk, kombinearje se mei radar- en lidargegevens en ynterpretearje se. Dit wurdt typysk dien troch masine learen, dy't ynkommende gegevens ferwurket en betsjutting jout, semantyske ynformaasje ekstrahearje lykas "d'r is in oare auto 20 yards foar jo." Dit binne de saneamde klassifikaasjeproblemen.
Spultsjes hawwe gjin kompleks systeem nedich om ynformaasje te ekstrahearjen, om't de measte gegevens der al in yntegraal diel fan binne. D'r hoege gjin algoritmen foar ôfbyldingsherkenning út te fieren om te bepalen as d'r in fijân foarút is - it spultsje wit en fiert de ynformaasje al direkt yn it beslútfoarmingsproses. Dêrom is it Sense-diel fan 'e syklus faak folle ienfâldiger as it Think and Act-diel.
Beheinings fan Game AI
AI hat in oantal beheiningen dy't moatte wurde observearre:
- AI hoecht net fan tefoaren te wurde traind, as wie it in masine-learalgoritme. It hat gjin sin om in neuraal netwurk te skriuwen tidens ûntwikkeling om tsientûzenen spilers te kontrolearjen en de bêste manier te learen om tsjin har te spyljen. Wêrom? Omdat it spul is net útbrocht en der binne gjin spilers.
- It spultsje moat leuk en útdaagjend wêze, sadat aginten de bêste oanpak tsjin minsken net moatte fine.
- Aginten moatte realistysk útsjen, sadat spilers fiele dat se spylje tsjin echte minsken. It AlphaGo-programma prestearre better as minsken, mar de keazen stappen wiene heul fier fan it tradisjonele begryp fan it spul. As it spultsje in minsklike tsjinstanner simulearret, soe dit gefoel net moatte bestean. It algoritme moat feroare wurde sadat it plausibele besluten makket ynstee fan ideale.
- AI moat yn realtime wurkje. Dit betsjut dat it algoritme it CPU-gebrûk net foar lange perioaden kin monopolisearje om besluten te nimmen. Sels 10 millisekonden is te lang, om't de measte spultsjes allinich 16 oant 33 millisekonden nedich binne om alle ferwurking te dwaan en troch te gean nei it folgjende grafyske frame.
- Ideaallik soe op syn minst in diel fan it systeem data-oandreaune wêze moatte, sadat net-coders feroarings kinne meitsje en oanpassingen rapper kinne barre.
Litte wy nei AI-benaderingen sjen dy't de heule Sense/Think/Act-syklus dekke.
Making Basic Besluten
Litte wy begjinne mei it ienfâldichste spultsje - Pong. Doel: ferpleatse de paddle sadat de bal derôf keatst ynstee fan foarby te fleanen. It is as tennis, wêr't jo ferlieze as jo de bal net slaan. Hjir hat de AI in relatyf maklike taak - beslute yn hokker rjochting it platfoarm ferpleatse sil.
Betingsten útspraken
Foar de AI yn Pong is de meast foar de hân lizzende oplossing om altyd te besykjen it platfoarm ûnder de bal te pleatsen.
In ienfâldich algoritme foar dit, skreaun yn pseudokoade:
elk frame / update wylst it spultsje rint:
as de bal links fan 'e paddle is:
bewege paddle lofts
oars as de bal rjochts fan 'e paddle is:
bewege paddle rjochts
As it platfoarm beweecht mei de snelheid fan 'e bal, dan is dit it ideale algoritme foar de AI yn Pong. D'r is net nedich om neat te komplisearjen as d'r net safolle gegevens en mooglike aksjes binne foar de agint.
Dizze oanpak is sa ienfâldich dat de hiele Sense/Think/Act-syklus amper te merken is. Mar it is der:
- It Sense-diel is yn twa as-útspraken. It spultsje wit wêr't de bal is en wêr't it platfoarm is, sadat de AI dernei sjocht foar dy ynformaasje.
- It Think-diel is ek opnommen yn 'e twa if-útspraken. Se befetsje twa oplossingen, dy't yn dit gefal inoar útslute. As gefolch, ien fan trije aksjes wurdt selektearre - ferpleatse it platfoarm nei lofts, ferpleatse it nei rjochts, of dwaan neat as it is al goed gepositioneerd.
- It diel fan 'e Wet is te finen yn' e ferklearrings fan 'e beweging Paddle Left en Move Paddle Right. Ofhinklik fan it spultsje-ûntwerp kinne se it platfoarm direkt of op in spesifike snelheid ferpleatse.
Sokke oanpakken wurde reaktyf neamd - d'r is in ienfâldige set regels (yn dit gefal as útspraken yn 'e koade) dy't reagearje op' e hjoeddeistige steat fan 'e wrâld en aksje nimme.
Beslútbeam
It Pong-foarbyld is eins lykweardich oan in formele AI-konsept neamd in beslútbeam. It algoritme giet der troch om in "blêd" te berikken - in beslút oer hokker aksje te nimmen.
Litte wy in blokdiagram meitsje fan 'e beslútbeam foar it algoritme fan ús platfoarm:
Elk diel fan 'e beam wurdt in knooppunt neamd - AI brûkt grafykteory om sokke struktueren te beskriuwen. D'r binne twa soarten knooppunten:
- Beslútknooppunten: kieze tusken twa alternativen basearre op it testen fan guon betingsten, wêrby't elk alternatyf wurdt fertsjintwurdige as in apart knooppunt.
- Einknooppunten: De aksje om út te fieren dy't it definitive beslút fertsjintwurdiget.
It algoritme begjint fan it earste knooppunt (de "root" fan 'e beam). It makket of in beslút oer hokker bernknooppunt om nei te gean, of it útfiert de aksje opslein yn 'e knoop en giet út.
Wat is it foardiel fan in beslútbeam itselde wurk te dwaan as de if-útspraken yn 'e foarige paragraaf? D'r is hjir in algemien systeem wêrby't elk beslút mar ien betingst hat en twa mooglike útkomsten. Hjirmei kin de ûntwikkelder AI meitsje fan gegevens dy't besluten yn in beam fertsjintwurdigje sûnder it hurd te koade. Litte wy it presintearje yn 'e foarm fan in tabel:
Oan 'e koadekant krije jo in systeem foar it lêzen fan snaren. Meitsje in knooppunt foar elk fan harren, ferbine beslút logika basearre op de twadde kolom, en bern knopen basearre op de tredde en fjirde kolommen. Jo moatte de betingsten en aksjes noch programmearje, mar no sil de struktuer fan it spultsje komplekser wêze. Hjir foegje jo ekstra besluten en aksjes ta, en oanpasse dan de heule AI troch gewoan it tekstbestân fan beamdefinysje te bewurkjen. Dêrnei drage jo it bestân oer nei de spultsje-ûntwerper, dy't it gedrach feroarje kin sûnder it spultsje opnij te kompilearjen of de koade te feroarjen.
Beslútbeammen binne tige nuttich as se automatysk wurde boud út in grutte set foarbylden (bygelyks mei it ID3-algoritme). Dit makket se in effektyf en heechprestearjend ark foar it klassifisearjen fan situaasjes basearre op de krigen gegevens. Wy geane lykwols fierder as in ienfâldich systeem foar aginten om aksjes te selektearjen.
Senario's
Wy analysearren in beslútbeamsysteem dat foarôf oanmakke betingsten en aksjes brûkte. De persoan dy't de AI ûntwerpt kin de beam organisearje lykas hy wol, mar hy moat noch fertrouwe op 'e coder dy't it allegear programmearre. Wat as wy de ûntwerper de ark kinne jaan om har eigen betingsten of aksjes te meitsjen?
Sadat de programmeur net hoecht te skriuwen koade foar de betingsten Is Ball Left Of Paddle en Is Ball Right Of Paddle, hy kin meitsje in systeem wêryn de ûntwerper sil skriuwe betingsten om te kontrolearjen dizze wearden. Dan sille de gegevens fan 'e beslútbeam der sa útsjen:
Dit is yn essinsje itselde as yn 'e earste tabel, mar de oplossingen yn harsels hawwe har eigen koade, in bytsje as it betingsten diel fan in as-ferklearring. Oan de koade kant, dit soe lêze yn de twadde kolom foar it beslút knopen, mar ynstee fan in sykje in spesifike betingst foar in útfiere (Is Ball Left Of Paddle), evaluearret it betingsten útdrukking en jout wier of falsk neffens. Dit wurdt dien mei de Lua of Angelscript skripttaal. Mei help fan harren, in ûntwikkelder kin nimme objekten yn syn spultsje (bal en paddle) en meitsje fariabelen dy't sil wêze beskikber yn it skript (ball.position). Ek is de skripttaal ienfâldiger dan C++. It fereasket gjin folsleine kompilaasjepoadium, dus it is ideaal foar it fluch oanpassen fan spiellogika en lit "non-coders" de nedige funksjes sels meitsje.
Yn it foarbyld hjirboppe wurdt de skripttaal allinich brûkt om de betingsten te evaluearjen, mar it kin ek brûkt wurde foar aksjes. Bygelyks, de gegevens Move Paddle Rjochts kinne wurde in skript statement (ball.position.x += 10). Sadat de aksje ek wurdt definiearre yn it skript, sûnder de needsaak om te programmearjen Move Paddle Right.
Jo kinne noch fierder gean en de hiele beslútbeam yn in skripttaal skriuwe. Dit sil koade wêze yn 'e foarm fan hurdkodearre betingsten, mar se sille lizze yn eksterne skriptbestannen, dat is, se kinne feroare wurde sûnder it hiele programma opnij te kompilearjen. Jo kinne it skriptbestân faaks bewurkje tidens gameplay om ferskate AI-antwurden fluch te testen.
Event Response
De foarbylden hjirboppe binne perfekt foar Pong. Se rinne kontinu de Sense / Think / Act-syklus en hannelje basearre op 'e lêste steat fan' e wrâld. Mar yn mear komplekse spultsjes moatte jo reagearje op yndividuele eveneminten, en net evaluearje alles yn ien kear. Pong is yn dit gefal al in min foarbyld. Litte wy in oare kieze.
Stel jo in skutter foar wêr't de fijannen sûnder beweging binne oant se de spiler ûntdekke, wêrnei't se hannelje ôfhinklik fan har "spesjalisaasje": immen sil rinne om "haast", immen sil fan fierren oanfalle. It is noch altyd in basis reaktyf systeem - "as in spiler wurdt opspoard, doch wat" - mar it kin logysk wurde opdield yn in spiler sjoen evenemint en in reaksje (selektearje in antwurd en útfiere it).
Dit bringt ús werom nei de Sense/Think/Act-syklus. Wy kinne in Sense-diel kodearje dat elk frame sil kontrolearje oft de AI de spiler sjocht. As net, bart der neat, mar as it sjocht, dan wurdt it Player Seen-evenemint makke. De koade sil in aparte seksje hawwe dy't seit "as de Player Seen-evenemint optreedt, do" wêr is it antwurd dat jo nedich binne om de Think and Act-dielen oan te pakken. Sa sille jo reaksjes ynstelle op it Player Seen-evenemint: foar it "rushing" karakter - ChargeAndAttack, en foar de sniper - HideAndSnipe. Dizze relaasjes kinne makke wurde yn it gegevensbestân foar rappe bewurking sûnder opnij te kompilearjen. Skripttaal kin hjir ek brûkt wurde.
It meitsjen fan drege besluten
Hoewol't ienfâldige reaksje systemen binne hiel machtich, der binne in protte situaasjes dêr't se binne net genôch. Soms moatte jo ferskate besluten meitsje op basis fan wat de agint op it stuit docht, mar it is dreech om dit as in betingst foar te stellen. Soms binne der tefolle betingsten om se effektyf te fertsjintwurdigjen yn in beslútbeam of skript. Soms moatte jo fan tefoaren beoardielje hoe't de situaasje sil feroarje foardat jo beslute oer de folgjende stap. Mear ferfine oanpak binne nedich om dizze problemen op te lossen.
Finite steat masine
Finite state machine of FSM (finite state machine) is in manier om te sizzen dat ús agint op it stuit yn ien fan ferskate mooglike steaten is, en dat it kin oergean fan de iene steat nei de oare. D'r binne in bepaald oantal sokke steaten - dêrom de namme. It bêste foarbyld út it libben is in ferkearsljocht. D'r binne ferskate sekwinsjes fan ljochten op ferskate plakken, mar it prinsipe is itselde - elke steat stiet foar wat (stopje, kuierje, ensfh.). In ferkearsljocht is yn mar ien steat op elts momint, en beweecht fan de iene nei de oare basearre op ienfâldige regels.
It is in ferlykber ferhaal mei NPC's yn spultsjes. Litte wy bygelyks in wacht nimme mei de folgjende steaten:
- Patroljen.
- Oanfallend.
- Flechte.
En dizze betingsten foar it feroarjen fan syn steat:
- As de wachter de fijân sjocht, falt er oan.
- As de wachter oanfalt, mar de fijân net mear sjocht, giet er werom nei patrol.
- As in wachter oanfalt mar slim ferwûne rekket, rint er fuort.
Jo kinne ek if-statements skriuwe mei in guardian state fariabele en ferskate kontrôles: is der in fijân yn 'e buert, wat is it sûnensnivo fan 'e NPC, ensfh. Litte wy noch in pear steaten tafoegje:
- Idleness - tusken patrols.
- Sykjen - as de opmurken fijân is ferdwûn.
- Help fine - as in fijân wurdt opspoard, mar te sterk is om allinich te fjochtsjen.
De kar foar elk fan har is beheind - bygelyks de wacht sil net sykje nei in ferburgen fijân as hy in lege sûnens hat.
D'r is ommers in enoarme list mei "as" , Dat "kin te omslachtich wurde, dus wy moatte in metoade formalisearje dy't ús steaten en oergongen tusken steaten yn gedachten hâlde kinne. Om dit te dwaan, nimme wy rekken mei alle steaten, en ûnder elke steat skriuwe wy yn in list alle oergongen nei oare steaten, tegearre mei de betingsten dy't nedich binne foar har.
Dit is in steatstransysjetabel - in wiidweidige manier om FSM te fertsjintwurdigjen. Litte wy in diagram tekenje en in folslein oersjoch krije fan hoe't NPC-gedrach feroaret.
It diagram wjerspegelet de essinsje fan beslútfoarming foar dizze agint basearre op 'e hjoeddeistige situaasje. Boppedat toant elke pylk in oergong tusken steaten as de betingst njonken it wier is.
Elke update kontrolearje wy de aktuele steat fan 'e agint, sjoch troch de list mei oergongen, en as de betingsten foar de oergong foldien binne, akseptearret it de nije steat. Bygelyks, elk frame kontrolearret oft de 10-sekonde timer is ferrûn, en as dat sa is, dan giet de wacht fan 'e Idling-steat nei patrolling. Op deselde manier kontrolearret de Oanfallende steat de sûnens fan 'e agint - as it leech is, dan giet it yn' e Fluchsteat.
Dit is it behanneljen fan transysjes tusken steaten, mar hoe sit it mei it gedrach ferbûn mei de steaten sels? Yn termen fan it útfieren fan it eigentlike gedrach foar in bepaalde steat, binne d'r typysk twa soarten "haak" wêr't wy aksjes oan 'e FSM tawize:
- Aksjes dy't wy periodyk útfiere foar de hjoeddeistige steat.
- De aksjes dy't wy nimme by de oergong fan de iene steat nei de oare.
Foarbylden foar it earste type. De patrolling steat sil ferpleatse de agint lâns de patrol rûte elk frame. De oanfalle steat sil besykje te begjinnen in oanfal elk frame of oergong nei in steat dêr't dit is mooglik.
Foar it twadde type, beskôgje de oergong "as de fijân sichtber is en de fijân is te sterk, gean dan nei de Fynhelpstatus. De agint moat kieze wêr't te gean foar help en bewarje dizze ynformaasje sadat de Finding Help steat wit wêr't te gean. Sadree't help wurdt fûn, de agint giet werom nei de Oanfallende steat. Op dit punt sil hy de bûnsmaten fertelle oer de bedriging, sadat de NotifyFriendOfThreat-aksje kin foarkomme.
Nochris kinne wy nei dit systeem sjen troch de lens fan 'e Sense/Think/Act-syklus. Sense wurdt belichaamd yn de gegevens brûkt troch de oergong logika. Tink - oergongen beskikber yn elke steat. En Act wurdt útfierd troch aksjes útfierd periodyk binnen in steat of by oergongen tusken steaten.
Soms kin kontinu polling oergongsbetingsten kostber wêze. Bygelyks, as eltse agint fiert komplekse berekkeningen elk frame foar in bepale oft it kin sjen fijannen en begripe oft it kin oergong fan de patrolling ta oanfallen steat, dit sil nimme in soad CPU tiid.
Wichtige feroaringen yn 'e steat fan' e wrâld kinne wurde tocht as eveneminten dy't sille wurde ferwurke as se foarkomme. Yn stee fan dat de FSM de oergongsbetingst kontrolearret "kin myn agent de spiler sjen?" elk frame, kin in apart systeem wurde konfigureare om minder faak te kontrolearjen (bgl. 5 kear per sekonde). En it resultaat is in útjaan Player Seen doe't de kontrôle foarby.
Dit wurdt trochjûn oan de FSM, dy't no moat gean nei it Player Seen-evenemint ûntfongen betingst en dêrop reagearje. It resultearjende gedrach is itselde, útsein in hast ûnmerkbere fertraging foardat jo reagearje. Mar de prestaasjes binne ferbettere as gefolch fan it skieden fan it Sense-diel yn in apart diel fan it programma.
Hierarchyske finite steat masine
It wurkjen mei grutte FSM's is lykwols net altyd handich. As wy wolle útwreidzje de oanfal steat te skieden MeleeAttacking en RangedAttacking, wy sille moatte feroarje de oergongen fan alle oare steaten dy't liede ta de oanfallen steat (hjoeddeistige en takomst).
Jo hawwe wierskynlik opfallen dat yn ús foarbyld in protte dûbele transysjes binne. De measte oergongen yn 'e Idling-steat binne identyk oan transysjes yn' e patrolling-steat. It soe moai wêze om ússels net te werheljen, benammen as wy mear ferlykbere steaten tafoegje. It makket sin om Idling en patrolling te groepearjen ûnder it algemiene label fan "non-combat", wêr't d'r mar ien mienskiplike set fan oergongen is om steaten te bestriden. As wy tinke oan dit label as in steat, dan Idling en patrolling wurde substates. In foarbyld fan it brûken fan in aparte oergongstabel foar in nije non-combat substate:
Haadsteaten:
Out of combat status:
En yn diagramfoarm:
It is itselde systeem, mar mei in nije non-combat steat dy't Idling en patrolling omfettet. Mei elke steat befettet in FSM mei substates (en dizze substates, yn beurt, befetsje harren eigen FSMs - ensafuorthinne sa lang as jo nedich hawwe), wy krije in Hierarchical Finite State Machine of HFSM (hierarchical finite state machine). Troch de non-combat state te groepearjen, snije wy in boskje oerstallige oergongen út. Wy kinne itselde dwaan foar alle nije steaten mei mienskiplike oergongen. Bygelyks, as wy yn 'e takomst de Oanfallende steat útwreidzje nei de MeleeAttacking en MissileAttacking steaten, sille se substaten wêze dy't oergong tusken elkoar basearre op ôfstân nei de fijân en beskikberens fan ammo. As resultaat kinne komplekse gedrach en subgedrachs wurde fertsjintwurdige mei in minimum fan dûbele transysjes.
Gedrachsbeam
Mei HFSM wurde komplekse kombinaasjes fan gedrach makke op in ienfâldige manier. D'r is lykwols in lytse muoite dat beslútfoarming yn 'e foarm fan oergongsregels nau besibbe is mei de hjoeddeistige steat. En yn in protte spultsjes is dit krekt wat nedich is. En soarchfâldich gebrûk fan steat hiërargy kin ferminderjen it oantal oergong werhellings. Mar soms hawwe jo regels nedich dy't wurkje yn hokker steat jo ek binne, of dy't jilde yn hast elke steat. Bygelyks, as de sûnens fan in agint sakket nei 25%, dan wolle jo dat hy fuortrint, nettsjinsteande oft hy yn 'e striid wie, idle, of praat - jo moatte dizze betingst tafoegje oan elke steat. En as jo ûntwerper letter de lege sûnensdrompel feroarje wol fan 25% nei 10%, dan moat dat nochris.
Ideaallik fereasket dizze situaasje in systeem wêryn besluten oer "wat steat te wêzen yn" bûten de steaten sels binne, om allinich op ien plak feroaringen te meitsjen en de oergongsbetingsten net oan te reitsjen. Gedragsbeammen ferskine hjir.
D'r binne ferskate manieren om se út te fieren, mar de essinsje is sawat itselde foar allegear en is fergelykber mei in beslútbeam: it algoritme begjint mei in "root" knooppunt, en de beam befettet knopen dy't besluten as aksjes fertsjintwurdigje. D'r binne lykwols in pear wichtige ferskillen:
- Knooppunten jouwe no ien fan trije wearden werom: slagge (as de taak foltôge is), mislearre (as it net kin wurde begûn), of rint (as it noch rint en der gjin einresultaat is).
- D'r binne gjin beslútknooppunten mear om te kiezen tusken twa alternativen. Ynstee, se binne Decorator knopen, dy't hawwe ien bern node. As se slagje, fiere se har ienige bernknoop út.
- Knooppunten dy't aksjes útfiere, jouwe in Running-wearde werom om de aksjes te fertsjintwurdigjen.
Dizze lytse set knopen kin wurde kombineare om in grut oantal komplekse gedrach te meitsjen. Litte wy ús de HFSM-wacht fan it foarige foarbyld foarstelle as in gedrachsbeam:
Mei dizze struktuer soe d'r gjin dúdlike oergong wêze moatte fan Idling / patrollearjende steaten nei oanfallen of oare steaten. As in fijân sichtber is en de sûnens fan it personaazje leech is, sil de útfiering stopje by de Fleeing-knooppunt, nettsjinsteande hokker knooppunt it earder útfierde - patrollearjen, idling, oanfallen of in oar.
Gedrachsbeammen binne kompleks - d'r binne in protte manieren om se te komponearjen, en it finen fan de juste kombinaasje fan dekorators en gearstalde knopen kin útdaagjend wêze. D'r binne ek fragen oer hoe faak de beam te kontrolearjen - wolle wy elk diel derfan trochgean of allinich as ien fan 'e betingsten feroare is? Hoe bewarje wy steat oangeande knopen - hoe witte wy wannear't wy 10 sekonden Idling west hawwe, of hoe witte wy hokker knopen de lêste kear útfierden, sadat wy de folchoarder korrekt kinne ferwurkje?
Dit is wêrom d'r in protte ymplemintaasjes binne. Bygelyks, guon systemen hawwe ferfongen decorator knopen mei inline decorators. Se beoardielje de beam opnij as de betingsten fan dekoraasje feroarje, helpe by knooppunten en jouwe periodike updates.
Utility-basearre systeem
Guon spultsjes hawwe in protte ferskillende meganika. It is winsklik dat se alle foardielen krije fan ienfâldige en algemiene oergongsregels, mar net needsaaklik yn 'e foarm fan in folsleine beam fan gedrach. Ynstee fan in dúdlike set fan karren as in beam fan mooglike aksjes, is it makliker om alle aksjes te ûndersiikjen en de meast geskikte op it stuit te kiezen.
It Utility-basearre systeem sil hjirmei helpe. Dit is in systeem dêr't de agint hat in ferskaat oan aksjes en kiest hokker te fieren basearre op it relative nut fan elk. Wêr't nut in willekeurige mjitte is fan hoe wichtich of winsklik it is foar de agint om dizze aksje út te fieren.
It berekkene nut fan in aksje basearre op 'e hjoeddeistige steat en omjouwing, de agint kin op elk momint de meast geskikte oare steat kontrolearje en selektearje. Dit is gelyk oan FSM, útsein wêr't transysjes wurde bepaald troch in skatting foar elke potinsjele steat, ynklusyf de hjoeddeiske. Tink derom dat wy de nuttichste aksje kieze om troch te gean (of bliuwe as wy it al foltôge hawwe). Foar mear ferskaat kin dit in lykwichtige mar willekeurige seleksje wêze út in lytse list.
It systeem jout in willekeurige berik fan brûkbere wearden - bygelyks fan 0 (folslein net winsklik) oant 100 (folslein winsklik). Elke aksje hat in oantal parameters dy't ynfloed hawwe op de berekkening fan dizze wearde. Werom nei ús foarbyld fan hoeder:
Transysjes tusken aksjes binne dûbelsinnich - elke steat kin elke oare folgje. Aksjeprioriteiten wurde fûn yn 'e weromjûne nutswearden. As in fijân sichtber is, en dy fijân is sterk, en de sûnens fan it karakter is leech, dan sille sawol Fleeing as FindingHelp hege net-nulwearden werombringe. Yn dit gefal sil FindingHelp altyd heger wêze. Likegoed komme net-bestridingsaktiviteiten nea mear as 50 werom, dus se sille altyd leger wêze as fjochtsjen. Jo moatte dit rekken hâlde by it meitsjen fan aksjes en it berekkenjen fan har nut.
Yn ús foarbyld jouwe de aksjes of in fêste konstante wearde of ien fan twa fêste wearden werom. In mear realistysk systeem soe in skatting werombringe út in trochgeande berik fan wearden. Bygelyks, de flechtaksje jout hegere nutwearden werom as de sûnens fan 'e agint leech is, en de oanfalle aksje jout legere nutwearden werom as de fijân te sterk is. Hjirtroch hat de Flechtaksje foarrang boppe Oanfallen yn elke situaasje dêr't de agint fielt dat er net genôch sûnens hat om de fijân te ferslaan. Hjirmei kinne aksjes wurde prioritearre op basis fan in oantal kritearia, wêrtroch dizze oanpak fleksibeler en fariabeler wurdt as in gedrachsbeam of FSM.
Eltse aksje hat in protte betingsten foar programma berekkening. Se kinne skreaun wurde yn skripttaal of as in searje wiskundige formules. De Sims, dy't de deistige routine fan in personaazje simulearret, foeget in ekstra laach fan berekkening ta - de agint krijt in searje "motivaasjes" dy't ynfloed hawwe op nutwurdearrings. As in karakter honger hat, sille se oer de tiid noch hongeriger wurde, en de nutwearde fan 'e EatFood-aksje sil tanimme oant it karakter it útfiert, wêrtroch it hongernivo ferminderje en de EatFood-wearde op nul werombringt.
It idee om aksjes te selektearjen op basis fan in beoardielingssysteem is frij ienfâldich, dus in Utility-basearre systeem kin brûkt wurde as ûnderdiel fan AI-beslútfoarmingprosessen, ynstee as in folsleine ferfanging foar har. De beslútbeam kin freegje om in nutwurdearring fan twa bernknooppunten en selektearje de hegere. Op deselde manier kin in gedrachsbeam in gearstalde Utility-knooppunt hawwe om it nut fan aksjes te evaluearjen om te besluten hokker bern it útfiert.
Beweging en navigaasje
Yn 'e foarige foarbylden hiene wy in platfoarm dat wy nei links of rjochts ferpleatse, en in wacht dy't patrollearre of oanfallen. Mar hoe krekt behannelje wy agintbeweging oer in perioade fan tiid? Hoe stelle wy snelheid yn, hoe foarkomme wy obstakels en hoe planne wy in rûte as it dreger is om nei in bestimming te kommen dan gewoan yn in rjochte line te bewegen? Litte wy nei dit sjen.
Governance
Yn 'e earste faze sille wy oannimme dat elke agint in snelheidswearde hat, dy't omfettet hoe fluch it beweecht en yn hokker rjochting. It kin mjitten wurde yn meter per sekonde, kilometer per oere, piksels per sekonde, ensfh. As wy de Sense/Think/Act-lus weromkomme, kinne wy ús yntinke dat it Think-diel in snelheid selektearret, en it Act-diel jildt dy snelheid foar de agint. Typysk hawwe spultsjes in fysikasysteem dat dizze taak foar jo docht, de snelheidswearde fan elk objekt leart en it oanpasse. Dêrom kinne jo de AI mei ien taak ferlitte - om te besluten hokker snelheid de agent moat hawwe. As jo witte wêr't de agint moat wêze, dan moatte jo it yn 'e goede rjochting ferpleatse op in fêste snelheid. In heul triviale fergeliking:
winske_travel = bestimming_posysje - agent_posysje
Stel jo in 2D wrâld foar. De agint is op punt (-2, -2), de bestimming is earne yn it noardeasten op punt (30, 20), en it fereaske paad foar de agint om dêr te kommen is (32, 22). Litte wy sizze dat dizze posysjes wurde mjitten yn meter - as wy de snelheid fan 'e agent nimme om 5 meter per sekonde te wêzen, dan sille wy ús ferpleatsvektor skaalje en in snelheid krije fan likernôch (4.12, 2.83). Mei dizze parameters soe de agint yn hast 8 sekonden op syn bestimming komme.
Jo kinne de wearden op elk momint opnij berekkenje. As de agent healwei it doel wie, soe de beweging de helte fan 'e lingte wêze, mar om't de maksimale snelheid fan 'e agint 5 m / s is (wy hawwe dit hjirboppe besletten), sil de snelheid itselde wêze. Dit wurket ek foar it ferpleatsen fan doelen, wêrtroch de agint lytse feroaringen kin meitsje as se bewege.
Mar wy wolle mear fariaasje - bygelyks de snelheid stadichoan ferheegje om in karakter te simulearjen dat fan stean nei rinnen giet. Itselde kin dien wurde oan 'e ein foardat jo stopje. Dizze funksjes binne bekend as stjoergedrach, elk fan dat hat spesifike nammen: sykje, flechtsje, oankomst, ensfh It idee is dat fersnellingskrêften tapast wurde kinne op 'e snelheid fan 'e agint, basearre op it fergelykjen fan 'e posysje en hjoeddeistige snelheid fan 'e agint mei de bestimming yn om ferskate metoaden te brûken om nei it doel te bewegen.
Elk gedrach hat in wat oar doel. Seek and Arrival binne manieren om in agint nei in bestimming te ferpleatsen. Hindernisferwidering en skieding oanpasse de beweging fan 'e agint om obstakels op' e wei nei it doel te foarkommen. Ofstimming en gearhing hâlde aginten byinoar yn beweging. Elk oantal ferskillende stjoergedrach kin wurde gearfette om in ienpaadvektor te produsearjen mei alle faktoaren yn rekken brocht. In agint dy't it gedrach fan 'e oankomst, skieding en foarkommen fan obstakels brûkt om fuort te bliuwen fan muorren en oare aginten. Dizze oanpak wurket goed op iepen lokaasjes sûnder ûnnedige details.
Yn dreger omstannichheden wurket de tafoeging fan ferskate gedrach slimmer - in agint kin bygelyks fêst yn in muorre komme troch in konflikt tusken Oankomst en Hindernisferwidering. Dêrom moatte jo opsjes beskôgje dy't komplekser binne dan gewoan alle wearden tafoegje. De manier is dit: ynstee fan it tafoegjen fan de resultaten fan elk gedrach, kinne jo beweging yn ferskate rjochtingen beskôgje en de bêste opsje kieze.
Yn in komplekse omjouwing mei deade eintsjes en karren oer hokker wei te gean, sille wy lykwols wat noch avansearrer nedich wêze.
In manier fine
Stjoergedrach is geweldich foar ienfâldige beweging yn in iepen gebiet (fuotbalfjild of arena) wêr't fan A nei B in rjocht paad is mei allinich lytse omwegen om obstakels. Foar komplekse rûtes hawwe wy paadsykjen nedich, dat is in manier om de wrâld te ferkennen en te besluten oer in rûte der trochhinne.
It ienfâldichste is in roaster oan te passen op elk plein neist de agint en evaluearje hokker fan harren kinne ferpleatse. As ien fan harren in bestimming is, folgje dan de rûte fan elk plein nei it foarige oant jo it begjin berikke. Dit is de rûte. Oars, werhelje it proses mei oare fjilden yn 'e buert oant jo jo bestimming fine of jo fjilden rinne (dit betsjut dat d'r gjin mooglike rûte is). Dit is wat formeel bekend is as Breadth-First Search of BFS (breadth-first search algorithm). By elke stap sjocht er alle kanten út (dus breedte, "breedte"). De sykromte is as in weachfront dy't beweecht oant it de winske lokaasje berikt - de sykromte wreidet by elke stap út oant it einpunt opnommen is, wêrnei't it werom te finen is nei it begjin.
As gefolch krije jo in list mei pleinen wêr't de winske rûte is gearstald. Dit is it paad (dus, paadfinen) - in list mei plakken dy't de agint sil besykje by it folgjen fan de bestimming.
Sjoen dat wy de posysje fan elk plein yn 'e wrâld kenne, kinne wy stjoergedrach brûke om lâns it paad te bewegen - fan knooppunt 1 nei knooppunt 2, dan fan knooppunt 2 nei knooppunt 3, ensfh. De ienfâldichste opsje is om nei it sintrum fan it folgjende plein te gean, mar in noch bettere opsje is om te stopjen yn 'e midden fan' e râne tusken it hjoeddeiske plein en de folgjende. Hjirtroch sil de agint hoeken kinne snije op skerpe bochten.
It BFS-algoritme hat ek neidielen - it ûndersiket safolle kwadraten yn 'e "ferkearde" rjochting as yn 'e "rjochte" rjochting. Dit is wêr't in komplekser algoritme neamd A * (A stjer) komt yn toanielstik. It wurket op deselde manier, mar yn plak fan om buorfjilden blyn te ûndersykjen (dan buorlju fan buorlju, dan buorlju fan buorlju fan buorlju, ensafuorthinne), sammelet it de knopen yn in list en sortearret se sa dat de folgjende ûndersochte node altyd de ien dy't liedt ta de koartste rûte. Knooppunten wurde sortearre op basis fan in heuristyk dy't rekken hâldt mei twa dingen - de "kosten" fan in hypotetyske rûte nei it winske plein (ynklusyf alle reiskosten) en in skatting fan hoe fier dat plein fan 'e bestimming is (mei it sykjen yn' e rjochte rjochting).
Dit foarbyld lit sjen dat de agint ien plein tagelyk ûndersiket, elke kear de neistlizzende kieze dy't it meast tasizzend is. It resultearjende paad is itselde as BFS, mar minder fjilden waarden beskôge yn it proses - dat hat in grutte ynfloed op spultsje prestaasjes.
Beweging sûnder in raster
Mar de measte spultsjes wurde net oanlein op in raster, en it is faak ûnmooglik om te dwaan sûnder in offer realisme. Kompromissen binne nedich. Hokker grutte moatte de fjouwerkanten wêze? Te grut en se kinne lytse gongen of bochten net goed foarstelle, te lyts en der sille tefolle pleinen wêze om nei te sykjen, wat úteinlik in protte tiid sil nimme.
It earste ding om te begripen is dat in mesh ús in grafyk jout fan ferbûne knopen. De A*- en BFS-algoritmen wurkje feitlik op grafiken en meitsje it hielendal net oer ús mesh. Wy kinne knooppunten oeral yn 'e spielwrâld pleatse: salang't d'r in ferbining is tusken twa ferbûne knooppunten, lykas tusken de start- en einpunten en op syn minst ien fan 'e knooppunten, sil it algoritme krekt sa goed wurkje as earder. Dit wurdt faaks in waypointsysteem neamd, om't elk knooppunt in wichtige posysje yn 'e wrâld fertsjintwurdiget dy't diel útmeitsje kin fan in oantal hypotetyske paden.
Foarbyld 1: in knoop yn elk plein. It sykjen begjint fan it knooppunt dêr't de agint leit en einiget by it knooppunt fan it winske plein.
Foarbyld 2: In lytsere set knopen (waypoints). It sykjen begjint op it plein fan 'e agint, giet troch it fereaske oantal knopen, en giet dan troch nei de bestimming.
Dit is in folslein fleksibel en krêftich systeem. Mar wat soarch is nedich by it besluten wêr't en hoe't jo in waypoint pleatse, oars kinne aginten it tichtstbyste punt gewoan net sjen en it paad net kinne begjinne. It soe makliker wêze as wy automatysk waypoints kinne pleatse op basis fan 'e mjitkunde fan' e wrâld.
Dit is wêr't it navigaasjemesh of navmesh (navigaasjemesh) ferskynt. Dit is normaal in 2D-mesh fan trijehoeken dat wurdt oerlein op 'e mjitkunde fan' e wrâld - wêr't de agint ek kin rinne. Elk fan 'e trijehoeken yn' e mesh wurdt in knooppunt yn 'e grafyk, en hat oant trije neistlizzende trijehoeken dy't neistlizzende knooppunten wurde yn' e grafyk.
Dizze foto is in foarbyld fan 'e Unity-motor - it analysearre de geometry yn' e wrâld en makke in navmesh (yn 'e skermôfbylding yn ljochtblau). Eltse polygoan yn in navmesh is in gebiet dêr't in agint kin stean of ferpleatse fan de iene polygoan nei in oare polygoan. Yn dit foarbyld binne de polygonen lytser as de flierren dêr't se lizze - dit wurdt dien om rekken te hâlden mei de grutte fan 'e agint, dy't bûten syn nominale posysje sil útwreidzje.
Wy kinne sykje nei in rûte troch dit mesh, wer mei it A * algoritme. Dit sil ús in hast perfekte rûte yn 'e wrâld jaan, dy't rekken hâldt mei alle mjitkunde en net nedich gjin ûnnedige knopen en it meitsjen fan waypoints.
Pathfinding is in te breed ûnderwerp wêrfoar ien seksje fan in artikel net genôch is. As jo it yn mear detail wolle studearje, dan sil dit helpe .
Planning
Wy hawwe leard mei paadfinen dat it soms net genôch is om gewoan in rjochting te kiezen en te bewegen - wy moatte in rûte kieze en in pear bochten meitsje om nei ús winske bestimming te kommen. Wy kinne dit idee generalisearje: it berikken fan in doel is net allinich de folgjende stap, mar in hiele folchoarder wêr't jo soms ferskate stappen foarút moatte sjen om út te finen wat de earste wêze moat. Dit hjit planning. Pathfinding kin beskôge wurde as ien fan ferskate útwreidingen foar planning. Wat ús Sense/Think/Act-syklus oanbelanget, is dit wêr't it Think-diel meardere Act-dielen foar de takomst plant.
Litte wy nei it foarbyld sjen fan it boerdspul Magic: The Gathering. Wy geane earst mei de folgjende set kaarten yn ús hannen:
- Swamp - Jout 1 swarte mana (lân card).
- Wâld - jout 1 griene mana (lân card).
- Fugitive Wizard - Fereasket 1 blauwe mana om op te roppen.
- Elvish Mystic - Fereasket 1 griene mana om op te roppen.
Wy negearje de oerbleaune trije kaarten om it makliker te meitsjen. Neffens de regels, in spiler is tastien om te spyljen 1 land card per beurt, hy kin "tikke" dizze kaart foar in extract mana út it, en dan cast spreuken (ynklusyf oprop in skepsel) neffens it bedrach fan mana. Yn dizze situaasje, de minsklike spiler wit te spyljen Forest, tap 1 griene mana, en dan ropt Elvish Mystic. Mar hoe kin it spultsje AI dit útfine?
Maklike planning
De triviale oanpak is om elke aksje op syn beurt te besykjen oant d'r gjin geskikte oer binne. Troch nei de kaarten te sjen, sjocht de AI wat Swamp kin spylje. En hy spilet it. Binne d'r oare aksjes oer dizze beurt? It kin gjin Elvish Mystic of Fugitive Wizard oproppe, om't se respektivelik griene en blauwe mana nedich binne om se op te roppen, wylst Swamp allinich swarte mana leveret. En hy kin net mear bosk spylje, want hy hat al Swamp spile. Sa folge it spultsje AI de regels, mar die it min. Kin wurde ferbettere.
Planning kin fine in list mei aksjes dy't bringe it spul nei de winske steat. Lykas elk plein op in paad buorlju hie (by paadsykjen), hat elke aksje yn in plan ek buorlju of opfolgers. Wy kinne nei dizze aksjes en folgjende aksjes sykje oant wy de winske steat berikke.
Yn ús foarbyld is it winske resultaat "as mooglik in skepsel oproppe." Oan it begjin fan 'e beurt sjogge wy mar twa mooglike aksjes tastien troch de regels fan it spul:
1. Spielje Swamp (resultaat: Swamp yn it spul)
2. Bosk spielje (resultaat: Wâld yn it spul)
Eltse aksje nommen kin liede ta fierdere aksjes en slute oaren, wer ôfhinklik fan de regels fan it spul. Imagine wy spile Swamp - dit sil fuortsmite Swamp as de folgjende stap (wy hawwe al spile it), en dit sil ek fuortsmite Forest (omdat neffens de regels kinne jo spylje ien lân card per beurt). Hjirnei foeget de AI ta it krijen fan 1 swarte mana as de folgjende stap, om't d'r gjin oare opsjes binne. As hy trochgiet en Tap the Swamp kiest, sil hy 1 ienheid swart mana ûntfange en sil der neat mei dwaan kinne.
1. Spielje Swamp (resultaat: Swamp yn it spul)
1.1 "Tap" Swamp (resultaat: Swamp "tapped", +1 ienheid fan swarte mana)
Gjin aksjes beskikber - END
2. Bosk spielje (resultaat: Wâld yn it spul)
De list mei aksjes wie koart, wy berikten in deade ein. Wy werhelje it proses foar de folgjende stap. Wy spielje Forest, iepenje de aksje "krije 1 griene mana", dy't op syn beurt de tredde aksje sil iepenje - Elvish Mystic oproppe.
1. Spielje Swamp (resultaat: Swamp yn it spul)
1.1 "Tap" Swamp (resultaat: Swamp "tapped", +1 ienheid fan swarte mana)
Gjin aksjes beskikber - END
2. Bosk spielje (resultaat: Wâld yn it spul)
2.1 "Tap" Wâld (resultaat: Wâld wurdt "tikke", +1 ienheid fan griene mana)
2.1.1 Summon Elvish Mystic (resultaat: Elvish Mystic yn spiel, -1 griene mana)
Gjin aksjes beskikber - END
Uteinlik ûndersochten wy alle mooglike aksjes en fûnen in plan dat in skepsel opropt.
Dit is in tige ferienfâldige foarbyld. It is oan te rieden om it best mooglike plan te kiezen, ynstee fan gewoan elk plan dat oan guon kritearia foldocht. It is oer it algemien mooglik om potinsjele plannen te evaluearjen op basis fan 'e útkomst of algemiene foardiel fan har ymplemintaasje. Jo kinne sels 1 punt skoare foar it spyljen fan in lânkaart en 3 punten foar it oproppen fan in skepsel. Moeras spielje soe in plan fan 1 punt wêze. En bosk spielje → Tap it Wâld → summon Elvish Mystic sil daliks 4 punten jaan.
Dit is hoe't planning wurket yn Magic: The Gathering, mar deselde logika jildt yn oare situaasjes. Bygelyks, in pion ferpleatse om romte te meitsjen foar de biskop om te bewegen yn it skaken. Of nim dekking efter in muorre om sa feilich te sjitten yn XCOM. Yn 't algemien krije jo it idee.
Ferbettere planning
Soms binne d'r te folle potensjele aksjes om elke mooglike opsje te beskôgjen. Werom nei it foarbyld mei Magic: The Gathering: lit ús sizze dat yn it spultsje en yn jo hân d'r ferskate lân- en skepselskaarten binne - it oantal mooglike kombinaasjes fan bewegingen kin yn tsientallen wêze. D'r binne ferskate oplossingen foar it probleem.
De earste metoade is efterút ketting. Yn stee fan alle kombinaasjes te besykjen, is it better om te begjinnen mei it einresultaat en besykje in direkte rûte te finen. Ynstee fan 'e woartel fan' e beam nei in spesifyk blêd, ferpleatse wy yn 'e tsjinoerstelde rjochting - fan it blêd nei de woartel. Dizze metoade is makliker en flugger.
As de fijân hat 1 sûnens, kinne jo fine de "deal 1 of mear skea" plan. Om dit te berikken moatte in oantal betingsten foldien wurde:
1. Skea kin wurde feroarsake troch in spreuk - it moat wêze yn 'e hân.
2. Foar in tsjoen, do moatst mana.
3. Om krijen mana, Jo moatte spylje in lân card.
4. Om spylje in lân card, Jo moatte hawwe it yn dyn hân.
In oare manier is bêste-earste sykjen. Ynstee fan alle paden te besykjen, kieze wy de meast geskikte. Meastentiids jout dizze metoade it optimale plan sûnder ûnnedige sykkosten. A* is in foarm fan bêste earste sykopdracht - troch de meast kânsrike rûtes fan it begjin ôf te ûndersykjen, kin it al it bêste paad fine sûnder oare opsjes te kontrolearjen.
In nijsgjirrige en hieltyd populêrder bêste-earste sykopsje is Monte Carlo Tree Search. Yn stee fan te rieden hokker plannen better binne as oaren by it kiezen fan elke folgjende aksje, kiest it algoritme willekeurige opfolgers by elke stap oant it de ein berikt (doe't it plan resultearre yn oerwinning of nederlaach). It einresultaat wurdt dan brûkt om it gewicht fan eardere opsjes te fergrutsjen of te ferminderjen. Troch dit proses ferskate kearen op in rige te werheljen, jout it algoritme in goede skatting fan wat de bêste folgjende beweging is, sels as de situaasje feroaret (as de fijân aksje nimt om de spiler te bemuoien).
Gjin ferhaal oer planning yn spultsjes soe folslein wêze sûnder doelrjochte aksjeplanning of GOAP (doelrjochte aksjeplanning). Dit is in breed brûkte en besprutsen metoade, mar oars as in pear ûnderskiedende details, is it yn essinsje de metoade foar efterút keatling dy't wy earder praat hawwe. As it doel wie "de spiler ferneatigje" en de spiler is efter dekking, kin it plan wêze: ferneatigje mei in granaat → krije it → smyt it.
D'r binne meastentiids ferskate doelen, elk mei in eigen prioriteit. As it doel mei de heechste prioriteit net foltôge wurde kin (gjin kombinaasje fan aksjes makket in plan "deadzje de spiler" om't de spiler net sichtber is), sil de AI weromfalle nei doelstellingen mei legere prioriteit.
Training en oanpassing
Wy hawwe al sein dat spultsje AI normaal gjin masine learen brûkt, om't it net geskikt is foar it behearen fan aginten yn realtime. Mar dit betsjut net dat jo net wat liene kinne fan dit gebiet. Wy wolle in tsjinstanner yn in skutter dêr't wy wat fan leare kinne. Fyn bygelyks út oer de bêste posysjes op 'e kaart. Of in tsjinstanner yn in fjochtspul dy't de faak brûkte kombinaasjebewegingen fan de spiler blokkearje soe, en him motivearje om oaren te brûken. Dat masine learen kin yn sokke situaasjes frij nuttich wêze.
Statistiken en kânsen
Foardat wy yn komplekse foarbylden komme, litte wy sjen hoe fier wy kinne gean troch in pear ienfâldige mjittingen te nimmen en se te brûken om besluten te nimmen. Bygelyks real-time strategy - hoe kinne wy bepale oft in spiler in oanfal kin lansearje yn 'e earste pear minuten fan it spul en hokker ferdigening om dit te meitsjen? Wy kinne de ûnderfiningen fan in spiler yn it ferline studearje om te begripen wat takomstige reaksjes kinne wêze. Om te begjinnen hawwe wy sokke rauwe gegevens net, mar wy kinne it sammelje - elke kear as de AI tsjin in minske spilet, kin it de tiid fan 'e earste oanfal opnimme. Nei in pear sesjes sille wy in gemiddelde krije fan 'e tiid dy't it sil nimme foar de spiler om yn' e takomst oan te fallen.
D'r is ek in probleem mei gemiddelde wearden: as in spiler 20 kear rûn en 20 kear stadich spile, dan sille de fereaske wearden earne yn 'e midden wêze, en dit sil ús neat nuttich jaan. Ien oplossing is om de ynfiergegevens te beheinen - de lêste 20 stikken kinne rekken holden wurde.
In ferlykbere oanpak wurdt brûkt by it skatten fan de kâns op bepaalde aksjes troch oan te nimmen dat de eardere foarkarren fan de spiler yn 'e takomst itselde sille wêze. As in spiler ús fiif kear oanfalt mei fjoerbal, twa kear mei bliksem, en ien kear mei melee, is it dúdlik dat hy it leafst fjoerbal hat. Lit ús ekstrapolearje en sjoch de kâns op it brûken fan ferskate wapens: fjoerbal = 62,5%, bliksem = 25% en melee = 12,5%. Us spultsje AI moat har tariede om himsels te beskermjen tsjin fjoer.
In oare nijsgjirrige metoade is om de Naive Bayes Classifier te brûken om grutte hoemannichten ynfiergegevens te studearjen en de situaasje te klassifisearjen sadat de AI op 'e winske manier reagearret. Bayesianske klassifikaasjes binne benammen bekend om har gebrûk yn e-post spamfilters. Dêr ûndersykje se de wurden, fergelykje se mei wêr't dy wurden earder ferskynden (yn spam of net), en lûke konklúzjes oer ynkommende e-mails. Wy kinne itselde ding dwaan sels mei minder ynput. Op grûn fan alle nuttige ynformaasje dy't de AI sjocht (lykas hokker fijân ienheden binne makke, of hokker spreuken se brûke, of hokker technologyen se ûndersocht), en it einresultaat (oarloch of frede, rush of ferdigenje, ensfh.) - wy sille it winske AI-gedrach kieze.
Al dizze trainingmetoaden binne genôch, mar it is oan te rieden om se te brûken op basis fan testgegevens. De AI sil leare oan te passen oan 'e ferskate strategyen dy't jo spieltesters hawwe brûkt. AI dy't him nei frijlitting oanpast oan de spiler kin te foarsisber wurde of te lestich om te ferslaan.
Wearde basearre oanpassing
Sjoen de ynhâld fan ús spulwrâld en de regels, kinne wy de set wearden feroarje dy't de beslútfoarming beynfloedzje, ynstee fan gewoan de ynfiergegevens te brûken. Wy dogge dit:
- Lit de AI gegevens sammelje oer de steat fan 'e wrâld en wichtige barrens tidens it spultsje (lykas hjirboppe).
- Litte wy in pear wichtige wearden feroarje op basis fan dizze gegevens.
- Wy implementearje ús besluten basearre op it ferwurkjen of evaluearjen fan dizze wearden.
Bygelyks, in agint hat ferskate keamers om út te kiezen op in earste-persoan shooter-kaart. Elke keamer hat syn eigen wearde, dy't bepaalt hoe winsklik it is om te besykjen. De AI kiest willekeurich nei hokker keamer te gean op basis fan de wearde. De agint ûnthâldt dan yn hokker keamer hy waard fermoarde en ferminderet de wearde (de kâns dat hy dêr weromkomt). Lykas foar de omkearde situaasje - as de agint in protte tsjinstanners ferneatiget, dan nimt de wearde fan 'e keamer ta.
Markov model
Wat as wy de sammele gegevens brûkten om foarsizzingen te meitsjen? As wy ûnthâlde elke keamer wy sjogge in spiler yn foar in bepaalde perioade fan tiid, wy sille foarsizze hokker keamer de spiler kin gean nei. Troch de bewegingen fan de spiler oer keamers (wearden) te folgjen en op te nimmen, kinne wy se foarsizze.
Lit ús nimme trije keamers: read, grien en blau. En ek de beoardielingen dy't wy opnommen hawwe by it besjen fan 'e spultsje sesje:
It oantal observaasjes yn elke keamer is hast gelyk - wy witte noch net wêr't wy in goed plak meitsje moatte foar in hinderlaag. It sammeljen fan statistiken wurdt ek yngewikkeld troch de respawning fan spilers, dy't lykmjittich op 'e kaart ferskine. Mar de gegevens oer de folgjende keamer dy't se ynfiere nei't se op 'e kaart ferskine, binne al brûkber.
It kin sjoen wurde dat de griene keamer past by de spilers - de measte minsken ferhúzje fan 'e reade keamer nei it, 50% fan harren bliuwt dêr fierder. De blauwe keamer, krekt oarsom, is net populêr, hast gjinien giet der nei, en as se dogge, bliuwe se net lang.
Mar de gegevens fertelle ús wat wichtiger - as in spiler yn in blauwe keamer is, sil de folgjende keamer wêryn wy him sjogge read wêze, net grien. Ek al is de griene keamer populêrder as de reade keamer, feroaret de situaasje as de spiler yn 'e blauwe keamer is. De folgjende steat (d.w.s. de keamer wêr't de spiler nei sil gean) hinget ôf fan 'e foarige steat (d.w.s. de keamer wêryn de spiler op it stuit is). Om't wy ôfhinklikens ûndersykje, sille wy krekter foarsizzings meitsje dan as wy gewoan observaasjes ûnôfhinklik telden.
It foarsizzen fan in takomstige steat basearre op gegevens út in eardere steat wurdt in Markov-model neamd, en sokke foarbylden (mei keamers) wurde Markov-keatlingen neamd. Sûnt de patroanen fertsjintwurdigje de kâns op feroarings tusken opienfolgjende steaten, se wurde visueel werjûn as FSMs mei in kâns om elke oergong. Earder brûkten wy FSM om de gedrachssteat te fertsjintwurdigjen wêryn in agint wie, mar dit begryp wreidet út nei elke steat, of it no ferbûn is mei de agint of net. Yn dit gefal fertsjintwurdigje de steaten de keamer dy't de agint beset:
Dit is in ienfâldige manier om de relative kâns op steatswizigingen te fertsjintwurdigjen, wat de AI wat fermogen jout om de folgjende steat te foarsizzen. Jo kinne ferskate stappen foarút ferwachtsje.
As in spiler is yn 'e griene keamer, der is in 50% chance dat hy bliuwt dêr de folgjende kear dat hy wurdt waarnommen. Mar wat binne de kânsen dat hy der ek dêrnei noch is? Net allinnich is der in kâns dat de spiler bleau yn 'e griene keamer nei twa observaasjes, mar der is ek in kâns dat hy ferliet en werom. Hjir is de nije tabel mei rekken hâldend mei de nije gegevens:
It lit sjen dat de kâns om te sjen de spiler yn de griene keamer nei twa observaasjes sil wêze gelyk oan 51% - 21% dat hy sil wêze út de reade keamer, 5% fan harren dat de spiler sil besykje de blauwe keamer tusken harren, en 25% dat de spiler sil net sil ferlitte de griene keamer.
De tabel is gewoan in fisueel ark - de proseduere fereasket allinich it fermannichfâldigjen fan de kânsen by elke stap. Dat betsjut dat jo mei ien warskôging fier yn 'e takomst sjen kinne: wy geane der fan út dat de kâns op it yngean fan in keamer folslein ôfhinget fan 'e hjoeddeistige keamer. Dit wurdt de Markov Property neamd - de takomstige steat hinget allinich ôf fan 'e hjoeddeiske. Mar dit is net XNUMX% krekt. Spilers kinne besluten feroarje ôfhinklik fan oare faktoaren: sûnensnivo of bedrach fan munysje. Om't wy dizze wearden net opnimme, sille ús prognosen minder akkuraat wêze.
N-Grams
Hoe sit it mei it foarbyld fan in fjochtspul en it foarsizzen fan de kombinaasjebewegingen fan de spiler? Itselde! Mar ynstee fan ien steat of evenemint, wy sille ûndersykje de hiele sekwinsjes dy't meitsje in kombinaasje strike.
Ien manier om dit te dwaan is om elke ynfier (lykas Kick, Punch of Block) yn in buffer op te slaan en de hiele buffer as in evenemint te skriuwen. Sa drukt de spiler ferskate kearen op Kick, Kick, Punch om de SuperDeathFist-oanfal te brûken, it AI-systeem bewarret alle ynputen yn in buffer en ûnthâldt de lêste trije brûkt yn elke stap.
(De fette rigels binne as de spiler de SuperDeathFist-oanfal lanseart.)
De AI sil alle opsjes sjen as de spiler Kick selekteart, folge troch in oare Kick, en dan fernimme dat de folgjende ynfier altyd Punch is. Dit sil tastean de agint te foarsizze SuperDeathFist syn combo beweging en blokkearje it as mooglik.
Dizze sekwinsjes fan eveneminten wurde N-grammen neamd, wêrby't N it oantal opsleine eleminten is. Yn it foarige foarbyld wie it in 3-gram (trigram), wat betsjut: de earste twa yngongen wurde brûkt om de tredde te foarsizzen. Dêrtroch, yn in 5-gram, de earste fjouwer yngongen foarsizze de fyfde ensafuorthinne.
De ûntwerper moat de grutte fan N-grams foarsichtich kieze. In lytsere N fereasket minder ûnthâld, mar bewarret ek minder skiednis. Bygelyks, in 2-gram (bigram) sil Kick, Kick of Kick, Punch opnimme, mar sil Kick, Kick, Punch net kinne opslaan, dus de AI sil net reagearje op 'e SuperDeathFist-kombo.
Oan 'e oare kant fereaskje gruttere oantallen mear ûnthâld en de AI sil lestiger wêze om te trenen, om't d'r folle mear mooglike opsjes sille wêze. As jo trije mooglike yngongen hawwe fan Kick, Punch of Block, en wy brûkten in 10-gram, dat soe sawat 60 tûzen ferskillende opsjes wêze.
De bigram model is in ienfâldige Markov ketting - elk ferline steat / aktuele steat pear is in bigram, en jo kinne foarsizze de twadde steat basearre op de earste. De 3-gram en gruttere N-grammen kinne ek tocht wurde as Markov-keatlingen, wêrby't alle eleminten (útsein de lêste yn 'e N-gram) tegearre de earste steat foarmje en it lêste elemint de twadde. It foarbyld fan it fjochtspul toant de kâns op oergong fan 'e Kick and Kick-state nei de Kick and Punch-state. Troch meardere ynfierskiednis yngongen as ien ienheid te behanneljen, transformearje wy yn wêzen de ynfiersekwinsje yn in diel fan 'e heule steat. Dit jout ús de Markov-eigenskip, wêrtroch't wy Markov-keatlingen kinne brûke om de folgjende ynput te foarsizzen en te rieden hokker kombinaasjebeweging folgjende sil wêze.
konklúzje
Wy prate oer de meast foarkommende ark en oanpak yn 'e ûntwikkeling fan keunstmjittige yntelliginsje. Wy hawwe ek sjoen nei de situaasjes wêryn se brûkt wurde moatte en wêr't se benammen nuttich binne.
Dit soe genôch wêze moatte om de basis fan spultsje AI te begripen. Mar, fansels, dit binne net alle metoaden. Minder populêr, mar net minder effektyf binne:
- optimisaasjealgoritmen ynklusyf heuvelklimmen, gradientôfstamming en genetyske algoritmen
- adversarial sykopdracht / skema algoritmen (minimax en alfa-beta snoeien)
- klassifikaasjemetoaden (perceptrons, neurale netwurken en stipe fektormasines)
- systemen foar it ferwurkjen fan aginten 'perception en ûnthâld
- arsjitektoanyske oanpakken foar AI (hybride systemen, subset-arsjitektueren en oare manieren om AI-systemen te oerlizzen)
- animaasje-ark (planning en bewegingskoördinaasje)
- prestaasjefaktoaren (nivo fan detail, elk momint, en algoritmen foar tiidferdieling)
Online boarnen oer it ûnderwerp:
1. GameDev.net hat , lykas ek .
2. befettet in protte presintaasjes en artikels oer in breed skala oan ûnderwerpen yn ferbân mei game AI ûntwikkeling.
3. omfettet ûnderwerpen fan 'e GDC AI Summit, wêrfan in protte fergees beskikber binne.
4. Nuttige materialen binne ek te finen op de webside .
5. Tommy Thompson, AI-ûndersiker en spultsje-ûntwikkelder, makket fideo's op YouTube mei in útlis en stúdzje fan AI yn kommersjele spultsjes.
Boeken oer it ûnderwerp:
1. De Game AI Pro-boeksearje is in samling koarte artikels dy't útlizze hoe't jo spesifike funksjes ymplementearje of hoe't jo spesifike problemen kinne oplosse.
2. AI Game Programming Wisdom rige is de foargonger fan de Game AI Pro rige. It befettet âldere metoaden, mar hast allegear binne ek hjoeddedei relevant.
3. is ien fan de basisteksten foar elkenien dy't it algemiene mêd fan keunstmjittige yntelliginsje begripe wol. Dit is gjin boek oer spultsje-ûntwikkeling - it leart de basis fan AI.
Boarne: www.habr.com