Производительность и оптимизация

[Narayan 915]

На прошлой неделе разработчики Star Citizen выпустили два очень важных выпуска своих шоу - Around the Verse и Reverse the Verse на тему оптимизации игры.

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

Переводы взяты от сюда и от сюда. Приятного просвещения!

 

Around the Verse - производительность и оптимизация

Большая проблема в том, что мы создаем игру о космосе, а это значит, что у нас очень-очень много сущностей (entity). Многие из них имеют весьма сложную логику и постоянные обновления, необходимые для того, чтобы добавлять или проверять таймеры, продвигающие игру вперед. И если их очень много это может быть очень проблематично, когда приходится обновлять каждый кадр. Если у нас есть 5000 объектов, то к следующему кадру должны произойти 5000 обновлений.

С высоты птичьего полета, видеоигра — это воспроизведение симуляции виртуального мира, построенного на обновлении базового цикла, состоящего из нескольких шагов:

Схема цикла

1. Ввод выборки (Sample input). Это когда игра реагирует на ввод внешних данных в начале кадра. Это может быть ввод при помощи мыши, клавиатуры или контроллера, но также это могут быть другие сетевые данные, если игра мультиплеерная.
2. Обновление состояния мира (Update world state). Виртуальный мир имеет состояние, а точнее многие объекты внутри него. Все они имеют значения позиционирования, цвета и т.д. Это состояние может постоянно меняться. Например, искусственный интеллект идет из точки А в точку Б. Каждый его шаг приводит к постоянным вычислениям.
3. Рендер сцены (Render scene). Последний шаг в каждом кадре, объединяющий полученную информацию и преобразующий ее в изображение, позволяя ей проигрываться, а нам видеть симуляцию мира. В этот момент объекты, которые определены как видимые, включаются в отображение на экране.

Мы сосредоточимся на обновлении симуляции и рендере сцены, потому что эти шаги имеют критическое значение для производительности. Не вдаваясь в большое количество подробностей, можно сказать, что каждый из этих шагов требует фиксированное количество операций, математических или логических, необходимых для обновления состояния мира и обновления отображаемого изображения. Если все эти операции укладываются в 1/60 секунды или в 16 миллисекунд, мы будем обновлять цикл 60 раз за секунду, что приравнивается к 60 FPS (кадрам в секунду). Но если обработка операций занимает 50 миллисекунд, то игровая сцена будет обновляться всего 20 раз в секунду, или в 20 FPS. Реальная оптимизация производительности — это поиск путей для уменьшения фиксированного объема операций, чтобы была возможность выполнять их в рамках заданного кадра.

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

Из чего состоит единица ввода

Для этого мы используем условную исполнительную единицу (execution unit), которая выполняет всю обработку, задействованную в обновлении мира. В этой схеме опущен этап ввода данных, потому что он, в основном, не влияет на производительность. В настоящее время, практически каждый компьютер оснащен чипом, разработанным специально для рендера — GPU. Эти два процесса (обновление и рендер) обычно разделены между CPU (центральный процессор) и GPU (графический процессор).

 

Разделение «обязанностей» CPU и GPU

 

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

 

Принцип конвейерной обработки

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

Для Star Citizen мы обычно выбираем лучшую задержку и позволяем GPU осуществлять лаг, отставая на 1 кадр. Такая проблема может происходить несколько раз подряд, когда потребитель быстрее обрабатывает данные, выданные производителем, тогда происходит «голодание» (starvation). В таких случаях один компонент будет всегда медленнее остальных, а игра будет всегда ограничена чем-нибудь одним — CPU или GPU.

 

Возникновение эффекта «голодания»

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

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

Потоки CPU

Во-первых, балансировка. Как мы видим, на примере GPU/CPU, система всегда зависит от наиболее медленного компонента. Для перевода работы центрального процессора на конвейерные рельсы, нужно искать рабочие кластеры, выполняющие схожую логику в одно и то же время. Это само по себе сложно и даже невозможно в динамичной игре, а с увеличением количества потоков и ядер CPU, вы скоро столкнетесь с наслоением одних систем на другие. Нам тогда понадобится либо специальная настройка для каждого потока, что приводит к кошмару в обслуживании, либо второй вариант, который мы и используем, когда операции объединяются в кластеры/пакеты и используют встроенную параллелизацию, что обычно и используется в играх. Например, в игре редко обновляется один персонаж, поэтому мы можем переместить других персонажей на остальные ядра CPU. Так происходит с любым объектом в игре. Эта схема позволяет нам гибко масштабироваться при большом количестве ядер. Процесс изменения всей логики игры продолжается, и мы переносим все больше и больше игровой логики на этот подход, чтобы лучше использовать ядра и потоки процессора, улучшая всю производительность.

Задержка ввода

Корень обсуждения 60 fps в контексте игр, не только в том, как быстро игра обновляет кадры и в каком визуальном качестве это происходит. Это также касается задержки ввода. Вводная задержка обычно измеряется в кадрах.

Как происходит задержка ввода

Каждый кадр должен иметь фиксированное количество операций, независимо от оборудования. Поэтому если нам нужно 3 кадра от ввода пользователем, до того, как произойдет визуализация эффекта, ввод будет иметь трехкратную задержку по 16 миллисекунд, что в сумме дает 48 миллисекунд при работе с 60 fps. Если игра будет работать в 30 fps, что означает продолжительность кадра в 33 миллисекунды, то есть появится задержка в 99 миллисекунд, что практически удваивает время между вводом и визуальным отображением. Это приводит к плохим впечатлениям от игры. Внедрение большей «конвейерности» процесса, лишь увеличивает задержку, поэтому мы пытаемся сохранять независимость от конвейерной обработки при использовании CPU, даже если это увеличивает фреймрейт, поскольку это будет стоить дороже и не исправит проблему вводного лага.

Один из частых вопросов, которым мы задаемся: нацелен ли сервер на фиксированный fps в 30, а клиент в 60 кадров. Как это возможно? Почему они не связаны друг с другом? И причина в том, что мы не работаем с тем, что называется lockstep (шаг в ногу или синхронизация). Это происходит, когда сервер отправляет обновление, а клиент ожидает ее получения, например: «хорошо, этот объект должен быть тут», потом ожидает следующего сообщения и: «теперь этот объект переместится сюда».

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

Уменьшение количества операций может быть достигнуто несколькими способами. Каждый из них используется в зависимости от времени и ситуации. Чаще всего объединяется сразу несколько подходов. Например, действие происходит на большом удалении от игрока, тогда мы должны решить, на каком расстоянии нам нужно отсечь объект, удаленный от игрока и что делать в «серой» области, где объекты едва различимы. 
Возьмем к примеру систему, в которой нам нужно отслеживать 1000 объектов в одном списке. Если вы удалите один из таких объектов, то придется удалять его из каждого списка. Прямой подход заключается в проверке объекта в каждом элементе нашего списка. Как только находим нужный объект, мы перемещаем его. Затем мы копируем каждый последующий объект в слот перед ним, чтобы заполнить образовавшуюся пустоту. Т.е. это всегда требует 1000 операций.

 

Пример не рациональной обработки списков

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

 

Пример рациональной обработки

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

В этой головоломке очень много подвижных частей. В основном, отдел тех. контента и тех. арта сосредотачивается на области работы GPU в этом процессе — на количестве draw call (вызовы отрисовки). У нас есть бюджет в примерно 2500 отрисовок для всех кораблей единовременно находящихся в экране. И корабль может иметь от 500 до 800 draw call при самом высоком разрешении. Так что мы пытаемся оптимизировать это наиболее подходящими способами. У нас для этого есть несколько трюков в запасе. Один из них — LOD (уровни детализации), когда художник создает модель с меньшей детализацией. В таких случаях происходит упрощение геометрии и материалов при удалении от объекта. Это выполняется как вручную, так и при помощи нашего инструмента — Simplygon.

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

Draw call похожи на материю, проходящую сквозь сетку (mesh). Так что один из способов их уменьшения — комбинация нескольких сеток вместе. Этот процесс назван skinning-ом. Когда я работаю, скажем, над посадочными шасси, я могу взять несколько различных частей: поршней, шестеренок и прочих механизмов и объединить их в одну сетку. В результате получится, что вместо 10 отрисовок для 10 различных сеток получится 10 отрисовок для одной сетки. Это приводит к значительной экономии бюджета отрисовок.

Еще один трюк: использование vis area и portal culling. Когда мы находимся вне судна, нам не нужно прорисовывать интерьер. Более того, даже если вы находитесь в одной комнате, вам не нужна отрисовка следующей. Можете сравнить порталы с дверьми — когда они открыты, происходит прорисовка внутреннего пространства комнаты, но когда дверь закрыта, ненужная геометрия отсекается. Мы используем vis area для подключения к дверям, которые имеют анимации и то открываются, то закрываются, тем самым включая и отключая порталы. Возьмем Caterpiller, эти двери объединены и оптимизированы, к ним применяются «порталы». В последнее время, мы заметили, что у нас есть проблемы с порталами, всего около четырех или пяти ошибок с ними связанных. Как только они будут исправлены, все станет работать быстрее и плавнее.

Еще одна вещь, над которой мы сейчас работаем — signed distance fields (генерация изображений с картой расстояний). Над этой технологией работает Крис Рейн. Это другой способ описания объема, путем записи расстояний. Эта технология сохраняет расстояния и мы это используем с волюметрикой, когда воксели обволакивают форму корабля и проецируют полученную локальную сетку на расстоянии. Это позволяет быстро описывать формы в высоком разрешении, благодаря чему мы можем узнать, находитесь ли вы внутри или снаружи корабля, сталкиваетесь ли вы с кораблем и т.д. Технология также позволяет нам использовать новые технологии для визуализации щитов, когда вместо обобщенной формы пузыря используется форма, детально повторяющая корпус корабля.

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

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

С выходом 3.0, у нас появилось не так много изменений, которые мы изначально планировали. Итак, помимо serialized variables (сериализированных переменных), над которыми мы так долго работали, к тому времени как вышел 3.0, мы почти закончили конвертацию большей части игрового кода, который использовал старые Aspect и RMI системы, заменяя их сериализированными переменными, а также remote methods (удаленными методами). Это значит, что у нас появилась возможность оптимизации одного конкретного пути кода. Тогда мы просто оставили устаревшие части как есть, что на самом деле не очень хорошо, но в то же время эти системы уже были слабо задействованы в работе, поэтому проблем не возникло. Серьезное изменение, которого мы достигли с появлением сериализированных переменных — игра теперь определяет, какие объекты изменили свои свойства, чтобы передать информацию об обновлении статуса. Этот процесс был распараллелен, поэтому работу, которую раньше выполнял один лишь главный поток, мы смогли разбить на несколько вспомогательных потоков.

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

Таким образом, bind culling (отсечение) должен будет устранить несоответствия между сервером и клиентом. Это несоответствие вызвано явным расхождением в мощности серверов и клиентов. Идея bind culling в том, что клиенты получают только ту информацию, которая им необходима. Все, что находится на другой планете или в паре сотен километров от игрока, если он не может этого увидеть — не должно его волновать. Клиент просто не должен об этом знать. Это сэкономит вычислительные мощности клиента, отсекая все ненужные объекты. Это то, что мы хотим сделать, однако это не очень просто. Для этого необходим способ контроля обновлений на сервере, чтобы он знал, какие обновления сущностей стоит отправить клиенту. Нам пришлось изменить логику, благодаря которой сетевые объекты могут изменять свой статус активности, переходя в режим отсечения. Но что делать, если вы захотели перелететь к другой планете? Как автоматически подключать и отключать сущности? Для этого пришлось изменить алгоритм спавна сущностей, раньше они появлялись синхронно, т.е. единоразово, затем к объекту подключалась физика, и все то, что ему нужно, после чего он отправлялся в свободное плавание. Поэтому нам пришлось ввести асинхронный спавн объектов, также известный как Object Container Streaming. Благодаря этой технологии сущности подгружаются и выгружаются в фоновом потоке, не вызывая затормаживания работы клиента.

Итак, нам нужна эта технология стриминга, чтобы объединить ее с отсечением ненужной информации. Это действительно то, что я хочу сделать настолько быстро, насколько это возможно, чтобы убедиться, что все на месте и работает, чтобы потом продолжить тестирование и поиск проблем. Возьмем, к примеру, миссию у Майлза Экхарта. Он сидит в баре Левски, а вы находитесь на Олисаре. Для этого вам нужно знать его местоположение, с чем вам помогает маркер, который рендерится в клиенте. С bind culling вам не нужно знать о том, что Майлз находится где-то в мире. Вам нужна только метка. С этим есть несколько проблем, которые нам нужно проверить и понять каким образом их стоит решать. Существует несколько разных способов, но прежде, чем мы это не протестируем, мы не сможем ввести отсечение, потому что это может поломать игровой процесс.

Вероятно, полной отвязки не будет до тех пор, пока у нас не появится стриминг контейнеров. Но для нас важно получить его как можно скорее, чтобы мы могли продвигаться дальше с нашими запланированными задачами. Итак, нам нужны: Bind culling, Object Container Streaming и Serialized variables. Как я уже сказал, у нас пока нет возможности ввести BC, но мы вполне можем ввести SV. По сути, это та же самая дистанционная отбраковка, благодаря которой сервер переводит удаленные объекты в режим сна. Это, как мы полагаем, даст серьезный прирост производительности.

Размер нашей игры не очень оптимизирован в процессе разработки. Вполне понятно, что чем быстрее версия, тем более она сложная и комплексная. Чем сложнее код, тем больше случаев, когда что-то может пойти не так, в результате чего появляются баги. Поэтому всегда приходится искать компромисс между скоростью разработки и производительностью. Если мы бросаем все силы на производительность, то падает скорость добавления новых фич, включая последующие фичи, которые используют еще более комплексную структуру. Еще хуже, если мы начнем оптимизировать весь код, а позже выяснится, что некоторые разработанные части и вовсе не нужны, поскольку фича не выполняет те функции, которые на нее возложены. Есть известная цитата: «Преждевременная оптимизация — корень всего зла». Другими словами, нам нужно видеть общий вид итоговой системы, чтобы понимать и анализировать возможные пути к оптимизации. Но хватит теории, в реальности наша игра уже работает и в нее можно играть, но играть в 15 фпс совсем не весело.

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

Мы используем различные инструменты для анализа производительности. Самый простой из них — классический sampling profiling. Такой профилировщик работает, останавливая CPU через определенные временные интервалы, записывая, что именно обрабатывал процессор в этот момент. Благодаря этому инструменту можно сделать выборку наиболее затратных процессов. Главный его недостаток в том, что он не показывает контекст, в котором производится та или иная операция. Для большей детализации мы используем внутренние инструменты-профайлеры, которые отображают различные аспекты. Эти инструменты очень полезны в некоторых особых ситуациях, но Star Citizen — совсем другой зверь. У нас есть 50 игроков, и запланировано еще больше на одном сервере, который при этом должен проводить симуляцию физики. Это значит, что каждый игрок может влиять на других игроков, замедляя общую работу сервера, что выражается в дерганных перемещениях, раббербендинге и тому подобном. В результате сервер перестает своевременно отправлять сообщения.

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

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

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

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

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

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

Во время разработки никогда не будет того момента, когда мы дойдем до черты, и производительность сразу выйдет на фантастический уровень. Это как правило постепенный процесс, в котором иногда производительность может даже ухудшаться. Необходимо найти баланс, как выстраивать оптимизацию, продолжая при этом разработку. Достичь 60 fps для всех сразу никогда не получится, но при этом надо двигаться вперед. Итак, сейчас мы сфокусированы на тех вещах, которые относятся к системной оптимизации: это bind culling (отвязка), server meshing (смешение серверов), component update scheduler (планировщик обновлений компонентов), и object container streaming. Все эти технологии системные, благодаря которым мы сможем дальше выстраивать игру.

 

 

Reverse the Verse - производительность и оптимизация

(Ответы разработчиков на вопросы игроков)

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

Отвечает Роб Джонсон: Я бы сказал, что «мешать» это небольшое преувеличение. В разработке игр часто наступает момент, когда необходимо выбирать краткосрочные, среднесрочные и долгосрочные решения. В нашей игре мы стремимся сразу выбирать лучшие долгосрочные решения. Это не та игра, где можно срезать путь. У нас всегда идет работа наперед, но когда наступает момент перед релизом очередного патча, появляется необходимость в решениях проблем, которые могут быть неуместны через год или два. Даже если бы мы не делали патчи с некоторой периодичностью, нам все равно понадобились краткосрочные решения. Постоянно идет прототипирование и какие-то моменты могут меняться

 

Вопрос: Какая разница между Serialized Variables Cullling (SVC) из 3.1 и Bind Culling (BC)?

Отвечает Клайв Джонсон: При Bind Culling сущности находящиеся вдалеке от вас, никак не влияют на работу клиента: они не используют память, не нагружают CPU. SV Culling просто отключает получение обновлений от удаленного объекта, но при этом сущность все еще занимает какое-то место в памяти. CPU не участвует в обработке таких сущностей, потому что не получает сетевые обновления.

 

Вопрос: Как давно идет разработка фич, повышающих производительность и исправляющих проблемы, связанные с ней? Эта работа началась с 3.0 или раньше?

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

РД: Да, нам тогда очень повезло (смеется), Клайв начал с обновления сетевого бэкенда, игровой код потребовал замены устаревших API движка. Эта конвертация потребовала нескольких месяцев и обновления нескольких сотен кусков кода, после чего мы убедились, что код обновлен, и работает куда оптимальней, чем раньше. И все это благодаря Клайву, проделавшему очень хорошую работу.

 

Вопрос от Джареда Клайву: Бэкеры постоянно связывают все проблемы производительности с этим загадочным «неткодом». Как сильно тебя это сводит с ума?

 

Ответ: КД: Чрезвычайно бесит.

РД: Да он аж полысел.

КД: Да, я полысел, когда попал в CIG.

РД: Ага, я видел фотку с пруфами, все так.

Джаред: Как мы можем убедить бэкеров, что это не проблемы «неткода»?

КД: Хорошо, конечно, с мультиплеером есть проблемы, это вполне нормально. Некоторые связывают это с тем, что в синглплеерном моде таких проблем нет. Но это не совсем корректно, потому что в одиночной и многопользовательской игре разные уровни взаимодействий. В одиночном режиме другой игрок не заспавнит лишних от 100 до 5000 сущностей, в зависимости от корабля, и не забьет потом грузовой отсек еще большим количеством объектов, как и не полетит воевать с пиратами, что приведет к дополнительному спавну ИИ. С увеличением количества игроков, нагрузка вырастает очень значительно. И это приводит к низкой производительности. Люди называют это «неткодом», это нормально, но это не какой-то специфический код, нет. Это обычный игровой код: физика, графика и прочие модули.

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

КД: Я думаю, что недопонимание возникло из-за того, что некоторое время препятствие в производительности было на стороне сервера, после чего многие стали это препятствие видеть во всем.

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

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

Джаред: пытаюсь вспомнить… кто-то мне сказал, что оригинальная модель Фрилансера имела реально смоделированные заклепки, из-за которых он занимал больше места в памяти, чем Идрис. И это никакой не «неткод», а всего лишь Фрилансер. Именно поэтому мы пришли к тому, что корабли требуют переработки, а не только из-за того, что менялись геймплейные аспекты.

 

Вопрос: Какие улучшения производительности необходимы после 3.4, чтобы появилась возможность реализации перелетов между системами, объединенными джамп-поинтами?

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

 

Вопрос: Какой вид оптимизации вы лично больше всего ждете и почему?

Ответ: РД: Для мня это, конечно, Object Container Streaming. Эта технология позволит поднять производительность в несколько раз. В PU вам понадобится подгружать только видимые игроком области. С этим связано много работы по замене устаревших компонентов, последние 3 или 4 года моей работы связаны переработкой старого кода, поэтому мы просто мечтаем о том дне, когда этот новый прекрасный код будет заменен, и нам не придется больше исправлять проблемы, связанные с тем, что было введено много-много лет назад. Мы просто начнем наслаждаться дальнейшей разработкой.

 

Вопрос: Объясните в двух словах, что значит «Object Container Streaming»?

Ответ: РД: Представьте, что большая часть игрового уровня — это такой здоровый список объектов. Что Cry Engine, что Lumberyard оперируют «сущностями». Это могут быть любые крупные объекты: корабли, станции, планеты — все это контейнеры объектов. Это похоже на данные в XML-формате, которые просто содержат список вещей. И OCS позволяет загружать только видимые объекты из этого списка. Он динамически удаляет и подгружает новые объекты в списках, по мере перемещения игрока в пространстве.

 

Вопрос: Возможны ли все еще битвы флотилий?

Ответ: КД: Да. Одна из вещей, которая стала доступна с 3.0 - серверы с 16 потоками. Существуют серверы с 72 потоками, и чем больше потоков, тем больше параллельных процессов сервер может обрабатывать. С расширением возможностей игрового кода, нам стала доступна расширенная масштабируемость всех процессов, поэтому мы может заполнять потоки так оптимально, как это возможно. Я верю, что когда все системы заработают вместе, у нас есть лучшие инженеры, благодаря которым, мы сможем сделать массовые космические бои реальными.

 

Вопрос: Почему Serialized Variables Cullling (SVC) менее проблематична, чем Bind Culling (BC), если они выполняют схожую работу?

Ответ: КД: Да, они очень похожи, единственное различие — при SVC, сущности сами хранятся у клиента, у BC обязательно сущности создаются у клиента, подключаясь к сети, связываясь друг с другом. Сервер знает, что такие сущности доступны для коммуникации с клиентом. Представим, что вы находитесь в Порте Олисар, мимо пролетает корабль. При подлете, к вашему клиенту загрузится информация, а как только он скроется вдали, информация будет вновь выгружена. Если он вернется, данные опять подгрузятся. И так постоянно. Причина, по которой мы перенесли BC с 3.1 в том, что мы не хотим портить игровой процесс в случае, если не успеем доработать эту фичу. Мы добавили ее в график изначально, потому что хотели посмотреть, что у нас получится. В процессе разработки, мы поняли, что выпускать BC прямо сейчас — авантюра, что это может привести как улучшению, так и усугублению ситуации. Поэтому мы решили сместить фокус на SVC, и убедиться, что все работает как надо.

 

Вопрос: Будет ли смешение серверов использоваться для создания единого шарда мира? Или пинг — нерушимый барьер?

Ответ: КД: Пинг действительно станет большим препятствием. Задержка между Австралией и США, например, будет в районе 200 мс. Потенциально, мы можем найти сервер, который географически находится в средней точке активных игроков. Т.е. сервер будет находится в географическом центре, на примерно одинаковом удалении от игроков. Мы могли бы поступить таким образом. Также мы можем создать серверные слои, когда игроки бы подключались к региональным серверам, которые бы взаимодействовали с географическими центрами, тем самым минимизируя пинг. В общем, да, это сложный вопрос и я не могу пока дать определенных ответов. Но мы должны попробовать. Еще я хотел бы сказать, что Arena Commander и Star Marine, вероятно, будут всегда подключаться к местным серверам.

 

Вопрос: Является ли Bind Culling проблемой для реализации таких вещей, как телескоп у Индевора, который будет иметь большое приближение?

Ответ: КД: Да, BC работает не только с отбраковкой на основе удаленности, но и с размерами области наблюдения. С использованием телескопа, вы сужаете видимое поле, но увеличиваете дальность обзора, так что вы увидите меньше объектов, но на большем расстоянии. Это может стать проблемой, но я думаю, что все будет хорошо, геймдизайнеры разрулят.

 

Вопрос: Будете ли вы уделять внимание старым ПК. Чтобы игрокам не пришлось лезть в карман за обновлением сборок?

Ответ: РД: Да, код не подстраивается под какие-то особенные спецификации ПК. Оптимизация одинаково влияет как на хай-энд, так и на более старые компьютеры.

 

Вопрос: У некоторых игроков наблюдаются серьезные спайки в PU. Какие меры по оптимизации повлияют на загрузку клиентского CPU?

Ответ: КД: Без более точного описания проблемы мы вряд ли скажем в чем причина этих спайков.

РД: Благодаря новой системе телеметрии, мы сможем автоматически определять причины кратковременных зависаний.

 

Вопрос: Существуют ли какие-то меры по оптимизации Squadron 42? Или вы все еще ищите новые приемы оптимизации, чтобы использовать их в будущем?

Ответ: РД: Обе игры выстраиваются на общей базе, поэтому многие методы оптимизации мы уже применяем в Sq42. И все те оптимизации, что основаны на дистанциях тоже там будут. Крис хочет, чтобы все больше подсистем использовали аналоги LOD (уровней детализации).

 

Вопрос: Что мешает, с точки зрения производительности, спавнить капитальные корабли в PU?

Ответ: КД: Я думаю, что это в основном связано с размерами корабля и отсутствием посадочных площадок нужного размера. Так что нужны еще стыковочные кольца. С точки зрения производительности, мы уже показывали Идрис в прошлом году на Gamescom, так что все уже есть, нужно только улучшать.

РД: Конечно, нам нужен Object Container Streaming, чтобы подгружать такие большие корабли в фоне. Это может быть и не блокер, просто мы хотим, чтобы такие корабли не нагружали систему, а для этого нужен стриминг. Идрис, конечно, большой, но у нас уже есть большие корабли вроде Реклеймера и Старфарера.

Изменено 13 марта, 2018 пользователем Narayan

[turbovenik 313]

Большое спасибо за труды! Статья действительно получилась очень собирательной и полезной 

Из общей вредности... повторяются два абзаца : 

15 часов назад, Narayan сказал:

Draw call похожи на материю, проходящую сквозь сетку (mesh). Так что один из способов их уменьшения — комбинация нескольких сеток вместе. Этот процесс назван skinning-ом. Когда я работаю, скажем, над посадочными шасси, я могу взять несколько различных частей: поршней, шестеренок и прочих механизмов и объединить их в одну сетку. В результате получится, что вместо 10 отрисовок для 10 различных сеток получится 10 отрисовок для одной сетки. Это приводит к значительной экономии бюджета отрисовок.

Draw call похожи на материю, проходящую сквозь сетку (mesh). Так что один из способов их уменьшения — комбинация нескольких сеток вместе. Этот процесс назван skinning-ом. Когда я работаю, скажем, над посадочными шасси, я могу взять несколько различных частей: поршней, шестеренок и прочих механизмов и объединить их в одну сетку. В результате получится, что вместо 10 отрисовок для 10 различных сеток получится 10 отрисовок для одной сетки. Это приводит к значительной экономии бюджета отрисовок.

[Монгол 2 355]

Спасибо за действительно полезную информацию! 

[wolik 273]

Пока что эти рассказы напоминают мне анекдот где мужика унесло на воздушном шаре и пролетая он спрашивает внизу прохожего "Где я нахожусь ?" на что тот отвечает " 125,17 северной долготы, 45,32 южной" Совершенно точный и совершенно бесполезный ответ.
В детали лезть нет смысла и желания.
Ждём. Разговоров и идей было много. До 3.2 или 3.3 не так уж и много времени осталось. 

[Монгол 2 355]

6 часов назад, wolik сказал:

Пока что эти рассказы напоминают мне анекдот где мужика унесло на воздушном шаре и пролетая он спрашивает внизу прохожего "Где я нахожусь ?" на что тот отвечает " 125,17 северной долготы, 45,32 южной" Совершенно точный и совершенно бесполезный ответ.

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

* обратно упал в спячку в ожидании 3.3 *

[Leonid 44]

18 минут назад, Монгол сказал:

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

* обратно упал в спячку в ожидании 3.3 *

Меня больше всего пугает , что эти "сетевики" уже 3 года в штате и "активно работали" все эти 3 года.

 

Изменено 13 марта, 2018 пользователем Leonid

[Roy Urquhart 4 464]

18 минут назад, Монгол сказал:

Не спорю, ответ не обещает нам ничего полезного.

(задумчиво почёсывая затылок) ась ?    К примеру ответ говорит что фпс от ширины потока в данной игре не зависит пока .. полезно ж .. а то люди может на новые интернеты переходили

2 минуты назад, Leonid сказал:

Меня больше всего пугает , что эти "сетевики" уже 3 года в штате и "активно работали" все эти 3 года.

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

[nimx 1 682]

Игра будет на 30 FPS?

[Leonid 44]

Только что, nimx сказал:

Игра будет на 30 FPS?

Х.з.

Обычно : создают игру - подключают все механики - оптимизируют.

Тут , всё как-то странно.

[nimx 1 682]

10 минут назад, Leonid сказал:

Тут , всё как-то странно.

Ну-у я не знаю. Странно, что именно 30-ть. Я бы вот от 40-ка не отказался бы. Идцать, конечно, не шишнадцать, но вот 40-к еще как-то приятнее чем идцать. Как думаешь?

 Собственно 60-т фэпээсов внукам то - да, но это же внукам.

Изменено 13 марта, 2018 пользователем nimx

[Roy Urquhart 4 464]

7 минут назад, Leonid сказал:

Обычно : создают игру - подключают все механики - оптимизируют.

Тут , всё как-то странно.

Как именно странно то .. желательно также назвать те самые "обычные" шаровые игры в которых ВСЕ механики подключали до  начала оптимизации ( я вот только Lines знаю .. но может ещё есть )

2 минуты назад, nimx сказал:

Ну-у я не знаю. Странно, что именно 30-ть. Я бы вот от 40-ка не отказался.

Если на сервере будет 30-к это уже счастье

[Kriptman 792]

30 серверных, боже. Вы чем читаете вообще? Кадры на сервере и кадры на клиенте это разные вещи.

[Leonid 44]

3 минуты назад, nimx сказал:

Ну-у я не знаю. Странно, что именно 30-ть. Я бы вот от 40-ка не отказался. Идцать, конечно, не шишнадцать, но вот 40-к еще как-то приятнее чем идцать. Как думаешь?

Я и на 20 могу играть.

 

[nimx 1 682]

1 минуту назад, Leonid сказал:

Я и на 20 могу играть.

 

Я не хочу.

[Leonid 44]

1 минуту назад, Roy Urquhart сказал:

Как именно странно то .. желательно также назвать те самые "обычные" шаровые игры в которых ВСЕ механики подключали до  начала оптимизации ( я вот только Lines знаю .. но может ещё есть )

Все игры так создаются 

Оптимизация последнее над чем бьются.

 

[nimx 1 682]

18 минут назад, Kriptman сказал:

30 серверных, боже. Вы чем читаете вообще? Кадры на сервере и кадры на клиенте это разные вещи.

Правда?

А там же написанно, что однох...но.

Зачем обманываешь?

Сколько там твоих герц на монике - никому не интересно.

 Нет. - Надо через консьержа стучаться чтоб серверных 40 фэпээсов на релиз у всех было.

Чтоб у ценителей глаза не выпали.

А 60-т внукам обещанных - ну их на..уй. Хех. Нет. Не внуков), а +хренлион игроков в инстансе.  И жаже заклепок на Фрилансере не жалко. Мне эти новомодные обещалки тоже не интересны. Неткод или код игры виноваты - мне п..ю и это.. - правильно) - одно..йственно.

Изменено 13 марта, 2018 пользователем nimx

[Leonid 44]

Нужно блокчейн сервер изобрести.

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

Таже самая цепочка транзакций , только чуть сложней:

Сущность - текущее положение - возможное положение - действия.

[Roy Urquhart 4 464]

16 минут назад, Leonid сказал:

Все игры так создаются 

Ну так и назови десяток хотя-бы в которых СНАЧАЛА подключили ВСЕ механики, а ПОТОМ бы занялись оптимизацией ... при этом с подтверждением твоих слов.  А с тем, что оптимизация это обычно последнее с чем ЗАКАНЧИВАЮТ биться никто и не спорит ... вот только разницу между НАЧИНАЮТ ПОСЛЕ ПОДКЛЮЧЕНИЯ и ЗАКАНЧИВАЮТ ПОСЛЕДНИМ достаточно легко увидеть .. или нет?

 

16 минут назад, Leonid сказал:

Оптимизация последнее над чем бьются.

См. выше

3 минуты назад, Leonid сказал:

Нужно блокчейн сервер изобрести.

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

Таже самая цепочка транзакций , только чуть сложней:

Сущность - текущее положение - возможное положение - действия.

Вздыхая ... это ... ну ... а врачи что говорят ?

18 минут назад, nimx сказал:

Правда?

А там же написанно, что однох...но.

Не .. там написано что клиентское от серверного зависит  ... то-бишь если на сервере будет 10 фпс, клиент с 200 будет недоумевать "что за нафиг"

 

18 минут назад, nimx сказал:

 Нет. - Надо через консьержа стучаться чтоб серверных 40 фэпээсов на релиз у всех было.

зачем ?

18 минут назад, nimx сказал:

Чтоб у ценителей глаза не выпали.

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

 

[Leonid 44]

1 минуту назад, Roy Urquhart сказал:

Вздыхая ... это ... ну ... а врачи что говорят ?

Что тут сказать можно?

Слишком крутая технология.

[Roy Urquhart 4 464]

1 минуту назад, Leonid сказал:

Что тут сказать можно?

Слишком крутая технология.

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

1) то, что в играх нафиг никому никогда нужно небыло,

2) то, что замедлит все процессы в нцать раз

Вот я и интересуюсь с какой травы ты её приплести попытался, и почему решил, что она что-то упростит или ускорит?