Это правильная архитектура для нашей мобильной игры MMORPG?

Question

В настоящее время я пытаюсь разработать архитектуру новой мобильной игры MMORPG для моей компании. Эта игра похожа на Mafia Wars, iMobsters или RISK. Основная идея состоит в том, чтобы подготовить армию к сражению с противниками (онлайн-пользователями).

Хотя ранее я работал над несколькими мобильными приложениями, но это для меня что-то новое. После большой борьбы я придумал архитектуру, которая проиллюстрирована с помощью высокоуровневой блок-схемы:

Мы решили использовать модель клиент-сервер. На сервере будет централизованная база данных. У каждого клиента будет собственная локальная база данных, которая будет синхронизирована с сервером. Эта база данных действует как кэш для хранения вещей, которые часто не меняются, например, карты, продукты, инвентарь и т. д.

С этой моделью я не знаю, как решить следующие проблемы:

• Как лучше всего синхронизировать серверные и клиентские базы данных?
• Должно ли событие быть сохранено в локальной БД перед его обновлением на сервере? Что если приложение по какой-то причине завершает работу перед сохранением изменений в централизованной БД?
• Будут ли простые HTTP-запросы служить для синхронизации?
• Как узнать, какие пользователи в настоящее время вошли в систему? (Один из способов может заключаться в том, чтобы клиент продолжал отправлять запрос на сервер через каждые x минут, чтобы уведомить его о том, что он активен. В противном случае считается, что клиент неактивен).
• Достаточно ли проверки на стороне клиента? Если нет, как отменить действие, если сервер что-то не проверяет?

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

Дополнительная информация:

Клиентская часть реализована в игровом движке C ++, который называется мармелад. Это кроссплатформенный игровой движок, который означает, что вы можете запускать свое приложение на всех основных мобильных ОС. Мы, конечно, можем добиться многопоточности, что также показано на моей блок-схеме. Я планирую использовать MySQL для сервера и SQLite для клиента.

Это не пошаговая игра, поэтому нет большого взаимодействия с другими игроками. Сервер предоставит список онлайн-игроков, и вы можете сразиться с ними, нажав кнопку боя, и после некоторой анимации будет объявлен результат.

Для синхронизации базы данных у меня есть два решения:

1. Сохранить временную метку для каждой записи. Также следите, когда локальная БД последнее обновление При синхронизации выбирайте только те строки, которые иметь большую метку времени и отправить в локальную базу данных. Сохранить флаг isDeleted для удаленных строк, поэтому каждое удаление просто ведет себя как обновление. Но У меня есть серьезные сомнения по поводу производительности, так как для каждого запроса синхронизации мы придется сканировать всю БД и искать обновленные строки.

2. Другим методом может быть ведение журнала каждой вставки или обновления это происходит против пользователя. Когда клиентское приложение запрашивает синхронизацию, перейти к этой таблице и узнать, какие строки какой таблицы были обновлен или вставлен. Как только эти строки успешно перенесены в клиент удалить этот журнал. Но потом я думаю о том, что произойдет, если пользователь использует другое устройство. Согласно таблице журналов все обновления были передан для этого пользователя, но на самом деле это было сделано на другом устройство. Таким образом, мы могли бы также отслеживать устройство. Внедрение эта техника занимает больше времени, но не уверенна выполняет первый.

Answer 1

Я действительно работал над некоторыми из названий, которые вы упомянули. Я не рекомендую использовать mysql, он неправильно масштабируется, даже если вы осколок. Если вы это сделаете, вы потеряете любые преимущества, которые вы можете иметь при использовании реляционной базы данных. Вы, вероятно, лучше использовать базу данных без SQL. Его быстрее разрабатывать, легко масштабировать и просто изменять структуру документа, которая дается для игры. Если ваши игровые данные просты, вы можете попробовать couchDB, если вам нужны расширенные запросы, вероятно, вам лучше использовать MongoDB. Позаботьтесь о безопасности на старте. Они наверняка попытаются взломать игру, и если у вас будет выпущено несколько клиентов, сложно сделать изменения безопасности обратно совместимыми. SSL мало что даст, так как проблема заключается в том, что конечный пользователь не подслушивает. Подписание или шифрование ваших данных затруднит добавление предметов и золота в свои учетные записи. Вы также должны определить свою архитектуру для поддержки нескольких клиентов без использования инструкций if и case. Прочитайте версию клиента и отправьте этого клиента в соответствующую кодовую базу. Имейте режим обслуживания с флагами для обновления, обслуживания и т. Д. Он избавит вас от некоторой слабости, если вам потребуется пересмотреть вашу БД или любые другие изменения, которые могут потребовать простоя. Недостаточно проверок на стороне клиента, особенно если вы используете покупки в приложении. Я согласен с вышеуказанным постом. Сервер должен контролировать игровую логику. Что касается синхронизации БД, лучше всего использовать memcache только для чтения данных. Типичными примерами являются покупаемые предметы, карты, новости и т. Д. Пользовательские данные сложнее, поскольку вы не сможете позволить себе потерять какие-либо измененные данные. Самый простой способ - кешировать пользовательские данные в течение пары часов и каждый раз записывать их напрямую в БД. Если вы используете no-sql, он, вероятно, выдержит высокую нагрузку без необходимости использовать постоянную очередь.

Answer 2

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

• Как сервер может проверить публикуемые данные? Если кто-то взломал ваше приложение, он мог бы изменить код, поэтому всякий раз, когда он размахивает своим мечом (или что бы он ни делал в вашей игре), это всегда является хитом. Делать это в одиночной игре не так уж и сложно, но делать это в MMORPG может испортить опыт для всех остальных. Таким образом, сервер должен проверять каждое обновление данных - или, что еще лучше, сервер должен отвечать за каждое бизнес-правило. Поэтому, когда вы размахиваете своим мечом против оппонента, это должен быть серверный вызов, и сервер возвращает ответ, является ли это ударом, и сколько очков жизни потерял противник.

• А как насчет взаимодействия с другими игроками (поскольку вы говорите, что это MMORP, будет взаимодействие с другими игроками)? Поскольку вы говорите, что обновляете сервер и получаете обновления в фоновом потоке, взаимодействие будет медленным. Когда вы общаетесь с другим персонажем, вы сначала должны подождать, пока фоновый поток синхронизирует данные, но вам также придется подождать в фоновом потоке другого проигрывателя, чтобы синхронизировать данные.

Answer 3

выглядит хорошо.Но из чего сделана сторона клиента?Веб?Можете ли вы использовать потоки для синхронизации обеих БД?Я должен сделать игру так, чтобы она немедленно взаимодействовала с локальной БД, и позволить некоторому фоновому механизму выполнять синхронизацию (что-то вроде снимка).Это заставляет меня задуматься о репликации MySQL.Я думаю, что стоит попробовать, но я никогда не делал.Это также приносит вам ответы на другие вопросы.Но как насчет платы (сколько клиентов связаны друг с другом)?

http://dev.mysql.com/doc/refman/5.0/en/replication.html

Answer 4

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