Android-игра UDP / TCP?

Question

Я вижу, что этот вопрос задавался ранее, но контекст вокруг вопросов обычно расплывчатый. Я собираюсь создать многопользовательскую игру в реальном времени для Android, в которой существует глобальное состояние, которое должно быть доступно всем клиентам Таким образом, я склонен полагать, что UDP может быть недостаточно. TCP дает надежность, но с внутренними издержками. Тем не менее, поскольку я впервые решаю такую ​​проблему, я ищу отзывы других людей.

Таким образом, (в общем случае) в контексте многопользовательской игры в реальном времени на смартфоне с ОС Android достаточно ли приемлемы накладные расходы, связанные с TCP, чтобы пользовательский интерфейс не оказывал такого неблагоприятного влияния? Также стоит отметить, что TCP-соединение должно быть постоянным. Кроме того, лучше ли будет использовать UDP в сочетании с некоторыми надежными механизмами, разработанными на заказ? Любой вклад действительно поможет мне и будет принята с благодарностью.

большое спасибо действительно

Answer 1

Лучший ответ, вероятно, "попробуй и посмотри".

Я придерживаюсь мнения, что издержки TCP на самом деле не так уж важны для большинства приложений. Размер заголовка составляет порядка 10 байт, и для каждого сообщения необходимо отправлять подтверждающие сообщения туда и обратно.

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

Как правило, проблема между ними сводится к обнаружению ошибок. Если сообщение как-то теряется в сети, как бы вы хотели, чтобы оно обрабатывалось? Если каждое сообщение является довольно важным, то если вы используете UDP, вам просто придется реализовать собственный TCP-подобный протокол поверх него. Вы также можете использовать TCP и позволить сетевому оборудованию помочь вам. Однако, если старые сообщения по истечении времени, необходимого для нескольких повторных попыток (каждое с задержкой в ​​сети), все равно будут мусором с появлением новых обновлений, то TCP для вас является пустой тратой.

Answer 2

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

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

Вот очень хорошая статья о реализации сети Quake3:

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

Просто, но эффективно, мне очень нравится и можеттолько рекомендую этот.

Вот также хорошая тема по теме:

http://www.gamedev.net/topic/319003-mmorpg-and-the-ol-udp-vs-tcp/

В некоторых играх используется UDP (особенно типы FPS и RTS), некоторые TCP,и некоторые из них представляют собой определенную комбинацию из них (например, UDP для отправки игровых данных, TCP для чата и другие вещи).Любой из них может работать.Вам также следует помнить, что пользователям может понравиться работа в сетях 2G, 3G или WiFi, и даже сети WiFi могут быть медленными и перегруженными.Я бы предложил реализовать быстрый прототип и протестировать его в различных сетевых средах.

Answer 3

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

"Опыт реализации Мобильная многопользовательская игра в реальном времени для Беспроводные сети с высокой задержкой »- http://www.hindawi.com/journals/ijcgt/2009/530367/

Answer 4

Вы можете увидеть мою игру (все еще в разработке) - https://market.android.com/details?id=com.reality.weapons.ak47

Используется TCP/IP. Вы можете почувствовать задержку, снимая и наблюдая уведомления в "Battle log".

Пока что я вполне доволен. В городских районах с хорошим покрытием GSM, туда и обратно

"огонь-> путешествие на сервер-> подсчет результатов-> результат поездки назад-> показать уведомление "

обычно занимает менее 200 мс.

Иногда это может быть 2 sec. Но на 99% он меньше 500 ms.