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

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

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

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

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

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

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

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

Вот некоторые риски, связанные с длительными игровыми сессиями:

• DDoS-атаки: Поскольку IP экземпляра игры не меняется при постоянной модели игровой сессии, существует возможность DDos-атак.
• Высокая стоимость облачных вычислений: На поддержание игры, которая всегда или почти всегда активна - даже если игроки в нее не играют, - уходит много дорогостоящих ресурсов.
• Перебои в работе из-за исправлений: Справиться с исправлением может быть непросто, поскольку в игре могут быть активные матчи, которые придется завершить, чтобы внести патч, что приведет к ухудшению впечатления игроков.

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

Вот некоторые соображения по поводу коротких игровых сессий:

• Высокая нагрузка на бэкэнд: Постоянные API-вызовы к бэкенду для облегчения коротких игровых сессий могут стать огромной нагрузкой, поэтому он должен быть устойчивым.
• Тяжело для инфраструктуры: Когда сервер перезапускается между короткими сеансами, вы можете наблюдать резкий рост процессора и оперативной памяти в начале загрузки процессов, что может быть дорогостоящим.
• Требуется надежная сваха: При коротких сессиях вам нужна эффективная сваха, которая будет заниматься подбором билетов для новых сессий, повторных встреч и т. д.
• Качество обслуживания (QOS): Вам понадобится провайдер, который позволит вам отправлять игровому клиенту список IP-адресов в режиме реального времени, чтобы определить регион сервера на основе реальных телеметрических данных, а не физического местоположения.
• Необходимы метрики и данные телеметрии: Если что-то пойдет не так, игрок скорее всего выйдет из игры и начнет новую сессию, чем сообщит об ошибке. Если вы не получаете метрики и телеметрию от этих коротких сессий, вы можете пропустить то, что идет не так в игре.

Вот плюсы и минусы игр, основанных на коротких сессиях:.

Плюсы:

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

Конс:

• Больше обратных вызовов, что означает большую нагрузку при масштабировании
• Стоимость облачных вычислений для перезапуска не является тривиальной в масштабе
• Условия гонки
• Скачки MEM/CPU при запуске
• Больше сложностей при подборе
• Проблемы с производительностью машины могут быть скрыты

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

Вот некоторые соображения по поводу дизайна постоянных игровых сессий:

• Может возникнуть проблема с составлением бюджета: Для обеспечения работы постоянных сессий требуются более надежные внутренние системы, поэтому, чтобы понять, подходит ли вам такой дизайн сессий, необходимо рассчитать стоимость обслуживания в зависимости от количества пользователей.
• Облако может оказаться невыполнимой задачей: Из-за высоких требований к постоянным игровым сессиям облако может оказаться слишком дорогим для вашего проекта.
• Качество сети чрезвычайно важно: Управление задержками и задержками сделает или сломает вашу постоянную игровую сессию для игроков, поэтому раннее и тщательное тестирование сети очень важно для хорошего опыта игроков.
• Установка исправлений - дело сложное и рискованное: Простои, связанные с техническим обслуживанием, никогда не бывают приятными для игроков - даже если они необходимы для улучшения общего впечатления от игры. Общение с населением о времени обслуживания - ключевой момент. Вы также можете рассмотреть возможность одновременного запуска нескольких версий игры и выпуска патчей с течением времени.

Вот плюсы и минусы постоянных сессионных игр:

Плюсы:

• Серверы всегда работают
• Возможна более короткая игровая петля
• Меньше нагрузки на ваш бэкэнд

Конс:

• Более сложная конструкция
• Нестабильность во времени
• Уборка сессий
• Необходим дизайн состояния покоя
• Необходимо, чтобы сваха была осведомлена
• А/Б исправления могут занять больше времени

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

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

Вполне вероятно, что вам придется патчить игру во время запуска. Именно поэтому важно создавать инфраструктуру с возможностью исправления в процессе производства и запуска. Это поможет сделать хаос в день запуска и обновления "на лету" гораздо более быстрым и гладким, а влияние на игроков - ограниченным.

Один из способов решения этой проблемы - одновременный запуск нескольких версий игры. Однако вам также придется убедиться в том, что ваша инфраструктура способна работать с несколькими версиями. Кроме того, вам понадобится "песочница" со всеми различными версиями.

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

Частое тестирование шкалы очень важно, поэтому поиск поставщика, который сможет помочь вам в этом, должен быть одним из основных моментов при выборе услуг.

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

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

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