Реал тайм игра - как реализовать?

[dimarik]

Сообщение от gloomyBrain

"Василий начал идти 3 секунды назад"
Или я брежу? =)

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

[gloomyBrain]

"Да, ты бредишь!" - но как ласково... =)
Согласен, особенно если отсылать сообщения только о начале и конце действия.

ЗЫ
Я бы отключил клиента секунд через 10 при отсутствии pong'а.

ЗЗЫ
А как правильно синхронизировать время? Я бы попинговал раз 10, отправил клиенту системное время с поправкой на лаг, потом через какой-то промежуток времени спросил время у клиента и, если оно не вписывается в лаг - синхронизировал заново.
Но что-то кажется мне, что большую часть таких синхронизаций я бы делал из-за скачков лага, а не из-за расхождений во времени.
Есть какой-то проторенный путь?

[YFred]

Сообщение от gloomyBrain

.
То есть сервер отправляет не "Василий начал идти в 19.00" а "Василий начал идти 3 секунды назад"

Получается если 1игрок начал идти в 19.00, а сообщение с сервера всем остальным о том что он начал идти пришло через 3 секунды. То получается, что картинка на клиентах будет рассинхронизирована? А это не есть гуд, а точнее вообще не гуд. Т.е может возникнуть ситуация в моей игре что 1игрок толкнул другого (визуально), а на самом деле в этой точке второго игрока уже и нет. Или я опять ничего не понял?

Добавлено через 4 минуты
и еще вопрос вдогонку: Какой протокол обмена сообщениями лучше выбрать для риал тайм игры? Разбирался с классом net.Socket, он может передавать данные как в бинарном виде, так и типизированные(строки, числа). В каком виде лучше передавать/принимать данные

[Psycho Tiger]

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

[dimarik]

Сообщение от YFred

Т.е может возникнуть ситуация в моей игре что 1игрок толкнул другого (визуально), а на самом деле в этой точке второго игрока уже и нет.

Видишь, в чем ситуация. Наши клиенты - тонки. Они простые телевизоры, покуда не начинают затевать обратную связь. А основная задача телевизора - максимально точно воспроизвести то, что показывает ретранслятор (сервер). Поэтому в хорошо спланированном сервер-клиенте у тебя не будет приведенной выше ситуации.

Сообщение от YFred

Какой протокол обмена сообщениями лучше выбрать для риал тайм игры? Разбирался с классом net.Socket, он может передавать данные как в бинарном виде, так и типизированные(строки, числа). В каком виде лучше передавать/принимать данные

Протокол лучше выбирать тот, который требует меньше времени на десериализацию и
потребляет меньше трафика. Socket ничего не знает о протоколах более высокого уровня, чем TCP/IP

[gloomyBrain]

получается, что картинка на клиентах будет рассинхронизирована?

Нет. Каждому игроку делается своя поправка на лаг. То есть, когда нам от Васи приходит "я начал идти" - это значит, что Пете мы пришлем "Вася начал идти (пинг Васи + пинг Пети) секунд назад".
Но это не круто, так как лаг может прыгать и "сколько секунд назад" может давать существенную погрешность.
Хотя опять же, если я проверяю пинг каждую секунду, то я могу сделать довольно адекватную поправку на пинг для обоих клиентов...
В общем и целом, синхронизация по времени выглядит более "чистым" решением

он может передавать данные как в бинарном виде, так и типизированные(строки, числа)

Все данные классом Socket передаются в бинарном виде (и строки, и числа). Строки записываются в кодировке UTF-8 (Socket.writeUTF()) или в какой-то еще кодировке (Socket.writeMultiBytes(...))
Числа записываются в байты в порядке LittleEndian (порядок байт по-умолчанию для сети)

а игрок двигается когда от сервера приходит уже ответ

Это кривая реализация. Ибо у себя на экране - да пусть двигается как хочет, а вот когда от сервера придет ответ - тогда быстренько перестроится под него.

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

Проще всего придумать свой протокол

[dimarik]

Сообщение от gloomyBrain

А как правильно синхронизировать время?
Есть какой-то проторенный путь?

Конечно, есть. У специалистов РосАвиаКосмоса. Там такие лаги, что мама не горюй. Но им проще. У них время лага детерминировано. А для нас - переносить часть логики сервера на клиент.

[gloomyBrain]

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

Я требую немедленных объяснений!

У специалистов РосАвиаКосмоса

У них читеров нет =)

[dimarik]

Сообщение от gloomyBrain

Я требую немедленных объяснений!

Пожалуйте )
Pathfinding. Мало того, что Вася побежал в точку Б. Путь до этой точки лежит через вершины графа, да еще кое-где и с весами. Дешевле путь рассчитать на клиенте, а сервер можнет иногда "поддакивать", если согласен с клиентом.

[gloomyBrain]

если согласен с клиентом

Если сервер согласен с клиентом, значит он тоже рассчитывает движение по графу.
По-моему, дешевле не становится