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


8

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

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

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

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

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

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


Это зависит от количества игроков, ИИ и тому подобного в игре. Например, MMO используют такие вещи, как графы сцен, для быстрого поиска, кто близок к тому, что для вещей, которые вы упомянули выше, в то время как игра FPS, которая отслеживает всего около 30 вещей, это было бы излишним, и скорее всего, просто связанный список из 30 объектов достаточно. Можете ли вы быть более конкретным в своих настройках? С 5 игроками и 7 ИИ я бы сказал, что вам не нужно делать ничего особенного, кроме того, все 13 сущностей загружаются в память как обычно.
Джеймс

Абсолютно средний случай игрового мира таков: более 20 регионов, как в городе, так и в окрестностях. Каждый регион - это то, что мы рассматриваем здесь, и он рекурсивно подразделяется на области в виде графика сцены, как вы сказали. Область может все еще быть больше, чем осознание сущности, и может прекрасно удерживать 100 или более врагов и ЛЮБОЕ количество игроков. Конечно, есть пустые места, но также переполненные
Grimshaw

1
Мне весьма интересны отзывы на этот вопрос.
Койот

Ответы:


7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Делегация

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

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

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


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


Ваш ответ, кажется, определяет большинство методов, которые просто фантастические! Создание такого сочетания кажется хорошим выбором, для такого приложения, критичного к производительности, все должно быть сделано в деталях, избегая излишних возможностей здесь и там. Кроме того, я действительно думаю, что если клиент авторитетен в отношении НИЧЕГО, он может и будет обманут: P
Grimshaw

Да ... но если вы можете делегировать некоторые вещи клиенту сейчас, вы сможете позже делегировать их на вторичные серверы, если хотите, ограничивая делегирование только серверами и отключая его на клиентах. Просто идея, хотя :)
Койот

Это хорошая идея, но игроки всегда будут эксплуатировать ее, когда она станет конкурентоспособной ... Я больше за использование вычислительной мощности клиента для приятных глаз и прочего для улучшения впечатлений, звука, графики и т. Д. Серверу не нужно отслеживать все, некоторые вещи, которые клиент может принять, не допуская обмана. В любом случае, большое спасибо за ответ, опять же, это поможет сбалансировать вещи!
Гримшоу
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.