Визуальная новелла может быть требовательной, даже если на экране почти ничего не движется. Крупные портреты персонажей, фоны, видеоролики и аудио влияют на время загрузки, занимаемое место, декодирование и использование памяти. Сцены в реальном времени добавляют работу по анимации, освещению и рендерингу. Статичной сцене тоже нужен бюджет.
Начните с утверждённого внешнего вида и бюджета для целевых устройств. Эмуляция в браузере может выявить проблемы с компоновкой, но производительность на физических устройствах нужно проверять на физических устройствах. Для каждого заявления о производительности указывайте устройство, браузер или среду выполнения, сборку и условия тестирования, чтобы результат можно было воспроизвести.
Выберите репрезентативные сцены и устройства
Выберите спокойную сцену, сцену с несколькими крупными ресурсами, последовательность с частыми переходами и все фрагменты с видео или сценами в реальном времени. Укажите устройство с минимальными поддерживаемыми характеристиками и распространённое устройство. Включите самый маленький экран, на котором игроки должны иметь возможность читать текст и делать выбор.
Измеряйте холодный старт, повторный запуск, переходы между сценами и продолжительное взаимодействие. Отделяйте первую загрузку ресурсов от запусков с использованием кеша. Фиксируйте отсутствующие текстуры, медленное декодирование, задержку ввода и перезагрузки как самостоятельные сбои: средняя частота кадров может скрыть эти проблемы.
Измерьте бюджет поставляемых ресурсов
Для каждого поставляемого ресурса записывайте размеры при экспорте, размер файла и число ресурсов, которые могут одновременно находиться в памяти. Размер загрузки не показывает, сколько памяти займёт декодированное изображение: сжатие может сделать файл гораздо меньше. Храните редактируемые исходные файлы отдельно от экспортированных файлов, поставляемых игрокам.
Подбирайте размер при экспорте в соответствии с тем, как ресурс действительно выглядит на экране. Сравните возможные форматы в целевой среде выполнения, прежде чем преобразовывать всю библиотеку, и сверяйте прозрачные края, градиенты, текст и лица с утверждёнными изображениями. Меньший файл — слабое утешение, если сжатие портит крупный план персонажа.
Учитывайте видео как отдельную нагрузку
Выделите для видео отдельную строку в бюджете. Записывайте разрешение, длительность, кодирование, битрейт, аудио и наличие предварительной загрузки для каждого ролика. На целевом устройстве проверьте начало воспроизведения, зацикливание, паузу и запасной вариант. Воспроизведение в настольном редакторе не позволяет установить, как ролик ведёт себя в браузере или упакованной мобильной сборке.
Загружайте варианты, нужные сцене, вместо того чтобы загружать все варианты сразу. Если это допускает дизайн, предложите постер или статичное изображение в качестве запасного варианта и предоставьте игроку управление воспроизведением. Измеряйте весь переход, включая декодирование и все изображения, присутствующие одновременно; размер файла экспортированного ролика отражает лишь часть нагрузки.
Сохраняйте отзывчивость взаимодействия
Сделайте текст разборчивым, а элементы управления достаточно крупными для использования. Проверяйте быструю навигацию, изменение размера или ориентации экрана, изменение настроек во время воспроизведения и возврат из фонового режима. Пока операция не завершена, проверяйте, что каждый ввод принимается только один раз, не вызывая повторных действий.
В браузерных играх проверяйте поведение клавиатуры, сенсорного ввода и фокуса везде, где это применимо. Даже плавная сцена кажется сломанной, если наложенный элемент скрывает следующий выбор или переход без предупреждения блокирует ввод. Считайте видимую обратную связь и доступность элементов управления частью отзывчивости.
Проверяйте варианты оптимизации по отдельности
Меняйте по одному значимому ресурсу или условию рендеринга за раз и сравнивайте с эталоном. Фиксируйте визуальную приёмку вместе с измерением производительности. При работе с 3D сравнивайте изменения LOD, текстур и освещения в одной и той же сцене с одной и той же камерой.
Сохраните оригинал для прямого сравнения. Само по себе уменьшение объёма поставляемых данных не доказывает улучшение производительности. Сжатие может изменить затраты на декодирование или передачу данных, а изменения рендерера могут повлиять на внешний вид. Измеряйте показатель, связанный с дефектом, который вы пытаетесь исправить.
Установите бюджет релиза и следите за его соблюдением
Используйте наблюдения за игровым срезом, чтобы установить практические ограничения на размер поставляемой сборки, задержки переходов, сбои, связанные с памятью, и отзывчивость ввода на целевых устройствах. Повторяйте проверку, когда новая глава или тип ресурсов увеличивает нагрузку. Бюджет должен отражать то, что могут выдержать сборка и устройства.
Архивируйте отчёт по устройствам вместе с кандидатной сборкой и отмечайте непротестированные устройства как непроверенные. Принимайте оптимизацию, если она сохраняет утверждённое оформление и улучшает намеченный пользовательский опыт в воспроизводимых условиях.
Ключевые решения
- Отдельно отслеживайте размер загрузки, использование памяти после декодирования и затраты на рендеринг.
- Измеряйте репрезентативные сцены на физических целевых устройствах.
- Сравнивайте одно предлагаемое изменение с утверждённым эталоном.
- Используйте эмуляцию для проверки компоновки, а тесты на устройствах — для подтверждения заявлений о производительности.
Файлы руководства
Реестр ресурсов ↓Матрица тестирования устройств ↓Внешние сообщества, посвящённые моделям, и внешние сайты для публикаций могут содержать откровенные материалы. Ссылки на источники открываются в новой вкладке; это руководство не загружает их предпросмотры.
Источники и дополнительные материалы +
- Документация Ren'Py для Android ↗
- Документация Ren'Py для веба ↗
- Рекомендации Godot по производительности ↗
Последняя проверка 5 октября 2026 г..