Разработка алгоритма для формирования поведения игрового агента
Анализ систем формирования поведения игрового агента и способов их применения. Описание систем Behavior Trees, Utility AI. Критерии сравнения жанров разработанных игр: форма, доступность, порог вхождения. Разработка алгоритмов поведения игрового агента.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 01.12.2019 |
| Размер файла | 2,8 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Появление Utility AI и его результативность привлекли большой интерес, и вскоре начали появляться инструменты, различными методами пытающиеся упростить процесс проектирования, снижая необходимость состоятельной теоретической базы и разработчика. Один из таких - плагин Apex Utility AI для Unity (см. рис. 2.2), предлагающий подход, схожий с Behavior Trees в плане строения структуры поведения, что упрощает общее понимание разрабатываемого ИИ. В инструмент можно встроить ряд необходимых показателей, а затем ассоциировать их с нужными узлами, благодаря чему достигаются достоинства обоих систем - лёгкая структура дерева и математические просчёты показателей в реальном времени.
В результате, имеется множество доступных инструментов, так или иначе снижающих входной порог разработчика в создание достаточно сложно поведения игрового агента. Выбор как игрового движка, так и расширений к нему в таком случае сводится к выбору, исходя их личных предпочтений, инструментов, находящихся в свободном доступе, а также имеющихся навыков в программировании.
Рисунок 2.2 Пример поведения игрового агента, построенного в Apex Utility AI
2.2.4 Порог вхождения
Под порогом вхождения предлагается понимать субъективную оценку сложности работы с инструментами какой-либо системы, основываясь на имеющихся навыках и личной уверенности. Behavior Trees имеют в своей структуре ряд ограничений и правил, всё же это положительно сказывается на понимании поведенческих деревьев и того, в каком порядке они работают. Строгость связей узлов практически гарантирует невозможность ошибиться при проектировании поведения, по крайней мере, при создании его простейшей версии. Иерархическая структура гарантирует понимание логических связей в поведении игрового агента, поскольку представляет строгий порядок - в самую первую очередь дерево проходит от верхнего уровня к нижнему.
Utility AI, с другой стороны, не связана рядом ограничений, будь то конечное множество элементов или жёсткие связи, что развязывает руки продвинутым разработчикам в плане расширения возможностей агента практически до бесконечности. Однако человек без большого опыта работы с игровым ИИ вряд ли сможет правильно подобрать ряд действительно нужных показателей, оценить их, правильно подобрав функцию распределения, и свести их с подходящими действиями. Таким образом, Utility AI - очень мощный инструмент, реализующий свой потенциал только в руках не только опытного разработчика, но и всей команды, способной грамотно составить концепцию поведения.
2.2.5 Модульность
Ни та, ни другая система в чистом виде не подразумевает внедрение каких-либо иных решений для решения разных проблем, чистой модульности они не имеет. Однако исследователи искали способы минимизировать их известные недостатки путём самостоятельного внедрения разных методик и инструментов, в т.ч. внедряя одну систему формирования поведения игрового агента в другую. Со временем это стало обычной практикой, которая привела к выделению решений, занимающих относительно узкую нишу, в иные сферы применения - робототехника, промышленная и военная инженерия и т.д.
2.2.6 Расширяемость
Под расширяемостью понимаются возможности по увеличению возможностей агента, работающего на той или иной системе. В прошлых работах неоднократно упоминалось, что недостаток Behavior Trees состоит в их схожести с конечным автоматом, от которого они произошли, что выражается в экспоненциально растущей сложности поведения. При расширении всё больше растёт количество узлов, и следить за ними становится всё сложнее. Utility AI менее подвержена такому недостатку, потому что в этой системе отсутствует какая либо преемственность поведений.
Также подчёркивалось, что Behavior Trees плохо подлежит изменению уже созданных моделей поведения из-за множества связей и зависимостей, при изменении есть риск разорвать нужные связи и нарушить поведение целиком. В Utility AI все действия могут быть независимы, их изменение, добавление и даже удаление не скажется на работоспособности всего поведения.
2.2.7 Способы принятия решений
Behavior Trees предлагают итерационный метод прохождения по путям решений - каждый конечный узел является решением, и в момент времени выполняться может только оно. Это единственный способ, заложенный в поведенческие деревья, принцип которых заключается в последовательном проходе по дереву, распараллеливания не предусмотрено. Это кардинально отличается от способа прохода по вариантам поведения в Utility AI, в котором все внесённые показатели просчитываются одновременно. Теоретически, это должно положительно сказаться на производительности, снижая задержки между принятиями решений агента. Сам метод принятия решений имеет несколько способов реализации в системе на основе теории полезности:
· абсолютный - в момент времени выбрать то действие, имеющее наибольшее значение полезности, иначе называемый методом рангов;
· относительный - выбор происходит из множества наиболее значимых в данный момент возможностей на основе псевдослучайного распределения, другое название - метод взвешенных оценок.
Разнообразие принятия решений в Utility AI позволяет ещё больше разнообразить моделирование мышления игрового агента, добавляя возможных противоречий в его механизм принятия решений. Это должно положительно сказываться на обработке некоторых более личностных решений, а также ряда противоречивых суждений и действий, вполне возникающих у человека в реальной жизни.
2.2.8 Сложность проектирования
Behavior Trees сам по себе является очень удобным инструментом проектирования поведения игрового агента, поскольку похожую структуру можно воссоздать с помощью множества разных методов моделирования - блок-схемы, конечный автомат, неформальное описание, иллюстрация и т.д. Такие изначальные формы, иллюстрирующие концептуально поведение игрового агента, легко преобразуются в поведенческое дерево. По сравнению с конечным автоматом, с видом поведенческих деревьев интуитивно проще работать, нежели с набором инструкций на определённом языке программирования или даже на псевдокоде.
Utility AI, в связи с вовлечением множества математических методов распределения, требует более обстоятельной работы над концепцией поведения. Связано это с необходимостью подбора показателей и их правильной оценки, с чего начинается проектирования системы теории полезности. Возможные ошибки приводят к лишним взаимодействия между дизайнерами и разработчиками, а впоследствии - в превышении сроков, отведённых на реализацию. По этой причине к дизайнерам выдвигаются большие требования, включая продвинутое аналитическое мышление и уверенное знание методов математического анализа
2.2.9 Сложность реализации
Сложность непосредственной разработки напрямую связан с используемыми инструментами, которые, как было указано, выбираются на основе имеющихся навыков. Было определено, что в общих чертах методы, используемые в популярных игровых движках, схожи, в связи с чем и игровой движок в целом выбирается в зависимости от предпочтений разработчика. Что касается работы с системами формирования поведения игрового агента, инструменты Behavior Trees выглядят более простыми для работы, чем аналогичные для Utility AI. Это связано с тем, что при первоначальной разработке в первом случае требуется создать только само поведенческое дерево, а в процессе построения добавлять нужные элементы. В случае с системой на основе теории полезности требуется выделить показатели, для них - функции полезности, сопоставить действия и ряд показателей. Такой подход не кажется таким последовательным, поскольку сначала создаётся множество некоторых элементов, а уже после этого им необходимо найти применение, возможно, даже прибегая к условностям и пренебрежению исходной логикой.
2.3 Проведение сравнительного анализа
Приведённые ранее критерии сравнения были успешно применены к каждой системе формирования поведения игрового агента, что позволило сопоставить их применимость в тех или иных обстоятельствах. Составлен обобщённый список описанных критериев (см таб. 2.1), где можно увидеть - каждой системе соответствует ряд ассоциируемых с ними характеристик. Это было сделано с целью как можно быстрее сделать выводы касательно выбора подходящей системы, если потребуется реализовать какой-либо алгоритм.
По приведённым критериям можно сделать некоторые выводы, касающиеся назначения обеих систем. Behavior Trees должны подходить для моделирования хорошо формализуемых и строго последовательных действий, в которых имеет большой смысл объективная оценка ситуации. По этой причине поведенческие деревья хорошо себя показали во время выхода игры Halo 2, поскольку там приходилось сталкиваться с отрядами инопланетной коалиции. Всё, что можно сказать об этих существах - это хорошо организованные вооружённые соединения, и их эмоциональное состояние крайне тяжело оценить. С помощью поведенческих деревьев разработчики смогли эффективно реализовать их известную характеристику - склонность к командной работе и тактике. Возможности по расширению возможностей деревьев позволили научиться применять эту систему в разных игровых жанрах, под каждую популярную категорию игр найдётся действенное решение на основе поведенческих деревьев
В свою очередь, Utility AI крайне эффективна в тех ситуациях, когда разработчик может сложить впечатление о том, что будет происходить в разуме моделируемого существа, особенно в случае, когда наступает критическая ситуация. Теория полезности позволяет гибко применять не только объективные показатели, но и абстрактные сущности с возможностью нормализовать их, приведя к множеству чисел, чтобы использовать в вычислениях.
Таблица 2.1
Сравнительные критерии систем формирования поведения игрового агента
|
Behavior Trees |
Utility AI |
||
|
Жанры разработанных игр |
First person shooter, Real-time strategy, Role playing game |
First person shooter, Third person shooter, Real-time strategy, Turn-based strategy, Simulation, Role playing game |
|
|
Форма представления |
Древообразный граф |
Граф, таблица, графики полезности |
|
|
Доступность инструментария |
Behavior Designer в Unity, Behavior Trees в UE4 |
Apex Utility AI в Unity, Gameplay Framework в UE4 |
|
|
Порог вхождения |
Низкий |
Высокий |
|
|
Модульность |
Хорошая |
Хорошая |
|
|
Расширяемость |
Плохая |
Хорошая |
|
|
Способы принятия решений |
Выполнение только одного подходящего под условие действия |
Выполнение действия с наибольшим значением полезности, выбор методом псевдослучайного распределения |
|
|
Сложность проектирования |
Средняя |
Высокая |
|
|
Сложность реализации |
Низкая |
Средняя |
Со своим выходом в свет, система Utility AI показала, что отлично подходит для реализации концептов, направленных на создание более приземлённого и детализованного поведения. Например, симуляции повседневной жизни или образа мышления объекта, на котором лежит большая ответственность и эмоциональная нагрузка - командира отряда или правителя государства. По этой причине, в короткий срок своего существования Utility AI была задействована в огромном количестве жанров и тематик, следовательно, породила множество эффективных решений для практически любой концепции поведения.
Выводы по главе 2
В качестве итогов проведённого сравнительно анализа будет представлена выбранная система, которая показалась наиболее подходящей для реализации некоторого ряда алгоритмов, которые были включены в постановку задачи. Учитывая, что в постановке были представлены задачи, включающие в себя базовые действия практически любого объекта в любой игре - движение, стрельба и т.д. - можно утверждать, что в основе оценки ситуации вокруг агента участвуют практически исключительно объективные показатели, проще говоря, его непосредственное окружение. По этой причине в качестве будущей реализации алгоритмов были выбраны поведенческие деревья - Behavior Trees. Уверенность в сделанном выборе усилили наиболее значимые достоинства такой системы - простота понимания, создания и низкий порог вхождения. В условиях небольшого количества времени гораздо лучше воспользоваться простой системой для настолько же простых действий, чем применять очень сильный инструмент лишь на малую часть его мощности.
Подводя итоги, несмотря на то, что обе системы появились с целью полностью заменить на рынке своих предшественников, этого не удалось достичь даже поведенческим деревьям, которые присутствуют на рынке компьютерных игр в качестве отступного решения уже более 20 лет. Системы формирования поведения игровых агентов - один из логичных шагов вперёд к передовому игровому искусственному интеллекту, предлагающий свои возможности для удовлетворения всё более растущих требований к поведению игровых агентов. Они разрабатывались с учётом большой гибкости применения, ведь иногда существует нужда в разработке простого поведения, или, наоборот, когда разработчику был предоставлен концепт революционного игрового ИИ. Гибкость характерна для обеих систем формирования поведения игрового агента, а значит, эти системы подходят практически для любого возможного проекта, но некоторые детали в них склоняют разработчиков в сторону той или другой. Эти системы ещё долго будут иметь ценность для разработчиков любого масштаба, поэтому вряд ли можно утверждать, что одна система действительно сможет заменить другую.
3. Описание решений по разработке алгоритмов поведения
В этой главе должны быть рассмотрены разные инструменты, применяющие систему формирования поведения игрового агента - Behavior Trees - в непосредственно среду разработки и то, какими преимуществами они обладают перед их непосредственным программированием. Кроме того, заказчик в лице Alternativa Games предоставил в рамках постановки задачи несколько алгоритмов, и необходимо определить, какие из них подлежат эффективной реализации с помощью Behavior Trees.
3.1 Описание предлагаемых к реализации алгоритмов
Системы формирования поведения создавались с целью унифицировать процесс разработки простого и сложного поведения, что значит, что они универсальны для огромного количества решений. Для того, чтобы приступить к разработке, требуется иметь представление об алгоритмах, требуемых для реализации - в частности, хотя бы краткую постановку, чтобы составить ряд ограничений, т.е. того, что делать не надо. Важно понимать границы поведения, чтобы не перегрузить его, что, как уже было описано в случае с Behavior Trees, крайне усложнит отладку множества состояний и возможностей. В рамках исследовательской работы компания Alternativa Games, которая изначально запросила разработку нового поведения для своей игры Tanki X. предоставила постановки поведения игрового агента, из которых необходимо выбрать одну для дальнейшей работы.
3.1.1 Поиск кратчайшего пути в полигоне
Полный текст постановки - найти путь между двумя заданными точками в сложном неконвексном полигоне. Это задание подразумевает построение вектора, вдоль которого агент будет двигаться из одной точки в другую. Построение точек и вектора должно происходить в реальном времени с помощью соответствующих алгоритмов, требующих минимальную задержку выполнения. Это задание практически не вовлекает в себя использование Behavior Trees, поскольку требуется разработать лишь движение по прямой.
3.1.2 Определение успешности атаки метательным/огнестрельным оружием
Имеется геометрия сцены. Необходимо определить, какие данные нужны для проверки, создать алгоритм, позволяющий производить проверку на основе данных. В этой задаче нужно определить, насколько успешным будет попадание по определённой цели при условии, что игровой агент может определять её позицию на карте, а также имеет орудие дальнего действия, позволяющее выпускать снаряды в пределах эффективной дальности. В зависимости от желания разработчика, можно включить в учёт огромное количество данных, которые будут влиять на результат. Так, самому агенту могут помешать препятствия на пути, неэффективность орудия на текущей дистанции и т.д. Снаряд не имеет сложного поведения, его траекторию можно как задать простейшей параболой, так и задать влияющие на неё критерии - скорость ветра, масса снаряда, поправка на разницу в высоте и т.д.
3.1.3 Поиск пути на больших картах
На больших картах поиск пути может быть долгим. Необходимо разработать решение, которое позволит просчитывать путь не полностью и с минимальными потерями качества. Для поиска пути агента существуют разные способы, например, задание вейпоинтов - waypoints - ключевых точек на всей игровой сцене, между которыми будет перемещаться агент. Проблема такого способа состоит в том, что чем больше и сложнее карта, тем больше требуется расставить точек, что программист делает вручную. Более того, вейпоинты обычно позволяют построить прямой путь для агента между точками, поэтому при их расстановке требуется иметь в виду препятствия, которые могут быть на этой прямой, в т.ч. спонтанные, такие как другие агенты. Другой возможный способ - генерация навигационного меша, который будет описан ниже. Так или иначе, задача, помимо задания поведения агента, вовлекает в себя дополнительные шаги по созданию поведения, выходящие за возможности Behavior Trees. Дополнительные задачи могут привести к тому, что поведения игрового агента придётся уделить меньше внимания, чем требуется, в связи с чем общие задачи исследовательской работы могут быть не достигнуты в полной мере.
3.1.4 Генерация навигационного меша
Суть задания - создание меша, который будет представлять собой поверхность по которой могут перемещаться игровые агенты. На примере ниже (см. рис. 3.1) меш, который в среде разработчиков называют navmesh - сокращение от navigation mesh - выделен поверх основной геометрии, означая зоны, за которые агент никогда не выйдет в пределах выполнения своего основного алгоритма. Тем не менее, этого недостаточно, чтобы обеспечить точную навигацию агента по сцене, поэтому требуется задать определённое поведение, направленное, например, на правильный обход препятствий, на что поведенческие деревья способны. Однако в этой задаче их применение имеет второстепенную роль, и его будет недостаточно в рамках исследовательской работы.
3.1.5 Выбор постановки алгоритма
При подборе наиболее подходящего для реализации алгоритма следует учитывать, куда и каким образом его следует внедрять, поскольку самостоятельный алгоритм не имеет большой ценности, но может оказаться заделом под более масштабную работу. В рамках исследовательской работы эти алгоритмы предложила компания Alternativa Games, которой, вероятно, требуется расширение функционала для своего новейшего проекта - Tanki X, в котором игроки противостоят друг другу, орудуя виртуальными танками.
Рисунок 3.1 Пример навигационного меша
Все предложенные задачи направлены на развитие нового режима игры, где вместо реальных игроков противниками будут ничем им не уступающие боты. Конечно, их разработка включает много этапов, направленных на отдельные возможности ботов, которые должны имитировать таковые у игроков - передвижение, распознание противника, стрельба и т.д.
Из представленных выше заданий наиболее подходящим под Behavior Trees подходит определение успешности атаки метательным оружием, поскольку имеет нужные и при этом не слишком строгие границы поведения - как минимум, оно должно включать в себя перемещение и стрельбу. Иных ограничений нет, что позволяет сформулировать на основе этой постановки ещё одну, в которую могут быть включены дополнения, касающиеся более правдоподобного поведения агента, например, при некоторых условия среды вокруг него.
3.2 Обзор инструментов для разработки на основе Behavior Trees
Стоит принимать во внимание возраст поведенческих деревьев и их авторитет среди именитых разработчиков, когда приходит время искать нужный инструментарий. В частности, на движке Unity существует множество способов задать поведение именно с помощью Behavior Trees, используя плагины. Unity имеет магазин, в котором можно найти решения разной степени сложности, которые обычно легко внедряются в базовый интерфейс. Все эти плагины призваны сократить итоговое время разработки, переводя работу со скриптов на графические элементы и отладку в реальном времени. Тем не менее, всегда есть возможность создать поведенческие поведения с нуля или используя шаблоны в открытом доступе, не уступающие в возможностях, но менее интуитивные в построении и дальнейшей отладке.
3.2.1 Платные Unity-плагины
Behavior Designer - очень популярный инструмент на движке Unity, предназначенный для разработки поведения исключительно на Behavior Trees, предлагающий создание сложного поведения практически без использования кода. В его основе лежит графический редактор, позволяющий сразу же строить диаграммы, структурно идентичные поведенческим деревьям (см. рис. 3.2). Среди иных достоинств Behavior Designer - дизайн, ориентированный на данные, т.е. различные переменные в игровой среде - координаты, скорость и т.д., что способствует отличной производительности. В графический редактор встроены парсеры, позволяющие отследить ошибки в коде ещё до того, как поведение будет запущено, что сводит на нет критические ошибки, оставляя только баги в процессе выполнения. Для их устранения Behavior Designer обладает отладчиком в реальном времени, отслеживающем поведение по узлам, подсвечивая текущие узлы и их сообщения, что позволяет разработчику быстро устранить любые недоработки. Конечно, такой сложный в исполнении инструмент обладает большой и точной документацией, позволяя упростить знакомство с инструментом.
Рисунок 3.2 Поведенческое дерево, построенное в Behavior Designer
Другой популярный плагин - NodeCanvas, более простой, но практически такой же эффективный в разработке поведения игрового агента. В первую очередь, графический редактор содержит лишь самые необходимые элементы Behavior Trees, что упрощает работы с плагином для новичков. В NodeCanvas проще по сравнению с Behavior Designer устроен порядок дерева и действий в нём за счёт интуитивных методов выстраивания в порядок и группировки дочерних элементов, как изображено на рис. 3.3. В достоинства также включены экстенсивная документация, инструменты для отладки и простота освоения.
Эти и некоторые другие популярные плагины объединяет один значимый недостаток - они платные, и из-за этого практически недоступны начинающему разработчику. Такие плагины создаются профессионалами с прицелом для таких же профессионалов, поэтому в них включено так много расширений и интеграций с иными плагинами, поскольку они необходимы для разработки коммерческих игр в нужные сроки.
Рисунок 3.3 Поведенческое дерево, построенное в NodeCanvas
Тем не менее, обзор их возможностей позволяет сформировать некоторый образец, которому следуют более дешёвые или даже бесплатные аналоги, создатели которых нацелены на иные цели. В остальном, платные решения обычно предлагают расширенные возможности, например, доступ к исходному коду, который вряд ли пригодится начинающему разработчику.
3.2.2 Бесплатные Unity-плагины
Игровой движок Unity пользуется огромной популярностью среди разработчиков самых разных масштабов по разным причинам, среди которых простота разработки, которой удаётся добиться лёгкой подстройкой рабочей среды движка под любые нужды - программиста, дизайнера и даже художника. Этому способствует открытость самого движка, а также доступ к множеству плагинов, среди которых небольшая часть (~7%) - бесплатные. Что касается инструментов разработки игрового ИИ, то это обычно похожие по функционалу на платные плагины решения, в первую очередь направленные на обучение разработке игр, не вовлекающее создание скриптов вручную.
Behavior Bricks - это, судя по всему, внутренний инструмент небольшой студии разработки мобильных игр на основе студенческого проекта, который они по каким-то причинам недавно вывели в открытый доступ. Это сказывается на степени адаптации для новичков, поскольку документация всё ещё пишется и на данный момент имеет небольшой объём, что затрудняет понимание возможностей плагина. Из того, что уже представлено - имеются графический редактор дерева (см. рис. 3.4) и набор необходимых элементов, а также инструмент отладки [15]. Создатели также акцентируют внимание на то, что узлы интегрируются с внутренними ресурсами Unity, что позволяет легко подключать и отслеживать любые скрипты и переменные, которые ассоциируются с данным узлом.
Рисунок 3.4 Поведенческое дерево, построенное в Behavior Bricks
Behaviour Machine - бесплатный инструмент для построения поведения, имеющий при этом широкий спектр применения. Помимо работы с поведенческими деревьями, этот плагин даёт возможность разработать конечный автомат и применять обе модели одновременно в зависимости от потребностей разработчика. Инструмент для работы с Behavior Trees не имеет графического редактора, предлагая вместо древообразного графа работу с деревьями непосредственно - создавать родительские и дочерние узлы, определять порядок в списке и т.д. Разработку упрощает большой список заготовленных узлов, предназначенных для базовых действий в любой игре, а также типовых событий - например, считывания ввода с мышки и клавиатуры или загрузки агента в игру. Бесплатная версия предлагает полный функционал, платить придётся только за исходный код, что для любительской разработки не нужно.
3.2.3 Выбор подходящего инструмента
Помимо представленных выше плагинов, есть возможность самостоятельно создать структуру поведенческого дерева на уровне кода с помощью редактора на языке программирования C#. Даже при таком выборе существуют шаблоны, находящиеся в открытом доступе, на основе которых, например, можно написать код для определённых действий, которые нужны в данный момент, или недостающих узлов. Теоретически, такой метод положительно скажется на производительности, поскольку работает непосредственно с кодом вместо визуальных элементов. Тем не менее, требуемое для реализации поведение не должно быть настолько сложным, чтобы это имело значение.
Если рассматривать из перечня доступных плагинов, в частности, бесплатных, Behavior Bricks выглядит наиболее удобным средством в случае, если нужно создать достаточно сложное поведение в небольшое время, что соответствует требованиям исследовательской работы. Несмотря на скудную документацию Behavior Bricks (существует только руководство для быстрого старта), графический интерфейс значительно упрощает разработку, особенно, если использовать заготовленные заранее шаблонные узлы действий. Behavior Machine обладает такими же преимуществами, но от его выбора пришлось отказаться по причине недостаточной поддержки продукта. Официальная страница утверждает, что последнее обновление было под версию Unity 2013 года, и запуск на версии 2019 оказался затруднён несколькими исключениями и нефункционирующим интерфейсом.
Выводы по главе 3
В этой главе определился набор инструментов, требуемых для разработки выбранного алгоритма. На основе предоставленной постановки тяжело составить требования, поскольку она очень обобщённая, но в таком случае можно учесть нужды заказчика. Alternativa Games - компания, предоставившая задания, поддерживает компьютерную игру Tanki X - современный аркадный проект, в котором на данный момент реализованы только сражения между игроками, и выполнение этих задач нужно компании для того, чтобы заложить фундамент под режим игры против ботов - PvE (Player versus Environment). Более того, игра разработана на движке Unity, что позволит достаточно легко интегрировать любые наработки. Ключевая характеристика проекта Tanki X - ориентация на аркадность игрового процесса, которая выражается в нескольких условных допущениях по сравнению с реальными танковыми сражениями, среди которых:
· скорость передвижения, манёвренность и разгон танков с места значительно выше практически всех реальных образцов техники;
· в связи с этим, поощряется ведение боевых действий на близких дистанциях;
· данную концепцию поддерживает дизайн игровых карт, которые преимущественно очень маленькие и имеют множество узких проходов;
· прицеливание из оружия упрощено и сводится к направлению башни в сторону противника с помощью мыши;
· разнообразие средств поражения противников помимо обычных разрывных снарядов - огнемёт, замораживание, лазерная пушка и т.д.;
· классификация танков в зависимости от типа корпуса, подбор которого влияет на скорость и прочность танка.
Исходя из представленных характеристик, можно сделать выводы о том, что поведенческие деревья очень хорошо подходят для реализации такого упрощённого поведения, ведь чем менее сложное поведение игрового агента задано, к примеру, в пределах одной функции наведения на цель, тем лучше они показывают себя. Тем не менее, легко провести трансформацию набора состояний, составляющих конечный автомат, в поведенческое дерево благодаря строгому порядку действий, что позволит создать алгоритм гораздо легче и быстрее по времени, чем с использованием Utility AI.
Что касается выбранных инструментов для разработки, игровой движок Unity, его редактор игровых сцен, а также большинство плагинов к нему направлены на достижение определённых узконаправленных целей на разных стадиях разработки на как можно более абстрактном уровне, порой даже полностью избегая работы с кодом. Все эти плагины одинаково успешно могут быть использованы для разных задач, поскольку проходят проверку качества перед публикацией в магазине Unity Asset Store. Зачастую выбор нужного плагина сводится к подходящей стоимости или бесплатности, и последний случай актуален для исследовательской работы в рамках учёбы для ознакомления. Таким образом, если нет конкретных требований к набору инструментов, выбор осуществляется обычно на уровне субъективных предпочтений определённых подходов к разработке - с акцентом на программирование или нет.
поведение игровой агент behavior trees utility
4. Разработка алгоритма поведения игрового агента
В этой главе предстоит реализовать игровой проект, реализующую игрового агента на основе имеющейся постановки алгоритма. Разработка целого игрового проекта - это комплексный процесс, в который входят, помимо настройки поведения ИИ, создание и положение объектов, смену игровых сцен, настройку камер и освещения и, навигацию агентов т.д. Игровой проект нужно разработать с помощью инструментария Unity Editor и языка программирований C#, для чего необходимо использовать информацию из книги [16], которая является комплексным справочником для разработки на движке Unity игр любых масштабов.
4.1 Проектирование алгоритма
4.1.1 Выявление требований
В условиях недостаточно проработанной постановки главной проблемой в ходе работы было определение источника, который бы смог высказать своё видение этой задачи. В связи с этим было принято решение обратиться к непосредственным потребностям компании-заказчика - Alternativa Games. Уже известно, что их текущий и самый большой проект - Tanki X - это эксклюзивно многопользовательский проект, и в целях расширения аудитории они нуждаются во внедрении в игру однопользовательского режима, т.е. противостояния игрока и ботов. Таким образом, если игровые боты, согласно определению, должны максимально достоверно имитировать действия игроков, необходимо определить возможности, доступные игроку во время игры в Tanki X. В следующих описаниях следует понимать определения «цель», «противник» и «враг» как идентичные.
Игрок появляется на игровой карте в одном из режимов игры - захват флага, командный бой или бой, и в двух последних идёт упор на поиск и уничтожение танков противника, поэтому в работе будет акцентировано внимание на условиях этих режимов. Если описывать поиск противника, то игрок способен найти его на любой дистанции, если имеется прямая видимость, и цель не закрывают полностью какие-либо элементы геометрии на карте. Проблема в задаче по уничтожению противника состоит в том, что сделать это можно только с помощью оружия на танке игрока, а оно не обладает такой же большой дальностью. Скорее всего, обнаружив противника на дальней дистанции, игрок захочет приблизиться к нему, чтобы наверняка нанести ему урон. Тем не менее, игроку не нужно вставать к цели вплотную, ведь человек может оценить, с какой дистанции он может поразить цель. Это зависит как от человеческих факторов, таких как уверенность в своих навыках или быстрота принятия решений, так и показателей, которые вполне могут быть измерены в игре, и, соответственно, применены к игровому агенту. К ним относятся, например, характеристики танка, на которые влияют модификации, которые можно устанавливать на танк перед началом игры или находящиеся на карте временные улучшения.
Рисунок 4.1 Диаграмма прецедентов игрока в Tanki X
На рис. 4.1 изображена составленная на основе описания и промо-материалов игры диаграмма прецедентов, описывающая, что может делать игрок. Темным цветом выделены ключевые варианты использования, которые будут рассматриваться в дальнейшем, потому что имеющаяся постановка указывает на необходимость атаки цели с помощью снаряда, а также нахождения его среди геометрии сцены, для чего требуется ориентация в пространстве. Конечно, в отличие от бота, реальному игроку не нужны какие-либо условия для исполнения любого из прецедентов. Игрок может намеренно не искать противника, а также просто стрелять в любой момент и в любом направлении. Поэтому при проектировании игрового агента необходимо разработать ряд условий, успешное исполнение которых приведёт к выполнению одного из базовых прецедентов.
На основе этого была составлена дополненная диаграмма прецедентов (см. рис. 4.2), где у игрового агента нет доступа к действиям игрока, но они достигаются выполнением промежуточных прецедентов, описание которых приведено ниже. В этих прецедентах должны проводиться преимущественно проверки каких-либо показателей, и на их основе агент сможет выполнить какие-либо из ключевых прецедентов.
Рисунок 4.2 Диаграмма прецедентов с включением игрового агента
Патрулировать - прецедент отвечает за простое перемещение по карте в случае, если никаких признаков противника в зоне его видимости. Таким образом, можно утверждать, что это состояние игрового агента по умолчанию, к которому он сможет вернуться, например, если цель была уничтожена. Этот прецедент должен состоять из двух простых действий, повторяющихся в цикле - движение к точке и ожидание в течение нескольких секунд. Каждый раз после совершения патрулирование проверяется присутствие цели рядом, и, если враг находится рядом, агент должен приступить к выполнению одного из прочих прецедентов - поиска или атаки.
Искать противника - прецедент должен вызываться, если противника нет в прямой видимости, но есть примерное понимание о его местоположении, например, если есть некоторая зона, где цель была перед тем, как уйти из виду агента. В таком случае, игровой агент немедленно отправится в эту зону и продолжит патрулировать там, но более старательно. Например, перемещаясь по этой зоне, агент может одновременно поворачивать башню, пытаясь обнаружить цель с большей вероятностью, чем пытаться искать только с переднего направления. После определённого количества попыток поиска агент должен сделать вывод, что цели здесь больше нет, прекратить поиск и продолжить патрулирование. Если противник в зоне найден - перейти к атаке.
Оценить шанс попадания - прецедент, иначе называемый «Атаковать», предполагает, что противник был обнаружен и, согласно инструкциям агента, должен быть атакован. Однако в диаграмме прецедентов задействована связь «расширение», а это значит, что не всегда при обнаружении цели агент сможет её успешно поразить. К примеру, у агента, по аналогии с игроком, большая область видимости, и найти цель он сможет с большой дистанции, но особенности его танка не позволяют ему поразить цель, которая находится слишком далеко. Следует учитывать ряд показателей, применимых к танку агента, чтобы он мог сделать вывод, стрелять ил нет. Для этого у танка должна быть характеристика под названием «эффективная дальность», определяющая, на какой скорости дуло танка пошлёт снаряд. Также в танк можно заряжать разные типы снарядов, которые также будут влиять на успешность попадания - это такие переменные, как, например, радиус поражения взрыва. Совокупность этих данных позволит агенту сделать выводы об успешности выстрела ещё до того, как он будет воспроизведён, что должно имитировать действия, которые бы проделал живой игрок. В случае, если агент сочтёт, что не сможет наверняка поразить противника, то он перейдёт к прецеденту «Приблизиться к противнику», т.е. переместиться ближе к цели на количество единиц, равное разнице дистанции между танками и эффективной дальности выстрела агента.
Учитывая, что постановка алгоритма поведения опирается на аркадный игровой проект с заметно упрощёнными по сравнению с реальной жизнью механиками, принятие решения игровым агентом тоже должно быть упрощено. Это необходимо не только для потенциального улучшения производительности, но и для будущего баланса игровых агентов в плане их противостояния игрокам. Неправильно настроенный агент будет заметно превосходить игрока в равном бою, поскольку может всегда предугадывать позицию игрока и стрелять по нему с максимальной точностью каждый раз. При разработке игрового ИИ всегда нужно учитывать, что виртуальный соперник, который всегда всё исполняет идеально, не имеет соревновательной ценности, поскольку всегда имеет преимущество перед любым игроком. Например, если взять прецедент «Оценить шанс попадания», можно сопоставить имеющийся шанс попадания с некоторым пороговым значением, которое должно настраиваться, если текущий шанс ниже порога, то агент не будет стрелять. Если порог понизить, агент будет действовать увереннее и наносить больше урона, т.е. он становится сложнее для игрока
Таким образом, к реализации алгоритма был составлен ряд требований, которые расширяют исходную постановку. Функциональные требования указывают, что игровой агент в проекте должен:
· уметь перемещаться по карте и искать противника в пределах установленной области видимости;
· реагировать на обнаружение противника переходом к подготовке атаки;
· выстреливать снаряд, который при столкновении с любым физическим объектом наносит урон и отбрасывает любые танки в установленном радиусе поражения;
· при обнаружении цели определять дистанцию между ним и собой;
· определять шанс попадания снаряда в цель до непосредственного выстрела на основе характеристик танка под управлением агента;
· искать противника в зоне его примерного местоположения, если такая присутствует в близости от агента.
Нефункциональные требования связаны с подготовкой среды и игрового проекта, в рамках которого будет реализовано поведение игрового агента, а также связаны с характеристиками проекта заказчика Tanki X. В эти требования входят:
· алгоритм должен быть реализован с помощью игрового движка Unity, с использованием инструментария Unity Editor в режиме 3D;
· при реализации поведения должна быть задействована парадигма проектирования игрового ИИ Behavior Trees;
· при подготовке проекта с игровым агентом должны использоваться бесплатные расширения;
· проект должен быть производительным.
4.1.2 Построение модели поведения
Имея набор требований, в который входит весь возможный функционал игрового агента, можно перейти к проектированию непосредственно поведенческого дерева. Создание дерева сразу сопряжено с рядом трудностей, поскольку нет чёткой нотации по преобразованию этих данных в элементы. В таком случае стоит воспользоваться промежуточным этапом, т.е. преобразовать требования в состояния конечного автомата и определить условия переходов. Это связано с основным преимуществом Behavior Trees, которые, будучи развитием конечного автомата, легко преобразуются из него. В таб. 4.1 указаны результаты преобразования, и, как и предполагалось, одному требованию соответствует одно состояние.
Таблица 4.1
Состояния и переходы для конечного автомата
|
Текущее состояние |
Условия перехода |
Новое состояние |
|
|
Стояние |
Прошла 1 секунда |
Патрулирование |
|
|
Известно примерное местоположение противника |
Поиск противника |
||
|
Противник обнаружен |
Подготовка к атаке |
||
|
Патрулирование |
Маршрут пройден |
Стояние |
|
|
Поиск противника |
Позиция противника не актуальна |
Стояние |
|
|
Противник обнаружен |
Подготовка к атаке |
||
|
Подготовка к атаке |
Противник обнаружен Шанс попадания достаточно высок |
Атака |
|
|
Противник обнаружен Шанс попадания недостаточно высок |
Сближение с противником |
||
|
Противник утерян из виду |
Поиск противника |
||
|
Атака |
Противник обнаружен Противник уничтожен |
Стояние |
|
|
Противник обнаружен Противник не уничтожен |
Подготовка к атаке |
||
|
Сближение с противником |
Противник обнаружен Приблизился к противнику на N единиц |
Подготовка к атаке |
|
|
Противник утерян из виду |
Поиск противника |
Для наглядности переходов был создан граф конечного автомата (см. рис. 4.3), который даже при достаточно небольшом числе состояний является обширным, а также повторяет некоторые условия, чтобы соответствовать требованиям. Дальнейшее расширение поведения игрового агента привело бы к большему количеству повторений просто из-за зависимости действий от присутствия цели вблизи от агента.
Рисунок 4.3 Конечный автомат поведения игрового агента
Несмотря на то, что в чистом виде конечный автомат для разработки не подойдёт, в нём можно проследить общий порядок состояний, по которым обычно проходит агент. В частности, начальное состояние агента обычно соответствует таковому у поведенческих деревьев, и у последних при каждом проходе это состояние проверяется в самом конце, т.е. когда остальные состояния отправили сообщения о неудаче.
На примере составленной схемы поведения игрового агента на основе Behavior Trees (см. рис 4.4) можно увидеть, что это делается с помощью селекторов - при отсутствии целей в поле видимости будет выбрано самое правое действие, а точнее, их последовательность - стояние и патрулирование, поскольку этот композитный блок позволяет объединить простые состояния в практически одно действие.
С переходом к Behavior Trees пропала проблема повторения условий, потому что внутри одного декоратора можно выполнить несколько действий, поставив сразу после него нужный композитный блок. Более того, такое дерево очень наглядно иллюстрирует общее поведение, потому что похоже на обычные блок-схемы.
Рисунок 4.4 Поведенческое дерево поведения игрового агента
При дальнейшей разработке надо понимать, что поведенческое дерево приведено в качестве единственной итерации, т.е. проход будет осуществляться только один раз. Такой метод не всегда позволит агенту уничтожить свою цель, поэтому стоит учитывать возможные изменения дерева далее на этапе реализации. Отсутствие строгой нотации у Behavior Trees позволяет разработчикам инструментария принцип построения и порядок элементов в зависимости от своих нужд, и то нужно учитывать при использовании сторонних расширений, список которых приведён в таб. 4.2.
Таблица 4.2
Используемые расширения из Unity Asset Store
|
Название расширения |
Версия |
Описание |
|
|
Behavior Bricks |
1.0.2 |
Инструмент для создания поведенческих деревьев с привязкой к одному игровому объекту. Имеет графический редактор, инструменты отладки и набор типовых |
|
|
Unity Particle Pack |
1.2 |
Бесплатный набор визуальных эффектов от разработчиков Unity. Эффекты можно привязать к игровому объекту и настроить условия их появления, например, взрыва при столкновении снаряда. |
4.2 Реализация алгоритма
4.2.1 Настройка игровой сцены
После создания проекта в Unity Editor создаётся также проект программы на C# с внедрёнными библиотеками Unity. В проекте каталоги были организованы так:
· BehaviorBricks - содержание расширения Behavior Bricks;
· Materials - текстуры или шаблоны физических материалов, которые можно наложить на модели;
· ParticlePack - содержание расширения Unity Particle Pack;
· Resources - содержит так называемые префабы - шаблоны, составленные из геометрических примитивов и использующиеся в качестве моделей;
· Scenes - игровые сцены, на которых размещаются объекты, присваиваются скрипты и исполняется игровой процесс;
· Scripts - файлы с расширением .cs, в которых содержится почти вся игровая логика, которую написал разработчик.
Таким образом, игровой процесс можно создать и воспроизвести только с помощью сцен. Их можно добавить из меню Assets Create Scene, присвоив им любое имя, после чего сцена появится в папке Scenes с рядом предустановленных элементов. На рис. 4.5 эти элементы - Main Camera, отвечающий за отображение части сцены с настраиваемого ракурса, и Directional Light, источник направленного света, необходимого, чтобы сцена не была залита черным цветом.
Любые объекты могут быть добавлены двумя способами - их можно перетащить в панель иерархии из структуры проекта, если они там есть. Иначе можно создать объект на основе большого количества геометрических примитивов из контекстного меню панели иерархии или в меню GameObject. В проекте за базовую геометрию уровня будет отвечать простая плоскость, которую можно создать из меню GameObject 3D Object Plane.
Рисунок 4.5 Пустая игровая сцена
Учитывая, что на уровне может присутствовать только одна плоскость, по которой будут перемещаться агенты, этот объект должен быть статичным в среде C#, что можно поменять сразу в инспекторе, изображённом на рис. 4.6, выбрав объект Plane. То же самое в дальнейшем будет касаться остальной геометрии сцены, включая препятствия.
Рисунок 4.6 Меню настроек объекта Plane
К игровым объектам можно подключать несколько разных компонентов, чтобы поменять их назначение или задать конкретный функционал, например, с помощью скрипта, что можно сделать в инспекторе кнопкой Add Component. Из важных компонентов, имеющихся у размещённой плоскости, можно выделить компонент Mesh Collider на рис. 4.7. Коллайдер - настраиваемая область, обычно повторяющая поверхность объекта, которая определяет факт столкновения с другими коллайдерами. Если у объекта нет коллайдера, то все остальные объекты, имеющие из, будут проходит сквозь него. Исходя из настроек коллайдера, можно сделать вывод, что плоскость - неконвексный полигон. Благодаря коллайдеру по ней в дальнейшем свободно смогут перемещаться игровые агенты, имеющие у себя аналогичный компонент.
Рисунок 4.7 Настройки компонента Mesh Collider у объекта Plane
После расположения плоскости надо разместить камеру таким образом, чтобы она охватывала место, где будут расположены все объекты, в данном случае, в ближнем углу. Для лучшего охвата камера будет следить сверху под наклоном в 45 градусов вниз. Помимо этого в инспекторе (Camera Projection) можно изменить режим отображения на Orthographic, после чего камера показывает сцену в режиме изометрии, т.е. без поправки на перспективу. После настройки камеры стоит настроить освещение, в Unity к сцене применяется один тип освещения из двух - статическое заготовленное или в реальном времени. Конечно, для экономии ресурсов лучше заготовить всю геометрию, после чего сгенерировать весь свет на сцене, чем нагружать компьютер покадровыми вычислениями. Для этого применим в панели Window Rendering Lighting Settings предпочитаемый режим Baked Global Illumination вместо Realtime Global Illumination.
...Подобные документы
Сбор и анализ сведений по предметной области по дисциплине "Астрономия" с целью разработки обучающего игрового приложения. Исследование алгоритмов и характеристик существующих программных систем аналогов. Разработка архитектуры программной системы.
курсовая работа [4,1 M], добавлен 27.11.2014Анализ и виды интеллектуальных агентов в системе дистанционного обучения и их характеристики. Построение интеллектуального агента глоссария на платформе Jadex с помощью XML формата. Среда разработки и описание интеллектуального агента с помощью BDI.
курсовая работа [113,6 K], добавлен 10.02.2011Изучение существующих подходов к использованию компьютерных игр в образовательном процессе. Разработка и реализация проекта игрового обучающего приложения на мобильной платформе. Выбор платформы и средств реализации игрового обучающего приложения.
дипломная работа [3,4 M], добавлен 12.08.2017Обзор системного и прикладного программного обеспечения используемого в ООО "Игровые системы". Описание компьютерной сети предприятия. Разработка игрового продукта для планшетов Apple iPad. Реализация визуального интерфейса и алгоритма работы модуля.
отчет по практике [1,4 M], добавлен 18.01.2015Разработка игрового проекта на игровом движке Unity 3D в среде программирования MS Visual Studio 2017. Блок-схема алгоритма работы приема сообщений с сервера на клиенте с упрощенным описанием выполняемых команд. Реализация пользовательского интерфейса.
курсовая работа [1,5 M], добавлен 10.07.2017Подбор игрового движка и описание его основных характеристик. Разработка структуры, алгоритма и интерфейса программы. Проектирование иерархии классов. Выделение типового приема визуализации. Тестирование правильности работы программного обеспечения.
курсовая работа [3,1 M], добавлен 19.01.2017Разработка программного продукта, предназначенного для имитации физического взаимодействия между объектами на основе игрового симулятора. Проектирование программы "LonelySpaceRanger", код которой представлен на языке VisualС++. Разработка интерфейса.
дипломная работа [3,2 M], добавлен 30.11.2011Структура Android-приложений. Особенности игрового движка. Алгоритмизация и программирование. Список игровых состояний. Настройка, отладка и тестирование программы. Разработка руководства пользователя. Тестирование инсталляции и отображения элементов.
дипломная работа [4,5 M], добавлен 19.01.2017Разработка компьютерных игр как зрелищная и наиболее сложная отрасль программирования. Рассмотрение основных особенностей конструирования классов CGame и Players, а также алгоритмов вычисления траектории полета снаряда. Анализ алгоритма PassivePlayer.
курсовая работа [5,1 M], добавлен 22.02.2013Технология программных агентов. Форматы метаданных, использующиеся для описания электронных ресурсов. Разработка интеллектуальных агентов. Среда разработки Jadex для построения интеллектуальных агентов. BDI модель интеллектуального агента ресурсов.
курсовая работа [279,8 K], добавлен 20.02.2011Базовые характеристики агента, требования к программированию. Особенности архитектуры, организуемой в виде нескольких уровней, представляющих разные функциональные характеристики. Проблемы многоагентных систем при реализации идеи коллективного поведения.
презентация [255,2 K], добавлен 25.06.2013Преимущества операционной системы Android. Проектирование интерфейса приложений. Визуальные редакторы и средства кроссплатформенной разработки. Оптимизация игрового процесса, выбор фреймворка и библиотек. Классификация и характеристика игр по жанрам.
дипломная работа [2,6 M], добавлен 10.07.2017Анализ игровых жанров для мобильных устройств и целевой аудитории. Разработка концепции игрового приложения, основной механики, меню и интерфейса игры. Описание переменных скриптов. Реализация выбора цели и стрельбы. Настройка работоспособности игры.
дипломная работа [1,4 M], добавлен 19.01.2017Изучение существующих подходов к использованию компьютерных игр в образовательном процессе. Особенности использования мобильного обучения. Методика и этапы закрепления полученных ранее знаний с использованием игрового приложения на мобильной платформе.
дипломная работа [813,0 K], добавлен 27.10.2017Анализ целевой аудитории. Функциональные характеристики пользовательского приложения. Разработка алгоритмов и интерфейса программного продукта, функций рабочей области. Написание скриптов на языке C#. Тестирование программы методом чёрного ящика.
дипломная работа [1,5 M], добавлен 09.11.2016Написание игры "Lines" на языке Object Pascal в среде Delphi. Алгоритм работы программы. Описание метода генерации поля. Используемые константы и переменные. Форма приложения после старта игрового процесса. Основные элементы формы и обработки событий.
курсовая работа [225,0 K], добавлен 12.04.2012Разработка инструментального средства для обнаружения уязвимостей веб-приложений на основе контроля поведения с функцией автоматического построения профилей нормального поведения. Основные методы обнаружения аномалий, анализ возможности их применения.
курсовая работа [865,8 K], добавлен 02.02.2015Знакомство с особенностями и этапами разработки приложения для платформы Android. Рассмотрение функций персонажа: бег, прыжок, взаимодействие с объектами. Анализ блок-схемы алгоритма генерации платформ. Способы настройки функционала рабочей области.
дипломная работа [3,4 M], добавлен 19.01.2017История создания компьютерных игр. Обзор современных игровых жанров. Выбор используемых инструментов. Руководство пользователя. Разработка игры в жанре 3D шутера от первого лица. Конструктор игр Game Maker. Создание уровня с несколькими регионами.
курсовая работа [961,8 K], добавлен 22.06.2015Анализ деятельности группы компаний "Инрэко ЛАН". Общая характеристика, основы проектирования и разработка операционной системы Android. Этапы разработки программного игрового приложения с использованием физики. Скриншоты, отображающие игровой процесс.
отчет по практике [2,7 M], добавлен 19.07.2012
