Как оптимизировать поведение тысяч предметов в игре одновременно: опыт создателей Satisfactory

Транспортные ленты против сетевого кода.

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

Это означает, что серверу нужно в реальном времени обрабатывать данные обо всех объектах на заводе. То, с чем пришлось разбираться в Coffee Stain — это уникальная ситуация, с которой вряд ли сталкивались разработчики типового многопользовательского шутера.

В своём блоге на Gamasutra сетевой программист Coffee Stain Гафхар Даваллиус рассказал о том, как в студии оптимизировали сетевой код игры. Мы выбрали главное из материала.

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

Первый — это полная синхронизация карты между всеми игровыми клиентами. В таком случае на компьютерах игроков бы воспроизводилась локальная симуляция. Так поведение всех объектов было бы на 100% предсказуемым — а вся информация бы обновлялась только тогда, когда происходят непредвиденные явления (например, действия игрока).

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

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

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

Поэтому, после выбора модели неткода, перед разработчиками встали следующие задачи.

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

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

На двух примерах Даваллиус объяснил, что сделали в Coffee Stain. В первую очередь разработчики переработали систему инвентаря. В Satisfactory помимо игрока предметы могут хранить контейнеры и некоторые объекты фабрики: информация о них обновляется в реальном времени, так как все ресурсы поступают напрямую в хранилища.

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

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

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

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

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

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

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

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

#satisfactory #опыт #лонг