Волшебство оптимизации

Новая статья в блоге игры рассказывает о проблемах с оптимизацией APB Reloaded. Почему лагает? Когда все починят? Каким образом? На эти и другие вопросы постарался ответить один из разработчиков игры.

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

---

Волшебство оптимизации
(Автор: Bjorn Book-Larsson, техмех)

Оптимизация продукта — одна из сложнейших задач для небольшой команды.

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

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

Мы очень гордимся, что АРВ Reloaded остается постоянным участником ТОП-5 (из 100+ проектов) бесплатных игр в Steam (кстати, большую часть траффика мы получаем прямо с сайта, а не через Steam, но статистика «стима» позволяет объективно сравнивать успехи игры с прочими проектами), так что в наших планах развивать игру еще не один год. Такой подход, при котором у нас имеются и долгосрочные задачи, и задачи, которые нужно решить быстро, ставит перед нами вечный вопрос - чем же заняться в первую очередь: новыми возможностями, картами («психушку» вызывали?), игровым контентом, безопасностью или оптимизацией?

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

АРВ - пожиратель серверных ресурсов?

Мало игр на движке Unreal пытались уместить сотню полностью кастомизируемых игроков (да даже обычных - много ли шутеров дают возможность боев 50 на 50?) в один бой, где каждый из игроков имеет полностью настраиваемый автомобиль и пушку, что означает более 200 уникальных предметов игрока, а так же до 850 пешеходов, 350 нейтральных автомобилей, ну и всякую мелочевку типа фонарных столбов, биллбордов и т.п.

Выходит, что на одном сервере (и на одном ядре!) находится примерно 18 000 динамических объектов.

Современные игры, работающие на других игровых движках (Planetside 2/Forelight), используют совсем иные методы оптимизации — «континенты», «дальность», «миссии». Это позволяет допустить больше игроков на континент, но необязательно в один бой. Fallen Earth использует систему динамических шардов, что позволяет находиться 10 000 игрокам в одной зоне. Но ни одна из этих игр не использует Unreal Engine.


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

Есть, конечно, и другие игры-шутеры с красивой графикой, отлично работающие на старом железе, но они и близко не стоят с АРВ по возможностям: ни сложной кастомизации, ни такого количества игроков… К тому же, часто такие игры больше RTS или RPG, а значит требования по регистрации попаданий куда ниже. Поразительно, что при всем этом АРВ работает даже на старом оборудовании.

Серверный FPS против клиентского FPS
(FPS — количество кадров в секунду)

Главное правило — сервер должен успевать делать полный цикл вычислений для всех 100 игроков в районе и 18 000 объектов 30 раз в секунду (то есть по 33 мс на полный цикл в одном кадре). Если мы достигаем 30 FPS на сервере, подключенные к нему клиенты могут легко работать на удвоенном или утроенном показателе (60-90 FPS) без каких-либо заметных потерь. При таком соотношении кадров в секунду, предсказание движений и интерполяция кадров работают очень плавно.


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

Оптимизация программ и время вычислений

Ниже представлен график серверных вычислений на версии 1.10.1 и новом оборудовании (подробности ниже) в идеальных условиях.

Сейчас (1.10.1) сервер выполняет полный цикл вычислений в 1 кадре, на 1 ядре, в одном полном районе и на новом оборудовании за 19.2 мс. Теоретически, таким образом можно запустить сервер на 52 FPS!

Сравнивая со старым оборудованием, мы могли сделать «стабильный» FPS только 25.

На нижней части графика показана версия 1.10.2 с новыми программными улучшениями.

Синтетический тест показал, что команде удалось выжать 16% дополнительной производительности одними улучшениями программ (что добавит примерно 10 FPS на сервере). Эти улучшения снижают время цикла до 16.1 мс, что в теории позволит запустить сервер аж на 62 FPS.

Это означает, что (опять же — в теории), улучшив лишь программный код, в новой версии игры (1.10.2) мы добьемся повышения производительности сервера, другими словами, вернем планку в 30 FPS.

Можете почитать эти графики снизу вверх. Что удивительно — почти половина времени уходит на операции по приему\отсылке информации, а её обработка занимает лишь другие 50%.



Загвоздка одного ядра

Unreal Engine — это отличный движок и фантастический рендерер. Он уже который год верно служит нам. Но дизайн движка обладает некоторыми решениями, которые ставят жесткие, труднопреодолимые рамки (у всех движков есть такие).


Самая большая проблема для больших игр — монолитная и практически однопоточная система сервер-клиент. Философия создателей понятна — в те времена движок рассчитывался для небольших игр с лобби или даже на одиночные проекты. Некоторые крупные игры используют лишь часть движка, дописывая остальное самостоятельно. Но самостоятельная часть таких проектов, обычно, рассчитана на РПГ, где на одном сервере находится 2000-3000 игроков, но от сервера требуется лишь 10 FPS или даже меньше.

АРВ использует гибрид стандартного кода Unreal (причем, от 2008-го года), свой собственный код для коммуникации между районами и мирами и собственную систему кастомизаций. Но главная часть взаимодействий все равно остается на системе, близкой к Unreal Engine, выполняемой в один цикл.

Это означает, что все действия в районе обрабатываются одним ядром и в один поток.

Можете представить себе это как пошаговую игру, где каждому игроку выделено 33 мс на ход или на комбинацию движений. Когда время вышло, игроки узнают о действиях других игроков и игра переходит на следующий ход (а из графиков вы видите, что на исполнение действий уходит лишь 7,5 мс, остальное занимает обмен информацией).

Человеческая реакция близка к 160 мс, так что потратив на все 33 мс, плюс 40-80 мс на обмен информацией, мы получим около 120 мс задержки, что даст нам плавный и приятный геймплей.

Однако даже небольшие улучшения серверной производительности увеличивают плавность игры. Мы, люди, очень хорошо замечаем разницу FPS, и легко заметим различие в фильмах с 24 FPS и 30 FPS (или 48 FPS если вы уже видели «Хоббита»). Это значит, что мы заметим визуальную разницу задолго до того, как поймем в чем она проявляется.

Почему же вся эта однопоточность так для нас важна? Ну, дело в том, что все серверное оборудование в последние годы эволюционирует именно в сторону многопоточности, увеличивая производительность за счет количества ядер. И это плохо для АРВ, потому что такое оборудование ничуть не улучшит производительность в одном единственном районе. Но… Надежда есть...

Новое открытое тестирование: OverKill

В ближайшее время мы планируем запустить тестовый мир под названием OverKill.


Сейчас сервера АРВ используют Intel Xeon x5570 (Nehalem), работающие на 3,2 ГГц в турбо режиме, с четырьмя ядрами по 2 процессора. Мы используем блейдовые сервера Dell M610, как на картинке.

Бонус блейдовых серверов — более высокая плотность, ведь мы можем уместить 16 серверов в место под 10. Минус — процессоры, поддерживаемые такими серверами, нельзя разгонять. А это проблема.

Мы долго искали подходящий процессор. Что-то, что может работать в нашем дата-центре и при этом обладать хорошим соотношением цена/качество, а так же работать на высоких скоростях на ядро. Тут на помощь приходят интеловские процессоры на Sandy Bridge и Ivy Bridge.

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


Эксперименты привели нас к решению использовать топовую материнскую плату ASUS Rampage 4 Extreme и разблокированный процессор Intel i7-3920K с шестью ядрами, работающий в условиях холодного воздуха помещений дата-центра на 4.25 ГГц. Можно и до 5 ГГц догнать, но начнем с малого.

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

В синтетике бенчмарк разогнанного i7 показывает прирост около 70% в сравнении с нашим старым другом. Мы теряем два ядра на сервер, но дополнительные сервера решат эту проблему.

Бенчмарк ЦП — один поток:

Старый процессор X5570 — 1349,
Экспериментальный 3930К — 2284.

Если нам удастся обратить эту производительность в улучшение FPS районов, нам не только удастся добиться стабильных 30 FPS, но и увеличить количество игроков в одном районе.

Как можно понять из графиков, на новом оборудовании мы, в теории, сможем запускать районы на 62 FPS, что на 206% больше, чем требуется.

Мы планируем использовать дополнительную мощность для увеличения численности игроков в одном районе. К сожалению, зависимость тут идет не линейная, количество игроков увеличится на 25%-50%, что и приведет к 30 FPS на сервере. Конечно, это все пока только слова, а как будет на самом деле - покажет только практика.

Что стоит знать — увеличение числа одновременно играющих в одном районе людей позволит существенно повысить качество матчмейкинга. Ведь 80 людей — 20 команд, 10 матчей. А 120 людей — 30 команд, 15 матчей. Аж 50% прироста. Ну, все не так просто, но об этом в другой раз.

Наше железо, программы и интернет, против ваших

В этот раз мы говорили только о серверной стороне и не затрагивали прочие вещи, влияющие на плавность игры. Первое и главное — для игры в АРВ вам потребуется мощный компьютер. Мы рекомендуем 8 ГБ ОЗУ и использование 64-х битной версии Windows 7. Все, что хуже этого, может вызывать проблемы. 64-х битная система вообще критична для АРВ. К тому же, все клиентские игры на Unreal’е заставляют игрока сильно лагать при полупрозрачных VFX событиях (т.е. больших взрывах, которые игрок ПЕРЕЖИВАЕТ, а в APB такое сплошь и рядом), так что только крутые видеокарты способны выдержать нагрузку и не потерять много FPS. Исправить это, к сожалению, очень трудно, об этом в другой раз.

Конечно же, пинг и качество сетевого подключения к нашим дата-центрам тоже сильно влияет.

Надеюсь, что эта статья достаточно рассказала вам о проделанной нами работе по оптимизации. В течение следующих двух недель OverKill появится в списке миров. А обновление 1.10.2, которое значительно улучшит производительность, выйдет уже совсем скоро.