FPS / Таймеры / box2d синхронизация
 

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

Никогда не делал многопользовательских игр с физикой, но вполне ожидаемо. Ошибки погрешности чисел с плавающей точкой у разных процессоров; пересчет физики, зависящий от фпс; рассинхронизация по времени (ну, это если у вас там динамика есть, типа раскачивающейся башни, что-нибудь такое). Да, вполне ожидаемо.
Я бы пожертвовал трафиком пользователей и считал физику только на сервере(если п2п, то пусть один из игроков будет ведущим), посылая клиенту. 100% синхронизации ну очень тяжело добиться на мой взгляд.

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

Ну, если п2п - то задержки будут не такими уж масштабными, и процессоры будут у клиентов греться.
Вообще, мне представляется, что наибольшие рассинхроны вызывает "пересчет физики, зависящий от фпс". Там, в box2d, помнится пытались стабилизировать фпс, ну, не фпс, а пересчет физики по таймеру, не знаю как сказать. В общем, там в событиях таймера чёрти-че понаписано, но все бестолку. Так вот можно попытаться синхронизировать эти события, отключив персчет физики по таймеру у "ведомого" и передавая ему некий "синхроимпульс" в котором бы передавался dt = current_time - t_prev; ведущего, чтобы синхронизировать пересчет физики.

А тут что-то такое заумное сказал =) Не уверен, что меня поймут =)))

И тут остаются проблемы:
Как решать кто ведущий, а кто ведомый?
Можно предположить что, они поочередно менются ролями. Но как быть в случае, если игра не пошаговая?
Получится фигня.
С чего бы это? Задержки будут так же зависить от расстояния между клиентами. Пинг никуда не денешь. Лад

Ну, как правило в р2р играх народ старается подобрать себе партнера поближе, подбирая по минимальному пингу; никому не хочется играть со слоупоками. Так что p2p - это намного лучше, чем клиент-сервер, когда два пользователя, физически находятся, скажем, в Киеве, а пакеты летают на сервер, арендованный в Москве.

А насчет ведущий-ведомый... я сторонник простых решений и "не создавай проблемы, пока ее нет". Пусть кто создает комнату, тот пусть и будет "ведущим", что-нибудь в этом роде.

Сколько я не тестировал, п2п работало хуже, чем клиент-сервер с сокет-соединением.

ага, спасибо,буду пробовать с таймерами разбираться

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

А какие тесты были? Мне вот интересно, да все никак руки не дойдут. В rtmfp , я так понимаю, udp используется, какая там логическая обертка сверху? Нужно ли заботиться о склеивании, потерях, о пакетах, приходящих в неправильном порядке?