Особенности разработки MMO на Unreal Engine

Меня зовут Максим, я руководитель проекта Will To Live Online, который 5 апреля вышел в раннем доступе в Steam. Если вкратце, это классическая MMORPG в сеттинге постапа и с видом от первого лица.

Сразу хочу отметить, что у нас небольшая команда, и это первый наш игровой проект — всему приходилось учиться на личном опыте. Поэтому мы изрядно «понаступали на грабли», но вынесли множество уроков. Так что, мне кажется, нам есть, чем поделиться. Эта статья носит рекомендательный характер для тех, кто желает заняться разработкой MMORPG на движке Unreal Engine и, возможно, позволит не совершить некоторых ошибок еще на этапе геймдизайна.

Обдумывание проекта «на берегу»

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

Выбор движка

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

И тогда наш выбор пал на Unreal Engine 4 (тогда еще в версии 4.9). Движок оказался очень простым для понимания (по крайней мере того, что нужно для начала работы) и очень гибким в плане возможностей. Помимо прочего, UE4 предлагал «из коробки» множество готовых решений, подходящих к шутерам, что нам и требовалось.

Также отдельно стоит отметить возможности Unreal Engine в плане профилирования и отладки работы сервера и клиента игры. Они поистине отличные! Так, например, с помощью специального приложения Unreal Frontend можно осуществлять профилирование практически всего (кроме, разве что, GPU — для этого есть другая утилита в редакторе), что происходит в игре (как на серверной стороне, так и на клиенте) с очень наглядным отображением информации.

Большой и бесшовный мир? Забудьте!

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

Как известно, выделенный сервер на UE4 «из коробки» имеет ограничение в 64 игрока. Согласитесь, для MMO не подходит. Безусловно, эту настройку можно поменять в файле конфигурации движка. Однако просто увеличение данной настройки ничего не дает. Нужно провести еще огромное количество работы по настройке и оптимизации сетевой части. Конечно, не стоит сбрасывать со счетов опыт Epic Games с Fornite, для которой в движок было введено множество оптимизаций и улучшений. В версии движка 4.19 произведено множество доработок, которые позволяют настроить сервер на одновременную игру 100+ игроков, но все равно многое зависит именно от вас. Так что, если планируете создавать MMORPG, будьте готовы к усердной работе по оптимизации сети и нагрузки на сервер.

Следующей проблемой, с которой вы обязательно столкнетесь, будет ограничение на количество монстров (ИИ). Стоит добавить пару сотен монстров в локацию — и процессорного времени перестанет хватать на поддержание необходимых fps на сервере (обычно — 20-30 кадров в секунду). Проблема кроется в физике. Так как ИИ для перемещения по локации так или иначе использует физическую сцену, количество запросов к ней является корневым фактором производительности.

Путей решения данной проблемы нам видится два:

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

Чтобы минимизировать обращение к физической сцене, можно применять различные механизмы, которые будут заставлять монстров, находящися далеко от всех игроков, «засыпать», переводить их в неактивные режимы перемещения или вовсе удалять за ненадобностью. Таким образом, в тех местах, где в данный момент нет игроков — нет и монстров, либо они проявляют минимальную необходимую для геймплея активность. В своей игре мы активно применяем данный подход, что позволило в некоторых случаях сократить до 50% использования физической сцены без каких-либо заметных для игрока последствий, что также однозначно хорошо сказалось на общей производительности сервера.

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

Для настройки физических свойств объектов в движке имеется ряд возможностей, в том числе — ручное создание коллизии и автоматическое генерирование на основе сетки объекта. Советов здесь можно привести тоже два:

1. Старайтесь по возможности избегать комплексной коллизии на объектах, используйте настройку движка по умолчанию (ProjectDefault). Это позволит в большинстве случаев использовать упрощенную коллизию, но при необходимости делать запрос на комплексную (когда это действительно нужно).
2. Если вам необходимо использовать комплексную коллизию для объекта — используйте ее по LOD’у данного объекта.

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

Не создавайте огромных локаций

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

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

Безусловно, такой подход требует от разработчиков создания дополнительного серверного решения — т.н. «Менеджера зон», который будет управлять переходами игроков между локациями. Идея его проста: каждая небольшая локация работает на собственном выделенном сервере (dedicated server), а перемещение между ними осуществляется через «Менеджер зон», который координирует перемещение клиентов: проверяет возможность перемещения, выдает данные для подключения к нужному выделенному серверу, возможно, даже осуществляет автоматическую балансировку нагрузки и т.д.

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

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

Совет геймдизайнеру

Если вы задумали создавать MMORPG, всегда старайтесь обдумывать дизайн игры с точки зрения максимально возможных нагрузок. Если есть хоть какая-либо возможность того, что игроки, вопреки всем вашим замыслам, соберутся в одном месте и вызовут дисбаланс нагрузки на сервер — они обязательно сделают это! Тщательно планируйте движение игроков по миру по мере продвижения их в игре. Находите особо нагруженные места в игре и старайтесь избавиться от них любыми возможными способами, создавайте больше геймплейных моментов, которые будут распределять игроков по миру. Все это намного проще, чем пытаться потом выжать производительность из перегруженных серверов.