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

Я хотел бы создать пошаговую многопользовательскую игру для 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. Наконец, может ли кто-нибудь порекомендовать хорошие книги по играм, в которых показаны примеры создания приличного игрового сервера?

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


person BeachRunnerFred    schedule 12.07.2010    source источник
comment
Сервисы WCF, вероятно, будут иметь больше смысла, чем MVC, поскольку на самом деле нет пользовательского интерфейса, а только обмен данными.   -  person Jason    schedule 12.07.2010


Ответы (2)


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

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

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

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

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

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

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

person Evan Plaice    schedule 12.07.2010
comment
спасибо, Эван, этот XML-RPC выглядит действительно хорошо. Вы когда-нибудь пользовались какой-либо из реализаций .NET? если да, то какие-нибудь предложения / рекомендации? - person BeachRunnerFred; 12.07.2010
comment
@BeachRunnerJoe Нет, не видел. Я упомянул XML-RPC только потому, что это хорошо известная архитектура веб-сервисов. Если вы хотите начать с ним работать, у Stack Overflow должно быть много информации от людей, которые его действительно используют. Посмотрите на это, чтобы начать. stackoverflow.com/questions/1348503/how- использовать-xmlrpc-in-c - person Evan Plaice; 12.07.2010

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

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

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

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

person Panagiotis Kanavos    schedule 12.07.2010