Комментарии 109
Несомненно + ))
Спасибо, очень интересная статья. О некоторых моментах не знал, но, так скажем, догадывался. Познавательно.
Интересно было бы узнать статистику, например, сколько запросов в секунду улетает от клиента к серверу в самых популярных онлайн играх (WoT, Dota и тп)?
Интересно было бы узнать статистику, например, сколько запросов в секунду улетает от клиента к серверу в самых популярных онлайн играх (WoT, Dota и тп)?
Пожалуйста! Еще две статьи на подходе.
Вот этот потрясающий разработчик иногда разбирает сетевые механики популярных игр.
Например тут он рассказывает про Overwatch.
Обновления от сервера к клиенту идут от 20 до 60 раз в секунду обычно. Чем чаще идут обновления — тем комфортней играть, но за счет техник согласования с сервером и локального предсказания, разница между 20 Hz и 60 не очень заметна, а нагрузка на сервера очевидно возрастает.
Вот этот потрясающий разработчик иногда разбирает сетевые механики популярных игр.
Например тут он рассказывает про Overwatch.
Обновления от сервера к клиенту идут от 20 до 60 раз в секунду обычно. Чем чаще идут обновления — тем комфортней играть, но за счет техник согласования с сервером и локального предсказания, разница между 20 Hz и 60 не очень заметна, а нагрузка на сервера очевидно возрастает.
Вы не поймёте что такое по-настоящему быстрая игра, пока не поиграете по сети в Rocket league. Поверьте: здесь чувствуется даже пинг в 50.
Скорее всего это связано с тем, что механизмы компенсации, о которых будет идти речь позже, неприменимы(или плохо применимы) к играм, где на физику одного объекта влияют несколько игроков.
Таким образом вероятно в Rocket League все ваши действия выполняются с задержкой, равной вашему пингу.
Таким образом вероятно в Rocket League все ваши действия выполняются с задержкой, равной вашему пингу.
могу ещё посоветовать поиграть в q3. там за время пока ты делаешь rocket-jump, противник успевает появиться на экране, сожрать power-up, на который ты делаешь rocket-jump и ускакать дальше.
Во всех FPS играх решают даже 10ms. А один из лучших игроков в League of Legends — SKT Faker, сказал, что несмотря на то, что это MOBA жанр, играть в нее с пингом выше обычного (они в корее играют с пингом 5-7) = ад.
Дело даже не в жанре мобы, а в специфике лола: скорость поворота персонажа довольно высокая, поэтому отклик сильно чувствуется.
Вероятно вы путаете LoL и Dota2.
В лоле скорость поворота отсутствует — юнит разворачивается на 180° моментально. В Dota2 они важны, можно ознакомиться в этой статье: http://dota2.gamepedia.com/Turn_rate
В лоле скорость поворота отсутствует — юнит разворачивается на 180° моментально. В Dota2 они важны, можно ознакомиться в этой статье: http://dota2.gamepedia.com/Turn_rate
Тем не менее в любой интерактивной хардкорной игре, вполне различаются 10-20 мс.
Да даже взять некогда существовавший отличный портал тетрисарена.
Двое игроков играют друг с другом в тетрис. Лаг в 50 милисекунд — это просто нереально играть для игроков, наигравших 5-7 тысяч дуэлей.
Да даже взять некогда существовавший отличный портал тетрисарена.
Двое игроков играют друг с другом в тетрис. Лаг в 50 милисекунд — это просто нереально играть для игроков, наигравших 5-7 тысяч дуэлей.
Про доту в курсе. Был не в курсе деталей лола в этом плане.
«даже в 50»
В контерстрайке 50 давным давно считается слишком плохо, И различается 20-30.
Есть даже соло игры, где при лаге в 50 мс вообще играть практически невозможно.
В контерстрайке 50 давным давно считается слишком плохо, И различается 20-30.
Есть даже соло игры, где при лаге в 50 мс вообще играть практически невозможно.
Gaffer on Games
Вот переводы его статей я бы почитал. (Особенно тех, которые закрыты.)
Спасибо за ссылку на Overwatch Netcode Analysis, не видел раньше, у автора также много других полезных видео, понравились.
Одна только маленькая поправка: Chris aka Battle(non)sense != Glenn Fiedler aka Gaffer on Games. Это разные люди. В этом легко убедится если загуглить например GDC видео с Glenn Fiedler-ом, а затем посмотреть любой «netcode analysis» от Chris-a :)
Кстати статьи Gaffer on Games очень толковые, некоторые уже стали почти классикой) Можно также подумать о переводе, например «Fix Your Timestep!» или «Networked Physics (2004)» — для которой есть потрясающая демка с исходниками на сишке: управляем кубом, симуляцию физики которого можно смотреть в трёх представлениях: клиент, сервер, прокси (регулируются такие параметры как "% packet loss" и «milliseconds latency»).
Одна только маленькая поправка: Chris aka Battle(non)sense != Glenn Fiedler aka Gaffer on Games. Это разные люди. В этом легко убедится если загуглить например GDC видео с Glenn Fiedler-ом, а затем посмотреть любой «netcode analysis» от Chris-a :)
Кстати статьи Gaffer on Games очень толковые, некоторые уже стали почти классикой) Можно также подумать о переводе, например «Fix Your Timestep!» или «Networked Physics (2004)» — для которой есть потрясающая демка с исходниками на сишке: управляем кубом, симуляцию физики которого можно смотреть в трёх представлениях: клиент, сервер, прокси (регулируются такие параметры как "% packet loss" и «milliseconds latency»).
Glenn Fiedler разместил ссылку на обзор Overwatch-а, сделанный ютьюбером Battle(non)sense
кстати, на его канале есть обзоры и других игр (BF, CoD, R6, The Division)
P.S. не заметил, что об этом уже написали, а как удалить комментарий еще не разобрался
кстати, на его канале есть обзоры и других игр (BF, CoD, R6, The Division)
P.S. не заметил, что об этом уже написали, а как удалить комментарий еще не разобрался
Осталось понять как остальным клиентам предсказывать действия первого клиента и сервера с протоколом, и что же отрисовывать?! Вы не указали механизм описания транзакции в протоколе, как результат «событие» "развалилось" на независимые, и каждый актор получит собственную историю, иногда это хорошо, но не всегда-же, иногда коллективное взаимодействие — часть игрового процесса.
Это будет описано как раз в следующей статье. Следите за обновлениями)
Жду с нетерпением, в этой статье описанное достаточно логично и предсказуемо, но вот этот факт тоже очень сильно интересует.
Проспойлерю, что идеального решения не существует. Причина этого в том, что любые два игрока находятся друг от друга на «расстоянии» в сумму их пингов.
Таким образом если результат действия первого игрока мгновенен, второй игрок на его клиенте еще находится в состоянии из прошлого. Что порождает парадоксы, т.к. хоть на самом деле игроки разделены во времени, мы стараемся делать вид, что они находятся совсем рядом.
Таким образом если результат действия первого игрока мгновенен, второй игрок на его клиенте еще находится в состоянии из прошлого. Что порождает парадоксы, т.к. хоть на самом деле игроки разделены во времени, мы стараемся делать вид, что они находятся совсем рядом.
Чтобы сократить пинг Игрок1-Сервер-Игрок2, пора бы придумать torrent сессии между игроками.
Чуть сложнее, но те же принципы предсказания и проверок на состояние могли бы скрасить ситуацию.
Необязательно всех-со-всеми, существуют локальные зоны, в которых находятся игроки.
Чуть сложнее, но те же принципы предсказания и проверок на состояние могли бы скрасить ситуацию.
Необязательно всех-со-всеми, существуют локальные зоны, в которых находятся игроки.
Т.е. отправлять команды не только на сервер, но и другим игрокам? Забавно.
Но есть несколько проблем.
Основная проблема, как мне кажется, в ненадежности клиента — он может на сервер отправлять одни команды, а игрокам — другие, тем самым усложняя задачу своим соперникам.
Есть и еще проблемы. Например, компенсация лага, о которой я буду говорить в четвертой статье, будет неприменима в такой игре.
Но есть несколько проблем.
Основная проблема, как мне кажется, в ненадежности клиента — он может на сервер отправлять одни команды, а игрокам — другие, тем самым усложняя задачу своим соперникам.
Есть и еще проблемы. Например, компенсация лага, о которой я буду говорить в четвертой статье, будет неприменима в такой игре.
Сервер сравнил команды. Не совпали? Сразу бан.
А то получается большая часть работы чтобы противостоять жуликам.
Хотя весь мир построен на этом.
С интересом жду следующей части. Спасибо!
А то получается большая часть работы чтобы противостоять жуликам.
Хотя весь мир построен на этом.
С интересом жду следующей части. Спасибо!
А с чем серверу сравнивать команды? Пересылать их от других клиентов серверу и сравнивать показания?)
Не сложно понять, что количество запросов на сервер будет возрастать квадратично. Да и нельзя верить командам от других клиентов.
Ждите!)
Не сложно понять, что количество запросов на сервер будет возрастать квадратично. Да и нельзя верить командам от других клиентов.
Ждите!)
Было одно секретное место, где вмногером можно было играть без лагов.
Клуб в подвале.
Деньги платились именно за это.
Клуб в подвале.
Деньги платились именно за это.
А если верить клиентам, но потом за ними перепроверять? Например, если игрок говорит, что прошёл сквозь стену, верить ему, а уже потом, «не торопясь», всё проверить. Если что-то подозрительное — банить. Примерно так работают некоторые самописные античиты в minecraft. Но нагрузка на сервер возрастает, конечно.
Концепция разнесенного на клиенты сервера? Кластер состоящий из компьютеров игроков? Да, на вскидку это сложно.
И вроде никто ещё так не делал в играх.
Фантасты описывают подобные решения, правда я помню только самообразовывающиеся сети из мобильных устройств, обычно это боевые роботы, которые создают сеть, и решают вопросы по взаимодействию между собой против кого либо.
Но как-то же кластеры распределенных вычислений между собой договариваются?
Это да, подобная система, конечно потребует новых решений известных проблем.
И вроде никто ещё так не делал в играх.
Фантасты описывают подобные решения, правда я помню только самообразовывающиеся сети из мобильных устройств, обычно это боевые роботы, которые создают сеть, и решают вопросы по взаимодействию между собой против кого либо.
Но как-то же кластеры распределенных вычислений между собой договариваются?
Есть и еще проблемы. Например, компенсация лага, о которой я буду говорить в четвертой статье, будет неприменима в такой игре.
Это да, подобная система, конечно потребует новых решений известных проблем.
такая схема приведет к еще большему соревнованию за хороший канал и половина игроков с худшим каналом всегда будет проигрывать
Концепция разнесенного на клиенты сервера? Кластер состоящий из компьютеров игроков? Да, на вскидку это сложно.
И вроде никто ещё так не делал в играх.
Вообще-то, это стандартное решение в стратегиях, где число юнитов на несколько порядков превышает число игроков.
Подскажите пожалуйста, как работают античит системы в таких играх? Ведь в стратегиях даже небольшое но постоянное изменение баланса может значительно изменить ход игры.
Все просто — все команды, отданные удаленными игроками, валидируются наравне с командами от локального игрока. Попытка читерить просто приводит к тому, что читер в итоге играет не в ту игру, что остальные. Или выкидывается при сравнении контрольных сумм состояния мира.
Единственный чит, который вообще возможен в такой схеме — это "мапхак", снятие тумана войны. Мапхак — это принципиальная уязвимость такого подхода. Каждый клиент знает полное состояние мира — и кто-нибудь всегда найдет способ его "вытащить" и показать игроку.
Даже последнее не возможно в «правильном протоколе». Снятие тумана будет читом только, если это позволит получить информацию недоступную при его наличии, т.е., если сервер настолько «туп», что сливает информацию без верификации и проверки прав; так же проблема телепортации и читерского дропа — это только проблема заоптимизации «сервера», предоставляющего права клиенту указывать где, кто и что делает.
Можно «заоптимизировать» верификацию, предоставив, Частично, распределенной сети пользователей, но окончательный результат должен быть отработан на серверах, и выдача/раздача бонусов должна осуществляться по итогам этой верификации.
Мультиплеер в ММОРПГ, по своей сути, вариант репликации распределенной базы данных на геораспределенной сети. И, где-то, сравним с работой банковского клиента(за исключением того, что последний работает в парадигме клиент-сервер, а нужно сервер-репликанты), и цели похожи, доступ к валюте/игровым бонусам. В связи с чем меня сильно удивляют результаты работы играделов (как корейских, так и китайских), обычно они хранят и раздают не ту информацию, которая нужна в игре, а ту, которая необходима «клиенту» для визуализации игрового процесса, например координаты игрока в городе, пока город пуст(по утрам), с этим еще мирится можно, но во время «флешмоба»!? Или во время осады, зачем мне приходят действия «зевак» в области где ПК запрещены, и во время эвента на котором они участвовать не могут(итак респаун мобов запредельный для «клиента», а тут еще и «зевак» пол сервера)!? Еще один баг-фича централизованной системы — обязательный рестарт Мира, закрытие всех подвисших транзакций, респаун «сбежавших» мобов, обновление магазинов… т.е. все это должно храниться! пока персов несколько десятков в игре эти действия не столь заметны, но прерваный гринд, или сообщение «игра будет остановлена для обновления через 180 секунд» положительных эмоций не оставляет. А нужно-то только обеспечения целостность транзакции «события», не нужны хранение толпы мобов, которые не участвуют в «событии» (а тем более по уровню не подходящие, но отсеиваемые SQL запросом), и репликация данных «по клиентам», если они не имеют никаких отношений к ним, в том числе, если скрыты «туманом», или находятся за пределом достижимости (не инициированные квестом мобы).
Можно «заоптимизировать» верификацию, предоставив, Частично, распределенной сети пользователей, но окончательный результат должен быть отработан на серверах, и выдача/раздача бонусов должна осуществляться по итогам этой верификации.
Мультиплеер в ММОРПГ, по своей сути, вариант репликации распределенной базы данных на геораспределенной сети. И, где-то, сравним с работой банковского клиента(за исключением того, что последний работает в парадигме клиент-сервер, а нужно сервер-репликанты), и цели похожи, доступ к валюте/игровым бонусам. В связи с чем меня сильно удивляют результаты работы играделов (как корейских, так и китайских), обычно они хранят и раздают не ту информацию, которая нужна в игре, а ту, которая необходима «клиенту» для визуализации игрового процесса, например координаты игрока в городе, пока город пуст(по утрам), с этим еще мирится можно, но во время «флешмоба»!? Или во время осады, зачем мне приходят действия «зевак» в области где ПК запрещены, и во время эвента на котором они участвовать не могут(итак респаун мобов запредельный для «клиента», а тут еще и «зевак» пол сервера)!? Еще один баг-фича централизованной системы — обязательный рестарт Мира, закрытие всех подвисших транзакций, респаун «сбежавших» мобов, обновление магазинов… т.е. все это должно храниться! пока персов несколько десятков в игре эти действия не столь заметны, но прерваный гринд, или сообщение «игра будет остановлена для обновления через 180 секунд» положительных эмоций не оставляет. А нужно-то только обеспечения целостность транзакции «события», не нужны хранение толпы мобов, которые не участвуют в «событии» (а тем более по уровню не подходящие, но отсеиваемые SQL запросом), и репликация данных «по клиентам», если они не имеют никаких отношений к ним, в том числе, если скрыты «туманом», или находятся за пределом достижимости (не инициированные квестом мобы).
Кажется, вы забыли, что мы разговаривали вот об этой ситуации:
Концепция разнесенного на клиенты сервера? Кластер состоящий из компьютеров игроков?
Перечитайте еще раз, это ответ именно на этот вопрос. Базу можно хранить в облаке — доверять ей — нет(блокчейн). Событие можно размещать в сети(и нужно, оно там и происходит), но раздача бонусов, в само событие, не входит, и требует некоторой централизации, все остальное — не принципиально. (еще большее разжевывание тривиальных фраз, уже, для меня проблемотично, куда еще проще?! может прежде, чем комменировать, попытаетесь сменить позицию с «оппонент — идиот» на «я был очень невнимателен, и чего-то захотел не понять»)
Но есть несколько проблем.
Про это я и говорю, Вы создали проблему, и героически ее решаете…
«Событие», это не то, что подтвердил сервер, а то что создали игроки, сервер может выдать «приз» или забанить, но он не часть транзакции, он арбитр, полководец…
Если религия позволяет, то посмотрите на ютубах (у гоблина в Разведопрос) беседы с Климом Жуковым про средневековые битвы. (в вашем случае, вывод по координации битв: правильно построил войска, предугадал действия противника — выиграл, если что-то пошло не так, то скоординировать в этой мясорубке ничего нельзя, поняли отряды изменившуюся обстановку — вырулили ситуацию, нет — драпанули или полегли).
Как мне видится решение: сервер — арбитр(а не актор), все игроки должны видить единую картину, т.е. сервер обеспечивает функцию прокси и регистрацию действий игроков, а как устраитель ловушек и генератор события предлагает ситуацию, загоняя читеров в уникальные, жесткие или безвыходные ситуации. Игроки (полноценные акторы, в том числе и читоры) должны стоять в равных условиях (транзакция корректирует ( выравнивая ) общую задержку, детектирование читера должно сливать всю пати игрой, а не «только баном», педагогика братья! не в наказании виновных[это правосудие], а в воспитании «законопослушного гражданина»</сарказм>).
После «события» сервер анализирует лог, и если не находит криминала выдает награды… в том чисте и экспу. Чем это может навредить, и зачем усложнять «на ровном месте»!?
вообще P2P в играх используется достаточно давно, правда как правило всё равно присутствует сервер на котором хранится нужная информация.
Если клиенты будут принимать решения на основе данных от других, обмениваясь при этом с сервером для подтверждения правильности, серверу придется решать кому доверять, а кому — нет. Чем-то на похоже на проблему византийских генералов, в обратную сторону. Ну и получится, что трафик между всеми возрастает, это надо как-то решать. Хотя интересно.
Обычно предполагается, что сервер способен обеспечить достаточную пропускную способность.
Передавать что-либо другим игрокам — гиблая затея.
Потому что подключение других игроков никак не гарантировано.
Зайдет в зону игрок с модема, и у всех резко лаги начались?
Передавать что-либо другим игрокам — гиблая затея.
Потому что подключение других игроков никак не гарантировано.
Зайдет в зону игрок с модема, и у всех резко лаги начались?
да и в след. статье тоже логично и предсказуемо. до тех пор, пока не начнешь это реализовывать ;)
НЛО прилетело и опубликовало эту надпись здесь
Оффтоп: а что делать если случайно отклонил комментарий? Есть возможность его вернуть?
Спасибо! Было бы так же интересно по читать как подобные механизмы реализованы в популярных сетевых фреймворках.
лагающий игрок это всегда боль. как для остальных игроков, так и для сервера(приходится откатываться на несколько тиков, делать перерасчеты). проще всего конечно применять инпут сразу, как только он пришел от игрока. не совсем честно, но некоторые игры не парятся)
Основной ужас таких механик в том, что даже при пинге 50 мс, оружия с долгой перезарядкой, большим уроном и точечной областью применения(Railgun какой-нибудь) становятся жутко неудобными.
Дело в том, что в тот момент, когда игрок выстрелит на сервере, персонаж врага уже убежит с того места, где он был.
Впрочем, тема откатывания состояния сервера будет раскрыта только в заключительной статье.
Дело в том, что в тот момент, когда игрок выстрелит на сервере, персонаж врага уже убежит с того места, где он был.
Впрочем, тема откатывания состояния сервера будет раскрыта только в заключительной статье.
есть и другой момент:
вы у себя на компе забежали за препятствие и спрятались, и а потом внезапно умерли от хедшота. бонусом вас может перенести на то место, куда в вас попали. т.е. перед препятствием. потому что игрок, который в вас стрелял был с пингом 250мс. у себя то он выбежал из-за угла, стрельнул и попал в вас. а вы в тот момент бежали за препятствие и никого не видели. лагающий игрок это боль(
вы у себя на компе забежали за препятствие и спрятались, и а потом внезапно умерли от хедшота. бонусом вас может перенести на то место, куда в вас попали. т.е. перед препятствием. потому что игрок, который в вас стрелял был с пингом 250мс. у себя то он выбежал из-за угла, стрельнул и попал в вас. а вы в тот момент бежали за препятствие и никого не видели. лагающий игрок это боль(
Это правда. И такая ситуация действительно выглядит нечестной для убитого игрока. Но это максимум честности, который только можно предоставить. Думаю, вы в этом убедитесь в четвертой статье.
Но ведь это огромный простор для читинга. Допустим у нас читят два клиента совместно, имея мизерный пинг между собой. Один клиент изображает лаги, а второй работает с сервером как можно быстрее. Их противник, например, скастовал заклинание, которое создаёт иллюзии. Тот, который «быстрый», прошёлся слабым заклинанием массового поражения. И передал результаты «медленному», чтобы тот знал где настоящий и нанёс ему урон точечным заклинанием.
В общем, получается, что один клиент может передавать другому информацию из будущего. Не обязательно про иллюзии. Например, про то, у кого из противников выпадет крит и кого надо убить до этого крита.
В общем, получается, что один клиент может передавать другому информацию из будущего. Не обязательно про иллюзии. Например, про то, у кого из противников выпадет крит и кого надо убить до этого крита.
Захотелось сдлать игру, намеренно основанную на такой безумной механике %)
Я помню, что читал обзор какой-то стратегии, где важным элементом механики были перемещения во времени. То есть, вы строите базу, армию, а потом внезапно проигрываете, потому что ваш противник переместился в прошлое и разрушил вашу базу в самом начале игры. Но при этом у вас есть панелька, которая показывает временнЫе возмущения, то есть если ваш противник переместится в прошлое огромной армией, то вы это увидите и сможете отреагировать. Очевидно, чем большая армия перемещается во времени, тем больше возмущение.
Если игрок находится в другом времени, то за него играет ИИ.
Но как ни стараюсь, я не могу вспомнить названия игры, это было лет 10-12 назад минимум.
К стати, предсказание на стороне клиент (client-side prediction) было реализовано в QuakeWorld в далёком 1998 году. С тех пор, как видно, революционных изменений не произошло.
Это просто только первые статьи из серий. Конечно же тут покрываются только самые базовые техники.
Но решений пространственно-временного парадокса действительно не так уж и много. Хотя простора для локальных улучшений просто тьма)
Но решений пространственно-временного парадокса действительно не так уж и много. Хотя простора для локальных улучшений просто тьма)
Но решений пространственно-временного парадокса
Чёрт, я один начинаю оглыдваться по сторонам и вспоминать всякие необъяснимые вещи?
Бермудский треугольник, пропадание людей и т.п.
Может всё просто? Есть в мире места где просто пинг, до главного сервера, длинный и текстуры плохо проверенны? Вот люди и исчезают? :)
Так же становится понятно, что разные супергерои, это по сути своей читеры, которые научились как-то обходить контроль главного сервера на валидность данных.
Мне как разработчику энтерпрайз-приложений особенно интересно читать про внутренности геймдева, там ведь вообще все по другому. Читал эту штуку в оригинале, с удовольствием прочту и перевод, спасибо!
Да, у нас действительно совсем другая кухня:) За то и люблю геймдев.
Хотелось бы уйти в такой «серьёзный» геймдев… Только такое ощущение что туда ещё фиг прорвёшься :) А «мобилочный» геймдев это вообще не то :(
> А «мобилочный» геймдев это вообще не то :(
Вот потому что все так думают, на мобилках и нет нормально сделанных игр.
Такое ощущение, что все делают сетевые игры по остаточному принципу. И так сойдет.
Как результат куча глюков, читеров и прочих радостей хреновой сетевой части.
Вот потому что все так думают, на мобилках и нет нормально сделанных игр.
Такое ощущение, что все делают сетевые игры по остаточному принципу. И так сойдет.
Как результат куча глюков, читеров и прочих радостей хреновой сетевой части.
Вы знаете, у нас пока что был мобильный геймдев. И могу вам сказать, что он ВЕСЬМА серьезный)
Все зависит от компании.
Все зависит от компании.
Учите плюсцы, нативный opengl/unreal.
Потом вперёд на gamedevmap.com.
Заодно можно с трактора смахнуть пыль.
Потом вперёд на gamedevmap.com.
Заодно можно с трактора смахнуть пыль.
OpenGL мало в геймдеве поможет
Почему вдруг?
Может по той причине, что gl это всего навсего способ вывода для 2D/3D, но не более.
Сеть, физика, звук, графика всего лишь относительно низкоуровневые инструменты. По мимо этого есть достаточно много других проблем, которые не менее важны. Часть из них вообще находятся в пределах влияния гуманитариев.
Во многих вакансиях затребован пресловутый directx/opengl, а вот phys-x не наблюдал в требованиях к кандидату ни разу.
+
Всегда было интересно как работает по сети Q3, динамичней игр я не встречал
Когда занимался разработкой сетевого шутера эта статья помогла разобраться в основах интерполяции и лаго-компенсации.
Представленная схема с отбрасыванием ИМХО не совсем годится для движения и аналогичных параметров.
Позиция персонажа штука не на 100% критичная.
Поэтому нормальная практике — использовать приближенные значения. Даже если мы предсказали одно значение, а с сервера пришло другое — не всегда нужно сразу на него прыгать. Во первых можно скорректирвоать позицию на следующей итерации, во вторых — если разница не слишком большая можно вообще ничего не делать оставляя позициюю той, что мы посчитали.
Пример: гоночная игра. траетория машин штука сложная, а скорости канала не хватает чтобы более менее в реальном времени отображать позицию.
Текущий кадр: машина другого игрока совершает поворот. Известна скорость, известна позиция, известен выворот колес. Мы экстраполируем состояние машины, пока не придут новые данные с сервера. Проблема в том, что в гонках идет постоянное подруливание. То есть выворот колес меняется постоянно, в несколько раз чаще чем кадры приходят.
Очевидно, что наша экстраполяция не будет корректной вообще никогда. Что делать? Экстраполировать как получается, а между кадрами плавно разницу между экстраполированным и реальным значением сглаживать. Просто плавно смещая машину в сторону для компенсации ошибки.
Если приглядется, то это дает артефакт в виде бокового движения автомобиля. Но на практике заметить это невозможно.
По поводу того, что с сервера приходят данные не о текущем состоянии, а о прошлом. Не надо пропускать кадры. Надо просто учитывать что есть новая точка для экстраполяции. Каждый новый кадр — это уточнение нашей экстраполяции. Уточнение ошибки. Указание, в какую сторону и с какой скорость надо двигать позицию, чтобы компенисровать ошибку.
Позиция персонажа штука не на 100% критичная.
Поэтому нормальная практике — использовать приближенные значения. Даже если мы предсказали одно значение, а с сервера пришло другое — не всегда нужно сразу на него прыгать. Во первых можно скорректирвоать позицию на следующей итерации, во вторых — если разница не слишком большая можно вообще ничего не делать оставляя позициюю той, что мы посчитали.
Пример: гоночная игра. траетория машин штука сложная, а скорости канала не хватает чтобы более менее в реальном времени отображать позицию.
Текущий кадр: машина другого игрока совершает поворот. Известна скорость, известна позиция, известен выворот колес. Мы экстраполируем состояние машины, пока не придут новые данные с сервера. Проблема в том, что в гонках идет постоянное подруливание. То есть выворот колес меняется постоянно, в несколько раз чаще чем кадры приходят.
Очевидно, что наша экстраполяция не будет корректной вообще никогда. Что делать? Экстраполировать как получается, а между кадрами плавно разницу между экстраполированным и реальным значением сглаживать. Просто плавно смещая машину в сторону для компенсации ошибки.
Если приглядется, то это дает артефакт в виде бокового движения автомобиля. Но на практике заметить это невозможно.
По поводу того, что с сервера приходят данные не о текущем состоянии, а о прошлом. Не надо пропускать кадры. Надо просто учитывать что есть новая точка для экстраполяции. Каждый новый кадр — это уточнение нашей экстраполяции. Уточнение ошибки. Указание, в какую сторону и с какой скорость надо двигать позицию, чтобы компенисровать ошибку.
Пока что речь шла только про многопользовательскую игру, по сути, с одним игроком. И рассматривался только вопрос синхронизации состояния сервера и состояния клиента с оговоркой, что сервер авторитарный.
Для такой ситуации описанная схема, пожалуй, самая адекватная. Если клиент не отправлял некорректного ввода и у игрока относительно адекватное соединение, поведение персонажа ничем не будет отличаться от сингл плеера. Никакого лага, никаких задержек, никаких неожиданностей.
В дальнейших статьях будут рассмотрены методы взаимодействия с другими игроками. Если говорить более предметно, речь пойдет об интерполяции позиций врагов.
В гоночных играх действительно правильнее использовать экстраполяцию, т.к. машины обладают большой массой и, как следствие, инерцией.
А вот в шутерах зачастую бывают совершенно непредсказуемые траектории, которые с результатом экстраполяции разойдутся очень быстро и в итоге мы получим весьма заметную погрешность.
Для такой ситуации описанная схема, пожалуй, самая адекватная. Если клиент не отправлял некорректного ввода и у игрока относительно адекватное соединение, поведение персонажа ничем не будет отличаться от сингл плеера. Никакого лага, никаких задержек, никаких неожиданностей.
В дальнейших статьях будут рассмотрены методы взаимодействия с другими игроками. Если говорить более предметно, речь пойдет об интерполяции позиций врагов.
В гоночных играх действительно правильнее использовать экстраполяцию, т.к. машины обладают большой массой и, как следствие, инерцией.
А вот в шутерах зачастую бывают совершенно непредсказуемые траектории, которые с результатом экстраполяции разойдутся очень быстро и в итоге мы получим весьма заметную погрешность.
А с ГГ все тоже самое. Не надо его прыжком двигать в точку синхронизации. Просто в процессе движения корректируем ошибку. Прыжок, только если расхождение значительное.
Причем даже больше — если расхождение не значительное, то можно не двигать ГГ вообще, а попросить сервер скорректировать позицию в соответствии с ошибкой. Сервер же, если видит что ошибка не критичная(коррекци не телепортирует ГГ через стену, не превышает скорость передвижения и т.п.) может скорректировать ошибку у себя, доверившись клиенту. Бага здесь нет.
Грубо говоря, если у нас на сервере игрок смещен на пол метра влево — и у клиента ГГ сейчас стоит — клиент можно послать сообщение — переместить игрока на пол метра вправо. При этом не двигать ГГ у себя вообще. Сервер штатно проверит, что можно выполнить команду и выполнит. В итоге ошибка будет скорректирована без артефактов на клиенте. При этом повышения уровня доверия не происходит, так как коррекция ошибки происходит по тем же правилам что и движение.
Грубо говоря, если у нас на сервере игрок смещен на пол метра влево — и у клиента ГГ сейчас стоит — клиент можно послать сообщение — переместить игрока на пол метра вправо. При этом не двигать ГГ у себя вообще. Сервер штатно проверит, что можно выполнить команду и выполнит. В итоге ошибка будет скорректирована без артефактов на клиенте. При этом повышения уровня доверия не происходит, так как коррекция ошибки происходит по тем же правилам что и движение.
на разных клиентах могут быть (и будут) разные расхождения. Поэтому последняя инстанция, похоже — это все-таки сервер. Вместо того, чтоб на сервере сместить игрока на полметра, Можно на клиенте подкорректировать позицию персонажа. И чтоб не было «скачка», надо попытаться сдвинуть его «естественно». Если движется — скорректировать скорость перемещения. Если уже стоит — пусть сделает шаг в нужную сторону. Статья http://www.gamasutra.com/view/feature/131638/dead_reckoning_latency_hiding_for_.php — для меня в свое время была отправной точкой при разработке мультиплеера.
Вы WoT расскажите про не критичность позиции и точки прицеливания :) Хотя у меня давно есть подозрение, что там очень много корректировок по этому поводу в зависимости от игрока, иногда реально «не пробил» в упор и слабое место, а иногда полный урон в самую толстую броню :)
Ещё есть много шуток про «Сурвариум», где тоже с позициями игроков всё плохо, «урон не прошёл» — просто бич игры.
Ещё есть много шуток про «Сурвариум», где тоже с позициями игроков всё плохо, «урон не прошёл» — просто бич игры.
Очень интеренсо) А посоветуйте плз более детальную инфу по этому вопросу может книга или форум разработчиков какойто игры ато в статьях обычно только базовое описано
Если у вас все в порядке с английским, прочитайте комментарии. Тут было дано немало полезных ссылок.
Если же английский для вас проблема — подписывайтесь на меня и ждите дальнейших статей:)
Если же английский для вас проблема — подписывайтесь на меня и ждите дальнейших статей:)
Погуглите инфу, как в Source сделана сеть. Там достаточно подробно всё разобрано, на примерах CS, если не ошибаюсь.
Очень понравились анимации в статье, всегда бы так наглядно демонстрировались алгоритмы в подобных разборах.
Кстати, насчет сложностей с физикой: замечал, что физика сделана только на клиенте, например мусор на улицах, колеса от взорванных машин, гильзы и тд. То есть эти объекты не синхронизируются никак, хотя люди картинку видят разную, и это может быть критично (снайпер залег за тем же колесом, а у другого игрока этого объекта в этом месте вообще нет), хотя такая «оптимизация» кочует из части в часть. Неужели все так плохо с нормальной синхронизацией кучи физических объектов одновременно, или просто разработчики посчитали это мелочами и не стали заморачиваться?
Кстати, насчет сложностей с физикой: замечал, что физика сделана только на клиенте, например мусор на улицах, колеса от взорванных машин, гильзы и тд. То есть эти объекты не синхронизируются никак, хотя люди картинку видят разную, и это может быть критично (снайпер залег за тем же колесом, а у другого игрока этого объекта в этом месте вообще нет), хотя такая «оптимизация» кочует из части в часть. Неужели все так плохо с нормальной синхронизацией кучи физических объектов одновременно, или просто разработчики посчитали это мелочами и не стали заморачиваться?
В Battlefield физика синхронизируется.
Синхронизация физики — сложная задача, которая не имеет однозначного решения.
Проблемы проистекают из парадокса: игроки должны быть в одном(синхронизированном) мире; результат ввода каждого игрока должен ему отображаться мгновенно; но игроки разнесены во времени пингом. Так что если два человека умеют воздействовать на один и тот же объект, этот парадокс покажется во всей красе, заставляя предмет телепортироваться в пространстве или резко менять направление движения.
Впрочем, если воздействие на колесо это действие «взорвать машину», это вполне можно синхронизировать.
А вот гильзы хоть и можно синхронизировать, так делать не стоит. Это только засорит трафик.
Проблемы проистекают из парадокса: игроки должны быть в одном(синхронизированном) мире; результат ввода каждого игрока должен ему отображаться мгновенно; но игроки разнесены во времени пингом. Так что если два человека умеют воздействовать на один и тот же объект, этот парадокс покажется во всей красе, заставляя предмет телепортироваться в пространстве или резко менять направление движения.
Впрочем, если воздействие на колесо это действие «взорвать машину», это вполне можно синхронизировать.
А вот гильзы хоть и можно синхронизировать, так делать не стоит. Это только засорит трафик.
Обычно игровые объекты, влияющие на процесс синхронизируются, а гильзы, пыль, следы от колёс/выстрелов и прочие красоты, которые пропадают через 10-15 секунд отрисовываются только клиентом для зрелищности. Это если говорить про правильную игру :)
Спасибо за статью. Сразу вспомнилось, как в GTA SA-MP ценили людей, обладавших особым навыком «стрельбы по пингу», потому как особенности клиент-серверного общения позволяли людям с пингом больше 1000 начать буквально телепортироваться вокруг другого пользователя за счёт быстрой смены направления бега, которая как раз до сервера вовремя не долетала.
SA-MP это наверное совсем отдельная тема, ведь там мультиплеер прикрутили к игре, которая не планировала быть сетевой. Кстати проблему с читерами на своём сервере решил кардинально — для подключения к серверу требовалось скачать кастомный клинет, который проверял целостность игровых файлов, защищал память процесса игры от внедрения чужих потоков и предотвращал все попытки её изменения извне. Конечно же и такой античит можно было обойти, но отсутствие готовых решений типа «скачай тренер и запусти» избавило сервер от набегов нечестных игроков.
Будет ли примеры с кодом в следующих частях? Было бы очень хорошо. И будут ли примеры каких либо не FPS мультиплееров типа La2, WoW и др, как там сервер обрабатывает мир и решает кому что показывать.
У меня вопрос, в большей степени касающийся техники античита — используются ли сейчас в каких-нибудь онлайн играх механики отложенной или «ленивой» проверки корректности действий и перемещений игрока? Я поясню свой вопрос примером:
Допустим, играет какой-то бессовестный человечек в Батлу, Контру или что-то подобное, при этом использует чит с функциями аимбота, воллхака, проход сквозь препятствия. Дотошные проверки в реальном времени (мог ли игрок попасть в другого со своей позиции, не было ли непроходимых препятствий на пути его движения или траектории выстрела и т.п.) потребуют слишком больших вычислительных ресурсов и замедлят ответ сервера.
Вопрос: можно ли ли сохранять всю хронику событий на сервере, условно доверяя клиенту игрока на текущий момент, а ретроспективную симуляцию и анализ проводить не вмешиваясь в текущую игровую сессию?
P.S. Играю в один MMOFPS шутер и часто замечаю, что периодические обновления, в которых декларируется улучшение/обновление античит-защиты обычно прибавляют лагов и тормозов, а полезного эффекта с гулькин нос. Через пару дней читы обновляются, и на ютубе появляются их новые рекламные ролики.
Допустим, играет какой-то бессовестный человечек в Батлу, Контру или что-то подобное, при этом использует чит с функциями аимбота, воллхака, проход сквозь препятствия. Дотошные проверки в реальном времени (мог ли игрок попасть в другого со своей позиции, не было ли непроходимых препятствий на пути его движения или траектории выстрела и т.п.) потребуют слишком больших вычислительных ресурсов и замедлят ответ сервера.
Вопрос: можно ли ли сохранять всю хронику событий на сервере, условно доверяя клиенту игрока на текущий момент, а ретроспективную симуляцию и анализ проводить не вмешиваясь в текущую игровую сессию?
P.S. Играю в один MMOFPS шутер и часто замечаю, что периодические обновления, в которых декларируется улучшение/обновление античит-защиты обычно прибавляют лагов и тормозов, а полезного эффекта с гулькин нос. Через пару дней читы обновляются, и на ютубе появляются их новые рекламные ролики.
P.S. Ни один чит не возможен вне игравого процесса, все баги заложенны в протокол: получение дропа, телепортация, бессмертие… Чтобы убрать чит лаги не нужны, достаточно сменить протокол, лаги же вызваны желанием получить контроль над пользователем, сбор информации, слежение за процессами (для контроля за мультами и левыми программами накручивающими какие-то параметры хранящиеся на «клиенте»), изменениями файлов в клиенте (с целью что-то начитерить), и увеличение трафика собранной информацией, и самое главное — раздувание клиента, за счет «нового» игравого контента, который перестает влезать в память и быстродействие падает… уходя в своп. Лаги часто наблюдаются даже при «толстых» каналах с минимальной загрузкой, причем утилизация процессора/ядер доходит до 100% и на длительный срок… в некоторых играх.
На сколько я понимаю, так и делается. Клиент получая новую информацию от сервера должен откатить состояние назад во времени, применить полученные изменения, а потом снов экстраполировать (предсказать) текущее состояние. Сервер этого не делает, так как ему не обязательно знать актуальное состояние мира, он может ждать, пока придут все инпуты, и только тогда применять их и проверять валидность.
админ удали случайно написал
Между прочим, в «реальном» мире существуют ровно те же особенности. Ни одно воздействие не распространяется мгновенно, будь то электромагнитная волна или гравитация. Визуальный сигнал также имеет задержку (тот же пинг).
Хуже того: в «реальном» мире нет понятия абсолютной одновременности (события, одновременные в одной системе отсчета, могут быть вовсе не одновременными в другой; см. парадокс шеста и сарая). И контрольный: понятие причинности (событие A могло являться причиной события B) применимо также не для любых двух событий, а только для «времениподобных» — тех, которые произошли, грубо говоря, «достаточно близко» друг от друга (между ними должен успеть пролететь свет; если не успел — то нельзя сказать, какое из них вообще было первое, а какое — второе, потому что существует одна система отсчета, в которой первым было A, и вторая, где первым было B).
А вы говорите — «геймдев, геймдев». Реальный мир и теория относительности намного круче.
Хуже того: в «реальном» мире нет понятия абсолютной одновременности (события, одновременные в одной системе отсчета, могут быть вовсе не одновременными в другой; см. парадокс шеста и сарая). И контрольный: понятие причинности (событие A могло являться причиной события B) применимо также не для любых двух событий, а только для «времениподобных» — тех, которые произошли, грубо говоря, «достаточно близко» друг от друга (между ними должен успеть пролететь свет; если не успел — то нельзя сказать, какое из них вообще было первое, а какое — второе, потому что существует одна система отсчета, в которой первым было A, и вторая, где первым было B).
А вы говорите — «геймдев, геймдев». Реальный мир и теория относительности намного круче.
Не понимаю за что вас заминусили. Если только за оценочный итог.
Вообще в самом начале статьи и написано, что проблемы идут от вполне реальных физических законов.
И в этом весь ужас. Надо создать иллюзию классической одновременности для людей, удаленных настолько, что для них бывает только одновременность из СТО.
Вообще в самом начале статьи и написано, что проблемы идут от вполне реальных физических законов.
И в этом весь ужас. Надо создать иллюзию классической одновременности для людей, удаленных настолько, что для них бывает только одновременность из СТО.
Я прошу прощения, но реальный мир не глючит и не лагает, если на одной локации соберется несколько десятков тысяч «игроков». Да даже миллионы можно вместить в пределах видимости, и фпс не упадет.
Также, в реальном мире нет проблем с текстурами и с коллизями.
Также, в реальном мире нет проблем с текстурами и с коллизями.
Почему вы так думаете? А как же черные дыры и сингулярности? А как же момент большого взрыва и теория струн с 10+ измерениями? Как же квантованность всего вокруг? Как же квантово-волновой дуализм и принцип неопределенности Гейзенберга? Как же квантовая запутанность? По-моему, очень даже глючит он, этот мир, и, по иронии, именно когда соберется много игроков на одной локации, а также когда зум очень уж выкручивают.
А мы не наблюдаем реальный мир через монитор, мы живем внутри него, и если и есть глюки, то мы глючим вместе с ними. В то время как по отношению к компьютерным играм, мы находимся вне системы, поэтому сравнивать глюки игры и реальную физику — нет смысла.
А мы не наблюдаем реальный мир через монитор,Сетчатка глаза, а также рецепторы в мозгу, обрабатывающие сигналы с нее, а еще лучше — ПО в мозгу, распознающее все это (и которому, кстати, даже и внешние сигналы-то не особенно нужны — например, во сне и без них все прекрасно работает) — это разве не аналог монитора?
мы живем внутри него, и если и есть глюки, то мы глючим вместе с ними… поэтому сравнивать глюки игры и реальную физику — нет смыслаСправедливо, но какая связь между фразой до «поэтому» и после? Вроде бы они независимы.
Я не так уж и троллю, между прочим. Аналогия и правда ведь есть, даже на эту тему фантастические романы пишут (вроде был такой, где аномалии квантовой физики объясняются ограниченностью компьютера, моделирующего мир).
«Сетчатка глаза, а также рецепторы в мозгу, обрабатывающие сигналы с нее, а еще лучше — ПО в мозгу, распознающее все это (и которому, кстати, даже и внешние сигналы-то не особенно нужны — например, во сне и без них все прекрасно работает) — это разве не аналог монитора?»
Конечно нет. Где у вас в мониторе распознающее ПО?
Если в поле зрения у вас человек, вы его распознаете. Но если у вас в поле зрения 10.000 человек, у вас что фпс в глазах падает? Нет конечно. Лагов нет, распространение сигналов в реальном мире для нас субъективно одинаково. Если даже на каком-то квантовом уровне начнутся проблемы и замедления, то сигналы в нашем мозгу замедлятся соответственно, и мы этого замедления не увидим — для этого нужно быть вне системы. Просто в тот момент, когда физика вокруг изменится слишком сильно, чтобы наши организмы могли функционировать, мы перестанем. Но вместе с окружающим миром, а не он себе лагает отдельно, мы лагаем отдельно.
Вот и хочется, чтобы компьютерные игры не лагали в мониторе, а показывали реалистичную картинку.
Конечно нет. Где у вас в мониторе распознающее ПО?
Если в поле зрения у вас человек, вы его распознаете. Но если у вас в поле зрения 10.000 человек, у вас что фпс в глазах падает? Нет конечно. Лагов нет, распространение сигналов в реальном мире для нас субъективно одинаково. Если даже на каком-то квантовом уровне начнутся проблемы и замедления, то сигналы в нашем мозгу замедлятся соответственно, и мы этого замедления не увидим — для этого нужно быть вне системы. Просто в тот момент, когда физика вокруг изменится слишком сильно, чтобы наши организмы могли функционировать, мы перестанем. Но вместе с окружающим миром, а не он себе лагает отдельно, мы лагаем отдельно.
Вот и хочется, чтобы компьютерные игры не лагали в мониторе, а показывали реалистичную картинку.
Супер статья, только недавно искал что-нибудь подобное, в котором было бы так «разжевано» про сетевые игры.
Это всё, конечно, хорошо, но что, если клиент даже приблизительно не представляет результат действия?
Например, клиент отправляет команду атаковать, но ему не известно, ни сколько жизней у противника, ни какая его защита, ни его навыки. Результат атаки обрабатывается на сервере и спектр возможных значений от «убил» до «ничего не произошло» или даже «вы критически промахнулись, попали в себя и потеряли меч». Как тут быть?
Например, клиент отправляет команду атаковать, но ему не известно, ни сколько жизней у противника, ни какая его защита, ни его навыки. Результат атаки обрабатывается на сервере и спектр возможных значений от «убил» до «ничего не произошло» или даже «вы критически промахнулись, попали в себя и потеряли меч». Как тут быть?
Отличная статья. Спасибо за перевод.
Делаю первые шаги в разработке онлайн игр и первая существенная проблема, с которой столкнулся — это именно синхронизация данных с сервером. И как раз в той части, где предсказания «забежали наперед», с сервера пришли данные и игрока откинуло назад.
Делаю первые шаги в разработке онлайн игр и первая существенная проблема, с которой столкнулся — это именно синхронизация данных с сервером. И как раз в той части, где предсказания «забежали наперед», с сервера пришли данные и игрока откинуло назад.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мультиплеер в быстрых играх (части I, II)