Какова лучшая архитектура для нескольких игровых серверов, которые должны общаться друг с другом? - PullRequest
1 голос
/ 04 марта 2009

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

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

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

Ответы [ 6 ]

4 голосов
/ 04 марта 2009

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

1 голос
/ 04 марта 2009

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

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

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

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

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

0 голосов
/ 30 мая 2011

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

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

0 голосов
/ 11 марта 2009

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

0 голосов
/ 04 марта 2009

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

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

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

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

0 голосов
/ 04 марта 2009

Я бы серьезно отнесся к Erlang и CouchDB или к их реализации в Google AppEngine.

...