Как устроено взаимодействие клиент\сервер в мобильных играх?
Привет, хабрадрузья.
Вопрос тривиальный, но для меня достаточно важный. Делаем с друзьями «в гараже» игру для мобильных устройств, есть описанная концепция, контент, дизайн. Приступаем к реализации клиента и сервера. Будем работать с фрилансером (надеюсь найти человека, который сможет написать сервер и клиент), но чтобы правильно сформулировать задачу, надо хотя бы примерно понимать решение. Парадокс, не правда ли:)
Игра подобна… например, покеру. Человек жмет на своем iOs\Android устройстве «Network Game», и начинается это самое взаимодействие:
→ экран загрузки (в это время клиент посылает на сервер запрос «кто еще ищет»);
→ сервер видит, что найдено пятеро со статусом «поиск» (кстати, где лучше хранить все статусы в sql?) и посылает всем пятерым статус «старт игры»;
→ далее сервер посылает пять ответов клиентам, один из них «ты водишь»;
→ тот который «водит» посылает серверу ответ;
→ сервер посылает опять всем пятерым, что ответил предыдущий и чей сейчас ход.
Ну, плюс фишка с таймером, если кто-то не делает телодвижения в течение 10 секунд, то сервер передает право хода.
Какие технологии применять (один сервер на нем python и mongo) или node и mongo? Какие существуют стандартные практики решения подобных задач?
P.S. Ну, собственно, я должен это написать: если ты светлый разработчик 80-го уровня и у тебя есть: а) желание нести пользу миру (самый высокий уровень развития по Маслоу, ну, вы поняли); б) желание поработать в «гаражной» команде; в) глубокие умения в mobile development — то пиши, мы небольшая команда, живем и работаем в Москве. Мечтаем сделать что-то настолько полезное, чтобы в раю нас поселили по соседству со Стивом и принцессой Дианой. Это первый проект, а в планах обучение буквам и словам для детей (международынй Appstore) и картинные галереи России (а вот с этим проектом хотим попробовать участие в Kickstarter). Если правилами запрещено, уберу.
JMeter в руки и вперёд. Это сильно зависит от «хитрости» самого клиента и логики игры. Некоторым разработчикам приходится делать абсолютно все на сервере т.к. клиенты ломаются моментально после релиза а другие «выкручиваются» по-другому (Eve Online / WoW).
Редис, мемкеч что? Вы хоть понимаете что пишете? Это обычное Client-Server приложение, зачем здесь хитрожопая БД? В таких приложениях все хранится в проге на серваке, а в вопросе не было: «А где нам хранить аккаунты или логи по предыдушим играм(или что у вас там)?», а если бы и был то ответ был бы SQL, но точно не редис.
ЗЫ Писал клиент сервеное приложения для завода по мониторингу статуса на станках, использовал самую обычную Java(даже не JEE ) ну и Objective-C.
Второй плюс можно читать как "/". Хотя насчёт конкуренции, не совсем согласен. Mемкэш non-persistent вообще, a Redis умеет много чего о котором мемкеш и не мечтал (положим, репликация и кластеринг).
В том то и дело что я всегда думал что мемкеш ничем не может удивить редис, разве что скорость немного больше из-за более простой констркуции. Оба key-value, оба данные держат в памяти, но у редиса больше возможностей =) Никогда даже мысли не было что их можно использовать вместе, мне кажется избыточностью, поэтому плюсик второй и смутил.
Я бы советовал вместо модных непроверенных технологий использовать проверенные — java или C++. Если хранить временные данные в памяти (зачем вам SQL??), то нормальный многоядерный/многигабайтный сервер будет держать соединения тыячами.
> С каких пор питон и редис из каментария выше «подные и непроверенные» технологии?
Имелось в виду «модные». На Ява/Си++ просто больше написано, в том числе сложных, масштабных, критичных к быстродействию приложений, а не простых сайтиков на джанго/РоР
Простой способ:
Берем ejabberd, пишем свои расширения и превращаем его в сервер для игры. Так ngmoco ;) делали. Eiminate Pro как раз на ejabberd сделан.
Можно конечно свое, что-то сделать а ля Go + Redis (для онлаин игроков) + PostgreSQL (для авторизации и прочего) или целиков все в Mongo (только надо проверить, что локи мешать не будут).
Средний
Простой
Средний
