Какая архитектура лучше всего подходит для нескольких игровых серверов, которым необходимо взаимодействовать друг с другом?

Question

Игра представляет собой стратегическую игру с низким уровнем графики (SVG).Каждый сервер представляет собой Игровой Домен со своими игроками.Все серверы должны иметь возможность общаться друг с другом, так как игроки могут перемещаться (в игре) с домена на домен / отправлять "дипломатических посланников" и т.д..

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

Мы находимся только в начале пути.Какие существуют платформы, на которые нам следует обратить внимание, чтобы помочь нам создать такой мир?

Answer 1

XMPP, ранее известный как Jabber, может быть хорошим местом для начала.

Answer 2

Во многом это зависит от того, каким объемом данных вы хотите поделиться между серверами.Вы хотите, чтобы каждый сервер обрабатывал свой собственный домен, но как насчет базы данных учетных записей, данных о том, кому какая информация принадлежит, топографии доменов, будут ли эти данные центральными и / или распределенными и как вы поддерживаете их синхронизацию?Таким образом, помимо работы игры, существует еще один набор метаданных, о которых серверы должны сообщать.Что касается игровых данных, вы, вероятно, будете передавать события, объекты данных и информацию о владении данными и контроле над ними.Вдобавок ко всему, должны быть некоторые метаданные внутриигровых часов, чтобы синхронизировать время доменов.

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

Пример: Один игрок отправляет игровую единицу X из домена A в домен B.Сервер домена A отправляет сообщение с событием на сервер домена B.При обработке очереди событий B получает сообщение и отправляет запросы a в очередь запросов на A для получения данных об устройстве X и разрешения на управление / изменение данных устройства X.Очередь запросов имеет более высокий приоритет и будет обработана раньше других событий в домене A.Домен A отправляет запрошенные данные и токен управления в очередь ответов домена B с наивысшим приоритетом.Тем временем сервер домена B уже обработал 3 других события, не дожидаясь завершения сеанса.

• Примечание: A должен устареть, обновить или удалить данные о блоке X на данном этапе.Если поступает запрос на получение данных из домена C, с этого момента он должен перенаправлять этот запрос на сервер B.
• Примечание: Приведенный выше пример может быть оптимизирован для отправки данных о блоке X непосредственно с соответствующим событием, но я хотел проиллюстрировать это простым примером.

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

Answer 3

Я бы серьезно подумал об Erlang и CouchDB или о внедрении их в Google AppEngine.

Answer 4

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

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

С точки зрения разработки, любой язык / фреймворк, который подходит для разработки веб-приложений, должен работать.Ruby на Rails, Python на Django, многочисленные фреймворки плюс Java или даже Cake w / PHP (ick) подошли бы для разработки.

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

Answer 5

Я думаю, что первый вопрос, на который нужно ответить, заключается в том, работает ли игра в реальном времени или управляется событиями, и является ли клиент браузером или нет.Похоже, что он управляется событиями, но помните, что сервер не может эффективно передавать результаты в обычный HTML-клиент, только в Java-апплет, встроенный Flash-фильм и т.д.Если у вас есть пользовательский клиент, то нет необходимости использовать систему в стиле HTTP на сервере, что означает, что взаимодействие сервер-> сервер и сервер-> клиент может осуществляться таким же образом.

Answer 6

Вам следует поискать статьи "Управление интересами" о p2p-играх, вы столкнетесь с действительно интересными подходами.Google Schoolar представит вам действительно хорошие работы.

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