Как мне спроектировать сервер БД и API для пошаговой многопользовательской настольной игры для iPhone? (думая о nodejs, монго, диване и т. д.)

Question

Я работаю над пошаговой настольной игрой для iPhone и, в конце концов, для Android. Я использую Appcelerator Titanium для его разработки. Мой многопользовательский дизайн похож на слова с друзьями. Пользователи по очереди по очереди, и затем игровое поле противника обновляется соответствующим образом.

Одна из моих потребностей - иметь API обмена сообщениями, который позволяет устройствам двух игроков обновлять друг друга в статусе игрового поля после хода. Подумайте об этом с помощью JSON и сохраните объект JSON на устройстве, которое содержит местоположение всех игровых фигур в любой момент времени. Это объект, который необходимо обновить на локальном устройстве, а затем отправить изменение на устройство противника после того, как сделан ход.

В прошлом я создавал API для мобильных платформ и для этого использовал PHP с MySQL и отправлял JSON туда-обратно между сервером API и мобильным устройством. Работает просто отлично для пользователей с низким уровнем одновременного использования и, как правило, не массовых приложений. Надеюсь, что этот станет массовым;)

Итак, теперь вместо обычного httpd-сервера и тому подобного я начинаю думать о постоянных сокетах и ​​о том, нужны они или нет для моей новой игры. Я также думаю, что было бы разумно отказаться от большого стека LAMP, а для масштабируемости и, возможно, простоты разработки - больше склоняться к потоку данных чего-то вроде Mongo / Couch -> node.js -> iPhone. Честно говоря, это был бы мой первый набег в не-sql db и node.js.

Заинтересован в том, чтобы услышать мнения других людей об этом, больше вариантов / мыслей, и думаю ли я об этом правильно или просто создаю головную боль для себя.

Answer 1

Прежде всего, Nodejs отлично подходит для записи обратных прокси TCP в базы данных NoSQL.Вы можете позволить всем стандартным командам проходить через, но изменять / расширять их API с помощью своего собственного волшебства, например, заставляя MongoDB говорить по HTTP или CouchDB говорить по двоичному протоколу через сокеты.

Когда дело доходит до выбора решения NoSQL для храненияЯ думаю, что Redis и CouchDB являются лучшими кандидатами.

1. CouchDB.Это быстро, надежно и может обрабатывать много одновременных HTTP-соединений.Это, вероятно, лучший вариант, потому что, в отличие от Redis, он может передавать сообщения при изменении документа. API непрерывных изменений делает для вас очень простым иметь монитор приложений каждого игрока на предмет изменений на их доске.Запрос может выглядеть так:curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000Каждый клиент будет получать объект JSON на строку в ответе каждый раз, когда соответствующий документ изменяется.(И пустая новая строка каждые 1000 мс, как своего рода keepalive.)
2. Редис.Он использует простой линейный протокол (такой как MemcacheD ++) для связи через сокет и позволяет хранить списки, наборы, хэши с произвольными - даже двоичными - значениями.Это очень быстро, потому что все происходит в памяти, но сохраняется на диск асинхронно.Но, прежде всего, вы должны оценить его, потому что в нем уже есть PubSub уведомления. Обратите внимание, что вам придется явно публиковать уведомления о перемещениях по каналу, которым делятся игроки, потому что Redis не будет автоматически публиковатькогда ключ / значение изменяются.

Поскольку MongoDB не имеет механизма для наблюдения за изменениями по мере их возникновения или выполнения pubsub, я не считаю это хорошим вариантом, хотя с дополнительнымусилия, которые вы могли бы заставить его работать.

Итак, в заключение вы можете заменить «большой стек LAMP» на один CouchDB, один Redis или любой, расположенный за приложением узла для фильтрации / расширения API.они уже дают то, что подходит для вашей игры.

Удачи!

Answer 2

Я только начал изучать монго, и это не сложно учиться.Такие вещи, как индексы и объяснения, существуют и работают одинаково.Когда дело доходит до архитектуры, вы хотите думать об обратном к SQL;вместо того, чтобы иметь вескую причину для нормализации, вам нужно найти вескую причину для нормализации.Ребята из 10gen (которые делают монго) скажут, что мышление по иерархии - это более естественный способ мышления о вещах, с которым я согласен (предварительно).Искатели также чувствуют своего рода sql-ish, хотя вы все равно будете использовать map-Reduce для запросов агрегации.

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

Node должен быть самым крутым, и я думаю, что это было бы отличным приложением для него.У меня нет опыта работы с ним, но из того, что я прочитал, он отлично подходит для множества небольших запросов и прекрасно масштабируется.Идиоматический javascript достаточно хорошо подходит для всей модели событий, а с v8 он работает просто неприлично быстро.