Бюджет производительности

Что нужно знать

Нужна запускаемая сцена и доступ к целевому устройству либо явно обозначенной промежуточной среде. Урок помогает заменить требование «сделай быстрее» на измерение конкретной нагрузки. Знания низкоуровневой оптимизации пока не нужны.

Принцип

Начните с платформы, разрешения, режима сборки и целевой частоты кадров. При 60 кадрах в секунду интервал между кадрами составляет примерно 16,67 мс; при 30 примерно 33,33 мс. Это арифметический ориентир для ритма кадров, а не обещание, что любая сцена успеет обработаться за это время.

Не складывайте автоматически все показания CPU и GPU: их работа может перекрываться. Смотрите, что измеряет конкретный инструмент, и ищите участок, задерживающий готовность следующего кадра. Оптимизация одной функции не поможет, если задержка возникает в другом месте.

Рекомендации Godot по оптимизации предлагают измерять узкие места и проверять результат изменений. Они также различают постоянную медленную работу, отдельные скачки задержек и долгую загрузку. Для этих проблем нужны разные сценарии наблюдения.

Практический пример

Арена с противниками

Предположим, на спокойной сцене всё плавно, а появление группы врагов вызывает остановку. Не начинайте с переписывания движения. Создайте воспроизводимый сценарий с одинаковой ареной, числом врагов, начальным значением генератора случайности (seed) и моментом появления.

scenario: spawn-wave
device: exact model and power mode
build: production configuration
resolution: fixed value
warmup: 20 seconds
record: 60 seconds
report: median, p95, p99 frame time and longest frame
compare: baseline versus one isolated change

Это пример процедуры. Выберите длительность под свою игру и сохраните её одинаковой в сравнении. p95 и p99 обозначают границы, в которые укладываются примерно 95% и 99% измеренных кадров. Так проще заметить редкие долгие кадры, которые скрывает среднее. Но короткая запись всё ещё может пропустить редкий сбой.

Запишите профиль момента появления врагов. Если время уходит на создание объектов и подготовку ресурсов, проверьте предварительную загрузку или распределение работы. Если постоянно дорого стоит обновление всех объектов, изучите частоту и объём этой работы. Выбирайте исправление по профилю, а не по популярности техники.

Частые ошибки

Object pool требует корректного сброса состояния. Если после повторного использования враг сохраняет старое здоровье или подписку, ускорение не компенсирует ошибку. Проверяйте игровой результат вместе со временем.

Сравнение редактора с production-сборкой на другом компьютере ничего не говорит об эффекте одной правки. Фиксируйте устройство, питание, сборку, настройки и внешнюю нагрузку. Не называйте проверку на мощном ноутбуке проверкой минимального целевого устройства.

Не оценивайте только FPS. Для проекта могут быть важнее первая загрузка, объём скачивания, пиковая память или время открытия меню. Выберите показатели, соответствующие наблюдаемой проблеме, и оставьте запас для обычных колебаний среды.

Проверка результата

• У цели указаны платформа, сцена и настройки.
• Есть исходная запись до изменения.
• Профиль объясняет выбор оптимизации.
• Сравнение использует одинаковые условия и нагрузку.
• Проверены редкие медленные кадры, а не только средний FPS.
• Поведение игры и потребление памяти не ухудшились незаметно.
• Непроверенные целевые устройства явно перечислены.

Задание для ИИ-агента

Сначала зафиксируй воспроизводимый сценарий и исходные измерения. Найди главное узкое место профайлером и предложи одно небольшое изменение. Сравни время кадра в одинаковых условиях, проверь игровой результат и память. Если целевое устройство недоступно, назови ограничение и не заявляй, что его производительность подтверждена.