Как спроектировать авторитетный игровой сервер?

Question

[Alexey Lizurchik]

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

1. Какими способами можно обеспечить одинаковый (хотя бы приблизительно) пинг для всех клиентов?
   
2. Как сервер должен обрабатывать стрельбу одного корабля в другого? Конкретно интересует, должен ли сервер в момент выстрела игрока А уже знать о том, убит ли игрок Б и послать ему соответственное сообщение, чтобы отрисовать уменьшение здоровья? Или он (сервер) должен узнать об этом лишь тогда, когда игрок Б отправит событие "по мне попали" и затем проверить, был ли произведен по нему выстрел и послать на клиент (игроку Б) результат "пальбы"?
   
3. Как организовать синхронизацию действий ИИ между клиентами? Кто (сервер или один из клиентов или кто-то еще) должен регулировать действия ИИ и оповещать об этом остальных клиентов?
   
4. Как проектируют моментальную синхронизацию и обработку действий между клиентами? Например в MOBA играх все происходит довольно быстро и порой бывает так, что необходимо синхронизировать какое-то действие, которое происходит за пол секунды, а то и меньше (например кто-то подпрыгнул, а его заморозили). Какие протоколы передачи данных используют в данном случае и какой порядок действий должен быть в общении между клиентами и сервером?
   

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

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

Спасибо!

Comments

[AtomKrieg]

пол секунды это 500мс

[Alexey Lizurchik]

AtomKrieg: спасибо за замечание. Ляпнул не подумав. В целом довольно много времени для передачи данных

Answer 1

[Saboteur]

1. Никак. Но у многих игр есть определенный критичный пинг, выше которого играть некомфортно.
Выход - изначально проектировать игровую механику таким образом, чтобы популярный пинг (до 10-20 мс) был более-менее комфортен.
2. У вас немного каша даже в том смысле, как вы описываете игру. Это шутер, это реал-тайм стратегия, это симулятор? У каждого свои фичи, но даже 50 мс вполне достаточно, чтобы более-менее адекватно успевать отрисовку. В большинстве случаев клиент некритичные вещи отрисовывает сразу по действию, а получая ответ-подтверждение от сервера уже доделывает более критичные (например уменьшить жизнь можно сразу, а уничтожить корабль можно только после подтверждения от сервера).
3. Конечно сервер должен регулировать действия. Все критичные вещи должны быть вычислены на сервере. Клиент может делать предупреждающие вычисления, которые дублируют то, что делает сервер, но только в плане отрисовки. Для этого алгоритм должен совпадать. Но подтверждение с сервера обязательно. Иначе такую игру взломать поддельными пакетами будет доступно любому школьнику.
4. В МОБА играх всего 10 игроков. Между моментальной и быстрой синхронизацией уйма времени.
Например игроку из России комфортно играть на русском и европейском сервере. А на американском пинг свыше 20-30 уже ВЕСЬМА заметен.

Протокол конечно же UDP, какой же еще.
Оптимизация - уменьшение трафика, максимально продумать что именно следует передавать, от этого отталкиваться в механике.

Comments

[AtomKrieg]

В наше время использовать один UDP это бред. Если игра критичная к частоте передаваемых данных, то идет связка tcp+udp.

[Alexey Lizurchik]

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

[Saboteur]

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

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

[Alexey Lizurchik]

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

[Saboteur]

Alexey Lizurchik: В сервере всегда есть свой цикл, по которому происходит процесс. У вас мобы как бегают? Мгновенно, или с определенной скоростью? У вас снаряды как летят - мгновенно, или от них можно увернуться? Как промежутки полета вычисляются?

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

[Alexey Lizurchik]

Сергей: на все 4ре вопроса хотел бы услашть ответ от вас, т.к. у меня этого ничего нету и собственно тема вопроса как раз об этом :)

[Saboteur]

Alexey Lizurchik: так я же уже ответил.

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

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

Дальше - думайте сами, игры разные, случаи разные...
Я еще помню doom2 целиком на tcp, который шел со скоростью самого медленного игрока в сети.

[Alexey Lizurchik]

Сергей: то есть по вашей примерной схеме сервер должен будет обработать эти три действия игрока только спустя полторы секунды? Как я понял, команды игрока и мира складываются в очередь и на каждом "тике" сервер достает последнюю команду и обрабатывает ее, так?

> А если ваш сервер выполняет действи исключительно по сигналу от игрока, то это неверно
Для каких случаев тогда целесообразно использовать, например , https://www.photonengine.com/en/Realtime ? Он, как я понял, рассылает события, полученные от игрока всем остальным игрокам в момент получения этих событий. Либо его можно использовать для синхронизации анимации, а авторитетный сервер наряду для проверки целостности происходящего в игровом мире?

[Saboteur]

Сервер будет отрабатывать действия по степени их реальной длительности. Если у сервера указано, что переход из комнаты в комнату длится два тика, значит следующий переход он будет выполнять через два тика.
При этом вполне можно добавить команду "стоп", при получении которой сервер сразу очищает весь буфер команд игрока, и ставит статус "стоп".
Очередной "тик" сервера, когда он пробегает по всем действиям игрокам, сервер увидит статус стоп и прервет текущий action игрока согласно очередности.

Что находится по вашей ссылке четко не ясно, но там не совсем то. Там вообще чуть ли не браузерка комнатная. В этом случае все делается иначе.
Пошаговая стратегия, в которой каждый игрок отправляет свои действия. Сервер может просчитывать какие-то действия сразу автоматом (например бои в порядке очереди), а например сами постройки и сбор ресурсов не считает в принципе. Для этого используется схема таймстампов и расчет по последнему обновлению.
Пример такой:
я захожу в казармы и заказываю постройку 1000 лучников. Каждый лучник строится 0.5 секунды. В момент заказа, на сервер отправлена команда 1000 лучников. Сервер получает ее, проверяет ресурсы, и записывает время начала выполнения.
Клиент со стороны игрока может сам по себе рисовать новых юнитов, согласно своим рассчетам, периодически отправляя запросы на обновление информации к серверу.
В момент такого запроса, сервер сравнивает прошлое время с текущим, высчитывает сколько должно было быть построено юнитов, и добавляет их.
Таким образом, расчеты делаются не каждые полсекунды для каждого игрока, а гораздо реже.
Если игрок выйдет из игры - расчет вообще будет выполнен при следующем логине. Либо если другой игрок зайдет в эту комнату (то есть не важно кто вызвал апдейт, главное что расчет информации будет идти строго по запросу). Так снижается нагрузка на сервер от регулярных расчетов всего и всея, но тут не требуется идеальная синхронность.
Взять популярные игры вконтактиках, с онлайном до 100к игроков, там даже начало боев часто определяется "примерно в пределах от 1 сек до 1 мин".

То есть не существует идеальной синхронизации для многих игроков.

Та же линейка, в момент осады (то есть пиковое время, когда в зоне видимости 2-4 тысячи человек), начинала жутко тормозить, а передавались исключительно клики мышкой, ибо в линейке нет такого, как движения стрелочкой, только клик "бежать по координатам x,y", кастануть в игрока ID xx скиллом yy

[Alexey Lizurchik]

Сергей: спасибо, много информации для размышления

[Alexey Lizurchik]

Сергей: добрый день! Появился вопрос касательно игрового цикла на сервере. Правильно ли я понял, что в промежуток между тиками сервер собирает действия всего, что происходит в мире, а потом, когда тик закончился начинается рассылка этих событий всем игрокам (тем, кто должен видеть эти изменений) в мире? А что делать в случае, есть накопилось достаточно много действий, рассылака которых займет времени больше, чем длительность тика, т.о. предыдущие действия еще не разошлются, а следующий тик уже закончится?