У Valve конечно же есть технология клиентского согласования. Но в доте она почти не используется, только вызывается отработка анимации.
Например, передвижение персонажа не предсказывается(как минимум, не предсказывалось в 2015 году, после выхода reborn) https://www.youtube.com/watch?v=fWaVcWNh3Ro&t=729s
Ни разу не встречал. Обычно математика описывает что-то не слишком рабочее.
Ну, прямо новая математическая теория скорее всего будет абстрактна и не привязана к реальности, т.к. изучает свойства существующих объектов. Но я не думаю, что здесь нужно изобретать что-то концептуально новое. И в таких случаях математика отлично справляется, это же отличный гибкий язык.
пункт в) оказывается неразрешимым, надо строить геймплей так, чтобы он встречался реже.
Да, так и стараются делать.
А вот как быть в гоночках? Там же каждый момент важен.
Если в гонках машины не умеют сталкиваться, их часто экстраполируют на основании текущей позиции и скорости. А если машины умеют сталкиваться, увы, ничего не поделать и только с низким пингом получится нормально играть.
Можно, конечно, понизить в правах лагающего, тогда страдать будет только он, но лучше так не делать.
Повторюсь, обычно так и делают — понижают лагающего в правах.
Dota в данном контексте лучше не вспоминать, там нет ни client side prediction, ни lag compensation. А смерть после телепорта видимо происходит если они прямо в одном кадре произошли.
Математика так не работает. Сначала делается понятная и удобная абстракция, а потом уже ищется как применить её к реальности.
Математика прекрасно так работает. Ценность математического аппарата, который не способен описать современные алгоритмы — нулевая. Так что придумывать десяток абстракций просто так — бесполезно. Должна быть непротиворечивая система, в которой можно доказывать теоремы в том числе для текущих игр.
1) Ну вот так вот обычно делают. Если хотите, можете проверку смерти сделать в прошлом, а значит применить выстрел. Все равно выстрел применится в настоящем. Да, враг умрет, но и вы тоже умрете.
А вот у игроков будет ощущение того, что что-то пошло не так, т.к. обоюдные убийства в игре с hitscan оружием поспринимаются как признак забагованности.
2) Вы не правы. Если клиентское согласование работает корректно, персонаж двигается по одинаковым траекториям что на сервере, что на клиенте. При этом персонаж мгновенно реагирует на ввод игрока.
Хотелось бы математически строго описания переключения состояний онлайн игры.
Если сделаете — будете первым, на сколько я знаю. Только учтите, что стоит формально описывать существующий механизм, а не тот, который вы придумали, ну либо сначала проверить, что ваша идея действительно лучше.
Да, игрок с более быстрым пингом получает преимущество.
В вашей схеме с ожиданием основные проблемы:
1) Стреляющий игрок гораздо хуже чувствует время, которое ему нужно потратить на убийство(это очень важная метрика, пруф: https://www.youtube.com/watch?v=EtLHLfNpu84). Что увеличивает чувство лага.
2) Игрок дольше чувствует себя живым, хотя на самом деле он мертв(и чаще он действительно умирает, а не оказывается чудесным образом спасен), что тоже увеличивает чувство лага.
Или я мыслю слишком утопично?
100% справедливости вы никогда не достигните, ведь игроки живут рассинхронизированных, немного отличающихся мирах.
Самое важное в мультиплеере — это иллюзия одновременности, а не сама одновременность. И поэтому выбор обычно делают в сторону уменьшения самых заметных проблем.
И да, сервер не может проверить что Л действительно отправил команду в t(1). Нет достоверного способа отличить пакет, который шел дольше обычного, от позже отправленного пакета. Так что стоит разрабатывать геймдизайн, который уменьшает профит от такого мухлежа.
Нет, не будут. Команды не сбрасываются из-за изменения мира(нигде такого не было написано).
Например, при выстреле произойдут следующие проверки:
1) Жив ли персонаж сейчас?
2.1) откатить время назад
2.2) может ли персонаж стрелять?
2.3) попал ли персонаж при выстреле во врага?
2.4) вернуть время назад
3) если все проверки прошли, наносим урон врагу
При передвижении произойдет следующее(предположим, что игрок контролирует персонажа только на земле)
1) На земле ли персонаж? (в настоящем времени)
2) Если на земле, изменить скорость в соответствии с пользовательским вводом
Итог: сервер никогда не меняет прошлое. Сервер иногда заглядывает в него, чтобы синхронизировать моменты, требующие особой точности.
Я знаю что такое согласование. Нет, клиент не должен сообщать серверу что он видел, клиент только отправляет команды. Перечитайте еще раз, возможно посмотрите на мои статьи(https://habrahabr.ru/post/302834/)
Нет.
Согласование — это техника, применяемая на клиенте. Она никак не затрагивает состояние сервера. Она нужна чтобы создать у игрока ощущение того, что его команды применяются мгновенно. Для этого результат каждой команды пользователя отправляется на сервер и сразу же симулируется на клиенте. Когда приходит состояние от сервера, надо с ним синхронизироваться. Для этого клиент применяет у себя состояние сервера, а затем локально переприменяет все свои команды, которые сервер еще не успел обработать.
Как видите, серверу наплевать на то, применяется ли техника согласования.
А вот компенсация лага — другое дело (см. https://habrahabr.ru/post/303006/). Но в моей статье как раз и написано, что выстрел происходит так: сервер откатывает состояние мира назад, проверяет попал ли выстрел, возвращается обратно к текущему состоянию(не переприменяет команды, а просто возвращается), а затем применяет эффект от попадания или промаха, в зависимости от того, попал выстрел. Таким образом бессмертия не достичь, так как:
1) если игрок умер, такой методой его уже не воскресить.
2) применяется компенсация лага только для темпорально критичных действий(таких как выстрел).
Если информация о выстреле дошла на какой-либо клиент, он уже произошел на сервере. Игрок уже считается мертвым, так что любой новый ввод от него игнорируется пока не произойдет респавн.
В IV части вы найдете все ответы( https://habrahabr.ru/post/302394/ ), но возможно стоит просмотреть так же предыдущие части чтобы убедиться что вы все правильно понимаете.
Потрясающая статья! Я не мог себе и представить, что можно подобным образом модифицировать нейронные сети.
И результаты со связным списком выглядят многообещающими.
У Valve конечно же есть технология клиентского согласования. Но в доте она почти не используется, только вызывается отработка анимации.
Например, передвижение персонажа не предсказывается(как минимум, не предсказывалось в 2015 году, после выхода reborn)
https://www.youtube.com/watch?v=fWaVcWNh3Ro&t=729s
Ну, прямо новая математическая теория скорее всего будет абстрактна и не привязана к реальности, т.к. изучает свойства существующих объектов. Но я не думаю, что здесь нужно изобретать что-то концептуально новое. И в таких случаях математика отлично справляется, это же отличный гибкий язык.
Да, так и стараются делать.
Если в гонках машины не умеют сталкиваться, их часто экстраполируют на основании текущей позиции и скорости. А если машины умеют сталкиваться, увы, ничего не поделать и только с низким пингом получится нормально играть.
Повторюсь, обычно так и делают — понижают лагающего в правах.
Dota в данном контексте лучше не вспоминать, там нет ни client side prediction, ни lag compensation. А смерть после телепорта видимо происходит если они прямо в одном кадре произошли.
Математика прекрасно так работает. Ценность математического аппарата, который не способен описать современные алгоритмы — нулевая. Так что придумывать десяток абстракций просто так — бесполезно. Должна быть непротиворечивая система, в которой можно доказывать теоремы в том числе для текущих игр.
1) Ну вот так вот обычно делают. Если хотите, можете проверку смерти сделать в прошлом, а значит применить выстрел. Все равно выстрел применится в настоящем. Да, враг умрет, но и вы тоже умрете.
А вот у игроков будет ощущение того, что что-то пошло не так, т.к. обоюдные убийства в игре с hitscan оружием поспринимаются как признак забагованности.
2) Вы не правы. Если клиентское согласование работает корректно, персонаж двигается по одинаковым траекториям что на сервере, что на клиенте. При этом персонаж мгновенно реагирует на ввод игрока.
Да, игрок с более быстрым пингом получает преимущество.
В вашей схеме с ожиданием основные проблемы:
1) Стреляющий игрок гораздо хуже чувствует время, которое ему нужно потратить на убийство(это очень важная метрика, пруф: https://www.youtube.com/watch?v=EtLHLfNpu84). Что увеличивает чувство лага.
2) Игрок дольше чувствует себя живым, хотя на самом деле он мертв(и чаще он действительно умирает, а не оказывается чудесным образом спасен), что тоже увеличивает чувство лага.
И да, сервер не может проверить что Л действительно отправил команду в t(1). Нет достоверного способа отличить пакет, который шел дольше обычного, от позже отправленного пакета. Так что стоит разрабатывать геймдизайн, который уменьшает профит от такого мухлежа.
Нет, не будут. Команды не сбрасываются из-за изменения мира(нигде такого не было написано).
Например, при выстреле произойдут следующие проверки:
1) Жив ли персонаж сейчас?
2.1) откатить время назад
2.2) может ли персонаж стрелять?
2.3) попал ли персонаж при выстреле во врага?
2.4) вернуть время назад
3) если все проверки прошли, наносим урон врагу
При передвижении произойдет следующее(предположим, что игрок контролирует персонажа только на земле)
1) На земле ли персонаж? (в настоящем времени)
2) Если на земле, изменить скорость в соответствии с пользовательским вводом
Итог: сервер никогда не меняет прошлое. Сервер иногда заглядывает в него, чтобы синхронизировать моменты, требующие особой точности.
Я знаю что такое согласование. Нет, клиент не должен сообщать серверу что он видел, клиент только отправляет команды. Перечитайте еще раз, возможно посмотрите на мои статьи(https://habrahabr.ru/post/302834/)
Нет.
Согласование — это техника, применяемая на клиенте. Она никак не затрагивает состояние сервера. Она нужна чтобы создать у игрока ощущение того, что его команды применяются мгновенно. Для этого результат каждой команды пользователя отправляется на сервер и сразу же симулируется на клиенте. Когда приходит состояние от сервера, надо с ним синхронизироваться. Для этого клиент применяет у себя состояние сервера, а затем локально переприменяет все свои команды, которые сервер еще не успел обработать.
Как видите, серверу наплевать на то, применяется ли техника согласования.
А вот компенсация лага — другое дело (см. https://habrahabr.ru/post/303006/). Но в моей статье как раз и написано, что выстрел происходит так: сервер откатывает состояние мира назад, проверяет попал ли выстрел, возвращается обратно к текущему состоянию(не переприменяет команды, а просто возвращается), а затем применяет эффект от попадания или промаха, в зависимости от того, попал выстрел. Таким образом бессмертия не достичь, так как:
1) если игрок умер, такой методой его уже не воскресить.
2) применяется компенсация лага только для темпорально критичных действий(таких как выстрел).
Если информация о выстреле дошла на какой-либо клиент, он уже произошел на сервере. Игрок уже считается мертвым, так что любой новый ввод от него игнорируется пока не произойдет респавн.
Подделать можно, но если клиент получил информацию о выстреле врага, его уже убили на сервере и что бы он не говорил о своих передвижениях, он мертв.
В IV части вы найдете все ответы( https://habrahabr.ru/post/302394/ ), но возможно стоит просмотреть так же предыдущие части чтобы убедиться что вы все правильно понимаете.
Я играл, мне не понравилось. Хотя я в Питере, а сервера в Москве, ощущение лага не проходило ни на секунду(пинг около 50).
FYI: Я переводил статьи Gabriel Gambetta(которые вы рекомендовали к прочтению):
https://habrahabr.ru/post/302394/
Это просто прекрасно! Не думал, что смогу рыдать от смеха глядя на код)
Потрясающая статья! Я не мог себе и представить, что можно подобным образом модифицировать нейронные сети.
И результаты со связным списком выглядят многообещающими.
Очень интересно! Спасибо за статью.
там же парень устроился работать в гугл)
Шикарная статья! Прочитал на одном дыхании.
Поддерживаю trapwalker
Сейчас бы на хабре писать "2к17" :D
И?)
А, блин, нормальная анаграмма.
Этот пункт беру обратно) Остальные остаются)