Модоробство та геймдев. Нові моделі поведінки НПС

Поговоримо про редагування моделей NPC , реалізованих в STALKER - розберемо пристрій файлів, у яких зберігається інформація про схеми поведінки мешканців «Зони».

Але спершу невеликий відступ. Чи знаєте ви, про товариші ігробудівники, що в основу моделей поведінки NPC, реалізованих у STALKER були покладені спеціальні алгоритми, які вперше були розроблені Гербертом Саймоном та Алленом Ньюеллом та застосовані у програмі з кодовою назвою GPS , що розшифровується як General Problem Solver або Універсальний Вирішувач Задач ( УРЗ ). GPS – це такий програмний комплекс, спеціальна ПК-модель, створена для моделювання всіх чи практично всіх способів вирішення завдань, які використовує людина.

Працював GPS за наступною схемою. На вході УРЗ отримував «пакет» певних умов, операторів та описів початкового та кінцевого станів системи. Вся ця інформація ретельно аналізувалась - виконувався пошук такої послідовності команд, яка дозволяла б привести початковий стан системи в кінцевий або, простіше кажучи, знайти рішення поставленого користувачем завдання. При чому, що цікаво - система GPS самостійно вибирала найперспективніший шлях, яким можна було продовжити пошук рішення. Як тільки GPS виявляв, що обраний шлях безперспективний, він виконував відкат до однієї з попередніх гілок. Така методологія отримала назву «Аналіз засобів та цілей».

1969 року проект GPS був заморожений. Через деякий час розробка чудо-системи була відновлена, але фахівці вже не ставили перед собою глобальної мети розробити потужну модель AI для вирішення найрізноманітніших завдань. Обмежилися створенням так званого GPS-навігатора для орієнтування на карті території. До речі, реалізація сучасних навігаційних приладів стала можливою лише з появою іншої не менш цікавої системи STRIPS .

Алгоритми поведінки NPC

Повертаємося до STALKER Система пошуку рішень у даному тайтлі отримала невигадливу назву «планувальник» і успадкувала все найкраще від УРЗ, тобто. також дозволяла виконувати розумний пошук рішень на основі заданих команд та умов.

Всі алгоритми поведінки персонажів у «Сталкері» зашиті у файли з розширенням .script і є банальною послідовністю скриптових команд (операторів). Проживають такі документи в каталозі \gamedata\scripts із розпакованою грою. Давайте вивчимо структуру одного з таких документів, наприклад скрипта xr_kamp.script . Підвантажте піддослідний файл у довільний текстовий редактор, наприклад, у Блокнот.

При швидкому перегляді документа неважко помітити, що алгоритм поведінки NPC ділиться на кілька складових блоків. У першій частині файлу - від коментаря --Evaluators до кейворда --Actions прописані звані евалуатори чи «оцінювачі». Це такі скриптові конструкції, які служать динамічної постановки умов під час гри. Так, наприклад, вони використовуються для визначення рівня здоров'я та ситості персонажів. Наведемо конкретний приклад. NPC «Петя» при розмові з одним із сталкерів страшенно зголоднів, евалуатор повернув значення істини ( true ) і «Петін» співрозмовник запропонував зробити паузу і пообідати, мовляв, на ситий шлунок думається краще. У другій частині скрипта - після ключового слова --Actions до пункту --Kamp binder розміщуються дії, які має виконати мешканець «Зони» - пообідати, вбити сталкера, «затравити» чергову байку чи анекдот. Ну і, нарешті, в третій частині документа, після коментаря Kamp binder , оголошуються різні активатори. Ось, у принципі, і все.

Редагування моделей поведінки персонажів " Сталкера " виконується... абсолютно правильно - в " Блокноті ". Спеціальних утиліт для моддингу AI поки просто немає.

Щоб розібратися в призначенні більшості операторів, досить просто вміти читати між рядками. Справа в тому, що творці гри, наші з вами співвітчизники, не вважали за труд прокоментувати деякі свої дії. Так, у тілі більшості скриптових конструкцій зустріти коментарі виду - чи можуть сталкери в таборі юзатися гравцем. », « -- ' Чи знаходимося ми на заданій позиції », « --' Просто сидить і встромляє ». Всі ці авторські нотатки дозволяють швидко вникнути у сенс певних скриптових блоків або окремо взятих операторів. Таким чином, ми не будемо детально розбирати призначення кожної команди, що фігурує у моделі поведінки NPC – розглянемо лише основні функції та оператори, які зустрічаються у кожній схемі поведінки персонажів. На початковому етапі роботи інтерес для нас представляють лише скриптові конструкції з блоку - Kamp binder - саме в них містяться основні дії та умови, визначені для даної схеми поведінки персонажів.

Команда class "evaluator_kamp_end" (property_evaluator) служить для оголошення класу оцінювача - евалуатора. Оператор function evaluator_kamp_end:__init(name, storage) super (nil, name) self.a = storage end ініціалізує функцію евалуатора. Управління ігровим планувальником здійснюється через спеціальну функцію add_to_binder (function add_to_binder(object, ini, scheme, section, storage)) , яка має 6 параметрів.

"Навчити комп'ютерних суперників розуму - справа п'яти хвилин."

Перша характеристика цієї функції - Object - відповідає за персонажа/об'єкт, котрій створюється планувальник. Другий, третій і четвертий атрибути ( ini , scheme , section ) вказують на файл ініціалізації, найменування схеми поведінки та назву блоку конфігураційного файлу відповідно. Нарешті, п'ятий і останній параметр - storage - служить визначення таблиці, у якій зберігатимуться характеристики даного алгоритму. Команда local manager = object:motivation_action_manager() служить активації менеджера дій (планувальника) для об'єкта object. Наступний блок команд, що починаються з ключових слів properties і operators , застосовується для присвоєння ідентифікаторів операторів та умов елементам масиву. У нашому «табірному» скрипті ця конструкція має такий вигляд:

properties["kamp_end"]=xr_evaluators_id.stohe_kamp_base+1 
properties["on_position"]=xr_evaluators_id.stohe_kamp_base+2 
properties["contact"] 
=xr_evaluators_id.stohe_meet_base+1 operators[" 1 
operators[ "wait"] = xr_actions_id.stohe_kamp_base+3

При цьому варто зазначити, що як значення ідентифікаторів повинні використовуватися тільки цілі числа. Два наступні рядки коду, розташовані після коментаря - Evaluators , визначають дві динамічні умови - закінчити «посидіти» і чи прийшов сталкер на своє місце біля костерка:

manager:add_evaluator (properties["kamp_end"], this.evaluator_kamp_end ("kamp_end", storage, "kamp_end")) 
manager:add_evaluator (properties["on_position"], this.evaluator_on_position ("kamp_on_position" ))

Слідом за цими командами йде великий блок із внутрішньою назвою - Actions - дії. Ось він нас цікавить найбільше. У цій категорії фігурує лише один складовий оператор і ланцюжок умов, виконання яких є обов'язковим для активації цієї команди:

local action = this.action_wait (object:name(),"action_kamp_wait", storage) 
action: add_precondition (world_property(stalker_ids.property_alive, true)) action 
: add_precondition (world_property(stalker_ids.property_dan)

Прокоментуємо всі дії, реалізовані в цьому скрипті:

- Чи живий сталкер? 
action:add_precondition (world_property(stalker_ids.property_alive, true)) 
- Чи загрожує персонажу небезпека? 
action:add_precondition (world_property(stalker_ids.property_danger,false)) 
- Чи є поблизу вороги? 
action:add_precondition (world_property(stalker_ids.property_enemy, false)) 
- Чи помічені аномалії поблизу героя? 
action:add_precondition (world_property(stalker_ids.property_anomaly,false)) 
-- Чи виконуються інші важливі умови, не зазначені вище? 
xr_motivator.addCommonPrecondition (action) 
- Чи знаходиться герой на позиції - поблизу багаття? 
action:add_precondition (world_property(properties["on_position"], true)) 
action:add_effect (world_property(properties["kamp_end"], true))

Якщо всі ці передумови виконуються, то значення динамічної умови

manager:add_evaluator (properties["kamp_end"], this.evaluator_kamp_end ("kamp_end", storage, "kamp_end"))

стане істинним і планувальник завершить роботу оператора:

action: add_effect (world_property(properties["kamp_end"], true))

Додавання створеного оператора до планувальника виконується командою:

manager:add_action (operators["wait"], action)

Що відбувається далі? Все просто – оголошення спеціальної команди, яка передає персонажу певні повідомлення (смерть NPC, влучення кулі в тіло товариша тощо):

xr_logic.subscribe_action_for_events(object, storage, action)

Переміщення актора (NPC) у бік вогнища здійснюється за допомогою такої невигадливої ​​команди:

action = this.action_go_position (object:name(),"action_go_kamp", storage)

Далі знову відбувається ініціалізація попередніх умов, перевірки та додавання чергового оператора до планувальника. Рядок end скрипт завершує свою роботу...

"Щоб створити і підключити до гри нові алгоритми поведінки персонажів, потрібно досконало володіти скриптовою мовою LUA."

У цій статті ми розібрали структуру файлів, що містять інформацію про моделі поведінки NPC, а також вивчили призначення основних команд, що фігурують у алгоритмах поведінки персонажів. Отриманих зі статті знань вам вистачить для редагування оригінальних схем поведінки мешканців зони. Для створення ж своїх власних AI-модів доведеться вивчити ази програмування скриптовою мовою LUA .