А как же отвлечься? на паузу поставить?
Задержки с помощью js и php не избежать (ведь не известно какая скорость передачи, отклика и тп.)

То есть все упирается только в скорость передачи у игроков?

Пытались сделать аэрохоккей. Клиент правда был на flash, сервер на realplexor + php. Всё-равно не особо хорошо это дело летало. Периодически возникали затыки, главным образом, когда между ударами проходило меньше секунды. Не помогал даже просчёт траектории движения шайбы, т.е. только начало, скорость и угол отправлялись. Может flash-программер подкачал - хз, но было неиграбельно - факт.

feniks_iopok
Пошаговые игры - без проблем. Единственное с графикой будет траблы, ты не сможешь использовать модели.
Лучшие игры: bk - бойцовский клуб, и травиан: travian.ru , написаны полностью PHP+JS, ничего более.
Мультиплеерные живые игры - это уже среднее программирование, а не легкое. Зато есть сервер для JS: node.js + socket.io , как раз для передачи данных при помощи соккетов. Я пробовал сделать мини-стрелялку, конечно не доделал, но факт остаётся фактом, задержка была почти нулевая для тех, кто был из одного города.

Интересный момент, поиграй в quake-live, вот там очень интересно сделано. Ни один человек не видит реальную задержку, хотя она на самом деле существует, порой даже высокая.

Всем спасибо за разъяснения)

Враг идеи это латентность.

Реал-тайм игру делать где требуется скорость реакции игрока сложно.

Ну вот пример.

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

Тут требуется, синхронизация с учетом задержек, а так же на стороне клиента чет траектории, скорости полета с компенсацией лага.

Т.е шлем объект из точки X = 0 к точке X = 100 со скоростью +1 x за 0.1 секунду.

Траектория известна, скорость тоже.

Как только мы отправили команду на отправку мячика, сервер начинает обработку на своей стороне в виде инкремента координаты X 0.1 раз в секунду прибавляя +1 к X, после чего сервер отправляет координаты объекта всем клиентам, что положение объекта изменилось на X за текущую 0.1 секунду = 1, а так же к пакету прибавляется таймштамп.

Когда клиент получает пакет с данными он проверяет, что он навычислял пока сервер обрабатывал, и смотрит сходится ли его координата с X и серверная X, при этом он проверяет таймштамп, зачем? Да чтобы убедиться, что погрешность X не более определенной константы например 2.

Т.е X может быть у клиента 2 в данную секунду, а серверный может быть 1.

В данном случае, для выравнивания и синхронизации используется 2 метода (ну по крайнем мере с которыми я знаком).

1. Если есть отставание, то внутренний таймер ускоряется таким образом, чтобы поравняться с серверными данными. Если вычисления быстрее чем серверные ("Лаг будущего"). То таймер замедляется, чтобы предотвратить полную десинхронизацию с сервером относительно константы погрешности. (Почти не заметный лаг ускорения, замедления. (используется часто))
2. Этот метод подходит только для игр типо ланейджев, вовов и других. Смысл в том, что когда объект испытывает десинхронизацию (клиентский X != серверный X). Сервер игнорирует это и клиент тоже, но как только десинхронизация выходит за рамки допустимого, клиент изменяет положение объекта в тот X, который был прислан от сервера. Получается "телепорт лаг". При этом на серверной стороне всегда актуальные данные, у разных клиентов, положение объекта может быть разным, все зависит от латентности получения данных.

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

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

Например игрок 1, латентность 100 мс, игрок 2 латентность 50 мс.

Серверный FPS 100 расчетов координат за 1 секунду. Этого вполне хватит, для отображения плавного перемещения объектов у игрока.

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

В этом случае мы компенсируем общий лаг. Но клиент пытается стремиться к выравниванию подобного десинхрона, за счет замедления или ускорения времени. Еще забыл учесть скорость развертки и прорисовки объектов, некоторые пакеты сервера игнорируются, при снижении FPS. Это значит, что если нам пришло 60 пакетов, то расчеты идут через 1, итого получаем 30, если наш FPS таковой на данный момент.

Обычно серверный FPS скачет, нагрузка как никак. На стороне сервера тоже требуется компенсация серверного лага, с или без учета лага игроков. Это значит, что серверные вычисления могут спешить или отставать. Вычисляется это по такт-рейту, т.е сколько раз в 1 секунду выполняется расчет фрейма. В случае провалов или слишком быстро, требуется выравнивания таймеров, для ограничения, завышенных вычислений, требуется что-то на подобии клиентского адаптивного vsync для монитора ) Но немного иначе, берется диапозон и смотрится за какое время выполнилось столько то вычислений, проверяем на сколько завышены вычисления, и меняем установки внутренних таймеров, (предсказываем, с какой скоростью прогонять таймеры, чтобы получить равномерное вычисление фреймов).Примерно то же самое делается на клиентской стороне, идет предсказание будущего положения объекта, относительно полученных ранее данных от сервера + средний арифметический латенси данных полученных от сервера.

Забыл написать, про адаптивный клиент-серверный фрейм-дроп.

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

Т.е сервер сделал расчеты 100 фреймов, у клиента FPS 30, в этом случае сервер пропустит часть кадров и отправить клиенту лишь 30 фреймов которые между собой равны по количеству дропов. Это уменьшит лаг у клиента, снизит его латентность и ему придется меньше вычислять, все остальное клиент сделает на основе полученных данных, чтобы выравнить положение объекта с предсказанием будущей позиции.

I++
Я не помню где, но видел реализацию, где вычисляется траектория полёта, а потом происходит следующий процес:
- первый этап мячик летит достаточно быстро (чтобы поглотить задержку), а когда догоняет реальное время - начинает лететь с реальной скоростью. Даже при задержке пинга в 100мс. мне кажется, что можно сделать теннис.
Спасибо за разъяснения небольшие, стало более понятно, почему на старых игрушках Близзардов есть опция как low-latency, high-latency.

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

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

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

Для браузерных используется tcp сокет, он не подходит совершенно, нужен именно UDP асинхронный с фиксированным размером пакета. Но там придется проверять очередность получения пакетов, они 100% будут лететь как попало, может придти сначало пакет 2, а не пакет 1, в этом случае нужно будет отбросить пакет 1, ибо содержит уже не актуальные данные.

На стороне клиента я хз как реализовать треды, вывод на экран и вычисления должны быть в разных тредах, иначе будут сплошные фризы.

Есть такая штука как Windows Debugging Tools, очень помогла мне вывести в DPC задержки.

Был очень впечетлен дровами Intel Raid Storage Tech, которые выдавали фризы по 150 ms на шине xD

Бло, они дрова на VB походу писали, а не на асемблере. Винда 8 даже не умеет препятствовать полному фризу, если например на дровах харда или на харде возникла задержка. Для реал-тайм вычислений не годится совершенно, если поставить обычный комп на самолет под windows 8, то фактор смертности от крушений повысится многократно, из-за иногда всплывающих фризов по 150 ms...

Теперь я понимаю почему железо и проги во многих сферах такие древние.

К слову, у меня libevent выдает 250 мегабайт в секунду через сокеты на локальном хосте.

Чтение происходит из ОЗУ в ОЗУ. Это полная х*рня!

У меня нативный Сишный тестер выдает 2300+ метров в сек.