Распределенный игровой сервер C ++, использующий базу данных


11

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

Существуют ли учебники / книги / общие стандарты, которые объясняют, как это сделать наилучшим образом?

Ответы:


8

MMO терминология для «оставаться в одном игровом мире» - это один осколок . EVE online - единственная крупная MMO, которая пытается втиснуть каждого игрока в один осколок.

К счастью для вас, они опубликовали очень информативную статью о том, как они это делают.


(источник: gamasutra.com )

Плохие новости. Вы не можете применять методы онлайн EVE в целом. Их решения абсолютно адаптированы к их конкретному жанру и реализации.
ПРИМЕЧАНИЕ . Для всей супер-необычной сети с одним шардом EVE они используют одну базу данных. Они не смогли разработать масштабируемое согласованное решение для распределенных баз данных в режиме реального времени.

В любом случае чтение того, как они это сделали, должно помочь вам разработать собственное решение. Однако будьте осторожны, вы пытаетесь решить очень сложную проблему.

Вместо того, чтобы распространять ваш игровой сервер, я бы предложил сначала изучить другие ваши возможности.

  • Профилируйте свой игровой сервер.
    • Оптимизируйте код своего сервера, чтобы снизить нагрузку на процессор, если это является проблемой.
    • Оптимизируйте протокол связи между клиентами и сервером, чтобы сократить количество разговоров в сети.
  • Оптимизируйте сервер игры для связи с базой данных.
    • Запустите оптимизатор запросов и внесите необходимые изменения.
    • сократить взаимодействие с БД до минимума
  • Переместите БД на отдельную машину.
    Это часто помогает тонну. Храните БД в той же локальной сети, если это возможно, но это должно помочь вашему игровому серверу быть намного бодрее, когда он работает только на оборудовании сервера.

Как вы определяете "майор"? Королевство ненависти использует один осколок. У всех один и тот же осколок Фармвилля. В Star Trek Online и Champions Online используется модель с одним осколком, но зоны инстанции.

Вместо использования базы данных SQL вы также можете использовать решение noSQL, которое было разработано для кластеризации и разделения, например MongoDB.
Филипп

1
@JoeWreschnig Webgames не в режиме реального времени игры, гораздо проще ... Я не уверен , сколько игроки делают Star Trek Online и Champions Online есть ...
о0.

4

Первым делом вы должны отделить прямой доступ к базе данных от игрового сервера и использовать специальное промежуточное ПО для подготовки данных для вашего сервера (например, XML, JSON). Они будут способны обрабатывать любое количество баз данных и, что более важно, предоставлять вам опции кэширования для конкретных приложений. Кэшируйте все, что можете, и придирайтесь к БД только тогда, когда это необходимо. Делайте большие выборки и редко вместо множества маленьких запросов, чтобы добиться максимальной производительности в вашем сценарии.

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


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

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

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

Данные никогда не дублируются - всегда за один объект отвечает только один сервер, и при необходимости он передает этот объект другому серверу. Объекты - это клиентские соединения, которые также включают в себя объект управления плеером. Тем не менее, это делается с помощью главного сервера и обсуждается между серверами. Таким образом , мы имеем дело с двумя видами данных - inforation базы данных (к которому мой оригинальный пост относится) и игровых объектов, которые создаются во время выполнения и получить розданы в нескольких серверов ммо а. Ни один из них никогда не должен попадать в состояние гонки или дублироваться на уровне приложения.
Конрада К.

3

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

Что касается базы данных: базы данных SQL обычно плохо масштабируются. Они не предназначены для распространения. Но в настоящее время существует довольно новая тенденция баз данных NoSQL, таких как MongoDB или Cassandra, которые были разработаны для распределения по нескольким серверам. Они значительно упрощают наращивание емкости, просто добавляя больше серверов. Так почему же не все крупные игры переключаются на них? Потому что:

  1. Базы данных SQL существуют более 40 лет, а базы данных NoSQL - всего несколько лет. Пока нет большого количества ноу-хау, как использовать их наиболее эффективно, и их развитие быстро продвигается. На рынке существует множество конкурирующих и совершенно несовместимых продуктов, и нет никаких признаков того, какой из них выживет, а какой устареет и будет прекращен через несколько лет. Большинство крупных игроков предпочитают известные недостатки SQL, а не неизвестные риски баз данных NoSQL.
  2. Они работают совсем не так, как базы данных SQL, и требуют переосмысления всей стратегии персистентности. Это может привести к радикальным изменениям всей вашей программной архитектуры.

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


0

Нет. Это невероятно сложная область, которая еще не решена.


Может быть, есть какое-то «шаблонное» (а не «шаблонное оформление C ++») решение? Существует множество MMORPG
Slav

2
Большинство ММО поддерживаются абсолютными бедствиями для баз данных.

В частности, у ММО часто очень разные подходы к сохранению данных, которые часто работают приемлемо для их собственного игрового дизайна, но не для других игровых проектов. Поскольку игровой дизайн является наиболее важной частью, вы не можете адекватно определить стратегию сохранения и распространения данных без нее. (Который может быть истолкован как: «Задайте более конкретный вопрос, сообщив нам, какие у вас есть данные, как часто они меняются и почему вы думаете, что хотите распределить один мир по нескольким серверам».)
Kylotan

0

Я знаю, что это старый, но ....

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

Вам нужно распределить ваше приложение по нескольким серверам. Вам необходимо распределить базу данных по нескольким серверам.

И вам нужно иметь избыточность для обоих.

Для этого есть несколько решений с открытым исходным кодом. Farmville - хороший пример использования MemSQL / Couchbase.


1
Распределение базы данных по нескольким серверам, безусловно, является решенной проблемой. К сожалению, это обычно не является важным требованием для онлайн-игр, которые сводят к минимуму доступ к БД. Напротив, распределение реального игрового процесса между несколькими серверами все еще не решенная проблема.
Kylotan
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.