Проектирование Непредсказуемого Интеллекта В Играх. Часть 2. Анализ Толпы

Как сделать умную толпу в игре и почему важен лидер толпы.

Толпе нужен лидер, даже толпе зомби.

Введение

В этой части я более подробно расскажу о классе NPC под названием толпа.

Оформить толпу можно по-разному; Самый простой способ сделать это — использовать простое дерево поведения, но в этой статье я начну проектировать толпу с помощью метода GOAP, который я описал в предыдущей статье.

Примеры будут написаны на C# и движке Unity 3d, потому что.

он очень хорош для быстрого прототипирования подобных сцен и легкого тестирования гипотез и новых архитектур.

Подробные реализации я скрою, а сами исходники прикреплю как проект на GitHub.

В своих статьях я стараюсь сосредоточиться на дизайне и концепции, а не на реализации.

Я не буду упрощать логику и злоупотреблять комментариями, некоторые фрагменты кода будут из боевых проектов, а архитектура вполне готова к работе из коробки.

Поэтому разжевывания элементарных вещей в программировании здесь тоже не будет. Наслаждайся чтением!

Вычислительные сложности искусственного интеллекта

Предложенная форма GOAP из предыдущей статьи имеет большой недостаток — для каждого NPC без многопоточности расчет вероятности вызова цели будет происходить отдельно в течение каждого кадра.

Представим себе простую сцену, где у нас одновременно есть N персонажей (из 100).

И обычный метод расчета вероятности вызова цели ReactOnCharacter, которая должна заставить NPC поговорить с другим персонажем, если они столкнутся или заблокируют путь.

Рисовать такое количество разных персонажей – это совершенно отдельная задача.

Наиболее распространенным примером алгоритма коллизий является создание области вокруг.

Большинство двигателей используют пространственный поиск .

Если стоит задача реализовать NPC на сервере (например, .

Net Core или C++ сервере), то она осложняется отсутствием таких утилит и этот метод придется реализовывать с нуля.

Это влечет за собой дополнительные архитектурные требования: система контроля положения всех динамических единиц игры (игровых и неигровых персонажей, транспорта и т.п.

), прогнозирование движения и компенсация задержки/задержки , а также системы мониторинга изменений мира (особенно важно для игр-песочниц).

После всего этого каждые N миллисекунд необходимо проверять каждого персонажа на предмет расстояния до ближайшего найденного NPC. Это все увеличивает нагрузку на ЦП, поэтому также потребует корректировок целей и поведения.

Толпа

Толпы не являются отдельными типами NPC и, скорее всего, не будут отражать высококачественное поведение каждого объекта в отдельности (кроме локальных взаимодействий и IK/анимации).

Для работы с толпой нам нужна сущность лидер .

Лидер — это основной блок, в котором будут обрабатываться все вероятностные расчеты.

С точки зрения GOAP и подобной механики, даже если вы напишете самодельную архитектуру ИИ, особой разницы не будет, концепция останется той же.

Кратко это так: есть сущность члена группы (скажем, член толпы ) и лидер группы ( лидер толпы ).

Руководитель группы строит план действий на основе своего основного образца; участники группы, в свою очередь, повторяют его действия и могут добавлять незначительные вариации.

Базовая архитектура

1. Подготовка Так.

Нам нужна сцена, нам нужны капсулы, самолет, навмеш и спаунер.

Для начала достаточно простой сцены Основная идея — создать как можно больше NPC, чтобы создать толпу, но я хочу показать немного больше, чем просто лидера толпы.

Я со своими лидерами разберу несколько групп и мы посмотрим, как они взаимодействуют друг с другом и что будет, если лидер умрет. Поэтому каждая группа появится в своей зоне и получит свой цвет: красный, синий и зеленый, а лидерами толпы будут темные оттенки своей группы.

1. Архитектура ГОАП Здесь все так же, как и в предыдущей статье, нам понадобится скелет нашего GOAP, чтобы его можно было расширить.

Я не буду заполнять вас примерами кода; Ознакомиться с подходом можно в репозитории.

Коротко о скриптах и о том, что у нас есть: • Атомные цели - простейшие задачи, часто состоящие из одного действия и отслеживающие статус выполнения цели.

• Композитные цели - составные задачи, которые собирают либо несколько CompositeGoals, либо несколько AtomicGoals. • Основной - абстракции архитектуры.

• оценщики - оценщики смотрят на возможность выполнения действия, глядя на условия окружающего мира.

• Функции - утилиты для целей, например поиска героев вокруг.

• Движение - корневой функционал для движения.

За основу взята логика рулевого движения из книги.

«Программирование игрового ИИ на примере».

• NPCOfflineManager И ОффлайнNPC - плагины, касающиеся спауна и обработки NPC ThinkGoal .

2. Интеллектуальный дизайн Если вы запускаете игру, где каждый является индивидуальностью, с определённым набором оценщиков, например ExploreGoal, IdlingGoal, LookAtPlayerGoal (базовый набор, который я рассматриваю в статье), то мы получим самостоятельные юниты, которые движутся или стоят в случайном порядке.

Через несколько секунд НПС разбегаются в разные стороны и начинают существовать отдельно.

Если мы создадим сотню игроков, каждый из них будет производить вычисления самостоятельно, и это, несомненно, сильно ударит по производительности (особенно если логика каждого NPC сложна и ему предстоит выполнять множество задач).

Помня, что для создания толпы мы должны обладать сущностью лидера и члена группы, следующим шагом будет создание связи.

лидер группы .

Хотя технически лидером является каждый отдельный NPC, существует два варианта создания члена группы:

1. Мы повторяем цели лидера, не оценивая их.

   Эоценщики всех задач NPC не будут использоваться, а значит нагрузка на каждые N мс «мозга» не нужна;

2. Используйте систему уведомлений и полностью отдельную логику от GOAP для участников группы.

   Этот подход хорошо подойдет для стаи птиц, где лидер выбирает направление, а все остальные просто следуют за ним.

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

Реализация логики толпы

Далее нам понадобится возможность голосовать за лидера — можно добавить отдельный оценщик, который будет оценивать необходимость голосовать за лидера на каждом тике.

Также спаунер должен контролировать голосование и назначать лидера (чтобы избавить от этого самих участников голосования и избежать путаницы).

Обозначу основные правила, которые необходимо учитывать в такой схеме:

• Голосование происходит до тех пор, пока не истечет время для него, каждый голос определяется уникальным идентификатором, по которому персонажи продолжают голосовать до тех пор, пока не будет выбран лидер;
• Участники могут голосовать только один раз;
• Если лидер уничтожен, голосование начинается заново;
• Лидером становится NPC, за которого проголосовало большинство;
  
  
  
  Таким образом, каждая группа получает своего лидера.

   

 public class NPCSpawner : MonoBehaviour
 {
 

   

• Управление Размером Outlook Pst В Режиме Imo

  19 Oct, 24

• Скрытая Экспедиция: Неизведанные Острова

  19 Oct, 24

• Как Улучшить Производительность И Безопасность Сети?

  19 Oct, 24

• Варианты Веб-Дизайна В Шеффилде Для Вашего Бизнеса

  19 Oct, 24

• Питон За Месяц

  19 Oct, 24

• Swift Tablemanager

  19 Oct, 24

• Как Вы Держите Свою Нокию?

  19 Oct, 24

• Смартфоны Lenovo На Ifa 2014

  19 Oct, 24

• `Мы С Яндексом На Вас!` Или Seo В России

  19 Oct, 24

• Распознавание Цифр С Использованием Простой Статистики И Анализа Топологии

  19 Oct, 24