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