Какие данные должны кэшироваться на многопользовательском сервере, относительно ИИ и игроков?

В виртуальном месте, полностью управляемом сетью, с произвольным количеством игроков и произвольным количеством врагов, какие данные должны быть кэшированы в памяти сервера, чтобы оптимизировать плавное моделирование ИИ?

Попытка объяснить, скажем, игрок A видит игрока B на E, а врага A на G. Каждый из этих игроков видит игрока A, но не обязательно друг друга. То же относится и к врагам. Подумайте об этом вопросе с точки зрения сверху вниз, пожалуйста.

Например, во многих случаях, когда игрок стреляет из своего оружия, сервер обрабатывает звук как радиальный «сигнал», который любой другой объект в пределах досягаемости «слышит» и реагирует на него.

Выполнение этих поисков все время для целой области, содержащей, возможно, много несвязанных игроков и врагов, кажется проблемой, когда бюджет для каждого агента ИИ настолько мал.

Должна ли каждая сущность кэшировать все, что входит и выходит из ее радиуса осознания? Есть ли отличный способ отследить близлежащие объекты, не заполняя память такими кэшами?

А как насчет других проблем, связанных с ИИ, которые могут возникнуть, если предположить, что предыдущий работает хорошо? Мы говорим об окружающей среде с сотнями врагов, роем.

Есть несколько способов сделать это, но они зависят от того, где вы будете иметь большое количество взаимодействий или очень плотное население.

К сожалению, если вы хотите, чтобы ваша симуляция сохраняла хорошую точность, вам нужно будет обработать большинство событий, сгенерированных всеми актерами, и найти всех / большинство актеров, требующих уведомления.

Cheap столкновения области

Что касается проблемы с областями осведомленности, вы можете решить ее, используя простое обнаружение столкновений.

В 2-м мире обнаружение столкновений на кругах "дешево". Например, операция по определению, находится ли точка в окружности, требует только 2 вычитаний, 2 умножений и сложения. Вам не нужно делать квадратный корень, так как вы можете хранить и сравнивать квадратный радиус вашей области с квадратным расстоянием напрямую.

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

Ориентированный на события радиус

Если объем событий (перестрелка, движение ...) низок, вы можете попытаться обнаружить каждого актера, на которого воздействует каждое событие. Ваши события будут генерировать области (где они могут быть услышаны).

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

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

-> Вы также можете создавать небольшие зоны (события), в которых все события регистрируются вместе и обрабатываются в виде групп (т. Е. 2 ​​удара пули и шаг ноги, происходящий в одной зоне, будут использовать только одно сканирование и будут отправлены всем затронутым объектам). <-

Актер ориентированные области

Вы можете использовать принцип «области осведомленности». То есть, если актер сталкивается с областью осведомленности (кругом) другого актера, вы просто добавляете конфликтующий актер в список потенциально взаимодействующих акторов. В зависимости от того, как построен ваш движок, вы можете зарегистрироваться для получения звуковых сообщений и других событий, происходящих от актеров в списке.

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

Вам не нужно проверять изменения области осведомленности каждый тик. Вы можете делать это время от времени, например, каждые 5-30 тиков.

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

Смешанный подход

Вы можете смешать оба подхода. Вы можете зарегистрировать актеров в областях осведомленности для таких событий, как шаги ног, носы двигателей и т. Д. И другие события (удары снарядов, взрывы и т. Д.) Могут запускать сканирование в зависимости от их важности. Вероятность того, что кто-то услышит взрыв гранаты, гораздо выше, чем удар от пули, поэтому взрыв гранаты должен вызвать более обширное сканирование, чем удар пули.

Я бы рекомендовал вам начать реализацию радиуса события в первую очередь. Как только это сработает, и вы сможете по желанию уменьшить / увеличить точность этого метода, вы можете приступить к реализации областей осведомленности актера. Таким образом, вы сможете начать перемещение некоторых событий во вторую систему.

Контекстные пулы

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

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

Конечно, вам не нужно создавать несколько «списков» для пулов. Вы можете просто использовать битовую маску и установить правильную маску для каждого актера / области. Таким образом, вы можете отфильтровать с простым или до проверки расстояния.

агрегирование

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

По существу, групповой объект становится заменой / прокси для всех сканирований, в то время как все члены группы удаляются из пулов.

Этот принцип также может применяться ко всем устройствам внутри автомобиля.

Активация близости

Если на сервере действительно много ботов (и вам действительно нужно поддерживать их всех живыми), то вы можете активировать осведомленность / ИИ только для тех, кто находится в специальной «зоне активации вокруг каждого игрока». Таким образом, боты (или группы) внутри одной или нескольких областей активации сохраняют себя и свою область осведомленности активированной (в пуле столкновений). В противном случае их область осведомленности удаляется из пула (-ов) активных областей.

Частота, с которой эти «области активации» сканируют «области осведомленности», может варьироваться в зависимости от скорости игрока. Игрок, путешествующий на более высокой скорости, активирует больше активаций, чем игрок, который разбивает лагерь в зоне (необходимо, по крайней мере, активировать бродящих ботов и деактивировать ботов, покидающих эту зону).

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

Делегация

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

Сервер может периодически отправлять список соседних участников (ботов и игроков), которые будут уведомлены клиентскими приложениями. Клиентское приложение должно будет выполнить сканирование и обнаружение событий для всех событий, сгенерированных проигрывателем. Например, он может отправить список актеров, чтобы уведомить о выстреле, ударе пули или шагах ноги.

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

Надеюсь, это поможет.