Ինչպես ստեղծել խաղային AI. ուղեցույց սկսնակների համար

Խաղերում արհեստական ​​ինտելեկտի մասին հետաքրքիր նյութերի հանդիպեցի։ AI-ի մասին հիմնական բաների բացատրությամբ՝ օգտագործելով պարզ օրինակներ, և ներսում կան շատ օգտակար գործիքներ և մեթոդներ դրա հարմար մշակման և դիզայնի համար: Ինչպես, որտեղ և երբ դրանք օգտագործել նույնպես կա:

Օրինակների մեծ մասը գրված է կեղծ կոդով, ուստի ծրագրավորման խորացված գիտելիքներ չեն պահանջվում: Կտրվածքի տակ կա 35 թերթ տեքստ՝ նկարներով և գիֆերով, այնպես որ պատրաստվեք։

UPD. Ներողություն եմ խնդրում, բայց ես արդեն արել եմ այս հոդվածի իմ սեփական թարգմանությունը Habré-ում PatientZero. Կարող եք կարդալ նրա տարբերակը այստեղ, բայց ինչ-ինչ պատճառներով հոդվածն անցավ իմ կողքով (ես օգտագործեցի որոնումը, բայց ինչ-որ բան սխալվեց): Եվ քանի որ ես գրում եմ խաղերի մշակմանը նվիրված բլոգում, որոշեցի բաժանորդներին թողնել թարգմանության իմ տարբերակը (որոշ կետեր այլ կերպ են ձևակերպված, որոշները դիտավորյալ բաց են թողնվել՝ մշակողների խորհրդով):

Ի՞նչ է AI-ն:

Խաղի AI-ն կենտրոնանում է այն բանի վրա, թե ինչ գործողություններ պետք է կատարի օբյեկտը՝ ելնելով այն պայմաններից, որոնցում գտնվում է: Սա սովորաբար կոչվում է «խելացի գործակալի» կառավարում, որտեղ գործակալը խաղացողի կերպար է, փոխադրամիջոց, բոտ կամ երբեմն ավելի վերացական բան՝ սուբյեկտների մի ամբողջ խումբ կամ նույնիսկ քաղաքակրթություն: Ամեն դեպքում դա մի բան է, որը պետք է տեսնի իր միջավայրը, որոշումներ կայացնի դրա հիման վրա և գործի դրանց համապատասխան։ Սա կոչվում է Զգայություն / Մտածել / Գործել ցիկլը:

• Զգացմունք. Գործակալը գտնում կամ ստանում է տեղեկատվություն իր միջավայրում գտնվող իրերի մասին, որոնք կարող են ազդել նրա վարքի վրա (մոտակայքում գտնվող սպառնալիքներ, հավաքելու իրեր, ուսումնասիրելու հետաքրքիր վայրեր):
• Մտածեք. Գործակալը որոշում է, թե ինչպես արձագանքել (մտածում է, թե արդյոք բավական անվտանգ է իրերը հավաքելը, թե արդյոք նա պետք է նախ կռվի/թաքնվի):
• Գործողություն. գործակալը գործողություններ է կատարում նախորդ որոշումը կատարելու համար (սկսում է շարժվել դեպի թշնամի կամ օբյեկտ):
• ...հիմա իրավիճակը փոխվել է կերպարների գործողությունների պատճառով, ուստի ցիկլը կրկնվում է նոր տվյալներով։

AI-ն հակված է կենտրոնանալ հանգույցի Sense մասի վրա: Օրինակ, ինքնավար մեքենաները լուսանկարում են ճանապարհը, դրանք համատեղում ռադարների և լիդարների տվյալների հետ և մեկնաբանում դրանք: Սա սովորաբար արվում է մեքենայական ուսուցման միջոցով, որը մշակում է մուտքային տվյալները և դրանց իմաստ է հաղորդում՝ արդյունահանելով իմաստային տեղեկատվություն, օրինակ՝ «ձեզնից 20 յարդ առաջ մեկ այլ մեքենա կա»: Սրանք այսպես կոչված դասակարգման խնդիրներն են։

Տեղեկատվություն կորզելու համար խաղերը բարդ համակարգի կարիք չունեն, քանի որ տվյալների մեծ մասն արդեն դրա անբաժանելի մասն է: Կարիք չկա գործարկել պատկերների ճանաչման ալգորիթմներ՝ որոշելու համար, թե արդյոք առջևում թշնամի կա. խաղն արդեն գիտի և տեղեկատվությունն անմիջապես փոխանցում է որոշումների կայացման գործընթացին: Հետևաբար, ցիկլի զգայական մասը հաճախ շատ ավելի պարզ է, քան «Մտածիր և գործիր» մասը:

Խաղի AI-ի սահմանափակումները

AI-ն ունի մի շարք սահմանափակումներ, որոնք պետք է պահպանվեն.

• AI-ն նախօրոք վերապատրաստվելու կարիք չունի, ասես դա մեքենայական ուսուցման ալգորիթմ լինի։ Զարգացման ընթացքում անիմաստ է գրել նեյրոնային ցանց՝ տասնյակ հազարավոր խաղացողների վերահսկելու և նրանց դեմ խաղալու լավագույն միջոցը սովորելու համար: Ինչո՞ւ։ Քանի որ խաղը չի թողարկվել, և խաղացողներ չկան:
• Խաղը պետք է լինի զվարճալի և դժվար, այնպես որ գործակալները չպետք է գտնեն լավագույն մոտեցումը մարդկանց դեմ:
• Գործակալները պետք է իրատեսական տեսք ունենան, որպեսզի խաղացողները զգան, որ խաղում են իրական մարդկանց դեմ: AlphaGo ծրագիրը գերազանցեց մարդկանց, սակայն ընտրված քայլերը շատ հեռու էին խաղի ավանդական ըմբռնումից: Եթե ​​խաղը նմանակում է մարդու հակառակորդին, ապա այս զգացումը չպետք է գոյություն ունենա: Ալգորիթմը պետք է փոխվի այնպես, որ այն կայացնի ոչ թե իդեալական, այլ իրական որոշումներ:
• AI-ն պետք է աշխատի իրական ժամանակում: Սա նշանակում է, որ ալգորիթմը չի կարող մենաշնորհել պրոցեսորի օգտագործումը երկար ժամանակ որոշումներ կայացնելու համար: Նույնիսկ 10 միլիվայրկյանները չափազանց երկար են, քանի որ խաղերի մեծ մասի համար անհրաժեշտ է ընդամենը 16-ից 33 միլիվայրկյան՝ ամբողջ մշակումը կատարելու և հաջորդ գրաֆիկական շրջանակին անցնելու համար:
• Իդեալում, համակարգի առնվազն մի մասը պետք է հիմնված լինի տվյալների վրա, որպեսզի ոչ կոդավորողները կարողանան փոփոխություններ կատարել, իսկ ճշգրտումները կարող են ավելի արագ տեղի ունենալ:

Դիտարկենք AI մոտեցումները, որոնք ընդգրկում են Զգայություն/Մտածել/Գործել ողջ ցիկլը:

Հիմնական որոշումներ կայացնելը

Սկսենք ամենապարզ խաղից՝ Պոնգից: Նպատակը. տեղափոխեք թիակը այնպես, որ գնդակը ցատկի դրանից, այլ ոչ թե թռչի դրա կողքով: Դա նման է թենիսի, որտեղ պարտվում ես, եթե չխփես գնդակը: Այստեղ AI-ն ունի համեմատաբար հեշտ խնդիր՝ որոշել, թե որ ուղղությամբ տեղափոխել հարթակը:

Պայմանական հայտարարություններ

Պոնգում AI-ի համար ամենաակնհայտ լուծումն է միշտ փորձել հարթակը տեղադրել գնդակի տակ:

Դրա համար պարզ ալգորիթմ, որը գրված է կեղծ կոդով.

յուրաքանչյուր կադր/թարմացում խաղի ընթացքում.
եթե գնդակը գտնվում է թիակի ձախ կողմում.
թիակը տեղափոխել ձախ
հակառակ դեպքում, եթե գնդակը գտնվում է թիակի աջ կողմում.
թիավարել աջ

Եթե ​​հարթակը շարժվում է գնդակի արագությամբ, ապա սա Պոնգում AI-ի համար իդեալական ալգորիթմ է: Պետք չէ որևէ բան բարդացնել, եթե գործակալի համար այդքան շատ տվյալներ և հնարավոր գործողություններ չկան։

Այս մոտեցումն այնքան պարզ է, որ ողջ Զգայություն/Մտածել/Գործել ցիկլը հազիվ նկատելի է: Բայց դա կա.

• Զգայական մասը բաղկացած է երկու եթե հայտարարություններից: Խաղը գիտի, թե որտեղ է գնդակը և որտեղ է հարթակը, ուստի AI-ն փնտրում է նրան այդ տեղեկատվության համար:
• «Մտածիր» հատվածը նույնպես ներառված է երկու if հայտարարությունների մեջ: Դրանք մարմնավորում են երկու լուծում, որոնք այս դեպքում իրարամերժ են։ Արդյունքում ընտրվում է երեք գործողություններից մեկը՝ հարթակը տեղափոխել ձախ, տեղափոխել աջ կամ ոչինչ չանել, եթե այն արդեն ճիշտ է տեղադրված:
• Act մասը գտնվում է Move Paddle ձախ և Move Paddle Right հայտարարություններում: Կախված խաղի դիզայնից՝ նրանք կարող են հարթակը տեղափոխել ակնթարթորեն կամ որոշակի արագությամբ։

Նման մոտեցումները կոչվում են ռեակտիվ. գոյություն ունի կանոնների մի պարզ շարք (այս դեպքում, եթե կանոնագրքի հայտարարությունները), որոնք արձագանքում են աշխարհի ներկա վիճակին և քայլեր ձեռնարկում:

Որոշման ծառ

Պոնգի օրինակը իրականում համարժեք է ֆորմալ AI հայեցակարգին, որը կոչվում է որոշումների ծառ: Ալգորիթմն անցնում է դրա միջով՝ հասնելու «տերևի»՝ որոշում, թե ինչ գործողություն պետք է ձեռնարկել:

Եկեք մեր պլատֆորմի ալգորիթմի համար կազմենք որոշումների ծառի բլոկային դիագրամ.

Ծառի յուրաքանչյուր հատված կոչվում է հանգույց. AI-ն օգտագործում է գրաֆիկների տեսությունը՝ նկարագրելու նման կառույցները: Գոյություն ունեն երկու տեսակի հանգույցներ.

• Որոշման հանգույցներ. ընտրություն երկու այլընտրանքների միջև՝ հիմնված որոշ պայմանի փորձարկման վրա, որտեղ յուրաքանչյուր այլընտրանք ներկայացված է որպես առանձին հանգույց:
• Վերջնական հանգույցներ. կատարվող գործողություն, որը ներկայացնում է վերջնական որոշումը:

Ալգորիթմը սկսվում է առաջին հանգույցից (ծառի «արմատը»): Այն կա՛մ որոշում է կայացնում, թե որ մանկական հանգույց գնալ, կա՛մ կատարում է հանգույցում պահված գործողությունը և դուրս է գալիս:

Ո՞րն է որոշումների ծառի օգուտը, որը կատարում է նույն աշխատանքը, ինչ նախորդ բաժնի if հայտարարությունները: Այստեղ կա ընդհանուր համակարգ, որտեղ յուրաքանչյուր որոշում ունի միայն մեկ պայման և երկու հնարավոր արդյունք: Սա թույլ է տալիս ծրագրավորողին ստեղծել AI տվյալներից, որոնք ներկայացնում են ծառի որոշումները՝ առանց այն կոշտ կոդավորելու: Ներկայացնենք աղյուսակի տեսքով.

Կոդի կողմում դուք կստանաք տողերի ընթերցման համակարգ: Նրանցից յուրաքանչյուրի համար ստեղծեք հանգույց, միացրեք որոշման տրամաբանությունը՝ հիմնված երկրորդ սյունակի վրա, իսկ երեխայի հանգույցները՝ երրորդ և չորրորդ սյունակների վրա: Դուք դեռ պետք է ծրագրավորեք պայմաններն ու գործողությունները, բայց այժմ խաղի կառուցվածքն ավելի բարդ կլինի: Այստեղ դուք ավելացնում եք լրացուցիչ որոշումներ և գործողություններ, այնուհետև հարմարեցնում եք ամբողջ AI-ն՝ պարզապես խմբագրելով ծառի սահմանման տեքստային ֆայլը: Այնուհետև դուք ֆայլը փոխանցում եք խաղի դիզայներին, ով կարող է փոխել վարքագիծը՝ առանց խաղը վերակոմպիլյացիայի կամ ծածկագիրը փոխելու։

Որոշման ծառերը շատ օգտակար են, երբ դրանք ավտոմատ կերպով կառուցվում են օրինակների մեծ շարքից (օրինակ՝ օգտագործելով ID3 ալգորիթմը): Սա դրանք դարձնում է արդյունավետ և բարձր արդյունավետ գործիք՝ ստացված տվյալների հիման վրա իրավիճակները դասակարգելու համար: Այնուամենայնիվ, մենք դուրս ենք գալիս գործակալների կողմից գործողություններ ընտրելու պարզ համակարգի սահմաններից:

Սցենարներ

Մենք վերլուծեցինք որոշումների ծառի համակարգը, որն օգտագործում էր նախապես ստեղծված պայմաններ և գործողություններ: AI նախագծողը կարող է ծառը կազմակերպել այնպես, ինչպես ցանկանում է, բայց նա դեռ պետք է ապավինի կոդավորողին, ով ծրագրավորել է այդ ամենը: Իսկ եթե մենք կարողանայինք դիզայներին տալ գործիքներ՝ ստեղծելու իրենց սեփական պայմանները կամ գործողությունները:

Որպեսզի ծրագրավորողը ստիպված չլինի կոդ գրել Is Ball Left Of Paddle և Is Ball Right Of Paddle պայմանների համար, նա կարող է ստեղծել մի համակարգ, որտեղ դիզայները կգրի պայմաններ՝ ստուգելու այս արժեքները: Այնուհետև որոշման ծառի տվյալները այսպիսի տեսք կունենան.

Սա, ըստ էության, նույնն է, ինչ առաջին աղյուսակում, բայց լուծումներն իրենց ներսում ունեն իրենց սեփական ծածկագիրը, որը մի փոքր նման է if դրույթի պայմանական մասին: Կոդի կողմում սա կարդա երկրորդ սյունակում որոշման հանգույցների համար, բայց կատարման համար հատուկ պայման փնտրելու փոխարեն (Is Ball Left Of Paddle), այն գնահատում է պայմանական արտահայտությունը և համապատասխանաբար վերադարձնում է true կամ false: Սա արվում է օգտագործելով Lua կամ Angelscript սկրիպտային լեզուն: Օգտագործելով դրանք՝ մշակողը կարող է վերցնել իր խաղի առարկաները (գնդակ և թիավարում) և ստեղծել փոփոխականներ, որոնք հասանելի կլինեն սցենարում (ball.position): Բացի այդ, սկրիպտավորման լեզուն ավելի պարզ է, քան C++-ը: Այն չի պահանջում ամբողջական կազմման փուլ, ուստի այն իդեալական է խաղի տրամաբանությունը արագ կարգավորելու համար և թույլ է տալիս «ոչ կոդավորողներին» ինքնուրույն ստեղծել անհրաժեշտ գործառույթները:

Վերևի օրինակում սցենարի լեզուն օգտագործվում է միայն պայմանական արտահայտությունը գնահատելու համար, բայց այն կարող է օգտագործվել նաև գործողությունների համար: Օրինակ, Move Paddle Right տվյալները կարող են դառնալ սցենարի հայտարարություն (ball.position.x += 10): Որպեսզի գործողությունը նույնպես սահմանված լինի սկրիպտում՝ առանց Move Paddle Right ծրագրավորման անհրաժեշտության։

Դուք կարող եք նույնիսկ ավելի հեռու գնալ և գրել որոշումների ամբողջ ծառը սցենարային լեզվով: Սա կոդ կլինի կոշտ կոդավորված պայմանական հայտարարությունների տեսքով, բայց դրանք կտեղակայվեն արտաքին սկրիպտային ֆայլերում, այսինքն՝ դրանք կարող են փոխվել՝ առանց ամբողջ ծրագիրը վերակոմպիլյացիայի։ Դուք հաճախ կարող եք խմբագրել սցենարի ֆայլը խաղի ընթացքում՝ արագ փորձարկելու տարբեր AI պատասխաններ:

Միջոցառման արձագանք

Վերոնշյալ օրինակները կատարյալ են Պոնգի համար: Նրանք շարունակաբար վարում են Զգայություն/Մտածել/Գործել ցիկլը և գործում են՝ հիմնվելով աշխարհի վերջին վիճակի վրա: Բայց ավելի բարդ խաղերում պետք է արձագանքել առանձին իրադարձություններին, այլ ոչ թե միանգամից գնահատել ամեն ինչ: Պոնգը այս դեպքում արդեն վատ օրինակ է։ Եկեք ընտրենք մեկ ուրիշը։

Պատկերացրեք հրաձիգ, որտեղ թշնամիներն անշարժ են մնում, քանի դեռ չեն հայտնաբերել խաղացողին, որից հետո նրանք գործում են՝ կախված իրենց «մասնագիտությունից». Այն դեռևս հիմնական ռեակտիվ համակարգ է. «եթե խաղացողը նկատվում է, ինչ-որ բան արեք», բայց այն կարող է տրամաբանորեն բաժանվել Player Seen իրադարձությունների և Reaction-ի (ընտրեք պատասխանը և կատարեք այն):

Սա մեզ հետ է բերում Զգայարան/Մտածել/Գործել ցիկլը: Մենք կարող ենք կոդավորել Sense մաս, որը կստուգի յուրաքանչյուր շրջանակ, թե արդյոք AI-ն տեսնում է նվագարկիչը: Եթե ​​ոչ, ոչինչ չի լինում, բայց եթե տեսնում է, ապա ստեղծվում է Player Seen միջոցառումը։ Կոդը կունենա առանձին բաժին, որտեղ ասվում է, որ «երբ տեղի ունենա Player Seen իրադարձությունը, արեք», որտեղ է պատասխանը, որը ձեզ անհրաժեշտ է «Մտածեք և գործեք» մասերին անդրադառնալու համար: Այսպիսով, դուք կստեղծեք Player Seen իրադարձության արձագանքները՝ «շտապող» կերպարի համար՝ ChargeAndAttack, իսկ դիպուկահարի համար՝ HideAndSnipe: Այս հարաբերությունները կարող են ստեղծվել տվյալների ֆայլում արագ խմբագրման համար՝ առանց վերակազմավորման: Սցենարների լեզուն կարող է օգտագործվել նաև այստեղ:

Դժվար որոշումներ կայացնելը

Չնայած պարզ արձագանքման համակարգերը շատ հզոր են, կան բազմաթիվ իրավիճակներ, երբ դրանք բավարար չեն: Երբեմն դուք պետք է տարբեր որոշումներ կայացնեք՝ հիմնվելով այն բանի վրա, թե ինչ է անում գործակալը ներկայումս, բայց դա որպես պայման դժվար է պատկերացնել: Երբեմն չափազանց շատ պայմաններ կան՝ դրանք արդյունավետ կերպով ներկայացնելու որոշումների ծառի կամ սցենարի մեջ: Երբեմն պետք է նախապես գնահատել, թե ինչպես կփոխվի իրավիճակը, նախքան հաջորդ քայլը որոշելը: Այս խնդիրների լուծման համար անհրաժեշտ են ավելի բարդ մոտեցումներ։

Վերջավոր վիճակի մեքենա

Վերջավոր վիճակի մեքենա կամ FSM (վերջավոր վիճակի մեքենա) մի միջոց է ասելու, որ մեր գործակալը ներկայումս գտնվում է մի քանի հնարավոր վիճակներից մեկում, և որ այն կարող է անցնել մի վիճակից մյուսին: Նման պետությունների որոշակի քանակ կա՝ այստեղից էլ անվանումը։ Կյանքի լավագույն օրինակը լուսացույցն է։ Տարբեր տեղերում կան լույսերի տարբեր հաջորդականություններ, բայց սկզբունքը նույնն է՝ յուրաքանչյուր պետություն ինչ-որ բան է ներկայացնում (կանգ, քայլել և այլն): Լուսացույցը ցանկացած պահի գտնվում է միայն մեկ վիճակում և շարժվում է մեկից մյուսը՝ պարզ կանոնների հիման վրա:

Դա նմանատիպ պատմություն է NPC-ների հետ խաղերում: Օրինակ՝ վերցնենք պահակը՝ հետևյալ վիճակներով.

• Պարեկություն.
• Հարձակում.
• Փախչելով.

Եվ դրա վիճակը փոխելու այս պայմանները.

• Եթե ​​պահակը տեսնում է թշնամուն, նա հարձակվում է։
• Եթե ​​պահակը հարձակվում է, բայց այլևս չի տեսնում թշնամուն, նա վերադառնում է պարեկություն կատարելու:
• Եթե ​​պահակը հարձակվում է, բայց ծանր վիրավորվում է, նա փախչում է։

Կարող եք նաև գրել if-statements խնամակալության վիճակի փոփոխականով և տարբեր ստուգումներով՝ մոտակայքում կա՞ թշնամի, որքան է NPC-ի առողջական մակարդակը և այլն։ Ավելացնենք ևս մի քանի վիճակ.

• Պարապություն - պարեկների միջև:
• Որոնում - երբ նկատված թշնամին անհետացել է:
• Օգնության որոնում. երբ թշնամուն նկատում են, բայց չափազանց ուժեղ է միայնակ պայքարելու համար:

Նրանցից յուրաքանչյուրի ընտրությունը սահմանափակ է, օրինակ, պահակը չի գնա թաքնված թշնամու փնտրելու, եթե նա վատ առողջություն ունի:

Ի վերջո, կա «եթե»-ների հսկայական ցուցակ. , Դա «Կարող է դառնալ չափազանց ծանր, ուստի մենք պետք է ձևակերպենք մի մեթոդ, որը թույլ կտա մեզ նկատի ունենալ վիճակները և պետությունների միջև անցումները: Դա անելու համար մենք հաշվի ենք առնում բոլոր նահանգները, և յուրաքանչյուր պետության տակ ցուցակում գրում ենք բոլոր անցումները դեպի այլ պետություններ՝ դրանց համար անհրաժեշտ պայմանների հետ միասին։

Սա վիճակի անցումային աղյուսակ է՝ FSM-ի ներկայացման համապարփակ միջոց: Եկեք գծենք դիագրամ և ստանանք ամբողջական ակնարկ, թե ինչպես է փոխվում NPC-ի վարքագիծը:

Դիագրամը արտացոլում է այս գործակալի որոշումների կայացման էությունը՝ հիմնվելով ներկա իրավիճակի վրա: Ավելին, յուրաքանչյուր սլաք ցույց է տալիս վիճակների միջև անցում, եթե դրա կողքի պայմանը ճշմարիտ է:

Յուրաքանչյուր թարմացում մենք ստուգում ենք գործակալի ներկայիս վիճակը, նայում ենք անցումների ցանկը, և եթե անցման պայմանները բավարարված են, այն ընդունում է նոր վիճակը: Օրինակ, յուրաքանչյուր կադր ստուգում է, թե արդյոք 10 վայրկյանանոց ժմչփի ժամկետը սպառվել է, և եթե այո, ապա պահակը պարապ վիճակից անցնում է Պարեկային: Նույն կերպ Հարձակվող պետությունը ստուգում է գործակալի առողջությունը՝ եթե այն ցածր է, ապա այն անցնում է Փախչող վիճակի։

Սա պետությունների միջև անցումներն է, բայց ինչ վերաբերում է հենց պետությունների հետ կապված վարքագծին: Որոշակի պետության համար փաստացի վարքագծի իրականացման առումով սովորաբար լինում են երկու տեսակի «կեռիկներ», որտեղ մենք գործողություններ ենք հանձնարարում FSM-ին.

• Գործողություններ, որոնք մենք պարբերաբար կատարում ենք ներկա վիճակի համար:
• Գործողությունները, որոնք մենք կատարում ենք մի վիճակից մյուսին անցնելիս:

Օրինակներ առաջին տեսակի համար. Պարեկային պետությունը գործակալին կտեղափոխի պարեկային երթուղու երկայնքով յուրաքանչյուր շրջանակ: Հարձակվող պետությունը կփորձի հարձակում սկսել յուրաքանչյուր շրջանակ կամ անցում կատարել մի վիճակի, որտեղ դա հնարավոր է:

Երկրորդ տեսակի համար հաշվի առեք անցումը «եթե թշնամին տեսանելի է, և թշնամին չափազանց ուժեղ է, ապա գնացեք «Գտնել օգնություն» վիճակ: Գործակալը պետք է ընտրի, թե ուր դիմել օգնության և պահպանի այս տեղեկատվությունը, որպեսզի «Գտնելով օգնություն» վիճակն իմանա, թե ուր գնալ: Երբ օգնությունը գտնվի, գործակալը վերադառնում է Հարձակվող վիճակ: Այս պահին նա կցանկանա դաշնակցին հայտնել սպառնալիքի մասին, այնպես որ կարող է տեղի ունենալ NotifyFriendOfThreat գործողությունը:

Կրկին, մենք կարող ենք այս համակարգին նայել Զգացմունք/Մտածել/Գործել ցիկլի ոսպնյակի միջոցով: Զգացմունքը մարմնավորված է անցումային տրամաբանության կողմից օգտագործվող տվյալների մեջ: Մտածեք - անցումներ հասանելի են յուրաքանչյուր նահանգում: Իսկ Act-ն իրականացվում է պետության ներսում կամ պետությունների միջև անցումներում պարբերաբար կատարվող գործողություններով:

Երբեմն շարունակական ընտրությունների անցումային պայմանները կարող են թանկ լինել: Օրինակ, եթե յուրաքանչյուր գործակալ յուրաքանչյուր շրջանակում բարդ հաշվարկներ է կատարում՝ որոշելու համար, թե արդյոք նա կարող է տեսնել թշնամիներին և հասկանալ՝ արդյոք կարող է անցնել Պարեկային վիճակից հարձակման վիճակի, դա շատ պրոցեսորի ժամանակ կխլի:

Աշխարհի վիճակի կարևոր փոփոխությունները կարելի է դիտարկել որպես իրադարձություններ, որոնք կվերամշակվեն, երբ դրանք տեղի ունենան: Փոխանակ FSM-ն ստուգի անցումային պայմանը «կարո՞ղ է իմ գործակալը տեսնել նվագարկիչը» յուրաքանչյուր կադր, առանձին համակարգ կարող է կազմաձևվել, որպեսզի ավելի քիչ հաճախակի ստուգի (օրինակ՝ վայրկյանում 5 անգամ): Եվ արդյունքն այն է, որ թողարկվի Player Seen-ը, երբ ստուգումն անցնի:

Սա փոխանցվում է FSM-ին, որն այժմ պետք է գնա Player Seen-ի ստացված իրադարձության վիճակին և համապատասխանաբար արձագանքի: Ստացված վարքագիծը նույնն է, բացառությամբ գրեթե աննկատելի ուշացման, նախքան պատասխանելը: Բայց կատարումը բարելավվել է Sense մասը ծրագրի առանձին մասի բաժանելու արդյունքում:

Հիերարխիկ վերջավոր վիճակի մեքենա

Այնուամենայնիվ, մեծ FSM-ների հետ աշխատելը միշտ չէ, որ հարմար է: Եթե ​​մենք ցանկանում ենք ընդլայնել հարձակման վիճակը՝ առանձնացնելով MeleeAttacking-ը և RangedAttacking-ը, մենք պետք է փոխենք անցումները մյուս բոլոր վիճակներից, որոնք տանում են դեպի Attacking վիճակ (ներկայիս և ապագա):

Դուք հավանաբար նկատել եք, որ մեր օրինակում կան բազմաթիվ կրկնօրինակ անցումներ: Պարապ վիճակի անցումներից շատերը նույնական են պարեկային վիճակում անցումներին: Լավ կլինի չկրկնվենք, հատկապես, եթե ավելացնենք նմանատիպ վիճակներ։ Իմաստ ունի պարապ և պարեկություն խմբավորել «ոչ մարտական» ընդհանուր պիտակի տակ, որտեղ կա միայն մեկ ընդհանուր շարք անցումներ դեպի մարտական ​​պետություններ: Եթե ​​այս պիտակը պատկերացնենք որպես պետություն, ապա պարապությունը և պարեկելը դառնում են ենթապետություններ։ Նոր ոչ մարտական ​​ենթակայության համար առանձին անցումային աղյուսակ օգտագործելու օրինակ.

Հիմնական պետությունները.


Մարտական ​​կարգավիճակից դուրս.


Եվ գծապատկերի տեսքով.

Դա նույն համակարգն է, բայց նոր ոչ մարտական ​​վիճակով, որը ներառում է պարապություն և պարեկություն: Յուրաքանչյուր վիճակով, որը պարունակում է FSM՝ ենթագրքերով (և այս ենթակետերը, իրենց հերթին, պարունակում են իրենց սեփական FSM-ները և այլն այնքան ժամանակ, որքան ձեզ անհրաժեշտ է), մենք ստանում ենք հիերարխիկ վերջավոր վիճակի մեքենա կամ HFSM (հիերարխիկ վերջավոր վիճակի մեքենա): Խմբավորելով ոչ մարտական ​​վիճակը՝ մենք կտրեցինք ավելորդ անցումների մի փունջ։ Մենք կարող ենք նույնը անել ընդհանուր անցումներով ցանկացած նոր պետության համար: Օրինակ, եթե ապագայում մենք ընդլայնենք Attacking վիճակը դեպի MeleeAttacking և MissileAttacking նահանգները, ապա դրանք կլինեն ենթատեսակներ, որոնք անցնում են միմյանց միջև՝ ելնելով հակառակորդի հեռավորությունից և զինամթերքի առկայությունից: Արդյունքում, բարդ վարքագծերը և ենթաբաժինները կարող են ներկայացվել նվազագույն կրկնօրինակ անցումներով:

Վարքի ծառ

HFSM-ով վարքագծի բարդ համակցությունները ստեղծվում են պարզ ձևով: Այնուամենայնիվ, կա մի փոքր դժվարություն, որ անցումային կանոնների տեսքով որոշումների կայացումը սերտորեն կապված է ներկա վիճակի հետ: Եվ շատ խաղերում հենց դա է անհրաժեշտ: Իսկ պետական ​​հիերարխիայի զգույշ օգտագործումը կարող է նվազեցնել անցումային կրկնությունների թիվը: Բայց երբեմն ձեզ հարկավոր են կանոններ, որոնք գործում են անկախ նրանից, թե որ նահանգում եք գտնվում, կամ կիրառվում են գրեթե ցանկացած նահանգում: Օրինակ, եթե գործակալի առողջական վիճակն իջնի մինչև 25%, դուք կցանկանաք, որ նա փախչի՝ անկախ նրանից՝ նա մարտում է եղել, պարապ, թե՞ խոսում է, դուք պետք է այս պայմանը ավելացնեք յուրաքանչյուր նահանգին: Եվ եթե ձեր դիզայները հետագայում ցանկանա փոխել առողջության ցածր շեմը 25%-ից մինչև 10%, ապա դա պետք է նորից արվի:

Իդեալում, այս իրավիճակը պահանջում է մի համակարգ, որտեղ «ինչ վիճակում լինել» որոշումները լինեն հենց պետություններից դուրս, որպեսզի փոփոխություններ կատարվեն միայն մեկ վայրում և չշոշափեն անցումային պայմանները: Այստեղ հայտնվում են վարքի ծառեր:

Դրանց իրականացման մի քանի եղանակ կա, բայց էությունը մոտավորապես նույնն է բոլորի համար և նման է որոշումների ծառին. ալգորիթմը սկսվում է «արմատային» հանգույցից, իսկ ծառը պարունակում է հանգույցներ, որոնք ներկայացնում են կամ որոշումներ կամ գործողություններ: Այնուամենայնիվ, կան մի քանի հիմնական տարբերություններ.

• Հանգույցներն այժմ վերադարձնում են երեք արժեքներից մեկը՝ Succeed (եթե աշխատանքը ավարտված է), Failed (եթե այն հնարավոր չէ սկսել), կամ Running (եթե այն դեռ աշխատում է, և վերջնական արդյունք չկա):
• Այլևս չկան որոշման հանգույցներ երկու այլընտրանքների միջև ընտրելու համար: Փոխարենը դրանք Decorator հանգույցներ են, որոնք ունեն մեկ երեխա հանգույց: Եթե ​​նրանք հաջողության հասնեն, նրանք կատարում են իրենց միակ երեխայի հանգույցը:
• Գործողություններ կատարող հանգույցները վերադարձնում են «Գործող» արժեք՝ կատարվող գործողությունները ներկայացնելու համար:

Հանգույցների այս փոքր հավաքածուն կարող է համակցվել՝ ստեղծելով մեծ թվով բարդ վարքագիծ: Եկեք պատկերացնենք նախորդ օրինակից HFSM պահակը որպես վարքագծի ծառ.

Այս կառուցվածքով չպետք է լինի ակնհայտ անցում պարապ/պարեկային վիճակից դեպի Հարձակվող կամ որևէ այլ պետություն: Եթե ​​թշնամին տեսանելի է, և հերոսի առողջական վիճակը ցածր է, կատարումը կդադարի փախչող հանգույցում, անկախ նրանից, թե որ հանգույցն էր նախկինում կատարում՝ պարեկություն, պարապ, հարձակվել կամ որևէ այլ:

Վարքագծի ծառերը բարդ են. կան դրանք կազմելու բազմաթիվ եղանակներ, և դեկորատորների և բարդ հանգույցների ճիշտ համադրություն գտնելը կարող է դժվար լինել: Հարցեր կան նաև այն մասին, թե որքան հաճախ պետք է ստուգել ծառը. մենք ուզում ենք անցնել դրա ամեն մի մասով, թե միայն այն դեպքում, երբ պայմաններից մեկը փոխվել է: Ինչպե՞ս ենք մենք պահում հանգույցներին վերաբերող վիճակը. ինչպե՞ս իմանանք, որ մենք անգործության ենք մատնվել 10 վայրկյան, կամ ինչպե՞ս իմանանք, թե որ հանգույցներն են աշխատել վերջին անգամ, որպեսզի կարողանանք ճիշտ մշակել հաջորդականությունը:

Ահա թե ինչու կան բազմաթիվ իրականացումներ։ Օրինակ, որոշ համակարգեր փոխարինել են դեկորատոր հանգույցները ներգծային դեկորատորներով: Նրանք վերագնահատում են ծառը, երբ դեկորատորի պայմանները փոխվում են, օգնում են միացնել հանգույցները և տրամադրում են պարբերական թարմացումներ:

Կոմունալ ծառայությունների վրա հիմնված համակարգ

Որոշ խաղեր ունեն շատ տարբեր մեխանիզմներ: Ցանկալի է, որ նրանք ստանան անցումային պարզ և ընդհանուր կանոնների բոլոր առավելությունները, բայց ոչ պարտադիր վարքագծի ամբողջական ծառի տեսքով։ Ընտրությունների հստակ հավաքածու կամ հնարավոր գործողությունների ծառ ունենալու փոխարեն ավելի հեշտ է ուսումնասիրել բոլոր գործողությունները և ընտրել տվյալ պահին ամենահարմարը:

Կոմունալ ծառայությունների վրա հիմնված համակարգը կօգնի հենց այս հարցում: Սա մի համակարգ է, որտեղ գործակալն ունի մի շարք գործողություններ և ընտրում է, թե որոնք պետք է կատարի յուրաքանչյուրի հարաբերական օգտակարության հիման վրա: Այնտեղ, որտեղ օգտակարությունը կամայական միջոց է այն բանի, թե որքան կարևոր կամ ցանկալի է գործակալի համար կատարել այս գործողությունը:

Գործողության հաշվարկված օգտակարությունը, որը հիմնված է ընթացիկ վիճակի և միջավայրի վրա, գործակալը կարող է ցանկացած պահի ստուգել և ընտրել առավել համապատասխան այլ վիճակը: Սա նման է FSM-ին, բացառությամբ այն դեպքերի, երբ անցումները որոշվում են յուրաքանչյուր պոտենցիալ վիճակի գնահատմամբ, ներառյալ ներկայիսը: Խնդրում ենք նկատի ունենալ, որ մենք ընտրում ենք ամենաօգտակար գործողությունը շարունակելու համար (կամ մնալ, եթե այն արդեն ավարտել ենք): Ավելի բազմազանության համար սա կարող է լինել հավասարակշռված, բայց պատահական ընտրություն փոքր ցուցակից:

Համակարգը նշանակում է օգտակար արժեքների կամայական տիրույթ, օրինակ՝ 0-ից (բոլորովին անցանկալի) մինչև 100 (միանգամայն ցանկալի): Յուրաքանչյուր գործողություն ունի մի շարք պարամետրեր, որոնք ազդում են այս արժեքի հաշվարկի վրա: Վերադառնալով մեր պահապան օրինակին.

Գործողությունների միջև անցումները երկիմաստ են. ցանկացած պետություն կարող է հետևել ցանկացած այլ վիճակի: Գործողությունների առաջնահերթությունները գտնվում են վերադարձված օգտակար արժեքներում: Եթե ​​թշնամին տեսանելի է, և այդ թշնամին ուժեղ է, և հերոսի առողջական վիճակը ցածր է, ապա և՛ Փախչելը, և՛ FindingHelp-ը կվերադարձնեն բարձր ոչ զրոյական արժեքներ: Այս դեպքում FindingHelp-ը միշտ ավելի բարձր կլինի: Նմանապես, ոչ մարտական ​​գործողությունները երբեք չեն վերադառնում ավելի քան 50, ուստի դրանք միշտ ավելի ցածր կլինեն, քան մարտականները: Դուք պետք է դա հաշվի առնեք գործողություններ ստեղծելիս և դրանց օգտակարությունը հաշվարկելիս:

Մեր օրինակում գործողությունները վերադարձնում են կա՛մ ֆիքսված հաստատուն արժեք, կա՛մ երկու ֆիքսված արժեքներից մեկը: Ավելի իրատեսական համակարգը կվերադարձնի գնահատական ​​արժեքների շարունակական միջակայքից: Օրինակ, «Փախուստ» գործողությունը վերադարձնում է ավելի բարձր օգտակար արժեքներ, եթե գործակալի առողջական վիճակը ցածր է, և «Հարձակում» գործողությունը վերադարձնում է ավելի ցածր օգտակար արժեքներ, եթե թշնամին չափազանց ուժեղ է: Դրա պատճառով «Փախուստ» գործողությունը գերակայում է «Հարձակման» նկատմամբ ցանկացած իրավիճակում, երբ գործակալը զգում է, որ ինքը բավարար առողջություն չունի թշնամուն հաղթելու համար: Սա թույլ է տալիս գործողություններին առաջնահերթություն տալ՝ հիմնվելով ցանկացած քանակի չափանիշների վրա՝ դարձնելով այս մոտեցումը ավելի ճկուն և փոփոխական, քան վարքագծի ծառը կամ FSM-ը:

Յուրաքանչյուր գործողություն ունի բազմաթիվ պայմաններ ծրագրի հաշվարկի համար: Դրանք կարող են գրվել սցենարային լեզվով կամ որպես մաթեմատիկական բանաձևերի շարք։ The Sims-ը, որը նմանակում է կերպարի առօրյան, ավելացնում է հաշվարկի լրացուցիչ շերտ՝ գործակալը ստանում է մի շարք «մոտիվացիաներ», որոնք ազդում են օգտակար ծառայության վարկանիշների վրա: Եթե ​​կերպարը քաղցած է, նա ժամանակի ընթացքում էլ ավելի քաղցած կդառնա, և EatFood գործողության օգտակար արժեքը կավելանա այնքան ժամանակ, մինչև կերպարը կատարի այն՝ նվազեցնելով քաղցի մակարդակը և վերադարձնելով EatFood արժեքը զրոյի:

Գնահատման համակարգի հիման վրա գործողություններ ընտրելու գաղափարը բավականին պարզ է, ուստի Կոմունալ ծառայությունների վրա հիմնված համակարգը կարող է օգտագործվել որպես AI որոշումների կայացման գործընթացի մաս, այլ ոչ թե որպես դրանց ամբողջական փոխարինում: Որոշման ծառը կարող է պահանջել երկու մանկական հանգույցների օգտակար վարկանիշ և ընտրել ավելի բարձրը: Նմանապես, վարքագծի ծառը կարող է ունենալ կոմպոզիտային Utility հանգույց՝ գնահատելու գործողությունների օգտակարությունը՝ որոշելու համար, թե որ երեխան պետք է կատարի:

Շարժում և նավարկություն

Նախորդ օրինակներում մենք ունեինք հարթակ, որը շարժվում էինք աջ կամ ձախ, և պահակ, որը պարեկություն էր անում կամ հարձակվում: Բայց կոնկրետ ինչպե՞ս ենք մենք ղեկավարում գործակալների շարժումը որոշակի ժամանակահատվածում: Ինչպե՞ս ենք մենք արագություն սահմանում, ինչպես ենք խուսափել խոչընդոտներից և ինչպես ենք պլանավորում երթուղին, երբ նպատակակետ հասնելն ավելի դժվար է, քան ուղղակի ուղիղ գծով շարժվելը: Եկեք նայենք սա:

Կառավարում

Սկզբնական փուլում մենք կենթադրենք, որ յուրաքանչյուր գործակալ ունի արագության արժեք, որը ներառում է, թե որքան արագ է այն շարժվում և ինչ ուղղությամբ: Այն կարող է չափվել մետր/վրկ, կիլոմետր/ժամ, պիքսել/վրկ և այլն: Հիշելով Sense/Think/Act օղակը՝ մենք կարող ենք պատկերացնել, որ Think մասը ընտրում է արագություն, իսկ Act մասը կիրառում է այդ արագությունը գործակալի վրա: Սովորաբար խաղերն ունեն ֆիզիկայի համակարգ, որը կատարում է այս խնդիրը ձեզ համար՝ սովորելով յուրաքանչյուր օբյեկտի արագության արժեքը և կարգավորելով այն: Հետևաբար, դուք կարող եք թողնել AI-ն մեկ առաջադրանքով՝ որոշել, թե ինչ արագություն պետք է ունենա գործակալը: Եթե ​​դուք գիտեք, թե որտեղ պետք է լինի գործակալը, ապա դուք պետք է այն տեղափոխեք ճիշտ ուղղությամբ սահմանված արագությամբ: Շատ չնչին հավասարում.

ցանկալի_ճանապարհորդություն = նպատակակետ_դիրք – գործակալ_դիրք

Պատկերացրեք 2D աշխարհ: Գործակալը գտնվում է (-2,-2) կետում, նպատակակետը գտնվում է հյուսիս-արևելքում (30, 20) կետում, և գործակալի համար այնտեղ հասնելու անհրաժեշտ ճանապարհը (32, 22): Ենթադրենք, այս դիրքերը չափվում են մետրերով. եթե գործակալի արագությունը վերցնենք վայրկյանում 5 մետր, ապա մենք կմեծացնենք մեր տեղաշարժի վեկտորը և կստանանք մոտավորապես (4.12, 2.83) արագություն: Այս պարամետրերով գործակալը իր նպատակակետին կհասներ գրեթե 8 վայրկյանում:

Դուք ցանկացած պահի կարող եք վերահաշվարկել արժեքները: Եթե ​​գործակալը կիսով չափ լիներ դեպի թիրախ, շարժումը կլիներ երկարության կեսը, բայց քանի որ գործակալի առավելագույն արագությունը 5 մ/վ է (սա որոշեցինք վերևում), արագությունը նույնն է լինելու։ Սա նաև աշխատում է շարժվող թիրախների համար՝ թույլ տալով գործակալին փոքր փոփոխություններ կատարել դրանք շարժվելիս:

Բայց մենք ուզում ենք ավելի շատ տատանումներ, օրինակ՝ դանդաղ բարձրացնել արագությունը՝ նմանակելու համար կանգնածից վազող կերպարը: Նույնը կարելի է անել վերջում՝ կանգ առնելուց առաջ։ Այս հատկանիշները հայտնի են որպես ղեկային վարքագիծ, որոնցից յուրաքանչյուրն ունի հատուկ անվանումներ՝ փնտրել, փախչել, ժամանում և այլն: Գաղափարն այն է, որ արագացման ուժերը կարող են կիրառվել գործակալի արագության վրա՝ հիմնվելով գործակալի դիրքի և ընթացիկ արագության համեմատության վրա՝ նպատակակետի հետ: նպատակին շարժվելու տարբեր մեթոդներ կիրառելու նպատակով:

Յուրաքանչյուր վարքագիծ ունի մի փոքր այլ նպատակ: Որոնումը և Ժամանումը գործակալին նպատակակետ տեղափոխելու ուղիներ են: Խոչընդոտների խուսափումը և բաժանումը կարգավորում են գործակալի շարժումը՝ նպատակին հասնելու ճանապարհին խոչընդոտներից խուսափելու համար: Հավասարեցումը և համախմբվածությունը պահպանում են գործակալներին շարժվել միասին: Ղեկավարման վարքագծի ցանկացած քանակ կարող է ամփոփվել՝ բոլոր գործոնները հաշվի առնելով՝ ստեղծելով մեկ ուղու վեկտոր: Գործակալ, որն օգտագործում է ժամանումը, բաժանումը և խոչընդոտներից խուսափելու վարքագիծը՝ պատերից և այլ գործակալներից հեռու մնալու համար: Այս մոտեցումը լավ է աշխատում բաց վայրերում, առանց ավելորդ մանրամասների:

Ավելի բարդ պայմաններում տարբեր վարքագծերի ավելացումն ավելի վատ է աշխատում. օրինակ՝ գործակալը կարող է խրվել պատի մեջ Ժամանման և Խոչընդոտների Խուսափման միջև կոնֆլիկտի պատճառով: Հետեւաբար, դուք պետք է հաշվի առնեք այնպիսի տարբերակներ, որոնք ավելի բարդ են, քան պարզապես բոլոր արժեքները ավելացնելը: Ճանապարհը սա է. յուրաքանչյուր վարքագծի արդյունքները գումարելու փոխարեն կարող եք դիտարկել շարժումը տարբեր ուղղություններով և ընտրել լավագույն տարբերակը:

Այնուամենայնիվ, բարդ միջավայրում փակուղիներով և ընտրությամբ, թե որ ճանապարհով գնանք, մեզ ավելի առաջադեմ բան պետք կգա:

Findանապարհ գտնելը

Ղեկավարման վարքագիծը հիանալի է բաց տարածքում (ֆուտբոլի դաշտ կամ ասպարեզ) պարզ տեղաշարժվելու համար, որտեղ A-ից B հասնելը ուղիղ ճանապարհ է՝ խոչընդոտների շուրջ միայն փոքր շրջանցումներով: Բարդ երթուղիների համար մեզ անհրաժեշտ է ուղի փնտրել, որը աշխարհն ուսումնասիրելու և դրանով երթուղի որոշելու միջոց է:

Ամենապարզը գործակալի կողքին գտնվող յուրաքանչյուր քառակուսի վրա ցանց կիրառելն է և գնահատել, թե նրանցից ում է թույլատրվում շարժվել: Եթե ​​դրանցից մեկը նպատակակետ է, ապա հետևեք երթուղին յուրաքանչյուր հրապարակից դեպի նախորդը, մինչև հասնեք սկզբին: Սա է երթուղին։ Հակառակ դեպքում, կրկնեք գործընթացը մոտակա այլ հրապարակների հետ, մինչև գտնեք ձեր նպատակակետը, կամ քառակուսիները սպառվեն (նշանակում է, որ հնարավոր երթուղի չկա): Սա այն է, ինչ պաշտոնապես հայտնի է որպես լայնություն-առաջին որոնում կամ BFS (լայնության առաջին որոնման ալգորիթմ): Ամեն քայլափոխի նա նայում է բոլոր ուղղություններով (հետևաբար՝ լայնություն՝ «լայնություն»)։ Որոնման տարածքը նման է ալիքի ճակատին, որը շարժվում է այնքան ժամանակ, մինչև այն հասնում է ցանկալի վայրին. որոնման տարածքը ընդլայնվում է յուրաքանչյուր քայլում մինչև վերջի կետը ներառվի, որից հետո այն կարող է հետագծվել դեպի սկիզբ:

Արդյունքում, դուք կստանաք քառակուսիների ցանկ, որոնց երկայնքով կազմվում է ցանկալի երթուղին: Սա ճանապարհն է (հետևաբար՝ ուղի գտնելը)՝ այն վայրերի ցանկը, որոնք գործակալը կայցելի նպատակակետին հետևելիս:

Հաշվի առնելով, որ մենք գիտենք աշխարհի յուրաքանչյուր քառակուսու դիրքը, մենք կարող ենք օգտագործել ղեկային վարքագիծը ուղու երկայնքով շարժվելու համար՝ հանգույց 1-ից հանգույց 2, այնուհետև հանգույց 2-ից մինչև հանգույց 3 և այլն: Ամենապարզ տարբերակը հաջորդ հրապարակի կենտրոն գնալն է, բայց ավելի լավ տարբերակն այն է, որ կանգ առնենք եզրագծի մեջտեղում՝ ներկայիս և հաջորդ հրապարակի միջև: Դրա պատճառով գործակալը կկարողանա կտրել անկյունները կտրուկ շրջադարձերի վրա:

BFS ալգորիթմն ունի նաև թերություններ. այն ուսումնասիրում է այնքան քառակուսիներ «սխալ» ուղղությամբ, որքան «ճիշտ» ուղղությամբ: Այստեղ է, որ գործում է ավելի բարդ ալգորիթմ, որը կոչվում է A* (A star): Այն աշխատում է նույն կերպ, բայց հարևանների քառակուսիները կուրորեն ուսումնասիրելու փոխարեն (այնուհետև հարևանների հարևանները, հետո հարևանների հարևանները և այլն), այն հավաքում է հանգույցները ցուցակի մեջ և դասավորում դրանք այնպես, որ հաջորդ հետազոտվող հանգույցը միշտ լինի մեկը, որը տանում է դեպի ամենակարճ ճանապարհը: Հանգույցները դասակարգվում են էվրիստիկայի հիման վրա, որը հաշվի է առնում երկու բան՝ հիպոթետիկ երթուղու «արժեքը» դեպի ցանկալի հրապարակ (ներառյալ ճանապարհորդության ծախսերը) և գնահատում, թե որքան հեռու է այդ քառակուսին նպատակակետից (որոնումը կողմնակալություն է առաջացնում): ճիշտ ուղղություն):

Այս օրինակը ցույց է տալիս, որ գործակալը միաժամանակ ուսումնասիրում է մեկ քառակուսի, ամեն անգամ ընտրելով հարակից հատվածը, որն առավել խոստումնալից է: Ստացված ուղին նույնն է, ինչ BFS-ն, բայց գործընթացում հաշվի են առնվել ավելի քիչ քառակուսիներ, ինչը մեծ ազդեցություն ունի խաղի կատարման վրա:

Շարժում առանց ցանցի

Բայց խաղերի մեծ մասը ցանցի վրա չի դրված, և հաճախ անհնար է դա անել առանց ռեալիզմի զոհաբերության: Փոխզիջումներ են պետք. Ինչ չափի պետք է լինեն քառակուսիները: Չափազանց մեծ է, և նրանք չեն կարողանա ճիշտ ներկայացնել փոքր միջանցքները կամ շրջադարձերը, չափազանց փոքր, և կլինեն չափազանց շատ հրապարակներ փնտրելու համար, ինչը, ի վերջո, շատ ժամանակ կխլի:

Առաջին բանը, որ պետք է հասկանալ, այն է, որ ցանցը մեզ տալիս է միացված հանգույցների գրաֆիկ: A* և BFS ալգորիթմներն իրականում աշխատում են գրաֆիկների վրա և ընդհանրապես չեն մտածում մեր ցանցի մասին: Մենք կարող ենք հանգույցներ տեղադրել խաղի աշխարհում ցանկացած վայրում. քանի դեռ կապ կա ցանկացած երկու միացված հանգույցների, ինչպես նաև սկզբի և վերջի կետերի և հանգույցներից առնվազն մեկի միջև, ալգորիթմը կաշխատի նույնքան լավ, ինչպես նախկինում: Սա հաճախ կոչվում է ճանապարհային կետի համակարգ, քանի որ յուրաքանչյուր հանգույց ներկայացնում է զգալի դիրք աշխարհում, որը կարող է լինել ցանկացած թվով հիպոթետիկ ուղիների մաս:

Օրինակ 1. հանգույց յուրաքանչյուր հրապարակում: Որոնումը սկսվում է այն հանգույցից, որտեղ գտնվում է գործակալը և ավարտվում է ցանկալի հրապարակի հանգույցում:

Օրինակ 2. հանգույցների ավելի փոքր հավաքածու (ճանապարհային կետեր): Որոնումը սկսվում է գործակալի հրապարակից, անցնում է անհրաժեշտ քանակի հանգույցներով, այնուհետև շարունակվում է նպատակակետ:

Սա լիովին ճկուն և հզոր համակարգ է: Սակայն որոշակի խնամք է անհրաժեշտ՝ որոշելով, թե որտեղ և ինչպես տեղադրել ճանապարհային կետը, հակառակ դեպքում գործակալները կարող են պարզապես չտեսնել մոտակա կետը և չկարողանան սկսել ուղին: Ավելի հեշտ կլիներ, եթե մենք կարողանայինք ավտոմատ կերպով ճանապարհային կետեր տեղադրել՝ հիմնվելով աշխարհի երկրաչափության վրա:

Այստեղ հայտնվում է նավիգացիոն ցանցը կամ navmesh (նավիգացիոն ցանց): Սա սովորաբար եռանկյունների 2D ցանց է, որը ծածկված է աշխարհի երկրաչափության վրա, որտեղ որ գործակալին թույլ են տալիս քայլել: Ցանցի եռանկյուններից յուրաքանչյուրը դառնում է գրաֆիկի հանգույց և ունի մինչև երեք հարակից եռանկյուններ, որոնք դառնում են հարակից հանգույցներ գրաֆիկում:

Այս նկարը օրինակ է Unity շարժիչից. այն վերլուծել է աշխարհի երկրաչափությունը և ստեղծել է navmesh (սքրինշոթում բաց կապույտով): Navmesh-ի յուրաքանչյուր բազմանկյուն տարածք է, որտեղ գործակալը կարող է կանգնել կամ տեղափոխվել մի բազմանկյունից մյուս բազմանկյուն: Այս օրինակում պոլիգոններն ավելի փոքր են, քան այն հարկերը, որոնց վրա գտնվում են. սա արվում է, որպեսզի հաշվի առնվի գործակալի չափը, որը դուրս կգա իր անվանական դիրքից:

Մենք կարող ենք երթուղի որոնել այս ցանցի միջոցով՝ կրկին օգտագործելով A* ալգորիթմը: Սա մեզ գրեթե կատարյալ երթուղի կտա աշխարհում, որը հաշվի է առնում ողջ երկրաչափությունը և չի պահանջում ավելորդ հանգույցներ և ճանապարհային կետերի ստեղծում։

Ճանապարհ փնտրելը չափազանց լայն թեմա է, որի համար հոդվածի մեկ բաժինը բավարար չէ: Եթե ​​ցանկանում եք ավելի մանրամասն ուսումնասիրել այն, ապա սա կօգնի Amit Patel կայքը.

Պլանավորում

Ճանապարհ փնտրելով մենք սովորել ենք, որ երբեմն բավական չէ պարզապես ընտրել ուղղություն և շարժվել. մենք պետք է ընտրենք երթուղի և մի քանի շրջադարձ կատարենք՝ հասնելու մեր ցանկալի նպատակակետին: Մենք կարող ենք ընդհանրացնել այս գաղափարը. նպատակին հասնելը ոչ միայն հաջորդ քայլն է, այլ մի ամբողջ հաջորդականություն, որտեղ երբեմն պետք է մի քանի քայլ առաջ նայել՝ պարզելու համար, թե որն է առաջինը: Սա կոչվում է պլանավորում: Ճանապարհ փնտրելը կարելի է համարել որպես պլանավորման մի քանի ընդլայնումներից մեկը: Ինչ վերաբերում է մեր Զգայարան/Մտածել/Գործել ցիկլի, սա այն վայրն է, որտեղ Think մասը նախատեսում է մի քանի Act մասեր ապագայի համար:

Դիտարկենք Magic: The Gathering սեղանի խաղի օրինակը: Մենք նախ գնում ենք հետևյալ քարտերի հավաքածուն մեր ձեռքում.

• Ճահիճ - Տալիս է 1 սեւ մանա (հողային քարտ):
• Անտառ - տալիս է 1 կանաչ մանա (հողային քարտ):
• Fugitive Wizard - Կանչելու համար պահանջվում է 1 կապույտ մանա:
• Էլվիշ միստիկ - Կանչելու համար պահանջվում է 1 կանաչ մանա:

Մենք անտեսում ենք մնացած երեք քարտերը՝ հեշտացնելու համար: Ըստ կանոնների՝ խաղացողին թույլատրվում է խաղալ 1 հողային քարտ յուրաքանչյուր հերթում, նա կարող է «կտպել» այս քարտին՝ դրանից մանա հանելու համար, այնուհետև հմայել (ներառյալ արարած կանչել)՝ ըստ մանայի քանակի: Այս իրավիճակում մարդ խաղացողը գիտի խաղալ Forest, կտտացնել 1 կանաչ մանա և հետո կանչել Էլվիշ Միստիկին: Բայց ինչպե՞ս կարող է խաղային AI-ն դա պարզել:

Հեշտ պլանավորում

Չնչին մոտեցումը յուրաքանչյուր գործողություն հերթով փորձելն է, քանի դեռ հարմարները չեն մնացել: Քարտերին նայելով՝ AI-ն տեսնում է, թե ինչ կարող է խաղալ Swamp-ը: Եվ նա խաղում է այն: Այս հերթից այլ գործողություններ մնու՞մ են: Այն չի կարող կանչել ո՛չ Էլվիշ միստիկին, ո՛չ էլ փախած կախարդին, քանի որ նրանց կանչելու համար պահանջվում է համապատասխանաբար կանաչ և կապույտ մանա, մինչդեռ Ճահիճը տրամադրում է միայն սև մանա։ Եվ նա այլեւս չի կարողանա խաղալ Անտառ, քանի որ նա արդեն խաղացել է Ճահիճ։ Այսպիսով, AI խաղը հետևեց կանոններին, բայց դա վատ արեց: Կարող է բարելավվել:

Պլանավորումը կարող է գտնել գործողությունների ցանկ, որոնք խաղը բերում են ցանկալի վիճակի: Ինչպես ուղու վրա գտնվող յուրաքանչյուր քառակուսի ուներ հարևաններ (ուղի գտնելիս), պլանի յուրաքանչյուր գործողություն նույնպես ունի հարևաններ կամ իրավահաջորդներ: Մենք կարող ենք փնտրել այս և հետագա գործողությունները, մինչև հասնենք ցանկալի վիճակին:

Մեր օրինակում ցանկալի արդյունքը «հնարավորության դեպքում արարած կանչեք»։ Շրջադարձի սկզբում մենք տեսնում ենք խաղի կանոններով թույլատրված միայն երկու հնարավոր գործողություն.

1. Խաղալ ճահիճ (արդյունք. Ճահիճը խաղում)
2. Խաղալ Forest (արդյունքը. Անտառը խաղում)

Կատարված յուրաքանչյուր գործողություն կարող է հանգեցնել հետագա գործողությունների և փակել մյուսները՝ կրկին կախված խաղի կանոններից: Պատկերացրեք, որ մենք խաղացել ենք Swamp - սա կհեռացնի Swamp-ը որպես հաջորդ քայլ (մենք արդեն խաղացել ենք), և սա նաև կհեռացնի Forest-ը (քանի որ կանոնների համաձայն դուք կարող եք խաղալ մեկ հողաթուղթ յուրաքանչյուր հերթափոխի համար): Դրանից հետո AI-ն ավելացնում է 1 սև մանա ստանալը որպես հաջորդ քայլ, քանի որ այլ տարբերակներ չկան: Եթե ​​նա առաջ գնա և ընտրի Tap the Swamp-ը, նա կստանա 1 միավոր սև մանա և չի կարողանա որևէ բան անել դրա հետ:

1. Խաղալ ճահիճ (արդյունք. Ճահիճը խաղում)
1.1 «Թափ» ճահիճ (արդյունք՝ ճահիճ «թակել», +1 միավոր սև մանա)
Գործողություններ չկան - END
2. Խաղալ Forest (արդյունքը. Անտառը խաղում)

Գործողությունների ցանկը կարճ էր, մտանք փակուղի։ Մենք կրկնում ենք գործընթացը հաջորդ քայլի համար: Խաղում ենք Անտառ, բացում ենք «ստանալ 1 կանաչ մանա» ակցիան, որն իր հերթին կբացի երրորդ գործողությունը՝ կանչիր Էլվիշ Միստիկին:

1. Խաղալ ճահիճ (արդյունք. Ճահիճը խաղում)
1.1 «Թափ» ճահիճ (արդյունք՝ ճահիճ «թակել», +1 միավոր սև մանա)
Գործողություններ չկան - END
2. Խաղալ Forest (արդյունքը. Անտառը խաղում)
2.1 «Թափ» անտառ (արդյունք. անտառը «ծակվում է», +1 միավոր կանաչ մանա)
2.1.1 Կանչեք Էլվիշ Միստիկին (արդյունքը՝ Էլվիշ Միստիկին խաղում, -1 կանաչ մանա)
Գործողություններ չկան - END

Ի վերջո, մենք ուսումնասիրեցինք բոլոր հնարավոր գործողությունները և գտանք մի ծրագիր, որը կանչում է արարածին:

Սա շատ պարզեցված օրինակ է։ Ցանկալի է ընտրել հնարավոր լավագույն պլանը, այլ ոչ թե որևէ պլան, որը համապատասխանում է որոշ չափանիշներին: Ընդհանուր առմամբ հնարավոր է գնահատել հնարավոր պլանները՝ հիմնվելով դրանց իրականացման արդյունքի կամ ընդհանուր օգուտի վրա: Դուք կարող եք ինքներդ ձեզ 1 միավոր վաստակել հողային քարտ խաղալու համար և 3 միավոր՝ արարած կանչելու համար: Swamp խաղալը կլինի 1 բալանոց պլան: Իսկ խաղալով Forest → Tap the Forest → հրավիրել Էլվիշ Միստիկին, անմիջապես 4 միավոր կտա:

Ահա թե ինչպես է պլանավորումը աշխատում Magic: The Gathering-ում, բայց նույն տրամաբանությունը գործում է այլ իրավիճակներում: Օրինակ՝ լոմբարդ տեղափոխելը, որպեսզի եպիսկոպոսի համար տեղ բացվի շախմատում տեղաշարժվելու համար: Կամ ծածկվեք պատի հետևում և ապահով նկարահանեք XCOM-ում այսպես: Ընդհանուր առմամբ, դուք հասկանում եք գաղափարը:

Բարելավված պլանավորում

Երբեմն չափազանց շատ պոտենցիալ գործողություններ են լինում՝ հնարավոր բոլոր տարբերակները դիտարկելու համար: Վերադառնալով Magic. Խնդրի մի քանի լուծում կա.

Առաջին մեթոդը հետընթաց շղթայում է: Բոլոր կոմբինացիաները փորձելու փոխարեն ավելի լավ է սկսել վերջնական արդյունքից և փորձել ուղղակի երթուղի գտնել։ Ծառի արմատից կոնկրետ տերեւ գնալու փոխարեն մենք շարժվում ենք հակառակ ուղղությամբ՝ տերևից արմատ։ Այս մեթոդը ավելի հեշտ է և արագ:

Եթե ​​թշնամին ունի 1 առողջություն, կարող եք գտնել «գործարք 1 կամ ավելի վնաս» պլանը։ Դրան հասնելու համար պետք է պահպանվեն մի շարք պայմաններ.

1. Վնասը կարող է պատճառել կախարդանքը՝ այն պետք է ձեռքի տակ լինի:
2. Հմայություն անելու համար մանա է պետք:
3. Մանա ստանալու համար հարկավոր է հողային քարտ խաղալ:
4. Հողային քարտ խաղալու համար հարկավոր է այն ունենալ ձեր ձեռքում:

Մեկ այլ միջոց է լավագույնը առաջին որոնումը: Բոլոր ուղիները փորձելու փոխարեն մենք ընտրում ենք ամենահարմարը։ Ամենից հաճախ այս մեթոդը տալիս է օպտիմալ պլան՝ առանց որոնման ավելորդ ծախսերի: A*-ը լավագույն առաջին որոնման ձևն է. ի սկզբանե ուսումնասիրելով ամենախոստումնալից երթուղիները, այն արդեն կարող է գտնել լավագույն ճանապարհը՝ առանց այլ տարբերակներ ստուգելու:

Հետաքրքիր և ավելի ու ավելի տարածված լավագույն առաջին որոնման տարբերակն է Մոնտե Կառլոյի ծառի որոնումը: Յուրաքանչյուր հաջորդ գործողություն ընտրելիս կռահելու, թե որ պլաններն են ավելի լավը, քան մյուսները, ալգորիթմն ընտրում է պատահական հաջորդներ յուրաքանչյուր քայլում, մինչև այն հասնի ավարտին (երբ պլանը հանգեցրեց հաղթանակի կամ պարտության): Վերջնական արդյունքն այնուհետև օգտագործվում է նախորդ տարբերակների քաշը մեծացնելու կամ նվազեցնելու համար: Այս գործընթացը մի քանի անգամ անընդմեջ կրկնելով՝ ալգորիթմը լավ գնահատական ​​է տալիս, թե որն է լավագույն հաջորդ քայլը, նույնիսկ եթե իրավիճակը փոխվի (եթե թշնամին գործողություններ ձեռնարկի խաղացողին խանգարելու համար):

Խաղերում պլանավորման մասին ոչ մի պատմություն ամբողջական չէր լինի առանց նպատակաուղղված գործողությունների պլանավորման կամ GOAP-ի (նպատակին ուղղված գործողությունների պլանավորում): Սա լայնորեն կիրառվող և քննարկված մեթոդ է, բայց բացի մի քանի տարբերակիչ մանրամասներից, այն ըստ էության հետընթաց շղթայական մեթոդն է, որի մասին մենք ավելի վաղ խոսեցինք: Եթե ​​նպատակը եղել է «ոչնչացնել խաղացողին», իսկ խաղացողը գտնվում է ծածկույթի հետևում, ապա պլանը կարող է լինել. ոչնչացնել նռնակով → ստանալ այն → նետել այն:

Սովորաբար կան մի քանի նպատակներ, որոնցից յուրաքանչյուրն ունի իր առաջնահերթությունը: Եթե ​​ամենաառաջնահերթ նպատակը հնարավոր չէ իրականացնել (գործողությունների ոչ մի համակցություն չի ստեղծում «սպանել խաղացողին» պլան, քանի որ խաղացողը տեսանելի չէ), AI-ն կվերադառնա ավելի ցածր առաջնահերթ նպատակներին:

Ուսուցում և հարմարեցում

Մենք արդեն ասել ենք, որ խաղի AI-ն սովորաբար չի օգտագործում մեքենայական ուսուցում, քանի որ այն հարմար չէ իրական ժամանակում գործակալներին կառավարելու համար: Բայց դա չի նշանակում, որ դուք չեք կարող ինչ-որ բան վերցնել այս տարածքից: Մենք հրաձիգում մրցակից ենք ուզում, որից ինչ-որ բան սովորենք: Օրինակ՝ իմացեք քարտեզի լավագույն դիրքերի մասին։ Կամ մարտական ​​խաղի հակառակորդը, ով արգելափակում է խաղացողի հաճախակի օգտագործվող կոմբինացիոն շարժումները՝ դրդելով նրան օգտագործել ուրիշներին: Այսպիսով, մեքենայական ուսուցումը կարող է բավականին օգտակար լինել նման իրավիճակներում:

Վիճակագրություն և հավանականություններ

Նախքան բարդ օրինակների մեջ մտնելը, տեսնենք, թե որքան հեռու կարող ենք գնալ՝ կատարելով մի քանի պարզ չափումներ և դրանք օգտագործելով որոշումներ կայացնելու համար: Օրինակ՝ իրական ժամանակի ռազմավարություն. ինչպե՞ս ենք մենք որոշել, թե արդյոք խաղացողը կարող է հարձակվել խաղի առաջին մի քանի րոպեներին և ինչ պաշտպանություն պատրաստել դրա դեմ: Մենք կարող ենք ուսումնասիրել խաղացողի անցյալի փորձը՝ հասկանալու համար, թե ինչպիսին կարող են լինել ապագա արձագանքները: Սկզբից մենք չունենք նման հում տվյալներ, բայց կարող ենք հավաքել դրանք՝ ամեն անգամ, երբ AI-ն խաղում է մարդու դեմ, այն կարող է գրանցել առաջին հարձակման ժամանակը: Մի քանի սեանսից հետո մենք կստանանք միջինը, թե որքան ժամանակ կպահանջվի խաղացողի համար ապագա հարձակման համար:

Կա նաև միջին արժեքների խնդիր. եթե խաղացողը շտապել է 20 անգամ և դանդաղ խաղացել 20 անգամ, ապա պահանջվող արժեքները կլինեն ինչ-որ տեղ մեջտեղում, և դա մեզ ոչ մի օգտակար բան չի տա: Լուծումներից մեկը մուտքագրման տվյալները սահմանափակելն է. կարելի է հաշվի առնել վերջին 20 կտորները:

Նմանատիպ մոտեցում է կիրառվում որոշակի գործողությունների հավանականությունը գնահատելիս՝ ենթադրելով, որ խաղացողի նախկին նախապատվությունները ապագայում նույնն են լինելու: Եթե ​​խաղացողը հարձակվում է մեզ վրա հինգ անգամ հրե գնդակով, երկու անգամ կայծակով և մեկ անգամ՝ մենամարտով, ապա ակնհայտ է, որ նա գերադասում է հրե գնդակը։ Եկեք էքստրապոլյացիա անենք և տեսնենք տարբեր զենքերի կիրառման հավանականությունը՝ հրե գնդակ=62,5%, կայծակ=25% և մենամարտ=12,5%։ Մեր խաղային AI-ն պետք է պատրաստվի կրակից պաշտպանվելու համար:

Մեկ այլ հետաքրքիր մեթոդ է օգտագործել Naive Bayes դասակարգիչը՝ մեծ քանակությամբ մուտքային տվյալներ ուսումնասիրելու և իրավիճակը դասակարգելու համար, որպեսզի AI-ն արձագանքի ցանկալի ձևով: Բայեսյան դասակարգիչներն առավել հայտնի են էլեկտրոնային փոստի սպամի զտիչներում դրանց օգտագործման համար: Այնտեղ նրանք ուսումնասիրում են բառերը, համեմատում դրանք նախկինում նշված բառերի հետ (սպամում, թե ոչ) և եզրակացություններ են անում մուտքային նամակների վերաբերյալ: Մենք կարող ենք նույն բանն անել նույնիսկ ավելի քիչ մուտքերով: Հիմնվելով AI-ի տեսած բոլոր օգտակար տեղեկատվության վրա (օրինակ, թե ինչ թշնամու ստորաբաժանումներ են ստեղծվում, կամ ինչ հմայքներ են նրանք օգտագործում, կամ ինչ տեխնոլոգիաներ են նրանք ուսումնասիրել), և վերջնական արդյունքը (պատերազմ կամ խաղաղություն, շտապում կամ պաշտպանում և այլն) - մենք կընտրենք AI-ի ցանկալի վարքագիծը:

Վերապատրաստման այս բոլոր մեթոդները բավարար են, սակայն նպատակահարմար է դրանք օգտագործել թեստավորման տվյալների հիման վրա: AI-ն կսովորի հարմարվել տարբեր ռազմավարություններին, որոնք օգտագործել են ձեր խաղացողները: AI, որը հարմարվում է խաղացողին թողարկումից հետո, կարող է դառնալ չափազանց կանխատեսելի կամ չափազանց դժվար՝ հաղթելը:

Արժեքի վրա հիմնված հարմարվողականություն

Հաշվի առնելով մեր խաղի աշխարհի բովանդակությունը և կանոնները, մենք կարող ենք փոխել արժեքների շարքը, որոնք ազդում են որոշումների կայացման վրա, այլ ոչ թե պարզապես օգտագործելու մուտքային տվյալները: Մենք անում ենք սա.

• Թող AI-ն հավաքի տվյալներ աշխարհի վիճակի և խաղի ընթացքում հիմնական իրադարձությունների վերաբերյալ (ինչպես վերևում):
• Այս տվյալների հիման վրա փոխենք մի քանի կարևոր արժեք։
• Մենք իրականացնում ենք մեր որոշումները՝ հիմնվելով այդ արժեքների մշակման կամ գնահատման վրա:

Օրինակ, գործակալն ունի մի քանի սենյակ, որոնցից կարող է ընտրել առաջին դեմքի հրաձիգ քարտեզի վրա: Յուրաքանչյուր սենյակ ունի իր արժեքը, որը որոշում է, թե որքանով է ցանկալի այցելել: AI-ը պատահականորեն ընտրում է, թե որ սենյակ գնալ՝ ելնելով արժեքից: Գործակալը հետո հիշում է, թե որ սենյակում է սպանվել և նվազեցնում է դրա արժեքը (հավանականությունը, որ նա կվերադառնա այնտեղ): Նմանապես հակառակ իրավիճակի դեպքում. եթե գործակալը ոչնչացնում է շատ հակառակորդների, ապա սենյակի արժեքը մեծանում է:

Մարկովի մոդել

Իսկ եթե մենք օգտագործեինք հավաքագրված տվյալները կանխատեսումներ անելու համար: Եթե ​​հիշենք յուրաքանչյուր սենյակ, որում տեսնում ենք խաղացողին որոշակի ժամանակահատվածում, մենք կկանխատեսենք, թե որ սենյակ կարող է գնալ խաղացողը: Հետևելով և գրանցելով խաղացողի շարժումները սենյակներում (արժեքներ), մենք կարող ենք կանխատեսել դրանք:

Վերցնենք երեք սենյակ՝ կարմիր, կանաչ և կապույտ։ Եվ նաև այն դիտարկումները, որոնք մենք արձանագրել ենք խաղի նիստը դիտելիս.

Յուրաքանչյուր սենյակում դիտումների թիվը գրեթե հավասար է. մենք դեռ չգիտենք, թե որտեղ կարելի է լավ տեղ պատրաստել դարանակալման համար: Վիճակագրություն հավաքելը նույնպես բարդանում է խաղացողների վերարտադրմամբ, որոնք հավասարապես հայտնվում են քարտեզի վրա: Բայց քարտեզի վրա հայտնվելուց հետո հաջորդ սենյակի մասին տվյալները արդեն օգտակար են։

Երևում է, որ կանաչ սենյակը համապատասխանում է խաղացողներին. մարդկանց մեծ մասը կարմիր սենյակից տեղափոխվում է այնտեղ, որոնց 50%-ը մնում է այնտեղ։ Կապույտ սենյակը, ընդհակառակը, հայտնի չէ, գրեթե ոչ ոք չի գնում այնտեղ, իսկ եթե գնում է, ապա երկար չեն մնում:

Բայց տվյալները մեզ ավելի կարևոր բան են ասում. երբ խաղացողը կապույտ սենյակում է, հաջորդ սենյակը, որում մենք տեսնում ենք նրան, կլինի կարմիր, ոչ թե կանաչ: Թեև կանաչ սենյակն ավելի հայտնի է, քան կարմիր սենյակը, իրավիճակը փոխվում է, եթե խաղացողը կապույտ սենյակում է: Հաջորդ վիճակը (այսինքն այն սենյակը, ուր խաղացողը կգնա) կախված է նախորդ վիճակից (այսինքն այն սենյակը, որտեղ խաղացողը ներկայումս գտնվում է): Քանի որ մենք ուսումնասիրում ենք կախվածությունները, մենք ավելի ճշգրիտ կանխատեսումներ կանենք, քան եթե մենք ուղղակի անկախ հաշվեինք դիտարկումները:

Անցյալ վիճակի տվյալների հիման վրա ապագա վիճակի կանխատեսումը կոչվում է Մարկովյան մոդել, իսկ նման օրինակները (սենյակներով) կոչվում են Մարկովյան շղթաներ։ Քանի որ օրինաչափությունները ներկայացնում են հաջորդական վիճակների միջև փոփոխությունների հավանականությունը, դրանք տեսողականորեն ցուցադրվում են որպես FSM-ներ՝ յուրաքանչյուր անցման շուրջ հավանականությամբ: Նախկինում մենք օգտագործում էինք FSM՝ ներկայացնելու վարքագծային վիճակը, որում գտնվում էր գործակալը, բայց այս հայեցակարգը տարածվում է ցանկացած վիճակի վրա՝ անկախ նրանից՝ կապված է գործակալի հետ, թե ոչ: Այս դեպքում նահանգները ներկայացնում են այն սենյակը, որը զբաղեցնում է գործակալը.

Սա վիճակի փոփոխությունների հարաբերական հավանականությունը ներկայացնելու պարզ միջոց է, որը AI-ին տալիս է հաջորդ վիճակը կանխատեսելու որոշակի հնարավորություն: Դուք կարող եք կանխատեսել մի քանի քայլ առաջ:

Եթե ​​խաղացողը գտնվում է կանաչ սենյակում, ապա 50% հավանականություն կա, որ նա կմնա այնտեղ հաջորդ անգամ, երբ իրեն դիտարկեն: Բայց որքա՞ն են շանսերը, որ նույնիսկ դրանից հետո նա դեռ այնտեղ կլինի։ Ոչ միայն հնարավորություն կա, որ խաղացողը երկու դիտարկումներից հետո մնաց կանաչ սենյակում, այլ նաև հնարավորություն կա, որ նա հեռացավ ու վերադարձավ։ Ահա նոր աղյուսակը՝ հաշվի առնելով նոր տվյալները.

Այն ցույց է տալիս, որ երկու դիտումներից հետո խաղացողին կանաչ սենյակում տեսնելու հնարավորությունը հավասար կլինի 51%-ի - 21%-ի, որ նա կլինի կարմիր սենյակից, 5%-ը, որ խաղացողը կայցելի նրանց միջև եղած կապույտ սենյակ, և 25%-ը, որ խաղացողը չի անի, կլքի կանաչ սենյակը:

Աղյուսակը պարզապես տեսողական գործիք է. ընթացակարգը պահանջում է միայն բազմապատկել հավանականությունները յուրաքանչյուր քայլում: Սա նշանակում է, որ դուք կարող եք հեռու նայել ապագային մեկ նախազգուշացումով. մենք ենթադրում ենք, որ սենյակ մտնելու հնարավորությունն ամբողջությամբ կախված է ներկայիս սենյակից: Սա կոչվում է Մարկովյան սեփականություն. ապագա վիճակը կախված է միայն ներկայից: Բայց սա հարյուր տոկոսով ճշգրիտ չէ։ Խաղացողները կարող են փոխել որոշումները՝ կախված այլ գործոններից՝ առողջական մակարդակից կամ զինամթերքի քանակից: Քանի որ մենք չենք գրանցում այս արժեքները, մեր կանխատեսումները ավելի քիչ ճշգրիտ կլինեն:

N-գրամ

Իսկ ի՞նչ կասեք մարտական ​​խաղի և խաղացողի կոմբինացիոն քայլերը կանխատեսելու օրինակի մասին: Նույնը! Բայց մեկ վիճակի կամ իրադարձության փոխարեն մենք կուսումնասիրենք ամբողջ հաջորդականությունը, որոնք կազմում են համակցված հարվածը:

Դա անելու եղանակներից մեկն այն է, որ յուրաքանչյուր մուտքագրումը (օրինակ՝ Kick, Punch կամ Block) պահել բուֆերում և ամբողջ բուֆերը գրել որպես իրադարձություն: Այսպիսով, խաղացողը մի քանի անգամ սեղմում է Kick, Kick, Punch՝ SuperDeathFist հարձակումն օգտագործելու համար, AI-ի համակարգը պահում է բոլոր մուտքերը բուֆերում և հիշում է վերջին երեքը, որոնք օգտագործվել են յուրաքանչյուր քայլում:

(Թավ տողերն այն են, երբ խաղացողը սկսում է SuperDeathFist հարձակումը):

AI-ը կտեսնի բոլոր տարբերակները, երբ խաղացողը ընտրի Kick-ը, որին հաջորդում է մեկ այլ Kick-ը, այնուհետև նկատում է, որ հաջորդ մուտքը միշտ Punch է: Սա թույլ կտա գործակալին կանխատեսել SuperDeathFist-ի համակցված շարժումը և հնարավորության դեպքում արգելափակել այն:

Իրադարձությունների այս հաջորդականությունը կոչվում է N-գրամ, որտեղ N-ը պահվող տարրերի թիվն է։ Նախորդ օրինակում դա 3 գրամ էր (եռագիր), ինչը նշանակում է, որ առաջին երկու մուտքերն օգտագործվում են երրորդը կանխատեսելու համար: Համապատասխանաբար, 5 գրամում առաջին չորս գրառումները կանխատեսում են հինգերորդը և այլն։

Դիզայները պետք է ուշադիր ընտրի N-գրամի չափը: Ավելի փոքր N-ը պահանջում է ավելի քիչ հիշողություն, բայց նաև պահում է ավելի քիչ պատմություն: Օրինակ, 2 գրամ (բիգրամ) ձայնագրելու է Kick, Kick կամ Kick, Punch, բայց չի կարողանա պահել Kick, Kick, Punch, այնպես որ AI-ն չի արձագանքի SuperDeathFist կոմբին:

Մյուս կողմից, ավելի մեծ թվերը պահանջում են ավելի շատ հիշողություն, և AI-ն ավելի դժվար կլինի մարզել, քանի որ շատ ավելի հնարավոր տարբերակներ կլինեն: Եթե ​​դուք երեք հնարավոր մուտք ունենայիք Kick, Punch կամ Block, և մենք օգտագործեինք 10 գրամ, դա կլիներ մոտ 60 հազար տարբեր տարբերակներ:

Բիգրամի մոդելը պարզ Մարկովյան շղթա է. յուրաքանչյուր անցյալ վիճակ/ընթացիկ վիճակ զույգը բիգրամ է, և դուք կարող եք կանխատեսել երկրորդ վիճակը՝ հիմնվելով առաջինի վրա: 3 գրամ և ավելի մեծ N-գրամները կարելի է համարել նաև որպես Մարկովյան շղթաներ, որտեղ բոլոր տարրերը (բացի N-գրամի վերջինից) միասին կազմում են առաջին վիճակը, իսկ վերջին տարրը՝ երկրորդը։ Մարտական ​​խաղի օրինակը ցույց է տալիս Kick and Kick վիճակից Kick and Punch վիճակի անցնելու հնարավորությունը: Մուտքային պատմության բազմաթիվ գրառումները դիտարկելով որպես մեկ միավոր, մենք ըստ էության փոխակերպում ենք մուտքագրման հաջորդականությունը ամբողջ վիճակի մասի: Սա մեզ տալիս է Մարկովի հատկությունը, որը թույլ է տալիս օգտագործել Մարկովի շղթաները՝ կանխատեսելու հաջորդ մուտքագրումը և գուշակելու, թե որ կոմբինացիոն քայլը կլինի հաջորդը:

Ամփոփում

Խոսեցինք արհեստական ​​ինտելեկտի զարգացման ամենատարածված գործիքների ու մոտեցումների մասին։ Մենք նաև նայեցինք այն իրավիճակներին, որոնցում դրանք պետք է օգտագործվեն և որտեղ դրանք հատկապես օգտակար են:

Սա պետք է բավարար լինի խաղի AI-ի հիմունքները հասկանալու համար: Բայց, իհարկե, սրանք բոլոր մեթոդները չեն։ Ավելի քիչ հայտնի, բայց ոչ պակաս արդյունավետ ներառում են.

• օպտիմիզացման ալգորիթմներ, ներառյալ լեռնագնացությունը, գրադիենտ վայրէջքը և գենետիկական ալգորիթմները
• հակառակորդների որոնման/պլանավորման ալգորիթմներ (մինիմաքս և ալֆա-բետա էտում)
• դասակարգման մեթոդներ (պերցեպտրոններ, նեյրոնային ցանցեր և օժանդակ վեկտոր մեքենաներ)
• գործակալների ընկալման և հիշողության մշակման համակարգեր
• AI-ի ճարտարապետական ​​մոտեցումներ (հիբրիդային համակարգեր, ենթաբազմության ճարտարապետություններ և AI համակարգերի ծածկման այլ եղանակներ)
• անիմացիոն գործիքներ (պլանավորում և շարժումների համակարգում)
• կատարողականի գործոններ (մանրամասների մակարդակ, ցանկացած պահի և ժամանակի կտրման ալգորիթմներ)

Առցանց ռեսուրսներ թեմայի վերաբերյալ.

1. GameDev.net-ն ունի բաժինը AI-ի վերաբերյալ հոդվածներով և ձեռնարկներովԻսկ форум.
2. AiGameDev.com պարունակում է բազմաթիվ շնորհանդեսներ և հոդվածներ խաղերի AI զարգացման հետ կապված թեմաների լայն շրջանակի վերաբերյալ:
3. GDC պահոց ներառում է թեմաներ GDC AI Summit-ից, որոնցից շատերը հասանելի են անվճար:
4. Կայքում կարելի է գտնել նաև օգտակար նյութեր AI Game Programmers Guild.
5. Թոմի Թոմփսոնը՝ AI հետազոտող և խաղերի մշակող, տեսանյութեր է պատրաստում YouTube-ում AI և Խաղեր կոմերցիոն խաղերում AI-ի բացատրությամբ և ուսումնասիրությամբ։

Գրքեր թեմայի շուրջ.

1. «Game AI Pro» գրքերի շարքը կարճ հոդվածների հավաքածու է, որը բացատրում է, թե ինչպես կիրառել կոնկրետ առանձնահատկություններ կամ ինչպես լուծել կոնկրետ խնդիրներ:

Խաղ AI Pro. Խաղային AI մասնագետների հավաքած իմաստություն
Խաղ AI Pro 2. Խաղային AI մասնագետների հավաքած իմաստություն
Խաղ AI Pro 3. Խաղային AI մասնագետների հավաքած իմաստություն

2. AI Game Programming Wisdom շարքը Game AI Pro շարքի նախորդն է: Այն պարունակում է ավելի հին մեթոդներ, բայց գրեթե բոլորը արդիական են նույնիսկ այսօր։

AI Game Programming Wisdom 1
AI Game Programming Wisdom 2
AI Game Programming Wisdom 3
AI Game Programming Wisdom 4

3. Արհեստական ​​բանականություն. ժամանակակից մոտեցում հիմնական տեքստերից մեկն է բոլորի համար, ովքեր ցանկանում են հասկանալ արհեստական ​​ինտելեկտի ընդհանուր ոլորտը: Սա խաղերի զարգացման մասին գիրք չէ, այն սովորեցնում է AI-ի հիմունքները:

Source: www.habr.com