Многопользовательская игра реального времени - нужен совет

[Gaen]

Допустим есть поле, по нему летают кораблики. Каждый юзер управляет своим корабликом при помощи стрелок: газ, поворот влево, поворот вправо. Вопрос: как организовать обмен данными между клиентом и сервером, чтобы все клиенты были синхронизированы, т.е. каждый видел реальное положение вещей? Дополнительное условие - желательно свести к минимуму количество запросов.

Пока думаю обмениваться сообщениями о нажатии и отпускании клавиш:
1. юзер нажимает кнопку (например газ), его корабль начинает газовать
2. на сервер уходит сообщение о том, что юзер включил газ, плюс его текущие координаты плюс локальный таймстамп (зная разницу во времени с сервером, можно вычислить время нажатия по серверным часам)
3. сервер запоминает что этот кораблик включил газ, шлет подтверждение и рассылает остальным клиентам сообщение о том что этот корабль включил газ (плюс координаты, таймстамп, все дела)
4а. клиент получает подтверждение, все ок, процесс продолжается
4b. клиент не получает подтверждение... тогда получается что юзер будет видеть газующий кораблик, пока клиент не получит новую порцию данных с сервера, в том числе о своих координатах и скорости, и тогда для юзера его кораблик встанет на реальное место и перестанет газовать. Чтобы включить газ, нужно будет отпустить кнопку газа и нажать снова.

Насчет отпускания - алгоритм тот же.

Какие плюсы и минусы у такого подхода? Какие ещё могут быть варианты? Что можно почитать по теме? (Статью Касперски читал, там несколько не то, это скорее обзорная статья по способам организации сети)

[BlooDHounD]

1. зачем он начинает газовать?
2. зачем отправляется что-то кроме вектора направления?
4b. этот пункт лишний.

[iflamberg]

искать по словам:
Dead Reckoning
Latency Hiding for Networked Games
lag compensation
latency compensation

собственно во отличная статья на тему http://www.gamasutra.com/features/19...aronson_01.htm

Замечу так же, что для первой простенькой игрушки можно не заморачиваться и просто передавать вектор или перемещение. Иначе можно запутаться, нагрузить кодом и впасть в прострацию =)

[Gaen]

Спасибо за ответы.

BlooDHounD

1. зачем он начинает газовать?

Чтобы сдвинуться с места

2. зачем отправляется что-то кроме вектора направления?

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

4b. этот пункт лишний.

Ок, если слать только вектора, думаю подтверждения станут не нужны.

iflamberg, спасибо за наводки

[BlooDHounD]

1. что бы сдвинуть с места ждите 4a
2. при это собираетесь слать кучу фигни, которая и так должна быть на сервере?

[AlexStukoff]

Координаты, вектор направления, скорость корабликов хранятся только на сервере!
Сервер принимает:
- нажатие влево/вправо (один бит)
- нажатие/отпускание газа (еще один бит)
Сервер отдает:
- только изменившиеся с последнего вызова координаты и вектора направлений корабликов.

всё. остальное. на. сервере.

в итоге программная часть клиента сведется к 100 строкам кода

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

[iflamberg]

На сервере все данные должны поверяться, чтобы хаков небыло. А то, можно нажатие влево-вправо передавать не 30 раз в секунду, а 100 и разворачиваться в 3 раза быстрее.

Програмная часть не сведется к 100 строчкам кода. Потому что свой "кораблик" и "кораблик" противника должен двигаться независимо от того, опаздывают данные или нет(а в флеш реализован только tcp/ip сокет, это значит что задержки будут от 70мс и выше). Иначе будут двигаться рывками. Для этого и применяются алгоритмы сглаживания.

[Gaen]

AlexStukoff, полностью согласен, кроме 100 строчек

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

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

Короче по дефолту считается, что данные дошли, ибо успешная доставка происходит гораздо чаще, чем потеря сообщения.

Вопрос: какая частота пересчета данных на сервере приемлема для такой игры? 2 раза в секунду - хватит?

[AlexStukoff]

можно передавать и будут передавать Левые сервер реджектит, это нормальная практика. А вот развернутся в 3 раза быстрее уже не удастся, ибо вектор вычисляется на сервере на основании только валидных сигналов разворота.

Что делать с рыками и сглаживанием - это отдельная тема. В самом простом случае - полагаем что кораблик двигается туда, куда он двигался и раньше, пока не поступят новые данные с сервера.
Правда в этом случае возможны неприятные фишки формата "кораблик летит вверх и вдруг- БАЦ -и он уже летит влево да еще и прыгнул пикселов на 10-20"

Но в целом по вопросу борьбы с лагами я склоняюсь перед вашим iflamberg авторитетом

[BlooDHounD]

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