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

По сути игра представляет собой пошаговую партию между 2мя игроками (а-ля шахматы). Игроки последовательно выполняют ходы, с целью достигнуть определенных условий победы над противником. В распоряжении игрока находится набор игровых объектов, ход заключается в разыгрывании самих объектов и использования различных способностей этих объектов. Визуально игровые объекты выглядят как 2d фигурки или картинки.
При этом должна вестись централизованная статистика игроков, рейтинги и т.д.

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

1.В системе должна использоваться масштабируемая СУБД, позволяющая централизованно хранить и обрабатывать данные, относящиеся к процессу игры: бизнес и графические объекты, аккаунты игроков, вспомогательную информацию (логи, статистику и прочую мишуру).
2. Должна быть возможность хранения графических объектов и на клиентском месте для избегания передачи десятков мегабайт графической информации при каждом подключении (разнообразие графических объектов очень большое - тысячи объектов, представление каждого может весить ~100 килобайт).
3. Игровая часть системы должна быть 3х-звенной, игровые клиенты должны через интернет и обращаться к серверу приложений, который в свою очередь имеет коннект к центральной БД.
4. Клиент игры должен поддерживать 2d графику, звуки и простейшие визуальные эффекты (анимацию), активное использование мыши - в том числе драг-н-дроп.
5. Необходима поддержка сеансов или сессий игры. Т.е. залогинился, поиграл партию, залогаутился (при закрытии клиента).
6. Должен быть предусмотрен некий аналог пинга, т.е. индикатор активности подключения для клиентских мест. Если противник "вывалился в оффлайн" мы должны об этом узнать.
7. Должна присутсвовать возможность отображения активных (подключенных к серверу) игроков. С ними ты можешь и разыграть партию.
8.Основная бизнес-логика должна быть вынесена на сервер приложений. Бизнес-логика должна описывать возможные изменения состояний тех или иных объектов в зависимости от их типов, значений атрибутов, выполняемых игроками действий, а так же отвечать за передачу управления одному или другому игроку. Логика может быть довольно сложная, поэтому предполагается что она будет реализовываться с помощью скриптов.
9. На клиентских местах не должно устанавливаться дополнительное ПО, кроме клиента игры (или в крайнем случае - минимум)
10. Платформа - Windows

Заранее спасибо всем, кто выскажет свое мнение по этому поводу!

AbstractionЧего нет:
а) Требования механизма авторизации. Без него концепция "аккаунта" теряет смысл.
б) Оценки интенсивности обмена информацией между клиентом и сервером. Если это пара сотен байт раз в десять секунд - разговор один, если задержки критичны и интенсивность существенно выше - другой.
в) Требований по защите от читеров, если не считать таковым пункт 3). Предположительно, требуется, помимо прочего, при получении сервером информации об очередном ходе, внимательно проверять её на легальность. Если сабж - игра с неполной информацией, то надо думать над каналами утечки.

а. Требования на авторизацию - класические. Заводится учетная запись, сожержащая логин и пароль. Сервер приложений должен предоставлять удаленную функцию авторизации, т.е. клиент вызывает такую функцию передавая введенные логин и пароль. На сервере приложений при проверки корректности должна создаваться сессия и её идентификатор возвращается клиенту. Все последующие обращения клиента должны содержать этот полученный идентификатор в качестве параметра.
б. На данном этапе интенсивность определяется исключительно количеством подключенных игроков. Если не считать системных (скрытых от пользователя, например - пингование) обращений к серверу, то интенсивность порядка 10-20 обращений в минуту в одной партии (при максимальной интенсивности игры). Это несколько килобайт в минуту. Задержки не критичны в пределах 2-3 секунд.
в. Про читеров пока разговро не идет, как вариант -шифрование трафика. На данном этапе считаем что играют "честные" люди ). Но в принципе да, проверка корректности хода может быть полезна.

ShSergeА насчёт второго - вопрос спорный... . Здесь, имхо, всё должно быть или оговорено или таймер какой-то, ограничивающий время обдумывания, должен быть. Но уж точно, не наличие игрока в онлайне, особенно, если дело касается интернета.

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

Статус онлайна нужен для 2х задач:
1. Чтобы игрок напрасно не ждал хода своего вылетевшего коллеги до окончания таймера. К тому же должно быть автоматическое присуждение победы в случае вылета в оффлайн и невозвращения в течении какого-то времени. Иначе будет практиковаться практика "ливания" проигрышных по ситуации матчей, с надеждой что у противника не хватит терпения дождаться окончания таймера и он сдастся.
2. Для реализации активной очереди игроков. Т.е. ты логинишься к серверу и становишься в очередь на поиграть либо видя список активных игроков выбираешь с кем играть.

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

AbstractionДа речь не о шифровании. Прочитайте эту статью, раздел "Доверчивость в MMORPG".

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

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

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

AbstractionBlackMirrorВ рассматриваемой игре возможностей для обмана очень мало, т.к. все ходы игрока по сути контролируются противником. Плюс "у меня все ходы записаны" ). Это как в шахматах - противника следящего за партией особо не обманешь.
При составлении нового протокола одно из необходимых качеств - вера в человеческую изобретательность.
Для примера: на сервер от клиента пришло сообщение с описанием хода (в результате которого ход должен перейти к оппоненту). В процессе обработки на сервер пришло ещё одно сообщение, от того же клиента, с другим описанием хода. Что будет?
Противник, конечно, поймёт если игра пойдёт не по правилам... но что он сможет сделать? Сдаться?

На самом деле это легко решается логикой сервера. Ходы нумеруются. Если мы получили описание хода N, то все остальные полученные описания этого же хода игнорируются.

AbstractionТогда можно сначала именно требования?


Собственно существенные с моей т.з. требования такие:

1. Общие требования
1а) Игра должна позволять играть через интернет.
1б) Архитектура игры – Клиент – Сервер – СУБД. (Во избежание путаницы с определением скольки это звенка)
1в) Ориентировочная платформа игры – ОС Windows.
1г) Длительность партии должна быть ограничена по суммарному времени ходов для каждого из игроков.
1д) Не должно использоваться дорогостоящих технических решений

2. Требования к данным
2а) Должно использоваться централизованное хранение данных при помощи реляционной СУБД.
2б) В центральной БД должны храниться описания игровых объектов, учетные записи пользователей, статистика и логи матчей.
2в) Описание игровых объектов должно включать в себя - тип или набор типов каждого объекта, его начальные характеристики, изображение. Хранение изображение в центральной БД обусловлено 2мя причинами – удобство при наполнении базы игровыми объектами и возможность клиенту получить недостающие объекты через запрос к серверу в случае необходимости.
2г) База должна поддерживать количество различных игровых объектов порядка 1000-5000 при размер графического представления каждого объекта порядка 50 кб.
2д) Графическое представление всех игровых объектов должно так же храниться на клиенте (во избежание разрастания трафика). При этом поиск и подгрузка нужного в конкретный момент набора объектов на клиенте должна быть сравнима со скоростью подобных операций с использованием СУБД.

3. Требования к серверу
3а) Должен обеспечивать идентификацию и взаимодействие клиентов игры между собой.
3б) Должен поддерживать аутентификацию пользователей (авторизованный доступ).
3в) Должен поддерживать сессии или сеансы работы клиентов.
3г) Обрабатывать порядка 10*(кол-во игроков) запросов от клиентских приложений в минуту.
3д) Должен отклонять запросы от версий клиентов, не соответствующие актуальной для него версии.
3е) Должен предоставлять возможность определения активных (онлайн) подключений. (требование может быть перенесено в раздел клиента в зависимости от реализации).

4. Требования к клиенту
4а) Должен предоставлять графический интерфейс с возможностью отображения 2d графики и простейших визуальных эффектов и анимации.
4б) Должна быть возможность воспроизведения звука.
4в) Должен предоставляться “мышиный” интерфейс, в том числе с поддержкой драг-н-дроп.
4г) Иметь возможность самообновления при обнаружении более новой версии.
4д) Не требовать установки дополнительного ПО.
4е) Обеспечивать скорость отклика (реакции на действия оппонента) не ниже 2-3 секунд.

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

AbstractionТо есть, если в одном случае время 1мс, а в другом 100мс, то всё, не подходит?



Имелось в виду что скорость выборки и поиска объектов на клиенте не должна зависеть от кол-ва объектов, среди которых мы ищем. Хранение объектов в виде обычного набора файлов скорее всего не подойдет.

AbstractionНу да ладно.


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

Немного не понятно, как учесть в такой реализации следующие моменты:
1. Как сервер сможет обрабатывать онлайн статус игрока. Для того, что бы засветить игроку оффлайн-статус, должна произойти обработка некоторого события (отстусвие пакета "есть тут кто?" в течении например минуты с последнего получения). Т.е. нужна некая эмуляция события OnTimeOut.
Собственно как раз и рассмативался SOAP-сервер под Apache, но не понятно как он сможет справится с этой ситуацией.

2. С помошью чего наиболее гибко реализовать игровую логику.
Поясню.
Помимо жесткой базовой логики которая "зашивается в код", игровой объект может обладать некоторыми активируемыми способностями типа "Если на поле есть 3 таких же объекта, вы можете уничтожить целевой объект соперника". Описание таких способностей на мой взгляд проще всего делать с помошью некоторого скрипта (хотя бы для того, чтобы при добавлении нового объекта с новыми способностями в игру не надо было бы менять код).

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

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

kosh the bestПоиск по sourceforge и аналогичным сайтам выдает сотни открытого кода mmorpg.
Поиск по amazon дает соответствующие книжки как делать.
В чем проблема?

Хотелось получить сжатые варианты технологический решений с покрытием предложенных требований. Разбираться в открытых кодах сотен мморпг весьма трудоемкая задача. К тому же большинство из них имеет совсем другие требования, и значит другие применяемые технологии.
Скорее всего наиболее близким к текущей задаче можно считать MtG:Online, но она закрытая.