Как лучше всего обмениваться GPS-координатами в реальном времени между группой?

Я разрабатываю игру, которая требует, чтобы игроки знали GPS-местоположение других игроков в реальном времени (близко к этому). Может быть ~ 5 секунд задержки и все еще работать хорошо.

Целевой платформой является Android, однако я был заинтересован в том, чтобы включить своих друзей с iPhone, поэтому я надеялся создать это в Интернете с использованием HTML5, Javascript и PHP.

Я пробовал несколько разных подходов, таких как BeaconPush и постоянное чтение/запись в базу данных MySQL, но я не уверен, что это ЛУЧШИЙ и самый эффективный способ сделать это. Я начинаю писать кучу кода, а затем обнаруживаю проблему, пробую другой маршрут и, кажется, продолжаю биться головой.

Игра немного похожа на Pac-Man. Три игрока пытаются «поймать» одного игрока. У одного игрока есть конкретная цель на карте реального мира. Игра берет координаты из базы данных и создает объекты/значки на карте Google. Используя navigator.geolocation.watchPosition, игра проверяет обнаружение попаданий с предметами, и игроки могут подбирать предметы, когда они проходят над ними. Все это прекрасно работает, но карта должна иметь возможность обновлять значки объектов по мере их удаления и обновлять значки с указанием местонахождения других игроков почти в реальном времени. Я не уверен, как наиболее эффективно поделиться GPS-местоположением каждого. Вся игра в основном функционирует и работает, за исключением одного (хотя и гигантского) кусочка головоломки.

Спасибо за любое руководство!


mysql mobile javascript php gps
person SuperChester    schedule 11.03.2011    source источник
comment
Учитывая, что большинство устройств GPS не очень точны (~ 20 м), вам понадобится довольно большое место, чтобы играть в это, не так ли?   -  person NullUserException    schedule 12.03.2011
comment
Даже с WiFi я бы не ожидал синхронизации с устройства в БД на другое устройство за 5 секунд. Звучит как завышенные ожидания для меня. Удачи.   -  person M'vy    schedule 12.03.2011
comment
@NullUserException Да, это общегородская игра; обнаружение столкновений в настоящее время установлено на четверть мили. @M'vy Вот чего я боюсь ... Я надеюсь найти лучший компромисс с учетом технологии и посмотреть, сработает ли он.   -  person SuperChester    schedule 12.03.2011
comment
Не говорите мне, что вам понадобится машина, чтобы играть в это. Что касается технологии, то, что вы используете на стороне сервера, вряд ли будет иметь значение. Попробуйте это с MySQL/PHP и посмотрите, как это работает. Если это слишком медленно, я бы вложил больше средств в сервер с лучшей пропускной способностью / задержкой (или лучшими телефонами / операторами связи).   -  person NullUserException    schedule 12.03.2011
comment
Да, идея состоит в том, чтобы иметь водителя и пассажира/оператора для каждой машины (пары по 2) с телефонами, работающими от машины, и дисплеями, настроенными на то, чтобы они никогда не выключались, чтобы данные GPS всегда отправлялись. В игре есть ограничение скорости с помощью coords.speed. Игра основана на стратегии (установка ловушек, использование проселочных дорог), поэтому безопасность не является проблемой, поскольку безрассудное вождение ничего не даст. Меня больше волнуют цены на бензин и обмен данными GPS!   -  person SuperChester    schedule 12.03.2011

Ответы (1)


arrow_upward
3
arrow_downward

Итак, ваш вопрос заключается в том, как эффективно общаться между СЕРВЕРОМ и несколькими КЛИЕНТАМИ почти в реальном времени. У вас две проблемы, эффективная коммуникация с клиентом. И эффективная связь между «сеансами» на сервере.

HTTP-КЛИЕНТ НА ​​СЕРВЕР

Протокол http не сохраняет состояние. Это означает, что вы отправляете запрос, сервер отвечает, а затем соединение закрывается. Это затрудняет двунаправленное общение или управление событиями, как того требует игра. Вот почему в большинстве сетевых игр используется протокол UDP, который имеет гораздо меньшие накладные расходы на отправку информации. Мы должны использовать TCP/IP, и мы должны использовать протокол HTTP в этом сценарии, так как мы можем сделать это эффективно?

Комета - это ответ. Сервер Comet — это просто «термин», означающий сервер, который держит соединение открытым в течение длительного времени для постоянной отправки данных клиенту. Серверы Comet используют асинхронные потоковые (ajax) соединения, которые позволяют клиенту «узнавать» о поступлении новой информации без необходимости чтения всего ответа. См. также: Долгий опрос PHP Comet Server

СЕССИЯ К СЕССИИ

Когда сервер получает запрос, ему нужно задать вопрос «Где все остальные», и он должен задавать этот вопрос часто и эффективно. Mysql не будет лучшим технологическим решением для чего-то подобного. Вы хотите ОЧЕНЬ ОЧЕНЬ быстро записывать и читать небольшие значения из нескольких процессов (каждого http-клиента)

Зачем отправлять данные через сетевое соединение, декодировать их из строки (sql), а затем ждать, пока сервер декодирует вставку или ответ и т. д. - все это звучит как много дополнительных накладных расходов.

Что вам нужно, так это настоящий IPC (межпроцессное взаимодействие). Этого трудно достичь в PHP, но это можно сделать. Использование общей памяти или даже запись в файл с отображением памяти было бы лучшим решением для обеспечения максимальной скорости чтения и записи обновлений GPS-координат. PHP IPC

Связываем вместе:

Клиент отправляет запрос на сервер и начинает его опрашивать. Сервер считывает общую память, чтобы узнать координаты других. Сервер записывает в открытое соединение строку, содержащую строку JSON, описывающую местонахождение всех игроков. В то же время, пока клиент опрашивает сервер, он также должен отправить запрос на сервер с описанием своего местоположения, и сервер должен записать это значение в разделяемую память. Программа остается в непрерывном цикле, пока клиент не закроет http-соединение.

Смотрите это:

Если общая память не подходит, я бы предложил использовать другую базу данных или что-то более простое, например хранилище ключей и значений (memcache) или даже mongodb. У них обоих будет меньше транзакционных издержек, и они смогут вставлять и опрашивать гораздо быстрее, чем MySQL.

Третий вариант — использование PostgreSQL в качестве механизма IPC. Вы можете использовать события LISTEN для этого, но это становится немного надуманным.

Примечания:

Это решение не очень хорошо масштабируется с PHP. Допустим, вы используете apache и у вас есть 20 воркеров в вашем пуле воркеров. Когда вы достигнете 20 подключений, все процессы php серверов будут поглощены другими запросами, поэтому 21-й запрос будет бесконечно ждать, пока рабочий станет доступным.

Лучшее решение — реализовать сервер Comet/long-polling в чем-то вроде Twisted или любого другого асинхронного фреймворка.

person Ben DeMott    schedule 11.03.2011