Что почитать о разработке сервера для браузерной игры?

Question

[Андрей К]

Всем привет!

Задался целью написать браузерную онлайн игру — пошаговая стратегия.
На клиенте HTML5, JS. Насчет сервера пока не определился.
Посоветуйте литературу (статьи, книги) о разработке backend-а для данной задачи.

p.s. какие технологии выбрали бы вы?

Answer 1

[Дамир Абдуллин]

VitaZheltyakov, нет, я просто веду к тому, что роль сервера сводится далеко не к

Роль сервера в браузерных игра простая — принять запрос клиента, направить запрос к базе и вернуть ответ клиенту.

Просто такими рассуждениями любая задача сведется лишь к 1/2/5/50 запросам к БД :) Я, конечно, не знаком со структурой вашей игры, но помимо того, что я написал есть и еще ряд задач. К примеру, на мой взгляд, нет смысла хранить в базе данных максимальный уровень жизни игрока, я храню лишь текущий. А максимальный рассчитываю по различным алгоритмам на основе других характеристик. И таких аспектов еще целая куча. Расчет на клиенте в лучшем случае лишь дублирует функциональность сервера, в ряде случаев это излишне. Выше Fally описал немного структуру своей игры, я делал примерно также. В моем случае клиент запрашивал состояние объекта, например противника в бою, и получал в ответ json с необходимыми характеристиками, на основе которого на клиенте отображалось состояние объекта.

Comments

[Дамир Абдуллин]

Прошу прощения, это ответ на комментарий к предыдущему ответу.

[Виталий Желтяков]

«Просто такими рассуждениями любая задача сведется лишь к 1/2/5/50 запросам к БД»
— Не больше 5 запросов. У пошаговых игр логика простая.

«В моем случае клиент запрашивал состояние объекта, например противника в бою, и получал в ответ json с необходимыми характеристиками, на основе которого на клиенте отображалось состояние объекта»
— Зачем? Почему бы просто перед началом боя не передать все необходимые данные и далее передавать только изменения (если они вообще есть)?

По поводу подходов:
Вижу тут нарастает спор «Тонкий клиент против толстого клиента». Мои аргументы в пользу толстого клиента:
— Удобно производить отладку и разработку, т.к. всё видно на клиенте.
— Меньше запросов.
— Двойная проверка данных.

Жду ваших аргументов в пользу тонкого клиента?

[Дамир Абдуллин]

Мне кажется у нас дебат немного о другом идет :) Я лишь склоняюсь к тому, что игровую механику бессмысленно рассчитывать на клиенте. Это накладно и не безопасно. Давайте рассмотрим простой случай: у нас происходит поединок между 2 игроками. При загрузке страницы мы имеем данные об обоих игроках.
В вашем случае после атаки одного игрока другим мы рассчитываем полученный урон на клиенте, рассчитываем обновленный уровень жизни атакуемого игрока и отправляем его на сервер, чтобы обновить базу данных. По крайней мере я так понял вашу позицию.
Моя позиция такова, что игрок при атаке производит действие, отправляя на сервер запрос (пусть это будет POST /attack/userID). Сервер ищет игрока с ID равным userID, рассчитывает наносимый урон и обновляет параметры обоих игроков, после чего отправляет обратно обновленные данные обоих игроков в формате json. Ну пусть даже он отправляет лишь изменившиеся за запрос данные, сути это не меняет :) Простите, если не так понял ваши доводы.

[Виталий Желтяков]

Вы не правильно меня понимаете.
Допустим у нас поединок между 2 игроками. При загрузке страницы мы имеем данные об обоих игроках. Один игрок атакует другого. На клиенте производится расчёт может ли он это сделать и как он это сделает. Если он это может сделать, то только тогда отправляется запрос. Сервер принимает этот запрос, проверяет может ли игрок выполнить это действие по тем же алгоритмам что и на клиенте (как он это сделает неважно), производит расчёт результата или подтверждает действие, ставит результат в очередь рассылки всем игрокам. И т.д.
Разница в том, что:
— Лишние запросы не делаются;
— Расчётов на сервере, как выполнить действие, нет.

[Дамир Абдуллин]

Тогда я действительно неправильно понял. Собственно у меня работа организованна похожим образом. Например предметы из инвентаря представляют из себя коллекцию backbone.js, для перетаскивания предметов используется draggable/droppable из jquery-ui. При перетаскивании предмета на клиенте проверяются доступные слоты, которые подсвечиваются. После того, как игрок опустит предмет в определенный слот, формируется запрос к сервер. Сервер производит необходимые вычисления и возвращает обновленные характеристики игрока (если необходимо, например мы одели предметв экипировку), либо код ответа 200 (если мы просто переместили предмет в соседний слот инвентаря).

Answer 2

[pomeo]

исходники почитать, под рукой есть github.com/tlhunter/Cobalt-Calibur-3
видел ещё несколько открытых

Answer 3

[Дамир Абдуллин]

Я пишу на tornado, если требуется обработка и вывод данных в реальном времени или на django, если подобной функциональности не требуется. Собственно во втором случае может подойти любой другой язык/фреймворк, на котором возможно создание web приложений.

Answer 4

[Виталий Желтяков]

А что там читать?

Все основные вычисления проходят на клиенте. Роль сервера в браузерных игра простая — принять запрос клиента, направить запрос к базе и вернуть ответ клиенту. Если поймёте как работает клиент, то с сервером проблем не возникнет.
Это утверждение основывается на личном опыте.

По поводу технологий:
— Сейчас пишу пошаговую ММОРПГ на PHP. В будущем планирую отказаться от PHP в сторону Node.js из-за сокетов.

Comments

[Виталий Желтяков]

Просьба минусующим аргументировать своё решение.

[Ренат Абдусаламов]

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

[Виталий Желтяков]

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

[Fally]

Ну допустим когда мы писали игру, у нас был тонкий клиент, который реализовывал лишь отображение пинформации с сервера и интерфейсы к различным действиям. Вся обработка игрологики происходила и валидировалась на сервере, поэтому говорить что клиент основное, тем более в ММОРПГ — это по-меньшей странно

[Виталий Желтяков]

Fally, а ваша ММОРПГ браузерная? Потому что тонкий клиент используют, по моим наблюдениям, только в играх с отдельными приложениями, либо люди делавшие такие игры.

[Дамир Абдуллин]

Делал браузерную одностраничную RPG. Могу с уверенностью сказать, что даже банальное действие «одеть предмет из инвентаря в экипировку» приводит к довольно сложным вычислениям. Требуется:
1. Проверить наличие предмета с указанным ID в инвентаре игрока;
2. Убедиться в возможности использования данного предмета игроком по уровню/профессии;
3. Обновить запись предмета, чтобы сменить контейнер, в котором он размещен;
4. Пересчитать все характеристики игрока на основе характеристик предмета;
5. Отправить игроку обновленные характеристики;
Пятый пункт можно отменить, если у нас на клиенте есть характеристики предмета, в остальном же в любом случае потребуются проверки.

[Виталий Желтяков]

damirazo, Вы называете сложным: 2 запроса к базе, сравнение результатов с сессиоными данными и формирование ответа на основе этого?
Это элементарные действия. На клиенте происходят (должны происходить) точно такие же действия + отрисовка.

[Fally]

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

[Виталий Желтяков]

Весьма странно. Рассинхронизацию можно получить, если клиент действует без подтверждения действия сервера. Подозреваю, что Вы слабо представляете, как действует толстый клиент.

Answer 5

[TXr]

Весьма интересным вариантом есть Smart Fox Server. Много задач там уже решено. Есть API для as3, unity 3d и еще парочки. Также можно расширять функционал комнат джава класами или на питоне. Есть удобная админ панель. Туториалы прилагаются.