Просмотр исходного текста страницы Игромания - Игрострой. Новые модели поведения NPC

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


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


General Problem Solver (GPS): http://storage4.static.itmages.ru/i/13/0722/h_1374485722_4087103_82a26a66ea.jpg<br />
"Примерно так можно интерпретировать процесс нахождения решения системой 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 пока просто нет.": http://storage4.static.itmages.ru/i/13/0722/h_1374486242_1298852_d73cc5a5bb.jpg<br />
http://storage6.static.itmages.ru/i/13/0722/h_1374486259_1803790_43148721bd.jpg


Чтобы разобраться в предназначении большинства операторов, достаточно просто уметь читать «меж строк». Все дело в том, что создатели игры, наши с вами соотечественники, не сочли за труд прокомментировать некоторые свои действия. Так, в теле большинства скриптовых конструкций встретить комментарии вида «'''-- могут ли сталкеры в лагере юзаться игроком.'''», «'''--' Находимся ли мы на заданной позиции'''», «'''--' Просто сидит и втыкает'''». Все эти авторские заметки позволяют быстро вникнуть в смысл определенных скриптовых блоков или отдельно взятых операторов. Таким образом, мы не будем детально разбирать предназначение каждой команды, фигурирующей в модели поведения 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''' применяется для присвоения идентификаторов операторов и условий элементам массива.  В нашем «лагерном» скрипте эта конструкция имеет следующий вид:


<code>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</code>


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


<code>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"))</code>


Следом за данными командами идет большой блок с внутренним названием '''-- Actions''' - действия. Вот он-то нас интересует больше всего. В данной категории фигурирует всего лишь один составной оператор и цепочка условий, выполнение которых является обязательным для активации данной команды: 


<code>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)
…</code>


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


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


Если все эти предусловия выполняются, то значение динамического условия


<code>manager:add_evaluator (properties["kamp_end"], 		this.evaluator_kamp_end	 ("kamp_end", storage, "kamp_end"))</code>


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


<code>action: add_effect (world_property(properties["kamp_end"],   true))</code>


Добавление созданного оператора в планировщик выполняется командой:


<code>manager:add_action (operators["wait"], action)</code>


Что происходит дальше? Все просто - объявление специальной команды, которая передает персонажу определенные уведомления (смерть NPC, попадание пули в тело товарища и т.д.):


<code>xr_logic.subscribe_action_for_events(object, storage, action)</code>


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


<code>action = this.action_go_position (object:name(),"action_go_kamp", storage)</code>


Далее вновь происходит инициализация предварительных условий, проверки и добавление очередного оператора в планировщик. Строкой '''end''' скрипт завершает свою работу...


"Чтобы создать и подключить к игре новые алгоритмы поведения персонажей, нужно в совершенстве владеть скриптовым языком LUA.": http://storage2.static.itmages.ru/i/13/0722/h_1374487375_4984143_534c8bed0d.jpg

= * * * =

В настоящей статье мы разобрали структуру файлов, содержащих информацию о моделях поведения NPC, а также изучили предназначение основных команд, фигурирующих в алгоритмах поведения персонажей. Полученных из статьи знаний вам с лихвой хватит для редактирования оригинальных схем поведения обитателей зоны. Для создания же своих собственных AI-модов придется выучить азы программирования на скриптовом языке '''LUA'''.


= Авторы =

Статью создал: [[ Эдуард Клишин ]]<br />
Добавил на stalkerin: [[aka_sektor]]<br />

[[Категория:Руководства]][[Категория:Скрипты]][[Категория:A-Life]]