Модели поведения NPC

Модели поведения NPC
Дата публикации	27 ноября 2007 (16 лет)
Автор	Эдуард Клишин

В прошлых статьях по модифицированию S.T.A.L.K.E.R. мы изучили такие сложные темы, как разработка новых уровней и миссий для игры. Сегодня же мы поговорим о редактировании моделей NPC, реализованных в S.T.A.L.K.E.R. - разберем устройство файлов, в которых хранится информация о схемах поведения обитателей «Зоны».

General Problem Solver (GPS)

Примерно так можно интерпретировать процесс нахождения решения системой GPS графически.

Но для начала небольшое отступление. Знаете ли вы, о товарищи игростроители, что в основу моделей поведения NPC, реализованных в S.T.A.L.K.E.R. были положены специальные алгоритмы, которые впервые были разработаны Гербертом Саймоном и Алленом Ньюэллом и применены в программе с кодовым названием GPS, что расшифровывается, как General Problem Solver или Универсальный Решатель Задач (УРЗ). GPS - это такой программный комплекс, специальная ПК-модель, созданная для моделирования всех или практически всех способов решения задач, которые использует человек.

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

В 1969 году проект GPS был заморожен. Спустя какое-то время разработка чудо-системы была возобновлена, но специалисты уже не ставили перед собой глобальной цели - разработать мощную модель AI для решения самых разнообразных задач. Ограничились созданием так называемого GPS-навигатора для ориентирования на карте местности. Кстати, реализация современных навигационных приборов стала возможной лишь с появлением другой не менее интересной системы STRIPS.

Алгоритмы поведения NPC

Возвращаемся к S.T.A.L.K.E.R. Система поиска решений в данном тайтле получила незатейливое название «планировщик» и унаследовала все самое лучшее от УРЗ, т.е. также позволяла выполнять разумный поиск решений на основе заданных команд и условий.

Все алгоритмы поведения персонажей в «Сталкере» зашиты в файлы с расширением .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["go_position"] = xr_actions_id.stohe_kamp_base+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", storage, "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_danger,false)
...

Прокомментируем все действия, реализованные в данном скрипте:

-- Жив ли сталкер?
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.