union platform задержка

[KingMaks]

Делаю мультиплеер для игры. Пока сервер стоял у меня на компе, все было отлично, открывал на два окна, двигался человечком, во втором окне все с точностью повторялось. Только поставил union platform на зареганный VPS, сразу пошли сильные задержки, то есть в одном окне двигаюсь человечком, а во втором он рывками и с опозданиями пытается повторить движения первого. В общем какая речь может вообще идти о мультиплеере, когда сообщения приходят с заметным опозданием? Тем не менее другие игры как то же работают по интернету без задержек, в чем же дело? в дешевом VPS или в union или еще в чем? Можно сократить количество сообщений серверу, но от опоздания в пол секунды или секунду это вообще не спасает. Поделитесь знаниями в этой теме

[caseyryan]

А вы как, просто без каких-либо теоретических знаний начали делать мультиплеер? По этой теме написана просто куча статей и книг. В том числе и о недостатках такого взаимодействия и способах обхода.
Тут дело не в дешевом VPS и не в юнион платформе. Просто чтобы сообщение с компа пользователя дошло на удаленный сервер (который возможно стоит за тысячи километров от него), нужно время. Плюс нужно время на обработку сообщения и на доставку ответа пользователю. Вкратце все эти временные затраты называются пингом. Почитайте про ping corrected motion, и вообще в целом про способы обхода задержек. Но сразу могу сказать, что почти все сводится к тому, что нужно предугадывать что произойдет с персонажем за время, равное пингу. Если первые сообщения передали ему, что нужно идти вперед, то нужно рассчитать сколько он пройдет в том же направлении за время пинга. То есть пока не придет другое сообщение, которое, возможно заставит его поменять направление движения или скорость. А чтобы он не дергался от резких изменений направления, надо как-то "твинить" его движения. В общем, нужно делать систему расчетов. Все это далеко не такая простая задача, как кажется вначале

[KingMaks]

caseyryan, да не просто конечно, смотрел я много информации как это делается и опыт небольшой был только с игрой попроще. Просто как я понял что бы было цивилизованно то логику игры нужно переносить на сервер, тогда получается игрок жмет клавишу, отправляется сообщение на сервер, сервер его обрабатывает и присылает ответ, в общем игрок будет двигаться с заметным запозданием, ну ладно, допустим все это можно слегка предугадать и более менее сделать движения похожими на правду. С другом просто тестировали игру в ВК контра сити. Вроде и не самую жосткую игру взяли для теста, начали проверять (рисовать автоматами восьмерки в воздухе и прочие фигуры) и на втором экране все эти движения с точностью передаются в этот же момент и с точно такой же траекторией, то есть по моему у них все обходится без предсказаний. Были бы предугадывания у фигур бы срезались углы или еще что, а так в движениях можно даже проследить дрожь человеческой руки, вот просто заметно что сейчас ету фигуру человек рисует, а не код предсказывает. (За пинг спасибо, почитаю методы обхода может какие есть)

[Котяра]

Есть ещё такая вещь как UDP, в AIR это DatagramSocket (в обычном flash-player нету)

[caseyryan]

) и на втором экране все эти движения с точностью передаются в этот же момент и с точно такой же траекторией, то есть по моему у них все обходится без предсказаний.

Это просто физически невозможно. Сигнал никак не может идти по проводам быстрее скорости электричества. Плюс всевозможные задержки на перенаправления, разные свичи, маршрутизаторы и все такое. Плюс правильная обработка пакетов, чтобы потерь не было. Предсказания у них ПО-ЛЮБОМУ есть. Ну и саму обработку сообщений надо сделать как можно быстрее. В юнион используется собственный протокол, на основе XML. Не самая быстрая штука. Плюс там очень мудреная система событий, в самом сервере. Они хотели сделать максимум похоже на флеш, но скорость от этого упала. Он не совсем игровой. Изначально Колин Мук и Дерек Клейтон разрабатывали его для сети американского интерактивного телевидения Megaphone. Для ТВ он в самый раз.
Но и для игр тоже можно адаптировать. Просто по возможности делать сообщения как можно короче. Ведь они там тоже обрабатываются по полной программе, пересобираются во внутренние объекты с интерфейсом Map. Посылать сообщения с большими интервалами. Не посылать одинаковые (кстати года три назад я им писал по этому поводу, и они внедрили в сам реактор проверку на дубли, так что самому можно уже не заморачиваться). В общем, способов оптимизации можно найти много, ели покопаться

[KingMaks]

caseyryan, ну ок, спасибо. Буду делать. Просто думал, что не правильно эти все предугадывания, а оказывается мультиплееры это сплошные обманы А есть для флеша что-то более быстрое или более удобное, чем union platform? И еще одно, что длина отправляемого сообщения и в правду так влияет на работоспособность, даже такие мелочи как отправка координат Number или Int?

[caseyryan]

И еще одно, что длина отправляемого сообщения и в правду так влияет на работоспособность,

Конечно влияет. Во-первых больше данных послать нужно, а во-вторых их надо еще и обработать. Чистая логика.

даже такие мелочи как отправка координат Number или Int?

Они там в любом случае отправляются как строка. int короче сам по себе, соответственно и строчное представление его, в большинстве случаев, будет короче

есть для флеша что-то более быстрое или более удобное

Сейчас в моде Node.js. Но на сколько он лучше или хуже, сказать не могу

[Котяра]

Они там в любом случае отправляются как строка.

Это если говорить о юнионе, там вообще xml, который содержит много лишнего. А вообще есть бинарные протоколы: ProtoBuf, AMF, BSON

[caseyryan]

там вообще xml

Там они в CDATA заворачиваются

[Котяра]

А внутри CDATA что? json? Я просто не в теме юниона.