Satisfactory с кем поиграть

Обновлено: 28.06.2024

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

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

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

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

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

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

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

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

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

Минимализировать количество отправляемой информации. Это можно сделать, выяснив, какие данные наиболее важны в определённый промежуток времени. К примеру, не нужно отправлять то, что игроки не видят.
Уменьшить частоту отправления информации. Если какой-то объект не меняется часто или его поведение достаточно предсказуемо, данные о нём можно посылать реже.
Сжать и уменьшить количество сведений, необходимых для точного отображения состояния игры.

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

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

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

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

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

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

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

Например — вместо того, чтобы отсылать данные про все 25 предметов на конвейере, мы отправляем лишь сведения о двух новых предметах, которые на нём появились, и об одном, который с него сошёл. То есть, мы используем только 12% всей информации.

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

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

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

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

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

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

Как настроить дозагрузку
контента для тяжёлой игры