Командный пакет содержит описание команды и время отдачи команды клиентом (например время нажатия кнопки на клавиатуре).
Возникает вопрос... даже два А что, если нехороший человек пошлет на сервер что он уже пять минут как нажал "вперёд" и держит — он получить возможность телепортироваться? И как быть серверу, если он получает команду из прошлого — при попытке рассчитать время назад возникает куча проблем, или хранить всю историю команд и пересчитывать весь мир/локацию в таком случае?
Когда сервер посылает клиенту время и состояние тут все понятно — ну подумаешь дернется герой, или упадет вораг замертво секундой позже, чем должен — это практически у всех так...
Вобщем у меня возникло ощущение, что я чегото не понимаю
Здравствуйте, hell citizen, Вы писали:
HC>Возникает вопрос... даже два А что, если нехороший человек пошлет на сервер что он уже пять минут как нажал "вперёд" и держит — он получить возможность телепортироваться? И как быть серверу, если он получает команду из прошлого — при попытке рассчитать время назад возникает куча проблем, или хранить всю историю команд и пересчитывать весь мир/локацию в таком случае?
Юзер шлёт с какой-то частотой что у него происходит. Если ничего не происходит то же шлет такое сообщение. В итоге подделать прошлое не получиться.
И я бы не преувеличивал число желающих таким образом читить. А кто захочет — всё равно извернётся.
Вы практически сами и отвечаете на вопрос. Видимо есть доверительный временной интервал в рамках которого сервер ещё готов принимать команды клиента. Думаю, что размер этого интервала коррелирует с среднестатистичекими лагами, и вполне может быть динамическим.
Здравствуйте, A4, Вы писали:
A4>Вы практически сами и отвечаете на вопрос. Видимо есть доверительный временной интервал в рамках которого сервер ещё готов принимать команды клиента. Думаю, что размер этого интервала коррелирует с среднестатистичекими лагами, и вполне может быть динамическим.
Практически, но не совсем... Я пытаюсь использовать вот эту штуку, но при этом я игнорирую timestamp, пришедший от клиента — я просто считаю, что событие произошло в тот момент, когда информация о нем попала на сервер.
Я так делаю потому, что мне не понятна одна вещь. А именно — как изменить мир, если он уже рассчитан на несколько тиков вперёд, а ему приходит информация что те и вон те на самом деле в это время не стояли на одном месте, а двигались. Вот о чем мой вопрос.
На клиенте же я учитываю timestamp от сервера, чтобы точнее предсказывать состояние мира. Т.е. смотрим что сейчас время T, T — timestamp он был там и шёл туда, значит T + 1 он будет вон там. Поехали. Тут вроде всё просто...
HC>Я так делаю потому, что мне не понятна одна вещь. А именно — как изменить мир, если он уже рассчитан на несколько тиков вперёд, а ему приходит информация что те и вон те на самом деле в это время не стояли на одном месте, а двигались. Вот о чем мой вопрос.
А хрен его знает... Насколько я в курсе предсказанием положения (экстратоляция в доверительном отрезке времени) объекта занимается клиент. Сервер же движение клиента не предсказывает, а принимат, то что есть. Вопрос, кстати довольно интересный и актуальный...
HC>На клиенте же я учитываю timestamp от сервера, чтобы точнее предсказывать состояние мира. Т.е. смотрим что сейчас время T, T — timestamp он был там и шёл туда, значит T + 1 он будет вон там. Поехали. Тут вроде всё просто...
Термин timestamp откровенно не понял... Определение, что это локальное время клиента... гм.. почти ничего. В чём идея то?
Здравствуйте, A4, Вы писали:
A4>А хрен его знает...
Вот и я про что. Может быть, автор того поста зайдёт и пояснит, что он имел в виду...
A4>Термин timestamp откровенно не понял... Определение, что это локальное время клиента... гм.. почти ничего. В чём идея то?
Там по ссылке написано. В кратце — синхронизорованное между клиентом сервером число, показывающее универсальное серверное время. Говорят, что у них достаточная точность и разрешающая способность таймера. Я пока склонен верить.
HC>Там по ссылке написано. В кратце — синхронизорованное между клиентом сервером число, показывающее универсальное серверное время. Говорят, что у них достаточная точность и разрешающая способность таймера. Я пока склонен верить.
А.. ну это обычные серверные тики (кадры, фрэймы). Разумеется тики клиента и сервера должные быть синхронизированы. Маленькое замечание: сетевые тики могут быть кратны тикам физики (актуально для MMORPG), т.е. на один сетевой кадр приходится N физических кадров.
Здравствуйте, A4, Вы писали:
A4>А.. ну это обычные серверные тики (кадры, фрэймы). Разумеется тики клиента и сервера должные быть синхронизированы. Маленькое замечание: сетевые тики могут быть кратны тикам физики (актуально для MMORPG), т.е. на один сетевой кадр приходится N физических кадров.
Не совсем...
A timestamp is nothing more than the local system time. Unfortunately, every system has a different local system time. If you were simply to send the system time over the network you'd get the value of the other machine's clock which tells you nothing about when the event happened because you only know your own system time, not anyone else's. The timestamping feature of RakNet allows times to be read relative to your own system, allowing you to concentrate on the game and not worry about the local times of other systems.
Т.е., это просто синхронизированное относительно машины, которая его получает (у нас речь идёт о сервере, значит относительно сервера), время. Ну а тогда уже M единиц = 1 сетевой тик = N физ. тиков. Но основного вопроса это не снимает ...
Здравствуйте, hell citizen, Вы писали:
HC>Здравствуйте, A4, Вы писали:
HC>...я игнорирую timestamp, пришедший от клиента...
На мой взгляд для коммерческой версии игры это недопустимо, представьте себе: вы нажали кнопку "вперёд", а изза лагов движение началось только через полсекунды. Потом вы отпустили кнопку... и, пролетев ещё экран, остановились. Как вам? Я уже не говорю о последствиях такого поведения на локациях с монстрами.
Кстати, такую вещь встречаю в большинстве корейских ММОРПГ. Уверяю вас, ужасно раздражает.
HC>... как изменить мир, если он уже рассчитан на несколько тиков вперёд, а ему приходит информация что те и вон те на самом деле в это время не стояли на одном месте, а двигались. Вот о чем мой вопрос.
Действительно ОЧЕНЬ сложный вопрос. Реализация сильно зависит от механики игры, игровой логики, дизайна. Пожалуй эту часть надо отлаживать под конец проекта.
В начале можно ограничиться только проверкой: если такое опоздавшее действие оказывает влияние только на игрока его совершившего то состояние игрока пересчитывается. Иначе считаем что действие совершено в момент прихода команды на сервер.
Вобщем то тут есть много вариантов... экспериментируйте.
E>На мой взгляд для коммерческой версии игры это недопустимо, представьте себе: вы нажали кнопку "вперёд", а изза лагов движение началось только через полсекунды. Потом вы отпустили кнопку... и, пролетев ещё экран, остановились. Как вам? Я уже не говорю о последствиях такого поведения на локациях с монстрами.
Истинно всё так и происходит =((.
Отсюда приходим к мысли распараллеливания процессов перемещения клиентского персонажа на клиенте и сервере. Разумеется недолго, в течении доверительного временного интервала (интуитивно равного где то времени между пакетами). Т.е. клиент рассуждает "ок, команда от юзера получена, начну ка я его двигать (кастовать, атаковать, и т.д.) а сервер извещу когда всё это началось". Команда приходит к серверу (который управлял персонажем паралельно). Сервер видит когда персонаж начал движение и зная положение персонажа на тот момент и вектор его скорости может вычислить его текущее положение доверяя (важный момент) в этом вопросе клиенту. После чего он утверждает текущее положение персонажа как правильное и отправляет его всем клиентам с указанием времени актуальности этих данных. Тут возникает новая трудность — время доставки этих пакетов к клиентам увы неизвестно и к моменту их прихода... они немного кривые =).
Основная идея тут такова — клиент говорит серверу: "я изменил своё поведение, но не сейчас, а тогда (когда был отправлен пакет, а не когда он дошёл), всё ок?" Сервер должен использовать эти данные и не пренебрегать временем задержек на пересылку, а учитывать и максимально использовать эти данные. Т.е. мы соглашаемся с тем, что все действия происходят в прошлом, и клиент и сервер пытаются это учитывать. Для организации такого механизма необходимо присутствие на сервере для каждого персонажа список предыдущих положений и скоростей привязанных ко времени (некие снимки прошлого). В принципе есть более дешёвый путь (он же более опасный) — не хранить список положений на сервере, а доверять координатам клиента указанными им на момент отправки пакета. Чревато некоторыми проблемами (хакерство, потеря пакетов). но ИМХО они решаемы.
E>Действительно ОЧЕНЬ сложный вопрос. Реализация сильно зависит от механики игры, игровой логики, дизайна. Пожалуй эту часть надо отлаживать под конец проекта.
Не соглашусь. Вопросы usability нужно отлаживать пораньше. Иначе есть риск сильно завязнуть в переделках.
A4>...время доставки этих пакетов к клиентам увы неизвестно и к моменту их прихода... они немного кривые =).
Хм.. думаю это время сервер всё таки может вычислить, примерно конечно. Ведь с каждой командой приходит клиентский тик. Усреднённое(серверный тик — полученный клиентский тик) ~= время прохождения пакета. Я не знаток сетевого железа, но думаю для большинства клиентов время прохождения пакета примерно одинаково в обе стороны.
Кстати сервер может дисконнектить клиента если задержка больше доверительного интервала. Так можно избавиться от ряда проблем. В общем то, по моим наблюдениям, так везде и сделано.
A4>Основная идея тут такова — клиент говорит серверу: "я изменил своё поведение, но не сейчас, а тогда (когда был отправлен пакет, а не когда он дошёл), всё ок?" Сервер должен использовать эти данные и не пренебрегать временем задержек на пересылку, а учитывать и максимально использовать эти данные. Т.е. мы соглашаемся с тем, что все действия происходят в прошлом, и клиент и сервер пытаются это учитывать.
Именно так.
A4> Для организации такого механизма необходимо присутствие на сервере для каждого персонажа список предыдущих положений и скоростей привязанных ко времени (некие снимки прошлого).
Думаю можно реализовать с помощью запоминания состояния игрока на момент прихода последней команды (влияющей на состояние) вне доверительного интервала и списка команд после неё. Здесь под командой понимается не только команда от клиента, это может быть команда от среды.
A4> В принципе есть более дешёвый путь (он же более опасный) — не хранить список положений на сервере, а доверять координатам клиента указанными им на момент отправки пакета. Чревато некоторыми проблемами (хакерство, потеря пакетов). но ИМХО они решаемы.
Самая главная проблема: если игра будет пользоваться спросом, то хакеры обязательно найдут эту лазейку и пролезут, будьте уверены. Эту проблему можно решить только частично и на некоторое время.
E>>Действительно ОЧЕНЬ сложный вопрос. Реализация сильно зависит от механики игры, игровой логики, дизайна. Пожалуй эту часть надо отлаживать под конец проекта. A4>Не соглашусь. Вопросы usability нужно отлаживать пораньше. Иначе есть риск сильно завязнуть в переделках.
Для максимально плавной игры придется вносить кучу триков в механизм синхронизации. Эти трики будут основаны на особенностях механики и дизайна конкретной игры.
Дизайн игр (особенно РПГ и ММОРПГ) часто модифицируется в процессе разработки. В результате трики придется удалять/добавлять/переделывать по многу раз. Проще и разумнее добавить их в конце. Тем более что как раз в это время будет идти тестирование, и можно будет проверить целесообразность внесения этих триков.
ЗЫ: надеюсь вы понимаете, что разработка успешной большой ММО (не лёгкой игрушки на полчаса в день), а в особенности ММОРПГ это огромная куча огромных трудностей.
Под Q3 есть мод CPMA, в котором как раз реализована "отмотка" событий назад для сильно лагающих клиентов. Т.е. возможна такая ситуация, что ты забежал за угол и после этого оказывается, что тебя подрейлил игрок, который по идее тебя уже не видит. Такая система реально улучшает качество игры — сравнивал обычный q3 и q3/cpma, в CPMA вполне комфортно играть с пингом 100-150(!).
В Q3-подобной игре warsow используется такая же техника, и ее исходники доступны.
Здравствуйте, ecco, Вы писали:
E>На мой взгляд для коммерческой версии игры это недопустимо, представьте себе: вы нажали кнопку "вперёд", а изза лагов движение началось только через полсекунды. Потом вы отпустили кнопку... и, пролетев ещё экран, остановились. Как вам? Я уже не говорю о последствиях такого поведения на локациях с монстрами.
Я наверное плохо объяснил, но такого не будет. По нажатии кнопки вперёд клиент отправляет "вперёд" на сервер и начинает движение сразу же, и заканчивает его по отпускании кнопки, каждый шажок отсылая на сервер "вперёд". Сервер считает, что клиент пошёл вперёд пингом позже. Если вперёд нельзя, сервер отошлёт "нельзя, иди в (0,0)" и клиента отшвырнёт назад (как, например, в ультима онлайн). Т.е. клиент идёт вперёд, пока не получит запрет от сервера или пока пользователь не отпустит кнопку. На самом же деле движение происходит спустя его пинг после нажатия кнопки и завершается спустя его пинг после отпускания. На экране же у пользователя он остановиться сразу, а спустя полсекунды получит подтверждение того, что находится в данной точке пространства и стоит на месте. А вот уже другие клиенты узнают об этом движении через их собственные пинги после того, как оно произошло.
E>Действительно ОЧЕНЬ сложный вопрос. Реализация сильно зависит от механики игры, игровой логики, дизайна. Пожалуй эту часть надо отлаживать под конец проекта.
Вот за это +1. Да, пожалуй это следует отложить и оставить пока всё как есть. Столько всего ещё может поменяться...
Здравствуйте, hell citizen, Вы писали:
HC>Если вперёд нельзя, сервер отошлёт "нельзя, иди в (0,0)" и клиента отшвырнёт назад (как, например, в ультима онлайн). Т.е. клиент идёт вперёд, пока не получит запрет от сервера...
Следует добавить: в большинстве случаев клиент сам в состоянии определить: может он идти дальше или нет. Зачем "отшвыриваться" попусту...
В ультиму играл только чуток, там что, действительно клиент сам не врубается в такие вещи? Не замечал...
Думаю если препятствие динамическое, то к клиенту должна прити команда о присутствии препятствия и клиент должен учесть её заранее или пересчитать всё (отображая с некоторой интерполяцией), если эта команда пришла с опозданием.
HC>Я наверное плохо объяснил, но такого не будет. По нажатии кнопки вперёд клиент отправляет "вперёд" на сервер и начинает движение сразу же, и заканчивает его по отпускании кнопки, каждый шажок отсылая на сервер "вперёд". Сервер считает, что клиент пошёл вперёд пингом позже... HC> ... На самом же деле движение происходит спустя его пинг после нажатия кнопки и завершается спустя его пинг после отпускания. На экране же у пользователя он остановиться сразу, а спустя полсекунды получит подтверждение того, что находится в данной точке пространства и стоит на месте. А вот уже другие клиенты узнают об этом движении через их собственные пинги после того, как оно произошло.
Да это тоже вариант конечно. По моему стоит реализовать хотя бы как базовый вариант, а потом плясать от него.
Здравствуйте, ecco, Вы писали:
E>Здравствуйте, hell citizen, Вы писали:
E>В ультиму играл только чуток, там что, действительно клиент сам не врубается в такие вещи? Не замечал... E>Думаю если препятствие динамическое, то к клиенту должна прити команда о присутствии препятствия и клиент должен учесть её заранее или пересчитать всё (отображая с некоторой интерполяцией), если эта команда пришла с опозданием.
Некоторые типы "нельзя" клиент определяет сам. Которые не может — его не пускает сервер. В ултиме так и есть. В некоторых местах или ситуациях отбрасывает назад, а в некоторых просто не идёт. Например, можно проскочить через только что поставленную парализующую стену, а через секунду обнаружить, что ты всё же попался в неё.
Здравствуйте, hell citizen, Вы писали:
HC>Всем доброго дня!
HC>Копал я тут форум на предмет того, как сделать игру клиент-сервер плавнее и красивше. В одном из постов
HC>Командный пакет содержит описание команды и время отдачи команды клиентом (например время нажатия кнопки на клавиатуре).
HC>Возникает вопрос... даже два А что, если нехороший человек пошлет на сервер что он уже пять минут как нажал "вперёд" и держит — он получить возможность телепортироваться? И как быть серверу, если он получает команду из прошлого — при попытке рассчитать время назад возникает куча проблем, или хранить всю историю команд и пересчитывать весь мир/локацию в таком случае?
HC>Когда сервер посылает клиенту время и состояние тут все понятно — ну подумаешь дернется герой, или упадет вораг замертво секундой позже, чем должен — это практически у всех так...
HC>Вобщем у меня возникло ощущение, что я чегото не понимаю
Пять минут ??
любая нормальная онлайновая реалтаймовая игра ( аля ВоВ и т.д. ) уже бы давно клиента отключила по тайм-ауту. вы попробуйте выдергнуть сетевой кабель во время игры... на 20 секунд ... потом вставьте назад -- таймаут обеспечен.
А что, если нехороший человек пошлет на сервер что он уже пять минут как нажал "вперёд" и держит — он получить возможность телепортироваться? И как быть серверу, если он получает команду из прошлого — при попытке рассчитать время назад возникает куча проблем, или хранить всю историю команд и пересчитывать весь мир/локацию в таком случае?
