Автор отвергает исходную гипотезу о «полностью оптимизированной» игре, в которой ради производительности остаётся только ухудшать графику, ИИ или уровни. На практике оптимизация начинается с измерений, а выбор изменений зависит от конкретной причины просадок.
Как находят проблему
В код систем добавляют маркеры начала и конца выполнения. Они позволяют измерить, сколько времени кадра занимают поиск пути, обработка визуальных эффектов, прицеливание и стрельба ИИ, рендеринг теней, расчёты освещения и другие операции. Профилирование обычно оставляют только в нефинальных сборках: сбор данных сам влияет на производительность и расходует память и место на диске.
После плейтестов команда анализирует отчёты, особенно в моменты рывков и падения частоты кадров. Причинами могут быть сотни попыток выстрела в одном кадре, множество одновременных эффектов, потеря сетевых пакетов, массовое появление и удаление ИИ или сочетание этих факторов.
Кто выбирает изменения
Инженерная команда — часто старшие программисты движка или технический директор — привлекает ответственных за проблемные системы, показывает данные и требует исправлений. Задача специалистов по производительности — вернуть потребление ресурсов в допустимые пределы; конкретный способ обычно выбирают команды, отвечающие за эти системы.
Исправление не обязательно означает снижение качества: можно распределить появление и удаление ИИ по нескольким кадрам или устранить баг, из-за которого все турели пытаются стрелять каждый кадр. В других случаях потребуется сократить количество визуальных эффектов. Команда должна сохранить желаемый игровой опыт, не нарушая требований к производительности. Выбор зависит от типа игры и уровня, сюжета, персонажей и доступных ресурсов, а не от универсальной очереди отделов «под нож».
Выводы
- Решения об оптимизации принимают по данным профилирования и плейтестов.
- Просадки могут возникать из-за пиков одновременных операций или нескольких систем сразу.
- Инженеры задают требования к производительности, а ответственные команды выбирают способ исправления.
- Снижение качества — не единственный вариант: помогают исправление ошибок и распределение нагрузки между кадрами.
- Приоритет изменений определяется контекстом и желаемым игровым опытом.
- Утверждение, что состояния «полностью оптимизировано, дальнейшие улучшения невозможны» не существует, слишком категорично. Для фиксированной задачи, оборудования и ограничений возможны доказуемые нижние границы затрат и оптимальные решения по конкретному критерию. На практике доказать полную оптимальность сложной игры обычно трудно, но это не означает принципиальной невозможности такого состояния.
- Потеря сетевых пакетов приведена как возможная причина падения частоты кадров без необходимых оговорок. Обычно она вызывает задержки сетевых обновлений, рывки движения или рассинхронизацию, а не непосредственно увеличение времени рендеринга кадра. Влияние на FPS возможно при определённой реализации сетевого кода; одних замеров времени выполнения функций обычно недостаточно, чтобы установить потерю пакетов как причину — нужна сетевая диагностика.
