Крис Робертс о 3.0
Перевод комментариев Криса Робертса в Spectrum по поводу выхода 3.0 на Live серверы.
Основной пост Криса.
Пребывая в праздничном настроении, я подумал, что было бы полезно поделиться некоторыми сведениями о производительности в 3.0.
Количество игроков на сервере оказывает меньшее влияние на клиентскую производительность, чем можно подумать. На заключительных этапах PTU мы проводили тесты с 50, 40 и 30 игроками на сервер. Несмотря на небольшое улучшение производительности, это вовсе не было пропорционально количеству игроков, что можно увидеть на графиках представленных ниже. Верхний — это полный сервер с 50 игроками, средний — с 40, нижний — с 30 игроками. Ось Х означает FPS, а Y — число выборок.
По данным, которые мы получаем, это не столько из-за количества игроков, сколько из-за того, что они делают. В нашем внутреннем тестировании не проявлялось таких проблем с производительностью, которые мы получили на PTU и Live, когда тысячи игроков зашли на серверы и начали делать всевозможные сумасшедшие вещи. Наполняя Caterpiller грузом, а затем взрывая его над планетарным аутпостом вы можете поставить клиент и сервер на колени (т.к. вы только что добавили сотни, если не тысячи дополнительных объектов для симуляции). Еще одна распространенная проблема, которая может убить производительность — взаимопроникновение объектов, потому что это вызывает перегрузку физики, особенно если это происходит на большом объекте. Примером этому является Астероидная миссия (которую мы отключили прошлой ночью), которая спавнилась над ил рядом с Олисаром и «всасывалась» локальную сетку, вызывая всевозможные проблемы и блокировки. Кроме того, нам необходимо сделать более эффективную работу с большими кораблями, которые привносят тысячи дополнительных элементов для обновления статуса, в отличие от небольших кораблей, у которых намного меньше геометрии и предметов. Имея кучу людей, летающих на Starfarer или Caterpillar, вы нагружаете клиент и сервер сильнее, чем имея кучу Aurora и Hornet.
У нас есть решения для всех этих вещей, в том числе перемещение физики из асинхронной в пакетную модель обновлений, что позволит нам значительно улучшить физику (в данный момент мы ограничены четырьмя потоками для физики, независимо от кол-ва ядер у клиента и сервера), уровень детализации обновления объектов на клиенте от сервера (это позволит не получать обновления, или получать их в меньшем объеме при удалении от объекта, отключать объекты от сети, если они находятся на большом удалении от клиента), Object Container Streaming или Потоковая передача Контейнеров Объектов (целые области игры будут прогружаться только по мере необходимости), и все эти решения находятся разных стадиях прогресса, но это не то, что мы сможем закончить за неделю или две.
На CitizenCon мы объявили о том, что переходим на ежеквартальный график выпуска обновлений, который меньше связан с функциями, и больше ориентирован на регулярные патчи. Выпуск 3.0 является первым шагом в этой стратегии. Мы могли бы потратить еще несколько недель на улучшение производительности и исправление багов, прежде чем запускать в релиз 3.0, уже после Праздничного перерыва, но т.к. большая часть нашей команды не вернется из отпуска раньше второй недели января (поскольку мы работали на неделю больше в 2017-ом, чем в 2016-ом), мы не смогли бы запустить Live до начала февраля. Учитывая тот факт, что нам важно начать Evocati-тестирование в середине февраля, для того, чтобы успеть к обновлению в первом квартале, это поставило бы нас в ту же ситуацию, что и в этом году, когда мы начали задержки, поскольку фокусировались на фичах вместо дат. Релиз 3.0 на Live позволяет нам объединиться с нашей основной веткой производства, продолжить работу над производительностью и оптимизацией (что будет большой частью будущих обновлений) и довести все это до надежного тестирования патча, приуроченного к первому кварталу 2018-ого. Таким образом, хотя 3.0 и может быть разочарованием из-за проблем с производительностью и багов, это все равно шаг на пути в большом путешествии Star Citizen, который будет лучше и больше отполирован со временем.
Если вы имеете производительность в пределах 10-15 фпс, то определенно что-то не так, особенно если у вас четырехъядерный процессор, 4 ГБ VRAM и не менее 16 ГБ RAM. Я видел, что люди сообщают о 5 фпс, когда другие игроки, с теми же характеристиками получают 25-30 фпс. Вероятно, это результат обращения игры к жесткому диску, в результате нехватки оперативной памяти, хотя иногда мы слышим об этом и на ПК с 16 ГБи больше, что требует большего изучения с нашей стороны. Это другие приложения, забивающие память? Плохое распределение памяти (когда необходимо 10ГБ, а выделено 16)? Утечка памяти в игре? У ПК есть множество преимуществ, но одним из недостатков является огромное разнообразие конфигураций, отчего трудно выявить причины некоторых проблем с производительностью. Мы вводим дополнительную телеметрию как на серверах, так и на клиентах, чтобы автоматически обнаруживать, когда что-то работает в не соответствии со спецификациями машины, и надеюсь, что это позволит определить некоторые проблемы, которые приводят к низкой производительности. Конечно, это займет какое-то время, поэтому, пожалуйста, будьте терпеливы.
Наконец, хочу поблагодарить всех за поддержку Star Citizen, ваш энтузиазм и самоотверженность действительно подпитывают энергией команду и меня. Мы строим что-то по-настоящему особенное, что возможно только из-за вас.
Счастливых всем праздников!
Дополнительные ответы Криса на комментарии бэкеров
Вопрос из комментариев:
Итак, что случилось с сериализированными переменными? Почему каждый клиент в Галактике должен знать, что «Кэт» на ГримХексе загружен золотом? Я думал, что мы видели, как вы это фиксили, или это еще слишком рано? Если это так, то нет смысла пытаться играть пряо сейчас, т.к. результаты всегда будут одинаковыми. Может до этого стоит ограничить число игроков и возможность выбора больших судов? (показывает скрин с 0.6 фпс)
(Крис) Если этот скрин сделан не во время спавна AI кораблей, то что-то не так, какая у вас конфигурация ПК?
Как я уже сказал, скокращение числа игроков на сервере незначительно влияет на производительность клиента (поэтому я и разместил графики). Вы также можете заметить, что не так много показателей из выборки, с 5 фпс. Говоря об этом, мы хотим, чтобы все, кто имеет минимальную конфигурацию, получали как минимум 30 фпс, но важно понимать, что игровой опыт в 3.0 не будет одинаковым для всех, только люди имеющие низкую производительность будут говорить об этом, что вполне понятно. Сейчас мы озадачены тем, почему у игроков, у которых игра должна работать лучше, в соответствии с характеристиками их ПК, этого не наблюдается. Это в высоком приоритете для нас. Что касается сериализованных переменных, мы должны запустить первый проход при следующем релизе, в марте.
Пока вы здесь, знаете ли вы, какое влияние на производительность оказывает баг с перехватом из квантума, и сколько из-за других «вещей» (вроде спавна многоместных кораблей).
(Крис) Перехват выходит за рамки запрета спавна ИИ-кораблей, что приводит к их «перенаселению» ( в т.ч. они спавняться друг на друге), что определенно оказывает эффект на производительность. После того, как произошло столкновение с ИИ при перехвате, они должны удаляться и очищаться сервером, однако есть вероятность, что появляется проблема с логикой сервера, поскольку это одна из последних фич, введенных в 3.0. К счастью, частота перехватов обрабатывается службой, для которой мы можем использовать хотфикс (хотя возможно не сегодня или завтра), такой же, каким мы исправил проблему спавна астероидов на Олисаре!
Источник: https://vk.com/
