Для выполнения дипломного
командного проекта реализуются перемещение подконтрольных юнитов, создание
построек, налаживание торговых путей и так далее. И было бы хорошо, но до
градостроительного симулятора командный проект далеко, да и команда любит
больше посоревноваться, что выбранный способ игроком захвата и доминирования
карты намного лучше, чем у кого-то. Появляется мотивация победить, стать ещё
лучше и даже чему-нибудь научится.
Была поставлена задача
разработать игрового бота, имитирующего человеческую игру. Почему не был выбран
мультиплеер? Потому что теряется функционал нормального обучения самого игрока.
С противником у текущего пользователя появляется высокий порог вхождения в
игру, потому что он будет играть против персонажа, с возможно уже имеющимися
навыками. А если вводить в баланс уровней игроков, их времени внутри игры и так
далее, то появляется проблема с фиксацией всех этих данных. Также желательно
разработать структуру бота, чтобы игроки могли на них обучаться, им
противостоять и так далее, так как бота можно будет гибко настраивать.
Перед тем, как полностью
реализовывать самого бота, был произведён поиск референсов, к чему можно
отсылаться внутри игры. Были просмотрены материалы по Civilization 5, Endless Legend, и другие игры с гексагональной
картой. Нормального объяснения в принципе, как писали ботов, не было, всё
только ссылались на литературу по написанию игровых ботов. Пока функционал ограничивается
кубиками и постройками, а также пока реализуется перемещения объектов по
гексагональной сетке, определили 3 основных функции игрового бота:
1) Восприятие
– функция, в которой бот получает все доступные ему данные (информация об
окружении, которая влияет на его поведение)
2) Мышление
– в зависимости от того, что происходит вокруг бота, он начинает принимать решения,
как поступить.
3) Действие
– все продуманные действия должны быть выполнены
Основой для этих 3
функции является зацикленность – появляются новые данные – значит нужно
продумать новые решения.
Так как передача данных –
это функция, которую можно реализовать, не применяя никаких решений, её мы не
затронем. Ведь на данном этапе разработки более важным является принятие
решений.
Во время мышления решили
взять структуру Decision
Tree
(Дерево решений), так как проще всего именно он в реализации и создаёт иллюзию,
что ты играешь против человека, а не против машины. Но если быть честным, то
внутри кода будет получено, в большей вероятности, if-else конструкции.
На данном этапе была продумана начальная, не продуманное дерево решений.
Это начальный уровень для
бота, если он начнёт распознавать вражеские единицы и действовать в зависимости
от окружения, то это уже успех и дерево можно будет только улучшать.
События и действия – это основной
функционал бота внутри проекта. Помимо этого дерева событий, именно игрового
бота, будет ещё дерево событий глобальное – которое не будет позволять боту
выходить за границы и которое будет его ограничивать. Туман войны, случайные события,
а также случайные поселения – за всё это будет отвечать глобальный бот. У него
тоже есть своё дерево решений. Это советовалось в статья GameAI pro (http://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter31_Spatial_Reasoning_for_Strategic_Decision_Making.pdf)
Также есть модель
поведения, когда глобальный бот диктует, как действовать подчинённому ему боту,
но в проекте в нём нет смысла, так как нет других подконтрольных городов, в
которых мы можем строить здания.
Таким образом, можно
сделать вывод, что для реализации игрового бота, вначале, неплохо было бы иметь
функционал игрока, а дальше нужно лишь развить дерево, чтобы дальше только к
определённой ветке дерева и его условию.