Каково различие между веб-сервером и Игровым Сервером?
Я хотел бы создать основанную на повороте, многопользовательскую игру iPhone, которая потребует, чтобы игровой сервер где-нибудь подключил плееры и подал мировые данные состояния. Я пытаюсь понять, как игровой сервер будет работать так, я могу начать разрабатывать и создавать его. Вплоть до сих пор у меня только есть опыт с созданием веб-приложений и так естественно, мой ум хочет разработать игровой сервер для работы подобным способом веб-сервером, но может это?
Веб-серверы MVC ASP.NET, которые я использовал в прошлой работе клиента, отправляющего запрос для некоторых данных веб-страницы к серверу и серверу, генерируют HTML или XML или JSON и возвращают его клиенту в пакете HTTP. Этот процесс звучит точно как то же для многопользовательской игры, кроме клиента, вероятно, не будет запрашивать HTML, но имело бы смысл запрашивать XML или данные JSON, правильно?
Таким образом, мои вопросы...
- Игровой сервер может быть записан с помощью ASP.NET MVC и работа то же как веб-сервер с помощью УСПОКОИТЕЛЬНОГО API, разработанного мной?
- Существует ли лучший подход к запросу и получению игровых данных, чем использование пакетов HTTP с XML или данными JSON, упакованными в них? Данные, возвращаемые из игрового сервера, будут маленькими.
- Используя УСПОКОИТЕЛЬНЫЙ API для доступа к данным из веб-сервера проявляет здравый смысл, но использование УСПОКОИТЕЛЬНОГО API, чтобы запросить игровые данные с игрового сервера не имеет смысла и, на самом деле, кажется, что могло вызвать проблемы безопасности, мысли?
- Наконец, кто-либо может рекомендовать какие-либо хорошие игровые книги, которые показывают примеры того, как создать достойный игровой сервер?
Большое спасибо заранее для Вашей справки!
2 ответа
Веб-серверам не хватает одного важного компонента...
IE. Они не имеют статических данных. Вся платформа веба (и HTTP-серверов в целом) основана на том, что они не имеют статических данных, то есть они не хранят данные, когда вы переходите от страницы к странице.
Существуют способы обойти это ограничение. На стороне клиента: вы можете использовать сессию для хранения данных, пока браузер открыт; или cookies для хранения данных в течение длительного времени. На стороне сервера: базы данных обычно используются для долгосрочного хранения состояния. Итак...
Да, но в зависимости от того, сколько и как долго вы хотите хранить состояние игровой сессии, вы можете обнаружить, что запуск игрового сервера/движка отдельно (а не как веб-сервера) даст вам гораздо больше возможностей для масштабирования/развития в будущем.
Да, и нет... XML/JSON - это практически единственный способ передачи состояния объекта по интернету, потому что он прост и не зависит от платформы. Поскольку вы можете/не можете написать свой собственный серверный бэкенд, я бы предложил вам взглянуть на использование XML-RPC, прежде чем вы рассмотрите возможность создания собственного решения с нуля.
Я не уверен, почему вы параноидально относитесь к безопасности. Если вы внедрите довольно строгую политику доступа для приемлемого цикла запроса/ответа, то проблем быть не должно. Как я уже говорил, посмотрите на XML-RPC. Главное, не давайте пользователю доступ к большему количеству данных игрового сервера, чем ему нужно.
Нет, в основном потому, что я не пишу игры. Хотя у меня есть опыт написания приложений с архитектурой клиент/сервер, и это не ракетная хирургия. Я предлагаю вам присоединиться к сайту Game Development Stack Exchange FAQ, который скоро выйдет в бета-версию.
Основное отличие состоит в том, что веб-сервер генерирует много относительно статического контента, используя (относительно) небольшую информацию о состоянии или вообще ее не используя. Даже когда используется состояние, оно обычно зависит от сеанса или пользователя. Чтение происходит намного чаще, чем запись, поэтому кеширование может помочь увеличить пропускную способность. Вы также можете доверять веб-браузерам передачу некоторых данных о состоянии и файлов cookie (относительно) надежным способом.
Игровой сервер, напротив, большую часть времени обрабатывает обновления от клиентов, сохраняет большое количество глобального состояния (все игры, игроки, состояние статуса) и отправляет обновления статуса клиентам, когда они их запрашивают. Кэширование невозможно, и вы не можете доверять своим клиентам говорить вам время суток - вы должны предположить, что они будут пытаться обмануть любым способом.
Использование REST API не является такой проблемой, поскольку вы можете использовать стандартные механизмы аутентификации, которые вы уже используете.
Глава 3 книги « Красивая архитектура » описывает архитектуру проекта Darkstar (ныне RedDwarf ), масштабируемого сервера приложений для онлайн-игр и виртуальных миров. Хотя масштабы RedDwarf НАМНОГО больше, чем вы хотите, в книге все же описано, что вам нужно решить при создании игрового сервера.