Требуется предложение о дизайне модели данных MMORPG, доступе к базе данных и питоне без стека [закрыто]

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

Закрыт 6 лет назад .

Я занимаюсь разработкой игрового сервера для пошаговой казуальной MMORPG.

Механизм низкого уровня (НЕ написанный нами), который обрабатывает сети, многопоточность, таймер, межсерверное взаимодействие, основной игровой цикл и т. д. были написано на C ++. Логика игры высокого уровня была написана на Python.

Мой вопрос касается дизайна модели данных в нашей игре.

Сначала мы просто пытаемся загрузить все данные плеера в ОЗУ и общие данные. кэш-сервер при входе клиента и расписании таймера периодически сбрасывает данные в сервер кеширования данных и сервер кеширования данных будут сохранять данные в базе данных.

Но мы обнаружили, что у этого подхода есть некоторые проблемы.

1) Некоторые данные необходимо сохранять или проверять немедленно, например, прогресс квеста, повышение уровня, получение предметов и денег и т. д.

2) Согласно игровой логике, иногда нам нужно запросить некоторых офлайн-игроков данные.

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

4) Игроку необходимо свободно переключаться между игровыми экземплярами.

Ниже приведены трудности, с которыми мы столкнулись в прошлом:

1) Все операции доступа к данным должны быть асинхронными, чтобы избежать сетевого ввода-вывода. блокирование основного потока игровой логики. Мы должны отправить сообщение в базу данных или кэш-сервер, а затем обработать ответное сообщение данных в функции обратного вызова и продолжить логику игры. Быстро становится больно писать умеренные сложная игровая логика, которая требует нескольких разговоров с БД и игровая логика разбросан по многим функциям обратного вызова, что затрудняет понимание и поддерживать.

2) Сервер специального кэша данных усложняет задачу, нам трудно поддерживать согласованность данных и эффективное обновление / загрузка / обновление данных.

3) Внутриигровой запрос данных неэффективен и громоздок, игровая логика должна запрашивать много информации, такой как инвентарь, информация об элементе, состояние аватара и т. д. транзакционный механизм также необходим, например, если один шаг не прошел всю операция должна быть откатной. Мы стараемся создать хорошую систему моделей данных в ОЗУ, построение множества сложных индексов для облегчения многочисленных запросов информации, добавление поддержка транзакций и т. д. Я быстро понял, что мы создаем в памяти система баз данных, мы изобретаем колесо ...

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

Фактически, доступ к базовой БД также асинхронизирован: один клиентский тасклет отправить запрос другому выделенному рабочему потоку ввода-вывода БД, и тасклет будет заблокирован на канале, но вся основная логика игры не заблокирована, другие тасклет клиента будет запланирован и запущен свободно. Когда данные БД отвечают заблокированный тасклет будет активирован и продолжит выполнение точка '(продолжение?).

С приведенным выше дизайном у меня есть несколько вопросов:

1) Доступ к базе данных будет более частым, чем в предыдущем кэшированном решении. БД может поддерживать частые операции запроса / обновления? Есть ли зрелый кеш такое решение, как redis, memcached, потребуется в ближайшем будущем?

2) Есть ли какие-нибудь серьезные подводные камни в моем дизайне? Можете ли вы, ребята, дать мне немного лучше предложения, особенно по шаблону управления данными в игре.

Мы будем благодарны за любые предложения.

задан texnician 13 June 2013 в 13:46

0 ответов

Другие вопросы по тегам:

python database python-stackless

Требуется предложение о дизайне модели данных MMORPG, доступе к базе данных и питоне без стека [закрыто]

0 ответов

Похожие вопросы: