Запаздывание в real-time онлайн игре

xjack · 07.02.2013, 22:41

Всем доброго времени суток. В данный момент занимаюсь созданием real-time игры для соц. сети, где необходимо моментально передавать информацию о перемещении игрока всем его оппонентам. Взаимодействие клиента и сервера осуществляется через сокеты. Сервер написан на C# c использованием асинхронных сокетов.
Сообщение серверу посылается не каждый кадр а в момент нажатия и отжатия игроком клавиши(если клавишу удерживать то сообщение не передается, только в момент клика), далее траектория его движения во флешках оппонентов высчитывается . Вес сообщения минимальный - всего 10 байт.
Когда запускаю сервер и клиентов(2 экземпляра флеш) на локальном компе, то все работает идеально, движения игрока без задержек отображаются в окне оппонента. Но как только запустил серверную часть на удаленном dedicated server(i7 - 4 ядра) все стало намного печальнее. Начало движения, изменение траектории, остановка происходят с весьма заметным опозданием. Самый простой пример - игрок движется по прямой, я отпускаю клавишу - он останавливается, но в окошке оппонента продолжает бежать еще несколько кадров. А когда начинаешь прыгать там вообще вся траектория сбивается.
Вопрос - что я делаю не так? По идее, если на локальном компе все ок, значит скорость работы серверной части нормальная. Объемы передаваемой по сети информации минимальны. Тестирую пока на двух игроках. В чем может быть проблема?

stasuss · 07.02.2013, 23:16

а может все таки дело в пинге до сервера?

xjack · 07.02.2013, 23:23

Пинг где-то от 80 до 115.

-De- · 08.02.2013, 01:35

Это не так мало. 115 - это более 4 кадров при 40фпс. Замерьте время между отправкой сообщения и приходом реакции от сервера (и ещё можно отдельно между отправкой и собственно рендером результата).

iflamberg · 08.02.2013, 14:11

Дык, это. Повсеместно это. А лаг вы, кстати, внутриигровой измеряете или просто пингуете? Потому что это разные вещи. Tcp, к сожелению, накладывает еще и свои ограничения, ну сами должны знать, ожидание устаревшего пакета и т.д. Поэтом и придумывают всякие алголитмы лаг компенсации и сглаживания-интерполяции, но в общем-то не очень-то и помогает. При пинге больше 200 - играть не комфортно, как ни старайся(ну это для шутеров, для рпг типа WoW или rts не так критично).

P.S. И не забудьте отключить алгоритм Нагля в настройках тсп серверного приложения. Хотя черт его знает, помогает ли, но все рекомендуют =)

xjack · 08.02.2013, 16:24

В общем, сегодня поэкспериментировал с измерением времени, так что теперь привожу конкретные данные.
в первом окошке засек время отправки сообщения о нажатии/отпуске клавиши, во втором - время его получения в миллисекундах.
И вот результаты: когда интервалы между сообщениями длительные(например нажал клавишу, несколько секунд удерживаю затем отпускаю), до оппонента они доходят примерно через 80 мс каждое. А теперь самое интересное -когда нажимаю и сразу же отпускаю(обычный клик). Key_down доходит также где-то через 80 мс, а вот key_up через ~300 мс! Вот например результаты последнего замера: Отправка (key_down:0, key_up:52), получение: (key_down:78, key_up:365(!!!)). Похоже дело не только в пинге.

iflamberg · 08.02.2013, 16:43

Э, так дело не покатит. Какие key_down, key_up? У тебя на сервере и на клиенте из-за лагов сети совершенно непредсказуемый промежуток времени между этими событиями произойдет. Изменение координат персонажей надо пересылать. А на клиенте полученные данные интерполировать, иначе персонаж скачками будет перемещаться. Вам бы теорию почитать. Много теории. Гуглите programming multiplayer games, interpolation, lag compensation, predicting, tcp vs upd. Конкретных статей не посоветую.

xjack · 08.02.2013, 17:23

Сделал замер времени на сервере - оказывается он УЖЕ получает данные сообщения с интервалом 280-300 мс, хотя ушли они с интервалом 50 мс. Кто может подсказать в чем проблема такого сдвига по фазе? Может быть есть некая минимальная задержка с которой TCP отправляет сообщения.

iflamberg · 08.02.2013, 17:39

Tcp/ip - протокол с гарантированной доставкой пакетов. Это означает, что 1) пакет не окажется в буфере, пока не сойдутся чексуммы 2) если не отключен алгоритм Нагля, то сервер не будет передавать следующий пакет в буфере отправки, пока не получит от клиента подтверждения о том, что предыдущий пакет доставлен без ошибок(это происходит на уровне протокола, естественно).
Вот и считай. Пинг от тебя до сервера, скажем 100мс. Соответсвенно, от клиента до сервера и к другому клиенту - 200мс. С ожиданием подтверждения о доставке пакета - еще больше. Такая математика.

KumoKairo · 08.02.2013, 17:42

xjack,Скорее всего дело в работе сервера.
Когда мы делали real-time клиент-серверное приложение на Flash + Java(сервер), пинг был 50-80 мс, с учетом того, что сервер, фактически, в соседнем городе.
Может быть проблема с удаленным сервером, может быть что-то еще.

Попробуйте запустить сервер у себя, и проверить с кем-нибудь из собственного горда работу приложения
______
А да, и потом мы все таки отступили от технологии socket server в пользу P2P. Для P2P соединений флеш использует UDP протокол.
Поскольку полноценный socket server в любом случае имеет верхнюю границу онлайна при передаче данных в режиме реального времени..