Создатели абонентских игр довольно часто сталкиваются с проблемой:

• Применять имеющиеся игровые серверы (на которых, прямо, действует игра) для снабжения функциональности чата
• Применять некоторые компьютера для реализации функциональности чата

В середине – концов, это так как просто чат, так? Небольшие известия передаются от клиента к клиенту/незначительный команде клиентов, вот и все. Так почему просто не добавить незначительно перечня возможностей на работающие серверы? Что может пойти не так?

Впрочем изначально это решение может показаться хорошим, в связи с ним может появиться ряд неприятностей. Ниже мы побеседуем о том, отчего вам нужно разграничивать игровые компьютера и разные социальные фичи (в особенности чат). Это деление позволит нам сделать лучше мощность и масштабируемость игры, также дав нам вероятность легко дополнять свежие «социальные» фичи» и увеличивать их работоспособность в дальнейшем. На сайте dixrix.net вы найдете очень удобный мониторинг игровых серверов.

Микросервисы делают игру не менее управляемой

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

Отделение игровых компьютеров от функциональности чата делает всю инфраструктуру дополнения не менее управляемой и форсирует нас к целиком микросервисно-ориентированной архитектуре. Давайте подробнее взглянем на внутриигровой чат и его «взаимоотношения» с игровыми серверами, обеспечивающими главную работоспособность игры.

При применении «монолитной» архитектуры бригада создателей оказывается урезанной одним стеком технологий – одними и теми же языками программирования, базами данных и окружениями подготовки, при помощи которых опубликована игра. Вложение в команду свежих разработчиков программного обеспечения либо введение свежих технологий реализуется намного легче и стремительней при микросервисном раскладе к архитектуре.

Связи также делаются намного более большими на единых архитектурах. Неисправность одной функции дополнения может привести к нерабочему положению всей игры. Деление игры на микросервисы упрощает изоляцию и фиксы багов в любом автономном модуле.

Главное предназначение игровых компьютеров (с которым они прекрасно управляются, либо, в любом случае, должны прекрасно управляться) заключается в синхронизации и передаче игрокам информации о перемещениях и пребывании игроков в настоящем. Технологии, применяемые на игровых серверах для достижения этих задач, едва ли считаются самым лучшим решением для реализации чата. Поделенные детали, как было замечено, не менее хороши в помощи и свободном масштабировании.

Чертеж, данный выше, объясняет инфраструктуру игры, в которой чат и игровые серверы есть раздельно друг от дружки.

Кроме чата, можно также добавить иные сервисы, имеющиеся раздельно от игровых компьютеров, такие как: активизация, статистика, информация о самых лучших игроках и т.д.

Обеспечение цельнотянутого игрового опыта и действенной работы чата

Мощность игры в общем считается весьма значительным условием для абонентской игры. Тихая скорость работы игры доведет к неизбежной утрате игроков. При применении цельной архитектуры, игра может демонстрировать хорошую мощность на раунде испытания, однако в военных условиях с множеством реальных игроков, раскиданных во всем мире и перебрасывающихся информацией на большой скорости оперативно выражаются лаги и повышение задержек как со стороны чата, так и со стороны, фактически, игры.

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

Предположим, у нас есть игра жанра battle arena – к примеру, LoL либо EVE On-line. Мы намерены снабдить вероятность одновременной игры нескольких сотен игроков в одном игровом мире. Это — тыс известий, представляющих из себя информацию обо всех действиях игроков, пересылаемых через игровые компьютера в живую. Добавим также сюда еще и известия чата. Вполне вероятно, что определенные игроки будут спамить в чат, чтобы специально замедлить скорость работы игрового компьютера (на плечах которого будет находиться как передача информации об игровом мире, так и передача известий чата). Разумеется, вероятно отлавливать подобных игроков и, к примеру, блокировать для них чат, однако для этого все равно понадобится делать особые вычисления на игровых серверах, съедая, так что, часть ресурсов, которые могли бы служить для игры.

Игровой компьютер и так загружен различными расчетами, сопряженными с физикой, графикой и звуком. Прибавление функциональности отправки известий — от игрока к игроку/команде/команде, их парсинга и маршрутизации — это равномерно усложняет инфраструктуру дополнения и ведет к смещению в худшую сторону совместной мощности игры.

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

UDP vs. TCP: Когда необходимы оба, когда довольно одного?

Перейдем к вопросу о избрании между протоколами UDP и TCP для реализации игр. Какой из них лучше выбрать в какой-то обстановки?

Активные абонентские игры (шутеры, MOBA и т.п.) применяют акт UDP для синхронизации перемещений игроков и обновления положения игры. UDP отлично подходит для размена отправки данной информации на весьма повышенной скорости, однако он не обещает качественной доставки известий и их попадания в верном порядке.
Акт TCP обещает доставку известий, что делает его оптимальным избранием для реализации чата. Можно достичь отличной мощности, если сама игра будет применять акт UDP, а разные социальные фичи — акт TCP.

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

Заминка также считается объектом, требующим интереса, в связи с тем что эталоны, устанавливающие дозволенные задержки для перечня возможностей самих абонентских игр и задержки для социальных фич (вроде чата) отличаются. Для абонентской игры (включающей синхронизацию положения игры между игроками и передачу информации об одних игроках иным игрокам) заминка не должна превосходить 20 миллисекунд, тогда как для дополнений чата допускаемая заминка составляет 250 миллисекунд.

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

Расширяемость перечня возможностей чата

Помощь чата как standalone-приложения и выбор для этого обычного индустриального протокола (к примеру, XMPP либо WebSockets) либо при помощи выключенной службы (к примеру, PubNub) открывает вероятность легко дополнять свежие социальные фичи.

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

Заключение

Огромные и небольшие компании, занимающиеся подготовкой игр (включая Pocket Games и EVE On-line) равномерно проходят (либо перешли) на данную архитектуру. Начиная с масштабируемости и повышенной мощности и заканчивая волей внедрения свежих технологий (без потребности закрываться внутри одного стека), превосходства явны: деление чата и игровых компьютеров — маршрут, которым стоит идти.