Би тоглоомон дээр хиймэл оюун ухааны талаар сонирхолтой материалтай танилцсан. AI-ийн талаархи үндсэн зүйлийг энгийн жишээн дээр тайлбарлаж, дотор нь түүнийг хялбар хөгжүүлэх, дизайн хийхэд хэрэгтэй олон хэрэгсэл, аргууд байдаг. Хэрхэн, хаана, хэзээ хэрэглэх вэ гэдэг нь бас бий.
Ихэнх жишээнүүд псевдокодоор бичигдсэн тул програмчлалын ахисан түвшний мэдлэг шаардагддаггүй. Зүссэн хэсэгт зураг, gif бүхий 35 хуудас текст байгаа тул бэлэн байгаарай.
UPD. Би уучлалт гуйж байна, гэхдээ би энэ нийтлэлийг Хабре дээр орчуулсан . Та түүний хувилбарыг уншиж болно , гэхдээ ямар нэг шалтгааны улмаас нийтлэл миний хажуугаар өнгөрөв (би хайлтыг ашигласан боловч ямар нэг зүйл буруу болсон). Би тоглоом хөгжүүлэхэд зориулсан блог дээр бичиж байгаа тул орчуулгын хувилбараа захиалагчдад үлдээхээр шийдсэн (зарим цэгүүдийг өөр өөр форматтай, заримыг нь хөгжүүлэгчдийн зөвлөгөөгөөр зориуд орхисон).
AI гэж юу вэ?
Тоглоомын AI нь тухайн объект байгаа нөхцөл байдлаас хамааран ямар үйлдэл хийх ёстойг анхаарч үздэг. Үүнийг ихэвчлэн "ухаалаг агент" удирдлага гэж нэрлэдэг бөгөөд агент нь тоглогчийн дүр, тээврийн хэрэгсэл, робот эсвэл заримдаа илүү хийсвэр зүйл юм: бүхэл бүтэн бүлэг аж ахуйн нэгж эсвэл бүр соёл иргэншил. Тэр болгондоо орчноо харж, түүн дээрээ үндэслэн шийдвэр гаргаж, түүндээ нийцүүлэн ажиллах ёстой зүйл. Үүнийг Мэдрэх/Бодох/Үйлдэх мөчлөг гэж нэрлэдэг:
- Мэдрэхүй: Агент нь хүрээлэн буй орчиндоо түүний зан төлөвт нөлөөлж болзошгүй зүйлсийн талаарх мэдээллийг олж авах эсвэл хүлээн авах (ойролцоох аюул заналхийлэл, цуглуулах зүйлс, судлах сонирхолтой газрууд).
- Бодоод үз: Төлөөлөгч хэрхэн хариу үйлдэл үзүүлэхээ шийддэг (энэ нь эд зүйлсийг цуглуулахад хангалттай аюулгүй эсэх, эсвэл эхлээд тулалдах/нуух хэрэгтэй эсэхийг авч үзэх).
- Үйлдэл: төлөөлөгч өмнөх шийдвэрийг хэрэгжүүлэх үйлдлийг гүйцэтгэдэг (дайсан эсвэл объект руу хөдөлж эхэлдэг).
- ...одоо дүрүүдийн үйлдлээс болж нөхцөл байдал өөрчлөгдсөн тул шинэ өгөгдөлтэй мөчлөг давтагдаж байна.
AI нь гогцооны мэдрэхүйн хэсэгт анхаарлаа төвлөрүүлэх хандлагатай байдаг. Жишээлбэл, бие даасан машинууд замын зургийг авч, тэдгээрийг радар, лидарын мэдээлэлтэй нэгтгэж, тайлбарладаг. Энэ нь ихэвчлэн ирж буй өгөгдлийг боловсруулж, "таны өмнө 20 метрийн зайд өөр машин байна" гэх мэт семантик мэдээллийг гаргаж авдаг машин сургалтаар хийгддэг. Эдгээр нь ангиллын асуудал гэж нэрлэгддэг асуудлууд юм.
Мэдээллийн ихэнх хэсэг нь аль хэдийн салшгүй хэсэг болсон тул тоглоомуудад мэдээлэл задлахад нарийн төвөгтэй систем хэрэггүй. Урьд нь дайсан байгаа эсэхийг тодорхойлохын тулд дүрсийг таних алгоритмуудыг ажиллуулах шаардлагагүй—тоглоом аль хэдийн мэдэж, шийдвэр гаргах үйл явцад шууд мэдээлэл өгдөг. Тиймээс мөчлөгийн мэдрэхүйн хэсэг нь "Бод, үйлд" хэсгээс хамаагүй хялбар байдаг.
Тоглоомын AI-ийн хязгаарлалт
AI нь дагаж мөрдөх ёстой хэд хэдэн хязгаарлалттай байдаг:
- Хиймэл оюун ухаан нь машин сургалтын алгоритм юм шиг урьдчилан сургах шаардлагагүй. Хөгжүүлэлтийн явцад хэдэн арван мянган тоглогчдыг хянаж, тэдний эсрэг тоглох хамгийн сайн аргыг сурахын тулд мэдрэлийн сүлжээ бичих нь утгагүй юм. Яагаад? Учир нь тоглоом гараагүй, тоглогч байхгүй.
- Тоглоом нь хөгжилтэй, сорилттой байх ёстой тул агентууд хүмүүсийн эсрэг хамгийн сайн арга замыг олох ёсгүй.
- Тоглогчид бодит хүмүүсийн эсрэг тоглож байгаа мэт сэтгэгдэл төрүүлэхийн тулд агентууд бодитой харагдах ёстой. AlphaGo хөтөлбөр нь хүнээс илүү гарсан боловч сонгосон алхмууд нь тоглоомын талаарх уламжлалт ойлголтоос маш хол байсан. Хэрэв тоглоом нь хүний өрсөлдөгчийг дуурайдаг бол энэ мэдрэмж байх ёсгүй. Алгоритмыг өөрчлөх хэрэгтэй бөгөөд ингэснээр хамгийн тохиромжтой шийдвэр биш харин үнэмшилтэй шийдвэр гаргах болно.
- AI бодит цаг хугацаанд ажиллах ёстой. Энэ нь алгоритм шийдвэр гаргахын тулд CPU-ийн хэрэглээг удаан хугацаагаар монопольчилж чадахгүй гэсэн үг юм. 10 миллисекунд ч гэсэн хэтэрхий урт, учир нь ихэнх тоглоомууд бүх боловсруулалтыг хийж, дараагийн график фрэйм рүү шилжихэд ердөө 16-33 миллисекунд шаардлагатай байдаг.
- Хамгийн сайн нь системийн ядаж хэсэг нь өгөгдөлд тулгуурласан байх ёстой бөгөөд ингэснээр кодлогч бус хүмүүс өөрчлөлт хийж, тохируулга илүү хурдан хийх боломжтой болно.
Мэдрэх/Бодох/Үйлдэл хийх мөчлөгийг бүхэлд нь хамарсан хиймэл оюун ухааны аргуудыг харцгаая.
Үндсэн шийдвэр гаргах
Хамгийн энгийн тоглоом болох Понгоос эхэлцгээе. Зорилго: Бөмбөгийг хажуугаар нь нисэхийн оронд сэлүүрээр хөдөлгө. Бөмбөг цохихгүй бол хожигддог теннис шиг. Энд хиймэл оюун ухаан харьцангуй хялбар даалгавартай - платформыг аль чиглэлд шилжүүлэхээ шийдэх.
Болзолт мэдэгдлүүд
Понг дахь AI-ийн хувьд хамгийн тодорхой шийдэл бол платформыг бөмбөгний доор байрлуулахыг хичээх явдал юм.
Үүнийг псевдокодоор бичсэн энгийн алгоритм:
Тоглоом ажиллаж байх үеийн хүрээ/шинэчлэлт бүр:
хэрэв бөмбөг сэлүүрийн зүүн талд байвал:
сэлүүрийг зүүн тийш хөдөлгө
Хэрэв бөмбөг сэлүүрийн баруун талд байвал:
сэлүүрийг баруун тийш хөдөлгө
Хэрэв платформ бөмбөгний хурдаар хөдөлдөг бол энэ нь Понг дахь AI-ийн хамгийн тохиромжтой алгоритм юм. Хэрэв төлөөлөгчийн хувьд тийм их мэдээлэл, боломжит арга хэмжээ байхгүй бол юу ч хүндрүүлэх шаардлагагүй.
Энэ арга нь маш энгийн тул Мэдрэх/Бодох/Үйлдэх мөчлөг бүхэлдээ бараг анзаарагдахгүй. Гэхдээ тэнд байна:
- Мэдрэхүйн хэсэг нь хоёр if хэллэгтэй. Тоглоом нь бөмбөг хаана, платформ хаана байгааг мэддэг тул хиймэл оюун ухаан нь энэ мэдээллийг хайж байдаг.
- Think хэсэг нь if илэрхийлэлд мөн багтсан болно. Эдгээр нь хоёр шийдлийг агуулсан бөгөөд энэ тохиолдолд бие биенээ үгүйсгэдэг. Үүний үр дүнд гурван үйлдлийн аль нэгийг сонгосон - платформыг зүүн тийш нь хөдөлгөж, баруун тийш шилжүүлж, аль хэдийн зөв байрлуулсан бол юу ч хийхгүй.
- Үйлдлийн хэсгийг Move Paddle Left болон Move Paddle Right хэллэгүүдээс олж болно. Тоглоомын загвараас хамааран тэд платформыг шууд эсвэл тодорхой хурдаар хөдөлгөж болно.
Ийм хандлагыг реактив гэж нэрлэдэг - дэлхийн өнөөгийн байдалд хариу үйлдэл үзүүлж, арга хэмжээ авдаг энгийн дүрмүүд байдаг (энэ тохиолдолд код дахь мэдэгдлүүд).
Шийдвэрийн мод
Понгийн жишээ нь шийдвэрийн мод гэж нэрлэгддэг албан ёсны AI ойлголттой дүйцэхүйц юм. Алгоритм нь "навч" -д хүрэхийн тулд үүнийг дамждаг - ямар арга хэмжээ авах тухай шийдвэр.
Платформынхаа алгоритмын хувьд шийдвэрийн модны блок диаграммыг хийцгээе.
Модны хэсэг бүрийг зангилаа гэж нэрлэдэг - AI ийм бүтцийг дүрслэхийн тулд график онолыг ашигладаг. Хоёр төрлийн зангилаа байдаг:
- Шийдвэрлэх зангилаа: Альтернатив бүрийг тусдаа зангилаа хэлбэрээр харуулсан зарим нөхцөлийг туршиж үзсэний үндсэн дээр хоёр хувилбараас сонгох.
- Төгсгөлийн зангилаа: Эцсийн шийдвэрийг илэрхийлсэн гүйцэтгэх үйлдэл.
Алгоритм нь эхний зангилаанаас (модны "үндэс") эхэлдэг. Энэ нь аль хүүхэд зангилаа руу очихоо шийднэ, эсвэл зангилаанд хадгалагдсан үйлдлийг гүйцэтгээд гарна.
Шийдвэрийн мод өмнөх хэсэгт байгаа if хэллэгтэй ижил үүрэг гүйцэтгэх нь ямар ашигтай вэ? Шийдвэр бүр нь зөвхөн нэг нөхцөл, хоёр боломжит үр дагавартай байдаг ерөнхий систем энд байна. Энэ нь хөгжүүлэгчдэд хатуу кодлохгүйгээр модны шийдвэрийг төлөөлөх өгөгдлөөс хиймэл оюун ухаан үүсгэх боломжийг олгодог. Үүнийг хүснэгт хэлбэрээр үзүүлье.
Кодын тал дээр та мөрүүдийг унших системийг авах болно. Тэд тус бүрт зангилаа үүсгэж, хоёр дахь багана дээр үндэслэн шийдвэрийн логик, гурав, дөрөв дэх багана дээр тулгуурлан хүүхдийн зангилааг холбоно. Та нөхцөл байдал, үйлдлүүдийг програмчлах шаардлагатай хэвээр байгаа боловч одоо тоглоомын бүтэц илүү төвөгтэй байх болно. Энд та нэмэлт шийдвэр, үйлдлүүд нэмж, дараа нь модны тодорхойлолтын текст файлыг засварлах замаар хиймэл оюун ухааныг бүхэлд нь өөрчлөх боломжтой. Дараа нь та файлыг тоглоомын дизайнер руу шилжүүлэх бөгөөд тоглоомыг дахин эмхэтгэх эсвэл кодыг өөрчлөхгүйгээр зан төлөвийг өөрчлөх боломжтой.
Шийдвэрийн мод нь олон тооны жишээнүүдээс автоматаар бүтээгдсэн тохиолдолд маш их хэрэгтэй байдаг (жишээлбэл, ID3 алгоритмыг ашиглан). Энэ нь тэдгээрийг олж авсан өгөгдөл дээр үндэслэн нөхцөл байдлыг ангилах үр дүнтэй, өндөр үзүүлэлттэй хэрэгсэл болгодог. Гэсэн хэдий ч бид агентуудад үйлдлүүдийг сонгох энгийн системээс давж гардаг.
Хувилбарууд
Бид урьдчилан бий болгосон нөхцөл, үйлдлийг ашигласан шийдвэрийн модны системд дүн шинжилгээ хийсэн. AI зохион бүтээгч хүн модыг хүссэнээрээ зохион байгуулж чадна, гэхдээ тэр бүгдийг программчилсан кодлогчдоо найдах ёстой. Хэрэв бид загвар зохион бүтээгчид өөрийн нөхцөл байдал, үйлдлүүдийг бий болгох хэрэгслийг өгч чадвал яах вэ?
Програмист нь Is Ball Left Of Paddle, Is Ball Right Of Paddle гэсэн нөхцлийн код бичих шаардлагагүй тул дизайнер эдгээр утгыг шалгах нөхцөлийг бичих системийг бий болгож чадна. Дараа нь шийдвэрийн модны өгөгдөл дараах байдлаар харагдах болно.
Энэ нь үндсэндээ эхний хүснэгттэй адил боловч шийдлүүд нь if хэллэгийн нөхцөлт хэсэгтэй адил өөрийн гэсэн кодтой байдаг. Кодын талаас энэ нь шийдвэрийн цэгүүдийн хоёр дахь баганад унших боловч гүйцэтгэх тодорхой нөхцөл хайхын оронд (Is Ball Left Of Paddle) нөхцөлт илэрхийллийг үнэлж, үнэн эсвэл худал утгыг буцаана. Үүнийг Lua эсвэл Angelscript скрипт хэл ашиглан хийдэг. Тэдгээрийг ашигласнаар хөгжүүлэгч тоглоомондоо объектуудыг (бөмбөг, сэлүүрт) авч, скриптэд (ball.position) боломжтой хувьсагчдыг үүсгэж болно. Мөн скрипт бичих хэл нь C++-ээс хялбар байдаг. Энэ нь бүрэн эмхэтгэлийн үе шат шаарддаггүй тул тоглоомын логикийг хурдан тохируулахад тохиромжтой бөгөөд "кодлогч бус" хүмүүст шаардлагатай функцийг өөрсдөө бий болгох боломжийг олгодог.
Дээрх жишээнд скрипт хэлийг зөвхөн нөхцөлт илэрхийллийг үнэлэхэд ашигладаг боловч үйлдлүүдэд ч ашиглаж болно. Жишээлбэл, Move Paddle Right өгөгдөл нь скрипт мэдэгдэл болж болно (ball.position.x += 10). Ингэснээр Move Paddle Right програмчлах шаардлагагүйгээр уг үйлдлийг скрипт дээр мөн тодорхойлсон болно.
Та цаашаа явж, шийдвэрийн модыг бүхэлд нь скрипт хэлээр бичиж болно. Энэ нь хатуу кодлогдсон нөхцөлт мэдэгдлийн хэлбэрээр код байх боловч тэдгээр нь гадаад скрипт файлуудад байрлах болно, өөрөөр хэлбэл програмыг бүхэлд нь дахин хөрвүүлэхгүйгээр өөрчлөх боломжтой. Та янз бүрийн AI хариултуудыг хурдан шалгахын тулд тоглоомын явцад скрипт файлыг засварлаж болно.
Үйл явдлын хариу үйлдэл
Дээрх жишээнүүд нь Понгийн хувьд төгс төгөлдөр юм. Тэд Мэдрэх/Бодох/Үйлдэх циклийг тасралтгүй ажиллуулж, дэлхийн хамгийн сүүлийн үеийн байдалд тулгуурлан ажилладаг. Гэхдээ илүү төвөгтэй тоглоомуудад та хувь хүний үйл явдалд хариу үйлдэл үзүүлэх хэрэгтэй бөгөөд бүгдийг нэг дор үнэлж болохгүй. Энэ тохиолдолд Понг аль хэдийн муу жишээ болсон. Өөр нэгийг сонгоё.
Дайснууд тоглогчийг илрүүлэх хүртлээ хөдөлгөөнгүй, дараа нь "мэргэшсэн" байдлаасаа хамааран үйлдэл хийдэг мэргэн буучийг төсөөлөөд үз дээ: хэн нэгэн "яарах" гэж гүйж, хэн нэгэн алсаас довтлох болно. Энэ нь үндсэн реактив систем хэвээр байгаа - "хэрэв тоглогчийг олж харвал ямар нэгэн зүйл хий" - гэхдээ үүнийг логикоор Тоглогчийн харсан үйл явдал болон Reaction (хариултыг сонгоод гүйцэтгэнэ) болгон хувааж болно.
Энэ нь биднийг Мэдрэх/Бодох/Үйлдэх мөчлөг рүү буцаан авчирдаг. Бид AI тоглогчийг харж байгаа эсэхийг фрейм бүрийг шалгах Sense хэсгийг кодлох боломжтой. Үгүй бол юу ч болохгүй, гэхдээ харвал Player Seen үйл явдал үүснэ. Код нь "Тоглогчийн харагдац үйл явдал тохиолдоход хийх" гэсэн тусдаа хэсэгтэй байх болно. Тиймээс та Player Seen арга хэмжээнд хариу үйлдэл үзүүлэх болно: "яаралтай" дүрд - ChargeAndAttack, мэргэн бууч - HideAndSnipe. Эдгээр харилцааг өгөгдлийн файлд үүсгэж, дахин хөрвүүлэх шаардлагагүйгээр хурдан засварлах боломжтой. Скрипт хэлийг энд бас ашиглаж болно.
Хэцүү шийдвэр гаргах
Хэдийгээр энгийн урвалын системүүд нь маш хүчтэй боловч тэдгээр нь хангалтгүй байдаг олон нөхцөл байдал байдаг. Заримдаа та төлөөлөгчийн хийж байгаа зүйл дээр үндэслэн янз бүрийн шийдвэр гаргах шаардлагатай байдаг ч үүнийг нөхцөл гэж төсөөлөхөд хэцүү байдаг. Заримдаа тэдгээрийг шийдвэрийн мод эсвэл скрипт дээр үр дүнтэйгээр илэрхийлэхэд хэтэрхий олон нөхцөл байдаг. Заримдаа та дараагийн алхамаа шийдэхээсээ өмнө нөхцөл байдал хэрхэн өөрчлөгдөхийг урьдчилан үнэлэх хэрэгтэй. Эдгээр асуудлыг шийдвэрлэхийн тулд илүү боловсронгуй арга барил хэрэгтэй.
Хязгаарлагдмал төлөвийн машин
Төгсгөлийн төлөвийн машин буюу FSM (finite state machine) нь манай агент одоогоор хэд хэдэн боломжит төлөвийн аль нэгэнд байгаа бөгөөд энэ нь нэг төлөвөөс нөгөөд шилжиж чадна гэж хэлэх арга юм. Ийм мужууд тодорхой тооны байдаг - иймээс нэр. Амьдралаас хамгийн сайн жишээ бол гэрлэн дохио юм. Өөр өөр газруудад гэрлийн янз бүрийн дараалал байдаг боловч зарчим нь ижил байдаг - муж бүр ямар нэг зүйлийг (зогсоох, алхах гэх мэт) илэрхийлдэг. Гэрлэн дохио нь ямар ч үед зөвхөн нэг төлөвт байх бөгөөд энгийн дүрмийн дагуу нэгээс нөгөөд шилжинэ.
Тоглоом дахь NPC-тэй төстэй түүх юм. Жишээлбэл, дараах төлөвтэй хамгаалагчийг авч үзье.
- Эргүүл хийж байна.
- Довтолж байна.
- Зугтаж байна.
Мөн түүний төлөвийг өөрчлөх эдгээр нөхцөлүүд:
- Хэрэв хамгаалагч дайсныг харвал тэр дайрдаг.
- Хэрэв харуул довтолсон боловч дайсныг харахаа больсон бол тэрээр эргүүлд буцаж ирдэг.
- Хамгаалагч дайрсан ч хүнд шархадвал зугтдаг.
Та мөн асран хамгаалагчийн төлөвийн хувьсагчтай if-мэдэгдэл болон янз бүрийн шалгалтуудыг бичиж болно: ойролцоох дайсан байна уу, NPC-ийн эрүүл мэндийн түвшин ямар байна гэх мэт. Өөр хэдэн төлөвийг оруулъя:
- Сул зогсолт - эргүүлийн хооронд.
- Хайж байна - анзаарагдсан дайсан алга болсон үед.
- Тусламж хайх - дайсан илэрсэн боловч ганцаараа тулалдахад хэтэрхий хүчтэй байх үед.
Тэд тус бүрийн сонголт хязгаарлагдмал байдаг - жишээлбэл, харуул эрүүл мэнд муутай бол далд дайсан хайхгүй.
Эцсийн эцэст, "хэрэв" гэсэн асар том жагсаалт байдаг. , Тэр Энэ нь хэтэрхий төвөгтэй болж болзошгүй тул бид төлөв байдал, муж хоорондын шилжилтийг санаж байх боломжийг олгодог аргыг албан ёсны болгох хэрэгтэй. Үүнийг хийхийн тулд бид бүх муж улсуудыг харгалзан үзэж, муж бүрийн дор бусад муж руу шилжих шилжилтийг, шаардлагатай нөхцөлүүдийн хамт жагсаалтад бичдэг.
Энэ бол төрийн шилжилтийн хүснэгт - FSM-ийг төлөөлөх цогц арга юм. Диаграммыг зурж, NPC-ийн зан байдал хэрхэн өөрчлөгдөхийг бүрэн тоймлон авч үзье.
Диаграм нь одоогийн нөхцөл байдалд үндэслэн энэ төлөөлөгчийн шийдвэр гаргах мөн чанарыг тусгасан болно. Түүнээс гадна, сум бүр нь түүний хажууд байгаа нөхцөл үнэн бол төлөв хоорондын шилжилтийг харуулдаг.
Шинэчлэлт бүрт бид төлөөлөгчийн одоогийн төлөвийг шалгаж, шилжилтийн жагсаалтыг хардаг бөгөөд хэрэв шилжилтийн нөхцөл хангагдсан бол энэ нь шинэ төлөвийг хүлээн зөвшөөрдөг. Жишээлбэл, фрэйм бүр 10 секундын таймерын хугацаа дууссан эсэхийг шалгадаг бөгөөд хэрэв тийм бол хамгаалагч Сул зогсолтоос эргүүл рүү шилждэг. Үүнтэй адилаар, довтолж буй муж нь төлөөлөгчийн эрүүл мэндийг шалгадаг - хэрэв энэ нь бага байвал, зугтах төлөвт орно.
Энэ нь муж улсуудын хоорондын шилжилтийг зохицуулах явдал боловч муж улсуудтай холбоотой зан үйлийн талаар юу хэлэх вэ? Тодорхой мужид бодит зан үйлийг хэрэгжүүлэхийн тулд бид FSM-д үйлдлүүдийг хуваарилдаг хоёр төрлийн "дэгээ" байдаг:
- Одоогийн төлөв байдалд бидний үе үе хийдэг үйлдлүүд.
- Нэг төлөвөөс нөгөөд шилжих үед бидний хийдэг үйлдлүүд.
Эхний төрлийн жишээ. Эргүүл хийж буй муж нь агентийг эргүүлийн маршрутын дагуу кадр бүрт шилжүүлнэ. Довтолж буй муж нь фрэйм болгонд халдлага эхлүүлэхийг оролдох эсвэл боломжтой төлөв рүү шилжих болно.
Хоёрдахь төрлийн хувьд "хэрэв дайсан харагдаж байгаа бөгөөд дайсан хэтэрхий хүчтэй бол "Filing Help" руу очно уу. Агент нь тусламж авахын тулд хаашаа хандахаа сонгож, энэ мэдээллийг хадгалах ёстой бөгөөд ингэснээр Finding Help муж хаашаа явахаа мэддэг байх ёстой. Тусламж олсны дараа агент довтлох төлөв рүү буцна. Энэ үед тэрээр аюул заналхийллийн талаар холбоотондоо хэлэхийг хүсэх тул NotifyFriendOfThreat үйлдэл гарч болзошгүй.
Дахин нэг удаа бид энэ системийг Мэдрэх/Бодох/Үйлдэх циклийн линзээр харж болно. Мэдрэхүй нь шилжилтийн логикийн ашигладаг өгөгдөлд тусгагдсан байдаг. Бодоорой - муж бүрт шилжилт хийх боломжтой. Мөн акт нь муж улсын дотор эсвэл муж хоорондын шилжилтийн үед үе үе хийгддэг үйлдлээр хийгддэг.
Заримдаа тасралтгүй санал хураах шилжилтийн нөхцөл нь өндөр өртөгтэй байж болно. Жишээлбэл, хэрэв агент бүр дайснуудыг харж чадах эсэхээ тодорхойлохын тулд нарийн төвөгтэй тооцоолол хийж, эргүүлээс довтолж байгаа төлөв рүү шилжиж чадах эсэхээ ойлгоход CPU-д маш их цаг зарцуулагдана.
Дэлхийн төлөв байдалд гарсан чухал өөрчлөлтүүд нь тохиолдох тусам боловсруулагдах үйл явдлууд гэж үзэж болно. FSM нь "Миний агент тоглуулагчийг харж чадах уу?" гэсэн шилжилтийн нөхцөлийг фрейм бүрт шалгахын оронд тусдаа системийг бага давтамжтайгаар (жишээ нь секундэд 5 удаа) шалгахаар тохируулж болно. Мөн үр дүн нь шалгалт өнгөрөх үед Player Seen гаргах явдал юм.
Үүнийг FSM-д дамжуулдаг бөгөөд энэ нь одоо Тоглогчийн харсан үйл явдлын хүлээн авсан нөхцөл рүү очиж, зохих хариу өгөх ёстой. Хариу өгөхөөс өмнө бараг анзаарагдахгүй удаашрахыг эс тооцвол үр дүн нь ижил байна. Гэвч Мэдрэхүйн хэсгийг тусад нь хөтөлбөрийн хэсэг болгон салгасны үр дүнд гүйцэтгэл сайжирсан.
Шаталсан төгсгөлтэй төлөвийн машин
Гэсэн хэдий ч томоохон FSM-тэй ажиллах нь үргэлж тохиромжтой байдаггүй. Хэрэв бид MeleeAttacking болон Ranged Attacking-ийг салгахын тулд халдлагын төлөвийг өргөжүүлэхийг хүсвэл бид дайралт хийх төлөв рүү (одоо ба ирээдүй) хүргэдэг бусад бүх мужаас шилжилтийг өөрчлөх шаардлагатай болно.
Манай жишээнд давхардсан шилжилтүүд их байгааг та анзаарсан байх. Сул зогсолтын төлөв дэх ихэнх шилжилтүүд нь эргүүлийн төлөв дэх шилжилтүүдтэй ижил байдаг. Өөрсдийгөө давтахгүй, ялангуяа ижил төстэй мужуудыг нэмбэл сайхан байх болно. Байлдааны мужид шилжих шилжилтийн цорын ганц нийтлэг багц байдаг тул "Байлдааны бус" гэсэн ерөнхий шошгон дээр Сул зогсолт, эргүүлийг бүлэглэх нь утга учиртай юм. Хэрэв бид энэ шошгыг муж гэж бодох юм бол Сул зогсолт, эргүүл нь дэд муж болно. Байлдааны бус шинэ дэд мужид шилжилтийн тусдаа хүснэгт ашиглах жишээ:
Үндсэн мужууд:
Байлдааны бус байдал:
Мөн диаграм хэлбэрээр:
Энэ нь ижил систем боловч Сул зогсолт болон эргүүлийг багтаасан байлдааны бус шинэ мужтай. Дэд мужууд бүхий FSM агуулсан муж бүр (мөн эдгээр дэд мужууд нь эргээд өөрийн FSM-ийг агуулсан байдаг - гэх мэт танд хэрэгтэй үед) бид шаталсан төгсгөлийн төлөвийн машин эсвэл HFSM (шаталсан төгсгөлийн төлөвийн машин) авдаг. Байлдааны бус байдлыг бүлэглэснээр бид олон тооны илүүдэл шилжилтийг таслав. Бид нийтлэг шилжилттэй аливаа шинэ мужуудын хувьд ижил зүйлийг хийж чадна. Жишээлбэл, хэрэв бид ирээдүйд Довтолж буй төлөвийг ойр дотны болон пуужингийн довтолгооны муж болгон өргөжүүлэх юм бол тэдгээр нь дайсан хүртэлх зай, сумны бэлэн байдлаас хамааран өөр хоорондоо шилжиж буй дэд мужууд байх болно. Үүний үр дүнд нарийн төвөгтэй зан үйл, дэд зан үйлийг хамгийн бага давхардсан шилжилтээр төлөөлж болно.
Зан төлөвийн мод
HFSM-ийн тусламжтайгаар зан үйлийн цогц хослолыг энгийн аргаар бүтээдэг. Гэсэн хэдий ч шилжилтийн дүрмийн хэлбэрээр шийдвэр гаргах нь өнөөгийн байдалтай нягт холбоотой байдаг нь бага зэрэг хүндрэлтэй байдаг. Мөн олон тоглоомд энэ нь яг хэрэгтэй зүйл юм. Мөн төрийн шатлалыг болгоомжтой ашиглах нь шилжилтийн давталтын тоог бууруулж чадна. Гэхдээ заримдаа танд ямар ч муж улсад үйлчилдэг, эсвэл бараг бүх мужид үйлчилдэг дүрэм хэрэгтэй болдог. Жишээлбэл, хэрэв төлөөлөгчийн эрүүл мэнд 25% болтлоо буурсан бол та түүнийг тулаанд байсан, сул зогссон, ярьж байсан эсэхээс үл хамааран зугтахыг хүсэх болно - та муж бүрт энэ нөхцлийг нэмэх хэрэгтэй болно. Хэрэв таны загвар зохион бүтээгч эрүүл мэндийн бага босгыг 25% -иас 10% болгон өөрчлөхийг хүсвэл үүнийг дахин хийх шаардлагатай болно.
Энэ нөхцөл байдал нь зөвхөн нэг газар өөрчлөлт хийх, шилжилтийн нөхцөлийг хөндөхгүй байхын тулд "ямар мужид байх вэ" гэсэн шийдвэр нь мужуудаас гадуур байдаг тогтолцоог шаарддаг. Энд зан үйлийн мод гарч ирдэг.
Тэдгээрийг хэрэгжүүлэх хэд хэдэн арга байдаг боловч мөн чанар нь бүгдэд адилхан бөгөөд шийдвэрийн модтой төстэй: алгоритм нь "үндэс" зангилаанаас эхэлдэг бөгөөд мод нь шийдвэр эсвэл үйлдлийг илэрхийлдэг зангилаануудыг агуулдаг. Гэсэн хэдий ч хэд хэдэн гол ялгаа байдаг:
- Зангилаанууд одоо гурван утгын аль нэгийг буцаана: Амжилттай (хэрэв ажил дууссан бол), Амжилтгүй (хэрэв эхлүүлэх боломжгүй бол) эсвэл Ажиллаж байна (хэрэв энэ нь ажиллаж байгаа бөгөөд эцсийн үр дүн байхгүй бол).
- Хоёр хувилбарын аль нэгийг сонгох шийдвэр гаргах цэг байхгүй болсон. Үүний оронд тэдгээр нь нэг хүүхэд зангилаатай Decorator зангилаанууд юм. Хэрэв тэд амжилтанд хүрвэл цорын ганц хүүхэд зангилааг гүйцэтгэдэг.
- Үйлдлийг гүйцэтгэдэг зангилаа нь гүйцэтгэсэн үйлдлүүдийг илэрхийлэхийн тулд Running утгыг буцаана.
Энэхүү жижиг зангилааны багцыг нэгтгэж, олон тооны нарийн төвөгтэй зан үйлийг бий болгож чадна. Өмнөх жишээн дээрх HFSM хамгаалагчийг зан төлөвийн мод гэж төсөөлөөд үз дээ:
Энэ бүтцээр Сул зогсолт/Эргүүлээс довтолж байгаа болон бусад муж руу шилжих нь тодорхой байх ёсгүй. Хэрэв дайсан харагдах бөгөөд дүрийн эрүүл мэнд муу байвал гүйцэтгэх ажиллагаа нь өмнө нь эргүүл хийх, сул зогсох, довтлох гэх мэт аль зангилаанаас үл хамааран зугтах цэг дээр зогсох болно.
Зан төлөвийн мод нь нарийн төвөгтэй байдаг - тэдгээрийг зохиох олон арга байдаг бөгөөд гоёл чимэглэлийн болон нийлмэл зангилааны зөв хослолыг олох нь хэцүү байж болно. Мөн модыг хэр олон удаа шалгах вэ гэсэн асуултууд гарч ирдэг - бид түүний хэсэг бүрийг үзэхийг хүсч байна уу эсвэл зөвхөн аль нэг нөхцөл өөрчлөгдсөн үед? Бид зангилаатай холбоотой төлөвийг хэрхэн хадгалах вэ - бид 10 секундын турш идэвхгүй байсан үеийг яаж мэдэх вэ, эсвэл дарааллыг зөв боловсруулахын тулд хамгийн сүүлд аль зангилаа ажиллаж байсныг яаж мэдэх вэ?
Тийм ч учраас олон хэрэгжилт байдаг. Жишээлбэл, зарим системүүд гоёл чимэглэлийн зангилааг доторлогоотой чимэглэгчээр сольсон. Тэд гоёл чимэглэлийн нөхцөл өөрчлөгдөхөд модыг дахин үнэлж, зангилаануудыг нэгтгэхэд тусалж, үе үе шинэчлэлт хийдэг.
Хэрэглээнд суурилсан систем
Зарим тоглоомууд олон янзын механиктай байдаг. Тэд энгийн бөгөөд ерөнхий шилжилтийн дүрмийн бүх ашиг тусыг авах нь зүйтэй боловч зан үйлийн бүрэн мод хэлбэрээр байх албагүй. Тодорхой сонголтууд эсвэл боломжит үйлдлүүдийн модтой байхын оронд бүх үйлдлүүдийг шалгаж, хамгийн тохиромжтойг нь сонгох нь илүү хялбар байдаг.
Utility-д суурилсан систем нь үүнийг хийхэд тусална. Энэ нь агент нь янз бүрийн үйлдэлтэй бөгөөд тус бүрийн харьцангуй ашигтай байдалд үндэслэн алийг нь гүйцэтгэхээ сонгодог систем юм. Хэрэгцээ гэдэг нь төлөөлөгчийн хувьд энэ үйлдлийг гүйцэтгэх нь хэр чухал эсвэл хүсч байгааг дурын хэмжүүр юм.
Тухайн үеийн төлөв байдал, хүрээлэн буй орчинд тулгуурласан үйлдлийн тооцоолсон хэрэглүүрийг агент хүссэн үедээ шалгаж, өөр хамгийн тохиромжтой төлөвийг сонгох боломжтой. Энэ нь шилжилтийг боломжит төлөв бүр, түүний дотор одоогийнх нь тооцоогоор тодорхойлогдохоос бусад тохиолдолд FSM-тэй төстэй юм. Бид үргэлжлүүлэхийн тулд хамгийн хэрэгтэй үйлдлийг сонгодог гэдгийг анхаарна уу (эсвэл аль хэдийн дуусгасан бол үлдэх). Илүү олон янз байдлын хувьд энэ нь жижиг жагсаалтаас тэнцвэртэй боловч санамсаргүй сонголт байж болно.
Систем нь ашиг тусын утгын дурын хүрээг хуваарилдаг - жишээлбэл, 0 (бүрэн хүсээгүй) -ээс 100 (бүрэн хүсч байна) хүртэл. Үйлдэл бүр нь энэ утгыг тооцоолоход нөлөөлдөг хэд хэдэн параметртэй байдаг. Бидний асран хамгаалагчийн жишээ рүү буцах нь:
Үйлдлүүдийн хоорондох шилжилт нь хоёрдмол утгатай байдаг - аль ч муж өөрийг дагаж болно. Үйлдлийн тэргүүлэх чиглэлийг буцаасан хэрэглүүрийн утгуудаас олж болно. Хэрэв дайсан харагдах бөгөөд тэр дайсан хүчтэй, мөн дүрийн эрүүл мэнд муу байвал Fleeing болон FindingHelp хоёулаа тэгээс өөр өндөр утгыг буцаана. Энэ тохиолдолд FindingHelp үргэлж өндөр байх болно. Үүний нэгэн адил байлдааны бус үйл ажиллагаанууд хэзээ ч 50-аас илүүгүй байдаг тул байлдааныхаас үргэлж доогуур байх болно. Үйлдлүүд үүсгэх, тэдгээрийн ашиг тусыг тооцоолохдоо та үүнийг анхаарч үзэх хэрэгтэй.
Бидний жишээн дээр үйлдлүүд нь тогтмол тогтмол утгыг эсвэл хоёр тогтмол утгын аль нэгийг буцаана. Илүү бодитой систем нь үргэлжилсэн утгын хүрээнээс тооцооллыг буцаана. Жишээлбэл, "Зугтах" үйлдэл нь агентын эрүүл мэнд муу байвал илүү өндөр хэрэглээний утгыг буцаана, дайсан хэт хүчтэй байвал Attacking үйлдэл нь бага хэрэглээний утгыг буцаана. Ийм учраас төлөөлөгч дайсныг ялахад хангалттай эрүүл мэнд байхгүй гэж үзсэн аливаа нөхцөл байдалд Fleeing үйлдэл нь Довтолгооноос илүү чухал байдаг. Энэ нь олон тооны шалгуур дээр үндэслэн үйлдлүүдийг эрэмбэлэх боломжийг олгодог бөгөөд энэ хандлагыг зан төлөвийн мод эсвэл FSM-ээс илүү уян хатан, хувьсах чадвартай болгодог.
Үйлдэл бүр нь програмыг тооцоолох олон нөхцөлтэй байдаг. Тэдгээрийг скрипт хэлээр эсвэл математикийн цуврал томъёо хэлбэрээр бичиж болно. Дүрийн өдөр тутмын хэв маягийг дуурайлган хийдэг Sims нь тооцооллын нэмэлт давхаргыг нэмдэг - агент нь хэрэглээний үнэлгээнд нөлөөлдөг хэд хэдэн "сэдэл" хүлээн авдаг. Хэрэв дүр нь өлсөж байвал тэд цаг хугацаа өнгөрөх тусам улам бүр өлсөх бөгөөд дүрийг гүйцэтгэх хүртэл EatFood үйлдлийн ашигтай үнэ цэнэ нэмэгдэж, өлсгөлөнгийн түвшинг бууруулж, EatFood-ийн утгыг тэг болгож өгнө.
Үнэлгээний системд суурилсан үйлдлүүдийг сонгох санаа нь маш энгийн тул Utility-д суурилсан системийг бүрэн орлуулахын оронд AI шийдвэр гаргах үйл явцын нэг хэсэг болгон ашиглаж болно. Шийдвэрийн мод нь хоёр хүүхдийн зангилааны хэрэглээний зэрэглэлийг асууж, түүнээс дээшийг сонгож болно. Үүний нэгэн адил зан үйлийн мод нь аль хүүхдийг гүйцэтгэхийг шийдэх үйлдлүүдийн ашиг тусыг үнэлэх нийлмэл Utility зангилаатай байж болно.
Хөдөлгөөн ба навигаци
Өмнөх жишээнүүдэд бид баруун эсвэл зүүн тийш хөдөлдөг тавцантай, эргүүл хийдэг эсвэл дайрдаг харуултай байсан. Гэхдээ бид тодорхой хугацааны туршид төлөөлөгчийн хөдөлгөөнийг яг яаж зохицуулах вэ? Зорьсон газартаа хүрэх нь шулуун замаар явахаас илүү хэцүү үед бид хурдыг хэрхэн тохируулах, саад бэрхшээлээс хэрхэн зайлсхийх, маршрутаа хэрхэн төлөвлөх вэ? Үүнийг харцгаая.
Удирдлага
Эхний шатанд бид агент тус бүр нь ямар хурдтай, ямар чиглэлд хөдөлж байгааг багтаасан хурдны утгатай гэж үзнэ. Үүнийг секундэд метр, цагт километр, секундэд пиксел гэх мэтээр хэмжиж болно. Мэдрэх/Бодох/Үйлдвэрлэх гогцоог эргэн санавал бид Think хэсэг нь хурдыг сонгож, Act хэсэг нь тухайн хурдыг агентад хэрэглэнэ гэж төсөөлж болно. Ерөнхийдөө тоглоомууд нь танд зориулж энэ ажлыг гүйцэтгэдэг физикийн системтэй байдаг бөгөөд объект бүрийн хурдны үнэ цэнийг сурч, түүнийг тохируулдаг. Тиймээс та хиймэл оюун ухааныг нэг даалгавар үлдээж болно - агент ямар хурдтай байх ёстойг шийдэх. Хэрэв та төлөөлөгч хаана байх ёстойг мэдэж байгаа бол түүнийгээ тогтоосон хурдаар зөв чиглэлд шилжүүлэх хэрэгтэй. Маш энгийн тэгшитгэл:
хүссэн_аялал = очих_байрлал – төлөөлөгчийн_байрлал
2D ертөнцийг төсөөлөөд үз дээ. Агент (-2,-2) цэг дээр, очих газар нь зүүн хойд зүгийн (30, 20) цэг дээр, агент хүрэхэд шаардлагатай зам (32, 22) байна. Эдгээр байрлалыг метрээр хэмждэг гэж бодъё - хэрэв бид төлөөлөгчийн хурдыг секундэд 5 метр гэж авбал бид шилжилтийн вектороо масштаблаж, ойролцоогоор (4.12, 2.83) хурдыг авна. Эдгээр параметрүүдийг ашигласнаар агент бараг 8 секундын дотор хүрэх газартаа хүрдэг.
Та хүссэн үедээ утгыг дахин тооцоолох боломжтой. Хэрэв агент зорилтот тал руугаа явсан бол хөдөлгөөн нь хагас урттай байх боловч агентын хамгийн дээд хурд нь 5 м/с (бид үүнийг дээр шийдсэн) учраас хурд нь ижил байх болно. Энэ нь мөн хөдөлж буй зорилтуудад ажилладаг бөгөөд агентыг хөдөлж байх үед жижиг өөрчлөлт хийх боломжийг олгодог.
Гэхдээ бид илүү их өөрчлөлтийг хүсч байна - жишээлбэл, зогсохоос гүйх хүртэл хөдөлж буй дүрийг дуурайхын тулд хурдыг аажмаар нэмэгдүүлэх. Үүнийг зогсоохын өмнө төгсгөлд нь хийж болно. Эдгээр шинж чанаруудыг жолоодлогын зан төлөв гэж нэрлэдэг бөгөөд тус бүр нь тодорхой нэртэй байдаг: Хайх, зугтах, ирэх гэх мэт. Гол санаа нь төлөөлөгчийн байрлал болон одоогийн хурдыг хүрэх газартай харьцуулах үндсэн дээр төлөөлөгчийн хурдад хурдатгалын хүчийг хэрэглэж болно. зорилгодоо хүрэх янз бүрийн аргыг ашиглах.
Зан бүр нь арай өөр зорилготой. Хайх ба ирэх нь төлөөлөгчийг очих газар руу шилжүүлэх арга зам юм. Саадаас зайлсхийх, салгах нь зорилгодоо хүрэх замд саад тотгор учруулахгүйн тулд төлөөлөгчийн хөдөлгөөнийг тохируулна. Зохицуулалт ба нэгдмэл байдал нь агентуудыг хамтдаа хөдөлгөдөг. Бүх хүчин зүйлийг харгалзан нэг замын векторыг бий болгохын тулд олон тооны янз бүрийн жолоодлогын зан үйлийг нэгтгэж болно. Хана болон бусад агентуудаас хол байхын тулд ирэх, салах, саад тотгороос зайлсхийх зан үйлийг ашигладаг агент. Энэ арга нь шаардлагагүй дэлгэрэнгүй мэдээлэлгүйгээр нээлттэй газарт сайн ажилладаг.
Илүү хүнд нөхцөлд янз бүрийн зан үйлийг нэмэх нь илүү муу ажилладаг - жишээлбэл, Ирсэн болон Саадаас зайлсхийхийн хоорондох зөрчилдөөний улмаас агент хананд наалдаж болно. Тиймээс та бүх утгыг нэмэхээс илүү төвөгтэй хувилбаруудыг авч үзэх хэрэгтэй. Энэ арга нь: зан үйл бүрийн үр дүнг нэмэхийн оронд янз бүрийн чиглэлд хөдөлгөөнийг авч үзэж, хамгийн сайн сонголтыг сонгож болно.
Гэсэн хэдий ч мухардалд орсон, аль замыг сонгох сонголттой төвөгтэй орчинд бидэнд илүү дэвшилтэт зүйл хэрэгтэй болно.
Аргаа олох нь
Жолооны зан үйл нь А-аас В хүртэл шулуун зам бөгөөд саад тотгорыг тойрон бага зэрэг тойрч гарах боломжтой нээлттэй талбайд (хөлбөмбөгийн талбай эсвэл талбай) энгийн хөдөлгөөн хийхэд тохиромжтой. Нарийн төвөгтэй маршрутын хувьд бидэнд ертөнцийг судлах, түүгээр дамжин өнгөрөх замыг шийдэх арга зам хайх хэрэгтэй.
Хамгийн энгийн нь агентын хажууд байгаа квадрат бүрт тор тавьж, тэдгээрийн алийг нь хөдөлгөж болохыг үнэлэх явдал юм. Хэрэв тэдгээрийн аль нэг нь очих газар бол эхлэлд хүрэх хүртлээ талбай бүрээс өмнөх замыг дагана уу. Энэ бол зам. Үгүй бол зорьсон газраа олох, эсвэл талбай дуустал (маршрут байхгүй гэсэн үг) ойролцоох бусад квадратуудаар энэ үйлдлийг давт. Энэ бол өргөн хүрээний анхны хайлт эсвэл BFS (өргөн-эхний хайлтын алгоритм) гэж албан ёсоор нэрлэгддэг зүйл юм. Алхам бүрт тэр бүх зүг рүү хардаг (тиймээс өргөн нь "өргөн"). Хайлтын орон зай нь хүссэн байрлалдаа хүрэх хүртлээ хөдөлдөг долгионы фронттой адил юм - хайлтын орон зай нь төгсгөлийн цэгийг оруулах хүртэл алхам тутамд өргөжиж, дараа нь эхнээс нь харж болно.
Үүний үр дүнд та хүссэн маршрутыг нэгтгэсэн квадратуудын жагсаалтыг хүлээн авах болно. Энэ бол зам (тиймээс зам хайх) - агентийн очих газраа дагаж очих газруудын жагсаалт.
Бид дэлхийн дөрвөлжин бүрийн байрлалыг мэддэг тул жолооны зан үйлийг ашиглан зам дагуу шилжих боломжтой - 1-р зангилаанаас 2-р зангилаа, дараа нь 2-оос 3-р зангилаа гэх мэт. Хамгийн энгийн сонголт бол дараагийн дөрвөлжингийн төв рүү чиглэх боловч одоогийн дөрвөлжин болон дараагийн талбайн хоорондох ирмэгийн дунд зогсох нь илүү сайн сонголт юм. Үүнээс болж агент нь огцом эргэлт дээр булангуудыг таслах боломжтой болно.
BFS алгоритм нь бас сул талуудтай - энэ нь "буруу" чиглэлд "зөв" чиглэлтэй адил олон квадратыг судалдаг. Эндээс A* (A star) хэмээх илүү төвөгтэй алгоритм гарч ирдэг. Энэ нь ижил аргаар ажилладаг боловч хөршийн квадратуудыг (дараа нь хөршүүдийн хөршүүд, дараа нь хөршүүдийн хөршүүд гэх мэт) сохроор шалгахын оронд зангилаануудыг жагсаалтад цуглуулж, дараачийн шалгасан зангилаа үргэлж байхаар ангилдаг. хамгийн дөт зам руу хөтөлдөг нэг. Хүссэн талбай руу хүрэх таамаглалын маршрутын "зардал" (ямар нэгэн аяллын зардлыг оруулаад) болон тухайн квадрат нь очих газраас хэр хол байгааг тооцоолсон (хайлтын хазайлтаар) гэсэн хоёр зүйлийг харгалзан үзсэн эвристик дээр зангилаануудыг эрэмбэлдэг. зөв чиглэл).
Энэ жишээ нь төлөөлөгч нэг нэг квадратыг судалж, хамгийн ирээдүйтэй нь зэргэлдээх талбайг сонгох бүртээ байгааг харуулж байна. Үүний үр дүнд хүрэх зам нь BFS-тэй адил боловч процессын явцад цөөн тооны квадратуудыг авч үзсэн нь тоглоомын гүйцэтгэлд ихээхэн нөлөөлдөг.
Торгүй хөдөлгөөн
Гэхдээ ихэнх тоглоомууд нь сүлжээнд тавигддаггүй бөгөөд бодит байдлыг золиослохгүйгээр үүнийг хийх боломжгүй байдаг. Буулт хэрэгтэй байна. Квадратууд ямар хэмжээтэй байх ёстой вэ? Хэт том бөгөөд жижиг коридор эсвэл эргэлтийг зөв илэрхийлэх боломжгүй, хэтэрхий жижиг, хайхад хэтэрхий олон квадрат байх болно, энэ нь эцэстээ маш их цаг хугацаа шаардах болно.
Хамгийн түрүүнд ойлгох ёстой зүйл бол тор нь бидэнд холбогдсон зангилааны графикийг өгдөг. A* болон BFS алгоритмууд нь үнэндээ график дээр ажилладаг бөгөөд бидний торонд огт хамаагүй. Бид тоглоомын ертөнцийн аль ч хэсэгт зангилаа байрлуулж болно: аль ч холбогдсон хоёр зангилаа, түүнчлэн эхлэл ба төгсгөлийн цэгүүд, ядаж нэг зангилааны хооронд холболт байгаа л бол алгоритм нь өмнөх шигээ ажиллах болно. Зангилаа бүр нь олон тооны таамаглалын замуудын нэг хэсэг болох дэлхийн чухал байр суурийг илэрхийлдэг тул үүнийг ихэвчлэн замын цэгийн систем гэж нэрлэдэг.
Жишээ 1: квадрат бүрт зангилаа. Хайлт нь агент байрладаг зангилаанаас эхэлж, хүссэн квадратын зангилаагаар дуусна.
Жишээ 2: Зангилааны жижиг багц (замын цэг). Хайлт нь агентын талбайгаас эхэлж, шаардлагатай тооны зангилаануудаар дамжиж, дараа нь хүрэх газар хүртэл үргэлжилнэ.
Энэ бол бүрэн уян хатан, хүчирхэг систем юм. Гэхдээ замын цэгийг хаана, хэрхэн байрлуулахаа шийдэхийн тулд бага зэрэг болгоомжтой байх хэрэгтэй, эс тэгвээс агентууд хамгийн ойрын цэгийг харахгүй байж, замыг эхлүүлэх боломжгүй болно. Хэрэв бид дэлхийн геометр дээр тулгуурлан замын цэгүүдийг автоматаар байрлуулж чадвал илүү хялбар байх болно.
Энд навигацийн тор буюу navmesh (навигацийн тор) гарч ирнэ. Энэ нь ихэвчлэн дэлхийн геометр дээр давхардсан гурвалжингийн 2D торон байдаг - төлөөлөгч хаана ч явахыг зөвшөөрдөг. Торон дахь гурвалжин бүр нь график дахь зангилаа болж, гурваас дээш тооны зэргэлдээ гурвалжнууд нь графикийн зэргэлдээ зангилаа болдог.
Энэ зураг нь Unity хөдөлгүүрийн жишээ юм - энэ нь дэлхийн геометрийг шинжилж, navmesh (цайвар цэнхэр өнгөөр дэлгэцийн агшинд) бүтээсэн. Навмеш доторх олон өнцөгт бүр нь агент зогсож эсвэл нэг олон өнцөгтөөс нөгөө олон өнцөгт шилжих боломжтой хэсэг юм. Энэ жишээнд олон өнцөгтүүд нь тэдгээрийн байрлах давхраас бага байдаг - энэ нь нэрлэсэн байрлалаас давж гарах агентын хэмжээг харгалзан үзэхийн тулд хийгддэг.
Бид дахин A* алгоритмыг ашиглан энэ сүлжээгээр дамжих замыг хайж болно. Энэ нь бидэнд бүх геометрийг харгалзан үзсэн, шаардлагагүй зангилаа, замын цэг үүсгэх шаардлагагүй дэлхийн бараг төгс замыг өгөх болно.
Зам хайх нь нийтлэлийн нэг хэсэг хангалттай биш хэтэрхий өргөн сэдэв юм. Хэрэв та үүнийг илүү нарийвчлан судлахыг хүсч байвал энэ нь туслах болно .
Төлөвлөлт
Заримдаа зүгээр л чиглэл сонгоод хөдлөх нь хангалтгүй гэдгийг бид зам мөрийг нь олж мэдсэн - бид хүссэн газраа хүрэхийн тулд маршрут сонгож, хэд хэдэн эргэлт хийх хэрэгтэй болдог. Энэ санааг бид ерөнхийд нь хэлж болно: зорилгодоо хүрэх нь зөвхөн дараагийн алхам биш, харин эхний алхам юу байх ёстойг олж мэдэхийн тулд заримдаа хэд хэдэн алхмуудыг урагшлуулах шаардлагатай бүхэл бүтэн дараалал юм. Үүнийг төлөвлөлт гэж нэрлэдэг. Зам хайх нь төлөвлөлтийн хэд хэдэн өргөтгөлийн нэг гэж үзэж болно. Манай Мэдрэх/Бодох/Үйлдэл хийх мөчлөгийн хувьд энэ нь “Бодлого” хэсэг нь ирээдүйн олон үйлдлийн хэсгийг төлөвлөдөг газар юм.
Magic: The Gathering хэмээх самбарын тоглоомын жишээг харцгаая. Бид эхлээд дараах багц картуудыг гартаа барьдаг.
- Намаг - 1 хар мана (газрын карт) өгнө.
- Ой - 1 ногоон мана (газрын карт) өгдөг.
- Fugitive Wizard - Дуудахын тулд 1 цэнхэр мана шаардлагатай.
- Elvish Mystic - Дуудахын тулд 1 ногоон мана шаардлагатай.
Бид илүү хялбар болгохын тулд үлдсэн гурван картыг үл тоомсорлодог. Дүрэм журмын дагуу тоглогч нэг ээлжинд 1 газрын карт тоглох эрхтэй бөгөөд тэрээр энэ хөзрөөс мана гаргаж авахын тулд "товшиж" дараа нь манагийн хэмжээгээр шившлэг (түүний дотор амьтныг дуудах) боломжтой. Энэ нөхцөлд хүн тоглогч Ойн тоглоомыг тоглож, 1 ногоон мана товшиж, дараа нь Elvish Mystic дуудахыг мэддэг. Гэхдээ тоглоомын AI үүнийг яаж ойлгох вэ?
Хялбар төлөвлөлт
Тохиромжтой зүйл үлдэхгүй болтол үйлдэл бүрийг ээлжлэн оролдох нь өчүүхэн арга юм. AI нь картуудыг харснаар Swamp юу тоглож болохыг олж хардаг. Тэгээд тэр тоглодог. Энэ ээлжинд өөр арга хэмжээ үлдсэн үү? Энэ нь Элвишийн ид шидийн болон оргодол шидтэний аль алиныг нь дуудаж чадахгүй, учир нь тэднийг дуудахын тулд ногоон, цэнхэр мана шаардлагатай байдаг бол Swamp нь зөвхөн хар мана өгдөг. Тэгээд тэр Forest-д тоглох боломжгүй болно, учир нь тэр аль хэдийн Swamp тоглосон. Ийнхүү AI тоглоом дүрмээ дагасан ч муу хийсэн. Сайжруулах боломжтой.
Төлөвлөлт нь тоглоомыг хүссэн төлөвт хүргэх үйлдлүүдийн жагсаалтыг олох боломжтой. Зам дээрх талбай бүр хөршүүдтэй байдаг шиг (зам хайхдаа) төлөвлөгөөний үйлдэл бүр хөршүүд эсвэл залгамжлагчидтай байдаг. Бид хүссэн төлөвт хүрэх хүртлээ эдгээр үйлдлүүд болон дараагийн үйлдлүүдийг хайж болно.
Бидний жишээн дээр хүссэн үр дүн нь "боломжтой бол амьтныг дуудах" явдал юм. Эргэлтийн эхэнд бид тоглоомын дүрмээр зөвшөөрөгдсөн хоёр л үйлдлийг харж байна.
1. Swamp тогло (үр дүн: Тоглоом дахь намаг)
2. Ойг тогло (үр дүн: Тоглолтонд ой)
Хийсэн үйлдэл бүр нь тоглоомын дүрмээс хамааран дараагийн үйлдлүүдийг хийж, бусдыг хааж болно. Бид Swamp тоглосон гэж төсөөлөөд үз дээ - энэ нь дараагийн алхам болох Swamp-ийг устгах болно (бид үүнийг аль хэдийн тоглосон), энэ нь мөн Ойг устгах болно (учир нь та дүрмийн дагуу нэг ээлжинд нэг газрын карт тоглох боломжтой). Үүний дараа AI дараагийн алхам болгон 1 хар мана авах болно, учир нь өөр сонголт байхгүй. Хэрэв тэр цааш явж Tap the Swamp-ийг сонговол 1 нэгж хар мана авах бөгөөд үүгээр юу ч хийх боломжгүй болно.
1. Swamp тогло (үр дүн: Тоглоом дахь намаг)
1.1 "Тап" намаг (үр дүн: намаг "товшсон", +1 нэгж хар мана)
Боломжтой үйлдэл байхгүй - END
2. Ойг тогло (үр дүн: Тоглолтонд ой)
Үйлдлийн жагсаалт богино байсан тул бид мухардалд орлоо. Дараагийн алхамд бид үйл явцыг давтана. Бид Forest тоглож, "1 ногоон мана авах" үйлдлийг нээнэ, энэ нь эргээд гурав дахь үйлдлийг нээх болно - Elvish Mystic-ийг дуудах.
1. Swamp тогло (үр дүн: Тоглоом дахь намаг)
1.1 "Тап" намаг (үр дүн: намаг "товшсон", +1 нэгж хар мана)
Боломжтой үйлдэл байхгүй - END
2. Ойг тогло (үр дүн: Тоглолтонд ой)
2.1 "Товч" ой (үр дүн: Ойг "товшсон", +1 нэгж ногоон мана)
2.1.1 Elvish Mystic-г дуудах (үр дүн: Elvish Mystic тоглож байна, -1 ногоон мана)
Боломжтой үйлдэл байхгүй - END
Эцэст нь бид бүх боломжит үйлдлүүдийг судалж үзээд амьтныг дуудах төлөвлөгөөг олсон.
Энэ бол маш хялбаршуулсан жишээ юм. Зарим шалгуурыг хангасан ямар ч төлөвлөгөө биш харин хамгийн боломжит төлөвлөгөөг сонгохыг зөвлөж байна. Боломжит төлөвлөгөөг хэрэгжүүлэх үр дүн эсвэл ерөнхий ашиг тусын үндсэн дээр ерөнхийд нь үнэлэх боломжтой. Газрын карт тогловол 1 оноо, амьтан дуудсан бол 3 оноо авах боломжтой. Swamp тоглох нь 1 оноотой төлөвлөгөө байх болно. Ой → Ойг товших → Elvish Mystic-г дуудвал шууд 4 оноо өгнө.
Magic: The Gathering-д төлөвлөлт ингэж явагддаг боловч бусад нөхцөл байдалд ижил логик үйлчилдэг. Жишээлбэл, хамба шатар тоглоход зориулж ломбард шилжүүлэх. Эсвэл хананы ард нуугдаж XCOM-д ийм байдлаар аюулгүй буудаарай. Ерөнхийдөө та санаагаа ойлгодог.
Сайжруулсан төлөвлөлт
Заримдаа боломжит хувилбар бүрийг авч үзэхэд хэтэрхий олон боломжит үйлдлүүд байдаг. Magic: The Gathering-ийн жишээ рүү буцах нь: тоглоомонд болон таны гарт хэд хэдэн газар, амьтдын картууд байгаа гэж бодъё - нүүдлийн боломжит хослолын тоо хэдэн арван байж болно. Асуудлыг шийдэх хэд хэдэн шийдэл байдаг.
Эхний арга нь арагшаа гинжлэх явдал юм. Бүх хослолыг туршиж үзэхийн оронд эцсийн үр дүнгээс эхэлж, шууд замыг олохыг хичээсэн нь дээр. Модны үндэснээс тодорхой навч руу шилжихийн оронд бид эсрэг чиглэлд - навчнаас үндэс рүү шилждэг. Энэ арга нь илүү хялбар бөгөөд хурдан юм.
Хэрэв дайсан 1 эрүүл мэндтэй бол та "1 ба түүнээс дээш хохирол учруулах" төлөвлөгөөг олох боломжтой. Үүнд хүрэхийн тулд хэд хэдэн нөхцлийг хангасан байх ёстой:
1. Хохирол нь шившлэгээс үүдэлтэй байж болно - энэ нь гарт байх ёстой.
2. Шившлэг хийхийн тулд мана хэрэгтэй.
3. Мана авахын тулд газрын карт тоглох хэрэгтэй.
4. Газрын карт тоглохын тулд гартаа байх хэрэгтэй.
Өөр нэг арга бол хамгийн сайн хайлт юм. Бид бүх замыг туршиж үзэхийн оронд хамгийн тохиромжтойг нь сонгодог. Ихэнх тохиолдолд энэ арга нь хайлтын шаардлагагүй зардалгүйгээр оновчтой төлөвлөгөөг өгдөг. A* нь хамгийн сайн хайлтын нэг хэлбэр бөгөөд хамгийн ирээдүйтэй маршрутуудыг эхнээс нь судалснаар бусад сонголтуудыг шалгах шаардлагагүйгээр аль хэдийн хамгийн сайн замыг олох боломжтой.
Сонирхолтой бөгөөд улам бүр түгээмэл болж буй хамгийн шилдэг хайлтын сонголт бол Монте Карло модны хайлт юм. Дараагийн үйлдэл бүрийг сонгохдоо аль төлөвлөгөө бусдаас илүү сайн болохыг таамаглахын оронд алгоритм нь төгсгөлд нь хүрэх хүртэл (төлөвлөгөө ялалт эсвэл ялагдал хүлээсэн үед) алхам бүрт санамсаргүй залгамжлагчдыг сонгодог. Дараа нь эцсийн үр дүнг өмнөх сонголтуудын жинг нэмэгдүүлэх эсвэл багасгахад ашиглана. Энэ үйл явцыг хэд хэдэн удаа дараалан давтснаар нөхцөл байдал өөрчлөгдсөн ч (хэрэв дайсан тоглогчид саад болох арга хэмжээ авбал) дараагийн алхам юу болохыг алгоритм нь сайн тооцоолж өгдөг.
Зорилгот чиглэсэн үйл ажиллагааны төлөвлөлт эсвэл GOAP (зорилго чиглэсэн үйл ажиллагааны төлөвлөлт)гүйгээр тоглоомын төлөвлөлтийн тухай ямар ч түүх бүтэхгүй байх болно. Энэ бол өргөн хэрэглэгдэж, яригдсан арга боловч хэд хэдэн ялгах нарийн ширийнийг эс тооцвол үндсэндээ бидний өмнө ярьсан арагшаа гинжлэх арга юм. Хэрэв зорилго нь "тоглогчийг устгах" байсан бөгөөд тоглогч халхавчны ард байгаа бол төлөвлөгөө нь: гранатаар устгах → түүнийг авах → шидэх.
Ихэвчлэн хэд хэдэн зорилго байдаг бөгөөд тус бүр өөрийн гэсэн тэргүүлэх чиглэлтэй байдаг. Хэрэв нэн тэргүүний зорилтыг биелүүлж чадахгүй бол (тоглогч харагдахгүй байгаа тул "тоглогчийг алах" төлөвлөгөөг бий болгодоггүй) хиймэл оюун ухаан нь тэргүүлэх зорилтууд руу буцах болно.
Сургалт ба дасан зохицох
Тоглоомын AI нь агентуудыг бодит цаг хугацаанд удирдахад тохиромжгүй тул машин сургалтыг ихэвчлэн ашигладаггүй гэж бид аль хэдийн хэлсэн. Гэхдээ энэ нь та энэ бүсээс ямар нэгэн зүйл зээлж чадахгүй гэсэн үг биш юм. Бид мэргэн буучдаа ямар нэгэн зүйл сурч болохуйц өрсөлдөгчийг хүсч байна. Жишээлбэл, газрын зураг дээрх хамгийн сайн байршлын талаар олж мэдээрэй. Эсвэл тулааны тоглоомын өрсөлдөгч нь тоглогчийн байнга ашигладаг комбо хөдөлгөөнийг хааж, бусдыг ашиглах сэдэл төрүүлдэг. Ийм нөхцөлд машин сурах нь маш ашигтай байж болох юм.
Статистик ба магадлал
Нарийн төвөгтэй жишээнүүд рүү орохын өмнө хэд хэдэн энгийн хэмжилт хийж, тэдгээрийг шийдвэр гаргахдаа ашиглан хэр хол явж болохыг харцгаая. Жишээлбэл, бодит цагийн стратеги - тоглогч тоглолтын эхний хэдэн минутад довтолгоо хийж чадах эсэхийг бид хэрхэн тодорхойлох вэ, үүний эсрэг ямар хамгаалалт бэлтгэх вэ? Ирээдүйд ямар хариу үйлдэл үзүүлэхийг ойлгохын тулд бид тоглогчийн өнгөрсөн туршлагыг судалж болно. Эхлэхийн тулд бидэнд ийм түүхий мэдээлэл байхгүй, гэхдээ бид үүнийг цуглуулж чадна - хиймэл оюун ухаан хүний эсрэг тоглох болгонд анхны халдлагын цагийг бүртгэж чадна. Хэдэн сессийн дараа бид тоглогч ирээдүйд довтлоход шаардагдах дундаж хугацааг авах болно.
Дундаж утгын асуудал бас бий: хэрэв тоглогч 20 удаа гүйж, 20 удаа удаан тогловол шаардлагатай утгууд нь дунд хэсэгт байх бөгөөд энэ нь бидэнд ашигтай зүйл өгөхгүй. Нэг шийдэл нь оролтын өгөгдлийг хязгаарлах явдал юм - сүүлийн 20 ширхэгийг анхаарч үзэх боломжтой.
Тоглогчийн өмнөх сонголт ирээдүйд ижил байх болно гэж үзэн тодорхой үйлдлүүдийн магадлалыг тооцоолохдоо ижил төстэй аргыг ашигладаг. Хэрвээ тоглогч бидэн рүү таван удаа галт бөмбөгөөр, хоёр удаа аянга цахилгаанаар, нэг удаа тулалдсан бөмбөгөөр дайрвал галт бөмбөгийг илүүд үздэг нь илт. Галт бөмбөг=62,5%, аянга=25%, тулалдаан=12,5% янз бүрийн зэвсэг ашиглах магадлалыг экстраполяци хийж, харцгаая. Манай тоглоомын хиймэл оюун ухаан өөрийгөө галаас хамгаалахад бэлтгэх хэрэгтэй.
Өөр нэг сонирхолтой арга бол Naive Bayes ангилагчийг ашиглан их хэмжээний оролтын өгөгдлийг судалж, нөхцөл байдлыг ангилж, хиймэл оюун ухаан хүссэн байдлаар хариу үйлдэл үзүүлэх явдал юм. Bayesian ангилагч нь имэйлийн спам шүүлтүүрт ашигладаг гэдгээрээ алдартай. Тэнд тэд үгсийг шалгаж, эдгээр үгсийг өмнө нь хаана (спам дээр) гарч ирсэнтэй харьцуулж, ирж буй имэйлийн талаар дүгнэлт гаргадаг. Бид цөөн оролттой ч гэсэн ижил зүйлийг хийж чадна. AI-ийн олж хардаг бүх хэрэгтэй мэдээлэл (дайсны ямар нэгжүүд бий болсон, ямар ид шид хэрэглэдэг, ямар технологиор судалсан гэх мэт) болон эцсийн үр дүн (дайн эсвэл энх тайван, яаравчлах эсвэл хамгаалах гэх мэт) дээр үндэслэн. - бид хүссэн AI зан төлөвийг сонгох болно.
Эдгээр бүх сургалтын аргууд хангалттай боловч туршилтын өгөгдөл дээр үндэслэн ашиглахыг зөвлөж байна. AI таны тоглогчдын ашигласан өөр өөр стратегид дасан зохицож сурах болно. Гарсны дараа тоглуулагчид дасан зохицдог хиймэл оюун ухаан нь хэтэрхий урьдчилан таамаглах эсвэл ялахад хэцүү болж магадгүй юм.
Үнэ цэнэд суурилсан дасан зохицох
Манай тоглоомын ертөнцийн агуулга, дүрмийг харгалзан бид зөвхөн оролтын өгөгдлийг ашиглахаас илүүтэйгээр шийдвэр гаргахад нөлөөлдөг үнэт зүйлсийн багцыг өөрчлөх боломжтой. Бид үүнийг хийдэг:
- AI-д тоглоомын үеэр дэлхийн байдал, гол үйл явдлуудын талаар мэдээлэл цуглуулахыг зөвшөөрнө үү (дээрх шиг).
- Энэ өгөгдөл дээр үндэслэн хэд хэдэн чухал утгыг өөрчилье.
- Бид эдгээр үнэт зүйлсийг боловсруулах эсвэл үнэлэх үндсэн дээр шийдвэрээ хэрэгжүүлдэг.
Жишээлбэл, агент нь анхны хүн буудлагын газрын зураг дээр сонгох хэд хэдэн өрөөтэй байдаг. Өрөө бүр өөрийн гэсэн үнэ цэнэтэй бөгөөд энэ нь зочлохыг хэр хүсч байгааг тодорхойлдог. AI нь үнэ цэнэ дээр үндэслэн аль өрөөнд орохыг санамсаргүй байдлаар сонгодог. Дараа нь агент аль өрөөнд амь үрэгдсэнээ санаж, түүний үнэ цэнийг бууруулдаг (тэр тийшээ буцаж ирэх магадлал). Үүний нэгэн адил эсрэг нөхцөл байдлын хувьд - хэрэв төлөөлөгч олон өрсөлдөгчөө устгавал өрөөний үнэ цэнэ нэмэгддэг.
Марковын загвар
Хэрэв бид цуглуулсан өгөгдлийг урьдчилан таамаглахад ашигласан бол яах вэ? Хэрэв бид тоглогчийг хардаг өрөө бүрийг тодорхой хугацаанд санаж байвал тухайн тоглогч аль өрөөнд орж болохыг урьдчилан таамаглах болно. Тоглогчийн өрөөнүүдийн хөдөлгөөнийг (утга) хянаж, бүртгэснээр бид тэдгээрийг урьдчилан таамаглах боломжтой.
Улаан, ногоон, цэнхэр гэсэн гурван өрөө авцгаая. Мөн тоглолтын хэсгийг үзэж байхдаа бидний тэмдэглэсэн ажиглалтууд:
Өрөө тус бүрийн ажиглалтын тоо бараг тэнцүү байна - бид отолт хийхэд тохиромжтой газар хаана хийхээ мэдэхгүй хэвээр байна. Статистик мэдээлэл цуглуулах нь газрын зураг дээр жигд харагдах тоглогчдыг дахин төрүүлэхэд төвөгтэй байдаг. Гэхдээ газрын зураг дээр гарч ирсний дараа дараагийн өрөөний тухай мэдээлэл аль хэдийн хэрэг болсон.
Эндээс харахад ногоон өрөө нь тоглогчдод тохирсон байдаг - ихэнх хүмүүс улаан өрөөнөөс түүн рүү шилждэг бөгөөд тэдний 50% нь тэнд үлддэг. Цэнхэр өрөө нь эсрэгээрээ алдартай биш, бараг хэн ч түүн рүү очдоггүй, хэрэв очвол тэд удаан үлдэхгүй.
Гэхдээ өгөгдөл бидэнд илүү чухал зүйлийг хэлж байна - тоглогч цэнхэр өрөөнд байх үед бидний харж буй дараагийн өрөө нь ногоон биш харин улаан өнгөтэй байх болно. Хэдийгээр ногоон өрөө нь улаан өрөөнөөс илүү алдартай ч тоглогч цэнхэр өрөөнд байгаа тохиолдолд нөхцөл байдал өөрчлөгддөг. Дараагийн төлөв (өөрөөр хэлбэл тоглогчийн очих өрөө) нь өмнөх төлөвөөс (жишээ нь, тоглогчийн одоо байгаа өрөө) хамаарна. Бид хараат байдлыг судалдаг учраас ажиглалтыг бие даан тоолж байснаас илүү үнэн зөв таамаглал гаргах болно.
Өнгөрсөн төлөвийн өгөгдөлд үндэслэн ирээдүйн төлөвийг урьдчилан таамаглахыг Марковын загвар гэж нэрлэдэг бөгөөд ийм жишээг (өрөөтэй) Марковын хэлхээ гэж нэрлэдэг. Загварууд нь дараалсан төлөвүүдийн хоорондох өөрчлөлтийн магадлалыг илэрхийлдэг тул тэдгээрийг шилжилт бүрийн эргэн тойронд магадлал бүхий FSM хэлбэрээр дүрслэн харуулдаг. Өмнө нь бид төлөөлөгчийн зан төлөвийг илэрхийлэхийн тулд FSM-г ашигладаг байсан ч энэ ойлголт нь агенттай холбоотой эсэхээс үл хамааран ямар ч төлөвт хамаатай. Энэ тохиолдолд мужууд төлөөлөгчийн байрлаж буй өрөөг төлөөлдөг:
Энэ бол AI-д дараагийн төлөвийг урьдчилан таамаглах чадварыг өгдөг төлөв байдлын харьцангуй магадлалыг илэрхийлэх энгийн арга юм. Та хэд хэдэн алхамыг урьдчилан харж болно.
Хэрэв тоглогч ногоон өрөөнд байгаа бол дараагийн удаа түүнийг ажиглахад тэнд үлдэх магадлал 50% байна. Гэхдээ тэр дараа ч гэсэн тэнд байх магадлал хэр байна вэ? Тоглогч хоёр удаа ажиглалт хийсний дараа ногоон өрөөнд үлдэх боломж байгаа төдийгүй түүнийг орхиж, буцаж ирэх магадлал бас бий. Шинэ өгөгдлийг харгалзан үзсэн шинэ хүснэгт энд байна:
Энэ нь тоглогчийг хоёр ажиглалтын дараа ногоон өрөөнд харах магадлал 51% - 21% нь улаан өрөөнөөс байх, 5% нь тэдний хоорондох цэнхэр өрөөнд зочлох боломжтой болохыг харуулж байна. 25% нь тоглогч ногоон өрөөнөөс гарахгүй.
Хүснэгт нь зүгээр л харааны хэрэгсэл юм - процедур нь зөвхөн алхам бүрт магадлалыг үржүүлэхийг шаарддаг. Энэ нь та нэг анхааруулгатай ирээдүйг харж болно гэсэн үг юм: өрөөнд орох боломж нь одоогийн өрөөнөөс бүрэн хамаарна гэж бид үзэж байна. Үүнийг Марковын өмч гэж нэрлэдэг - ирээдүйн төлөв байдал нь зөвхөн одоогийн байдлаас хамаарна. Гэхдээ энэ нь зуун хувь үнэн зөв биш юм. Тоглогчид бусад хүчин зүйлээс хамааран шийдвэрээ өөрчилж болно: эрүүл мэндийн түвшин эсвэл сумны хэмжээ. Бид эдгээр утгыг бүртгэдэггүй тул бидний таамаглал үнэн зөв биш байх болно.
N-грамм
Тулааны тоглоомын жишээ болон тоглогчийн комбо хөдөлгөөнийг урьдчилан таамаглах талаар юу хэлэх вэ? Үүнтэй адил! Гэхдээ нэг төлөв эсвэл үйл явдлын оронд бид комбо цохилтыг бүрдүүлдэг бүх дарааллыг судлах болно.
Үүнийг хийх нэг арга бол оролт бүрийг (Kck, Punch эсвэл Block гэх мэт) буферт хадгалж, буферийг бүхэлд нь үйл явдал болгон бичих явдал юм. Тиймээс тоглогч SuperDeathFist халдлагыг ашиглахын тулд Kick, Kick, Punch товчлууруудыг дахин дахин дарснаар AI систем нь бүх оролтыг буферт хадгалж, алхам бүрт ашигласан сүүлийн гурвыг нь санах болно.
(Тодоор бичсэн мөрүүд нь тоглогч SuperDeathFist довтолгоог эхлүүлэх үед байна.)
Тоглогч Kick, дараа нь өөр нэг цохилтыг сонгох үед хиймэл оюун ухаан бүх сонголтыг харж, дараагийн оролт нь үргэлж Punch гэдгийг анзаарах болно. Энэ нь агентад SuperDeathFist-ийн комбо хөдөлгөөнийг урьдчилан таамаглаж, боломжтой бол хаах боломжийг олгоно.
Эдгээр үйл явдлын дарааллыг N-грам гэж нэрлэдэг бөгөөд N нь хадгалагдсан элементүүдийн тоо юм. Өмнөх жишээнд энэ нь 3 грамм (триграмм) байсан бөгөөд энэ нь: эхний хоёр оруулга нь гурав дахь хэсгийг таамаглахад ашиглагддаг гэсэн үг юм. Үүний дагуу 5 граммаар эхний дөрвөн оруулга нь тав дахь гэх мэтийг таамаглаж байна.
Дизайнер нь N-грамын хэмжээг анхааралтай сонгох хэрэгтэй. Жижиг N нь санах ой бага шаарддаг ч түүхийг бага хадгалдаг. Жишээлбэл, 2 грамм (биграмм) нь Kick, Kick, эсвэл Kick, Punch-г бичих боловч Kick, Kick, Punch-г хадгалах боломжгүй тул хиймэл оюун ухаан SuperDeathFist комбод хариу өгөхгүй.
Нөгөөтэйгүүр, их тоо нь илүү их санах ой шаарддаг бөгөөд AI-г сургахад илүү хэцүү байх болно, учир нь илүү олон боломжит сонголтууд байх болно. Хэрэв танд Kick, Punch эсвэл Block гэсэн гурван боломжит оролт байсан бөгөөд бид 10 грамм ашигласан бол энэ нь 60 мянга орчим өөр сонголт байх болно.
Биграмын загвар нь энгийн Марковын гинжин хэлхээ юм - өнгөрсөн төлөв/одоогийн төлөв бүр нь биграмм бөгөөд та эхний дээр үндэслэн хоёр дахь төлөвийг урьдчилан таамаглах боломжтой. 3 грамм ба түүнээс дээш хэмжээтэй N-граммыг Марковын гинж гэж үзэж болох бөгөөд бүх элементүүд (N-грамын сүүлчийнхээс бусад) нийлээд эхний төлөв, сүүлчийн элемент нь хоёр дахь төлөвийг бүрдүүлдэг. Тулааны тоглоомын жишээ нь Өшиглөлт ба цохилтын төлөвөөс Өшиглөлт ба цохилтын төлөв рүү шилжих боломжийг харуулж байна. Олон тооны оролтын түүхийн оруулгуудыг нэг нэгж болгон авч үзсэнээр бид үндсэндээ оролтын дарааллыг бүх төлөвийн хэсэг болгон хувиргаж байна. Энэ нь Марковын өмчийг бидэнд олгодог бөгөөд энэ нь Марковын гинжийг ашиглан дараагийн оролтыг урьдчилан таамаглах, дараа нь ямар комбо хөдөлгөөн болохыг таамаглах боломжийг олгодог.
дүгнэлт
Бид хиймэл оюун ухааныг хөгжүүлэх хамгийн түгээмэл арга хэрэгсэл, арга барилын талаар ярилцлаа. Бид мөн тэдгээрийг ашиглах шаардлагатай нөхцөл байдал, ялангуяа ашигтай байх нөхцөлүүдийг авч үзсэн.
Энэ нь AI тоглоомын үндсийг ойлгоход хангалттай байх ёстой. Гэхдээ мэдээжийн хэрэг эдгээр нь бүх арга биш юм. Бага алдартай боловч үр дүнтэй байдаггүй нь:
- Ууланд авирах, градиент уруудах, генетикийн алгоритм зэрэг оновчлолын алгоритмууд
- сөргөлдөөнтэй хайлт/хуваарийн алгоритмууд (минимакс ба альфа-бета тайрах)
- ангиллын аргууд (перцептрон, мэдрэлийн сүлжээ ба туслах вектор машинууд)
- агентуудын ойлголт, санах ойг боловсруулах систем
- AI-ийн архитектурын арга барил (эрлийз систем, дэд бүтэц болон хиймэл оюун ухааны системийг давхарлах бусад арга замууд)
- хөдөлгөөнт хэрэгсэл (төлөвлөлт, хөдөлгөөний зохицуулалт)
- Гүйцэтгэлийн хүчин зүйлс (нарийвчилсан түвшин, хүссэн үедээ болон цагийн хуваарь хийх алгоритмууд)
Сэдвийн талаархи онлайн эх сурвалжууд:
1. GameDev.net-д байдаг Тэгээд .
2. Тоглоомын AI хөгжүүлэхтэй холбоотой өргөн хүрээний сэдвээр олон илтгэл, нийтлэлүүдийг агуулсан.
3. GDC AI Summit-ийн сэдвүүдийг багтаасан бөгөөд тэдгээрийн ихэнх нь үнэ төлбөргүй байдаг.
4. Ашигтай материалыг мөн вэбсайтаас олж болно .
5. AI судлаач, тоглоом хөгжүүлэгч Томми Томпсон YouTube дээр видео хийдэг арилжааны тоглоомууд дахь AI-ийн тайлбар, судалгаатай.
Энэ сэдвээр бичсэн номууд:
1. Game AI Pro номын цуврал нь тодорхой функцуудыг хэрхэн хэрэгжүүлэх эсвэл тодорхой асуудлыг хэрхэн шийдвэрлэх талаар тайлбарласан богино өгүүллийн цуглуулга юм.
2. AI Game Programming Wisdom цуврал нь Game AI Pro цувралын өмнөх хувилбар юм. Энэ нь хуучин аргуудыг агуулдаг боловч бараг бүгдээрээ өнөөг хүртэл хамааралтай байдаг.
3. нь хиймэл оюун ухааны ерөнхий талбарыг ойлгохыг хүсдэг хүн бүрийн үндсэн бичвэрүүдийн нэг юм. Энэ бол тоглоом хөгжүүлэх тухай ном биш бөгөөд энэ нь хиймэл оюун ухааны үндсийг заадаг.
Эх сурвалж: www.habr.com