logo

Игровые сервера WOW

Сетевые многопользовательские игры на сегодняшний день стали огромной частью программного обеспечение игровой индустрии. Количество игроков, участвующих в мультиплеерных играх ошеломляет. Например, популярная многопользовательские игра WOW имела более миллиона игроков в режиме реального времени. Все больше игр, которые исторически были направлены на игру в режиме одного игрока, теперь включают в себя компоненты сетевых мультиплеерных иг]. Данные игры не только пользуются большим спросом во всем мире, но и служат своего рода полигоном для испытания новейших методов программирования. Именно поэтому, исследования архитектурных решений при
создании мультиплеерных игр является актуальной задачей.

Мир WOW все время развивается и растет. Создается свежий контент, рейды, подземелья и локации. Разработчики продолжают создавать все новые и новые дополнения.
Среди сетевых архитектур, используемых при построении мультиплеерных мультимедийных игр, стоит выделить следующие: клиент-серверная архитектура, одноранговая архитектура и смешанные архитектуры. В данном контексте рассматривается архитектура с точки зрения коммуникаций игроков между собой, но некоторые сетевые решения требуют использования комплексных, то есть сложных архитектур, которые могут включать в себя подсистемы со своими сетевыми архитектурами.
При построении архитектуры мультиплеерных мультимедийных игр важно принимать во внимание проблематику построения сетевых приложений, поскольку архитектура приложений должно способствовать приемлемом игровом опыта игрокам.
Одной из сетевых проблем является латентность — задержка между стимулом и реакцией. Определенное количество латентности всегда неизбежна. Для разработчиков игр уменьшение латентности является одним из способов улучшения опыта игры своих пользователей. Хотя и существует много источников задержек, сетевая латентность является наиболее весомой причиной задержек в многопользовательских играх. Джиттер — это отклонение круговой задержки от ожидаемого значения. Любой из типов сетевых задержек может внести свой вклад в джиттера. Джиттер может вызвать ситуацию, при которой пакеты не приходят в ожидаемом порядке.
Методы, снижающие джиттер, очень похожие на те, что используются для снижения латентности: стоит отправлять как можно меньше пакетов и держать сервер рядом с игроками. Используя геолокационный балансировки клиентов-игроков в клиент-серверной архитектуре, удается предоставлять игрокам, которые находятся рядом, ближайший к ним обоим один сервер. данный подход потребует содержания еще одного сервера, который занимался бы данной задачей.
С точки зрения обеспечения отказоустойчивости систем, таких серверов должно быть несколько. тогда возникает вопрос, на какой именно сервер балансировки игрок должен делать запрос, чтобы получить дальнейшее сервер для игры. В данном случае целесообразно использовать балансировки нагрузки на стороне клиента. Обычно, балансировка нагрузки лучше положить на сервер, но поскольку в данном случае мы балансируем только в смысле выбора балансирующего сервера, то данный подход приемлемым и решает задачу.
Выделим сервер соединения на wow classic boost, который будет держать список известных ему серверов, для входа и балансировки нагрузки. Основная идея заключается в том, чтобы использовать случайные числа на клиенте для того, чтобы выбрать игроку сервер подключения. При этом целесообразно было бы опираться на случайную генерацию на основе времени, поскольку это может привести к случаям, когда многие игроки подключаются в одно и то же время, например, после перезапуска серверов, обновление и тому подобное. Также стоит обновлять списки серверов соединения. Это возможно сделать с помощью сетей доставки контента (CDN), что является очень надежными. Если строить сеть доставки контента только ради этих целей нецелесообразно, то серверы соединение могут держать информацию обо всех подобных серверы и при запросе отправлять клиенту необходимую информацию. Другой вариант — построение одноранговой сети между данными серверами; новые серверы соединение автоматически подключались бы к данной сети. Также стоит добавить логику, которая выбирала
бы другой адрес, когда исходный сервер соединение не отвечает по той или иной причине. Для лучшего опыта игры стоит попробовать все серверы соединения перед тем, как сообщить игроку о проблеме. Также в таком случае полезно было бы использовать прямые IP-адреса на случай, если DNSсерверы НЕ БУДУТ работать.

Вам также будет интересно:

Расскажите друзьям об этой странице!

Оставить комментарий

Яндекс.Метрика