Вокруг Вселенной наоборот

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

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

Какая разница между 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, чтобы подгружать такие большие корабли в фоне. Это может быть и не блокер, просто мы хотим, чтобы такие корабли не нагружали систему, а для этого нужен стриминг. Идрис, конечно, большой, но у нас уже есть большие корабли вроде Реклеймера и Старфарера.

Источник: https://vk.com/@starcitizen