В чем разница между веб-сервером и игровым сервером?

Question

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

Веб-серверы ASP.NET MVC, которые я использовал в прошлой работе, когда клиент отправлял запрос на некоторые данные веб-страницы на сервер, а сервер генерировал HTML, XML или JSON и возвращал ихклиент в пакете HTTP.Этот процесс звучит точно так же для многопользовательской игры, за исключением того, что клиент, вероятно, не будет запрашивать HTML, но имеет смысл запрашивать данные XML или JSON, верно?

Так что мои вопросы ...

1. Может ли игровой сервер быть написан с использованием ASP.NET MVC и работать так же, как веб-сервер с использованием разработанного мной RESTful API?
2. Есть ли лучший подход для запроса и полученияигровые данные, чем использование пакетов HTTP с данными XML или JSON, упакованными в них?Данные, возвращаемые с игрового сервера, будут небольшими.
3. Использование RESTful API для доступа к данным с веб-сервера имеет смысл, но использование RESTful API для запроса игровых данных с игрового сервера не даетсмысл и, на самом деле, звучит так, как будто это может вызвать проблемы с безопасностью, ваши мысли?
4. Наконец, кто-нибудь может порекомендовать какие-нибудь хорошие книги по играм, в которых приведены примеры того, как построить достойный игровой сервер?

   Заранее большое спасибо за помощь!

Answer 1

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

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

Использование REST API не является такой проблемой, так как вы можете использовать стандартные механизмы аутентификации, которые вы уже используете.

Глава 3 книги " Beautiful Architecture " описывает архитектуру проекта Darkstar (теперь RedDwarf ), масштабируемого сервера приложений для онлайн-игр и виртуальных миров. Хотя масштаб RedDwarf НАМНОГО больше, чем вы хотите, в книге описывается, что вам нужно учитывать при создании игрового сервера.

Answer 2

На веб-серверах отсутствует один важный компонент ...

IE. Они без гражданства. Вся веб-платформа (и HTTP-серверы в целом) основана на том, что они не сохраняют состояния, то есть не сохраняют данные при переключении со страницы на страницу.

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

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

2. Да, и нет ... XML / JSON - это в значительной степени способ передачи состояния объекта по Интернету, поскольку он прост и независим от платформы. Поскольку вы, возможно, не пишете свой собственный серверный бэкэнд, я бы посоветовал вам изучить использование XML-RPC , прежде чем вы решите развернуть собственное решение с нуля.

3. Я не уверен, почему вы параноики по поводу безопасности. Если вы реализуете довольно строгую политику доступа для определения приемлемого цикла запроса / ответа, то проблем быть не должно. Как я уже говорил ранее, загляните в XML-RPC. Ключ в том, чтобы пользователь не получил доступ к данным игрового сервера больше, чем ему нужно.

4. Нет, главным образом потому, что я не пишу игры. Хотя у меня есть опыт написания приложений клиент-серверной архитектуры, и это не ракетостроение. Я предлагаю вам взглянуть на сайт Разработка игр Stack Exchange FAQ, который вот-вот выйдет на бета-версию.