Реалтайм игра, cirrus и передача данных
 

Добрый вечер, появилась мысль сделать для общего развития простую многопользовательскую игрушку, пользователи должны будут отбивать мячик. Для этого решил использовать cirrus и соответственно p2p соединение. Тут у меня появился вопрос, каким образом передавать координаты мяча, т.е. Допустим пользователь отбил мяч и инициировал передачу его координат, соперник отбил мяч, 1ый пользователь прекратил передавать данные мяча и это начал делать соперник. Либо передавать данные о координатах одновременно, чтобы добиться корректировки (не могу просчитать, что получиться но я думаю очч криво) или последний вариант - выбрать главного игрока который будет передавать координаты мяча и передавать от 2го только координаты устр-ва которым он будет его отбивать (тогда возможны погрешности у 2го игрока, так как все расчеты траектории будут происходить у первого). Посоветуйте пожалуйста оптимальный вариант...

Странно вы мыслите. Зачем передавать координаты мяча, если достаточно передавать положение биты.

А мяч пусть преспокойно тем же box2D просчитывается в каждой флешке.

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

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

Кроме того, п2п не всегда и всем доступен, так как все сидят не белыми айпишниками, да кучи файерволов, антивирусов, маршрутиризаторов и прочей сетевой приблуды делают свое дело: с точки зрения событий при программировании все может проходить нормально, но один из игроков может быть просто не доступен. Кроме всего прочего использовать п2п опасно так как доверия клиентам в этом смысле нет(хотя это попса попсовая).

Проблема в том, что из-за отсутствия централизованного сервера лаги будут в любом случае. Минимальных лагов я добился только в одном случае: это один из клиентов является "ведущим", второй только передает координаты своей ракетки. К слову сказать, лаги все равно присутствуют, как их скомпенсировать я знаю. От самого простого и идиотского(увеличить размер ракетки-физический а не визуальный) до учета примерного пинга до второго игрока с целью скомпенсировать этот косяк.

С целью пощупать эту технологию: Вперед.
С целью сделать приложение, не советую. Только как вспомогательная технология и то, чтобы ее функциональность была не критичной.

Нельзя! Box2d недетерминирован!
Горячо советую автору прочитать Синхронные движки RTS и история рассинхронизаций и Как стреляет шутер

Добавлено через 12 минут
Причём комментарии к тем статьям ценны не менее самих статей.

Недетерминированность обычно лезет из неодинаковости вычислений с числами с плавающей запятой (т.е. на разных компьютерах получаются разные результаты). Но на флэш оно всё одинаково (Floating Point Determinism есть просто на халяву). Потому конкретно от Box2d ничего такого не будет. Только всё равно там много чего из-за задержек вылезет.

-De- Никогда не слышал о том что во флеше по умолчанию включена строгая работа FPU. Ну если включено то отлично. Хотя надо будет проверить. И кстати. Box2d может быть детерменированным если шаг обсчета фиксирован, а если выравнивать скорость симуляции при просадках fps то точно разойдётся, причём существенно.

Флэш слишком прост, чтоб там оно было включено/не включено %) Просто есть, как и в яве.
Естесственно, что число шагов должно строго совпадать (как и вообще всё, что относится к общей модели).

Я имею ввиду то, что процессор должен знать об этом, т.к. обычно, по умолчанию, он не строго следует стандарту.

Хм. Я думал использование direct connection без нет групп спасет) Ну да ладно, я думаю победим... Спасибо за советы, буду реализовывать идею с главным игроком, хотя конечно еще немного поэкспериментирую)