Многопользовательская синхронизация и поиск пути


8

У меня есть интерфейс типа point & click на клиенте, который запускает A * на сервере для поиска пути.

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

Каков наилучший способ синхронизации движений игрока между сервером и клиентом, после того как я вычислил пути?

Нужно ли серверу синхронизировать клиентов на каждом шаге / кадре анимации? или он может просто сказать клиенту "перейти в положение X, Y" для каждого узла на пути и каждого движущегося игрока? Или лучше всего запустить таймеры анимации как на клиенте, так и на сервере и синхронизировать их таким образом?

Каким будет типичный обмен данными для движения по траектории?

РЕДАКТИРОВАТЬ:

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

Ответы:


2

Альтернативой является поиск пути на клиенте, которому принадлежит устройство. Это имеет преимущество в более равномерном распределении работы. Недостаток выполнения всего поиска пути на сервере состоит в том, что сервер должен делать все это; недостатком отправки только команд «перейти к X, Y» клиентам является то, что каждый клиент должен найти каждый отдельный путь. Вместо этого, каждый «тик» в цикле шага блокировки, каждый клиент сообщает серверу, буквально, о каждом следующем шаге своего подразделения. Сервер удостоверяется, что устройство действительно может переместиться туда, и перемещает устройство. Поскольку клиент не имеет всей информации (в частности, что делают модули другого клиента), неверная команда перемещения не считается ошибкой. Это приводит к потере некоторой полосы пропускания, чтобы получить больше времени для расчета путей.

Заменить сервер равноправным; этот метод работает и для одноранговых игр, при условии, что порядок, в котором рассматриваются движения юнитов, одинаков на всех машинах.


1

Игры RTS обычно имеют синхронизацию по шагам (синхронизация происходит каждый кадр). Указание любых путей к клиенту позволит взломанным клиентам злоупотреблять дополнительной информацией.


1

Ни. Единственное, что вы должны отправить, это команды. Пример: эти 20 юнитов должны переместиться в (X, Y), а затем дать каждому игроку понять, как они туда попали. Самое сложное - убедиться, что все они делают одно и то же. Для достижения этой цели используется модель, основанная на шаге, ссылки ниже должны объяснить это подробно. Кроме того, вы должны синхронизировать только важные части. Все, что не меняет игровой процесс, не должно синхронизироваться. Анимации в RTS-играх обычно только для визуальной стороны.

Другое дело, что игры RTS обычно не клиент-серверные, а P2P. Таким образом, один из игроков не сможет обмануть, потому что при обнаружении несоответствия вы просто отключаетесь.

Вот что вам поможет: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php http://altdevblogaday.com/2011/07/09/synchronous-rts-engines-and- a-tale-of-desyncs / http://altdevblogaday.com/2011/07/24/synchronous-rts-engines-2-sync-harder/


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

Если у вас есть более чем, скажем, 50 полностью динамических объектов в любой момент времени, вам может понадобиться изучить механику RTS. Ваша игра похожа на CIV или LOL?
Питер Олстед

Это больше похоже на Diablo, Dungeon Siege или HoN, но с указанием и щелчком. Максимум на экране должно быть не более ~ 20 единиц.
Облако

1

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


Хорошо, это то, к чему я иду.
Облако

1

В моей игре (многопользовательская игра типа RPG) я отправляю части пути клиенту (для NPC поблизости), т.е. 3 следующих позиции и Время, когда NPC должен быть там. Для игроков я просто отправляю последнюю действительную позицию + ее временную метку, чтобы на клиенте я мог сделать полный расчет (или что-то более сложное, если нужно).

Это работает вполне нормально, в основном потому, что нет столкновений между игроками / NPC (с низкой задержкой вы ничего не замечаете, например, с задержкой 250+ мс, вы заметите разницу, если увидите два экрана (двух игроков). ) в то же время, но это все еще не очень примечательно на «одном экране»).

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

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

Возможно, вы также захотите проверить прогнозирование времени (т. Е. Попытаться максимально синхронизироваться с сервером).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.