Как правильно называется принцип равномерного движения при разных FPS

Всем добрый день, кто может подсказать, как правильно называется или может, кто-то уже описывал данный принцип равномерного движения при разных FPS?
Что интересует, при локальной обработке, из-за разных причин FPS может быть разным и если скорость забить константой, то кто-то будет двигаться слишком быстро, а кто-то болтаться как улитка. По этому, как я почитал, используют время прошлого кадра сцены и добавляют это время в зависимость к скорости. И оно таки помогает. Сейчас хочу реализовать взаимодействие с сервером и не совсем понятно, как регулировать эту скорость через сервер? Чтобы реализовать client prediction нужно знать эту скорость заранее на клиенте, чтобы плавно передвигать модель, по этому я так понимаю, что я не могу завязываться на сервер. В общем может кто-то уже имел опыт с подобный? Предполагается движения в 3д мире. А так же возможность изменения скорости движения.

0

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

0

Меня интересует синхронизация скорости перемещения клиента с сервером.
На пример формула расчета скорости:
Видно, что клиент у которого ФПС будет ниже, будет компенсировать это более длинным шагом. Для локальной версии сойдет. Но вот, если координаты клиента (200, 200, 10) у него 200FPS, он пытается пойти вперед(по X), очевидно, что он будет это делать на 1. Значит, не вдаваясь в подробности, у сервера спрашивается может ли клиент походить на (1, 0, 0). Сервер, то не знает какой FPS там и почему клиент пытается походить именно на 1. Можно подменить данные и попросить передвинуть на (200, 0, 0) серверу снова лишь останется проверить и сказать да\нет.
При всем этом, еще если еще учесть изменение скорости, по типу:
Тогда будут постоянно разные скоростя и как серверу контролировать, что клиент прислал правильные данные.

0

Возможно, будет полезно http://habrahabr.ru/post/136878/

1

Хорошая статья Но не дает ответ, что делать с сервером. Можно найти, где хранятся данные ограничения обработки и изменить их увеличив свою скорость.

0

Сообщение от TGrey[WoLf] Но вот, если координаты клиента (200, 200, 10) у него 200FPS, он пытается пойти вперед(по X), очевидно, что он будет это делать на 1.

Нет, клиент не должен принимать решения о скорости. Он просто говорит, в каком направлении он хочет двигаться, а уже сервер решает (с учетом всех маунтов, эффектов и прочего), на какое именно расстояние. Собственно, поэтому от FPS каждого клиента ничего не зависит - количество тактов определяется только сервером, а все остальные подстраиваются под него.

0

Так вот я и не пойму, как сервер должен делать это. Как мне на клиенте реализовать prediction если клиент не знает с какой скоростью ему двигаться.

0

Предположим, что у нас есть персонаж, который бежит со скоростью 2 м/с. Считается, что сервер N (допустим, 100) раз в секунду обновляет состояние мира. Фактически это означает, что каждые 10 мс он должен выдавать клиентам очередное состояние в момент времени t0 + i * 10 мс.

При этом у сервера персонаж движется со скоростью 0.02 м за один тик.

У первого клиента, предположим, FPS = 50. Это значит, что он отрисовывает каждый второй тик сервера, при этом на каждом кадре он перемещает персонажа на 0.04 м вперед (что персонаж имеет скорость 2м/с - он знает).

У второго клиента FPS = 60. Неудобно, т.к. не укладывается целое число тиков, но ничего страшного в этом нет. Просто за один кадр смещаем персонажа на 0.(3) м вперед. Поскольку сервер нам не говорит, что его скорость меняется, то целых 60 кадров мы его так и перемещали, а потом (раз в секунду) запросили у сервера не только скорости, но и координаты всех объектов. Выяснилось, что персонаж отстал на какие-нибудь 0.00031415 м от реального положения (как на сервере) - так переместим его куда надо.

В общем, все скорости задаются в единицах в секунду, а не в единицах в кадрах. И именно к этим величинам клиенты и серверы подгоняют свои фактические перемещения.

0

Так, а как клиент знает, что персонаж имеет скорость 2м\с? Потом клиент, на пример, включает нитро и должен уже перемещаться 10м\с. Потом использует транспорт и скорость 20м\с + нитро. Эта часть должна дублироваться на клиенте, чтобы он знал, как ему двигаться или сервер каким-то образом должен сообщить о скоростях?

0

а нельзя чтобы всё считал только сервер ? результаты вычислений отправляются на клиенты для обновления данных. не надо никакой синхронизации. ведь так проще всего.

0

Сообщение от heymdall а нельзя чтобы всё считал только сервер ? результаты вычислений отправляются на клиенты для обновления данных.

И что, гонять каждый тик дельту ситуации? Для реалтайма жирно будет.

Сообщение от TGrey[WoLf] Эта часть должна дублироваться на клиенте, чтобы он знал, как ему двигаться или сервер каким-то образом должен сообщить о скоростях?

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

0

Ну у меня была идея сделать возможность установки разных скоростей, чтобы на сервере создал нового маунта, на пример, и проставил ему свою скорость и тогда клиент будет на нем перемещаться чуть быстрее, чем кто-то на другом. Но в таком случае получается, что пока на клиент не будет этих данных, то я не смогу нормально двигаться.
Ну и исходя из всего этого, я так понял, что совет в том, чтобы использовать Frame based движение? Хотя все равно я не пойму, какой толк. ФПС то величина плавающая, как раньше приводили пример, что у одног ФПС 50, он будет двигаться со скоростью 0.02. Но через пару сек, он может попасть в локацию, где его ФПС просядет или наоборот увеличится и соответственно скорость нужно уже рассчитывать не от 50 ФПС, а от нового значения. Одна беда заниматься этим геймдевом

0

Сообщение от TGrey[WoLf] Ну у меня была идея сделать возможность установки разных скоростей, чтобы на сервере создал нового маунта, на пример, и проставил ему свою скорость и тогда клиент будет на нем перемещаться чуть быстрее, чем кто-то на другом. Но в таком случае получается, что пока на клиент не будет этих данных, то я не смогу нормально двигаться.

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

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

0

Из статьи, что показали выше, я думаю, буду пробовать метод "Постоянная скорость игры, независящая от переменного FPS". Но из-за отсутствия опыта работы в этой сфере у меня в голове не проявляется картинка, как клиент должен рассчитывать скоростя, как он узнает о них, чтобы потом нормально предсказывать у себя? Может кто-то может псевдокод накидать или таки как-то объяснить это?

0

не могу подсказать на счет отношений клиент-сервер, но могу подсказать про метод "Постоянная скорость игры, независящая от переменного FPS":
1.вычисляешь время выполнения одного кадра в долях секунды
в моём примере(см. прикрепл файл) это переменная GlobalStep в модуле VideoThreadUnit.pas.
для замеров времени выполнения участков кода (время выполнения одного кадра) я использую RDTSC, что и рекомендую. кстати FPS = 1 / GlobalStep; Если FPS измеряется в Герцах (Гц), то соответственно размерность GlobalStep : Гц^-1

2.в формулу расчета перемещения объекта общий вид которой X := X + dX
где X текущая координата объекта, а dX - скорость, т.е. величина изменения координаты объекта в каждом кадре.
так вот в эту формулу вставляется эта самая вычисленная переменная GlobalStep. и формула становится:
X := X + GlobalStep * dX
теперь вне зависимости от FPS объект перемещается по оси X с постоянной скоростью dX , размерность скорости : длина/секунда.
в моем примере эта формула видна в методе TPlaneta.TransformBeforeGlobal в модуле Unit_SolSystemObjects, вот она: Ugol := Ugol + GlobalStep * VAParamSolP[NumPlanet].UgSpeed

только в моем примере изменяется не расстояние, а угол в радианах.
и поэтому у меня в примере планета Юпитер вращается с угловой скоростью 2 радиана в секунду (рад/сек), Меркурий - ПИ рад/сек, Уран - 1 рад/сек ровно и плавно вне зависимости от FPS, которая постоянно скачет, что видно как цифра в левом верхнем углу.

Вложения

SolSystem5.rar (2.88 Мб, 5 просмотров)

0

Для отвязки от фпс достаточно считать логику не с фиксированной дельтой времени, а с вычисляемой. То есть объект при постоянной скорости перемещается не на speed * const_tick, а на speed * время_прошедшее_после_предыдущего_расчёт а.

Небольшой пример по компенсации задержки: путь объект двигался со скоростью v = 3, на текущий момент игрового времени t = 5c он будет в точке 15(дело происходит на прямой). Нам приходят данные, что другой клиент в момент t = 4c добавил ему две единицы скорости, тогда в синхронизированном состоянии объект должен находиться на координате 17. В принципе можно было бы его прямо там и отобразить, но выглядел бы этот скачок некрасиво. Вместо этого мы сводим состояния постепенно, например, к t = 6с. И вот в эту секунду мы показываем игроку такие картинки, будто бы объект двигается со скоростью v = 9(реально в синхронизированном состоянии скорость всё так же v = 7), отыгрывая тем самым разницу.

0

Ребят спасибо за ответы! Но это не много не то) Как двигать и какой метод использовать это уже другой вопрос, мне бы сейчас подошел и метод, где клиент с 15, рывком прыгает на 17
Я в упор не понимаю, как клиент, знает, что ему нужно переместиться на 2...
То есть, как мне сказали, что данные с клиента на сервер не должны уходить, только запросы. То есть получается, что-то вроде того, я на клиенте нажал вперед и после этого отправился пакет типа "Запрос на шаг вперед", сервер ловит его, сервер знает скорость, берет у себя считает может ли клиент туда пойти и отправляет назад "Переходи в 17, скорость 2", я сохраняю эту скорость локально и делаю "предсказание", с учетом этой скорости, когда она изменится и сервер пришлет новую "Переходи в Х, скорость 10", то я перезатру старую и буду "предстказывать" по новой. Но тогда получается, что первый шаг, я должен дождаться ответ от сервера со скоростью, чтобы знать сохранить ее. А потом уже используя, то, что писали вы, дельты времени, расчет времени выполнения и т.п. я смогу(теоретически) делать над известной скоростью, то есть если я уже знаю, что она у меня 2 и у меня например специально ограничен ФПС до 25, то я буду эти 2 разбивать на мелкие куски для 25 кадров.
Тогда, как-то странно получается с первым шагом, раз скорости еще нет, я не могу делать плавное перемещение, выходит клиента должно как-бы дернуть... Ну или тогда присылать скорость в пакете сразу при входе в игру, как только клиент появился в мире...
Вот, я это себе представляю, как-то так. Но я не уверен, что это правильный вариант. Если это верный алгоритм, то для начала я мог бы замутить и без предсказаний, пусть и с рывками, а потом бы уже оптимизировал. Но я не знаю, как этот алгоритм "общения" правильно реализовать.

0

Сообщение от TGrey[WoLf] То есть, как мне сказали, что данные с клиента на сервер не должны уходить, только запросы.

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

Добавлено через 6 минут
Хотя, конечно, можно вообще всё считать на сервере, а клиентам непрерывно отдавать готовые снимки ситуации.
Но при сколько-то большом количестве изменений это приведёт к высокой нагрузке на сеть, что ни есть хорошо.
С другой стороны полная секурность: игрок не сможет вытянуть из клиентской программы излишние данные, если их там не будет вообще.

0

Сообщение от NoMasters Все данные, необходимые для симуляции игрового процесса от и до, за исключением действий игроков у каждого клиента есть ещё до начала партии.

Именно, но как клиент знает об этих данных? Допустим скорость Шага и Бега константная и я могу продублировать ее изначально и на клиенте и на сервере, тогда да, могу начать симуляцию, но что если скорость динамическая, то есть устанавливается скриптом на сервере и может постоянно меняться, тогда клиент никак о ней не может знать, пока ему об этом не скажут(наверно сервер). Вот этот момент мне и не понятен, где клиент берет данные для того, чтобы верно выполнять симуляцию, с учетом, что данные динамические.

0

Что мешает на клиенте выполнить тот же самый скрипт?
Ну а если предсказать изменение невозможно, то да, каждый раз слать. Причём необязательно каждое незначительное изменение. В принципе, если объект будет двигать пару секунд с постоянной скоростью 300 вместо переменной 270..320, игрок этого не заметит, а по получению данных за всё время состояние можно синхронизировать.
Вообще я бы посоветовал начать с чего-нибудь простого(пошаговая игра, например) и накручивать фичи постепенно, а не влезать сразу в дебри по самые уши.

0