Разработка мобильной игры на Flame (Flutter)

Разработка игры на Flutter: где ломаются проекты

Разработка игры на Flutter почти всегда стартует быстро: сцена, спрайты, ввод, пара механик — прототип собирается за считаные дни и на топовом устройстве идёт ровно. Сложности приходят позже, когда объектов на сцене становятся сотни и выясняется главное: логика и отрисовка живут в одном потоке.

Пока он считает физику, коллизии, спавн и анимации, на подготовку следующего кадра времени уже не остаётся. На слабых устройствах это даёт просадки, которые видно глазом: рваное движение, задержку на нажатие, «залипший» персонаж. Игрок не разбирается в причинах — он видит, что игра тормозит, и уходит; в отзывах это возвращается рейтингом и досрочными удалениями.

Второе узкое место игрового цикла — жёсткая связка со сценой. Каждая новая механика правит общие базовые классы, где описаны обновление и отрисовка, и задевает то, что уже работало: бонусы начисляются дважды, сохранения расходятся с состоянием, уровень перестаёт собираться. Переписывать приходится не одну сцену, а половину игры — и это уже задача не про графику, а про сроки.

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

Что даёт единая кодовая база для двух платформ

Кроссплатформенная мобильная игра на Flame собирается из одного дерева исходников: игровой цикл, физика столкновений и слой анимаций работают поверх Flutter и не знают, на какой платформе запущены. Логика уровней, баланс, экономика и прогресс игрока живут в общем слое, а различия — ввод, покупки внутри приложения, уведомления, локальное хранилище — выносятся в тонкие платформенные прослойки с одинаковым интерфейсом. Такой разрез держит расхождения между сборками в пределах единиц процентов вместо десятков.

С точки зрения сроков выпуска обновлений это и есть основной эффект. Один цикл проверки, один набор автотестов и один разбор правок закрывают обе платформы, поэтому релиз готовится параллельно, а не двумя последовательными итерациями. Время сборки релиза сокращается примерно вдвое: тяжёлые шаги — компиляция ядра, прогон тестов, упаковка артефактов — выполняются один раз, а удваивается только тонкий платформенный слой.

Отдельно уходит класс отказов, который дороже всего чинить: рассинхрон версий, когда на одной платформе уже новая механика, а на другой ещё старая, и игроки видят разный баланс. При единой кодовой базе такое состояние физически невозможно — номер версии, набор уровней и правила начисления наград приходят из одного источника.

Чтобы эффект не растворялся со временем, сборочный контур фиксирует общий тег версии и единый набор веток, а платформенные различия допускаются только в прослойках — проверка на ревью это отслеживает. Тогда следующий сезон контента добавляется один раз и сразу становится доступен обеим аудиториям.

Режимы разработки: движок, нативный модуль, гибрид

Выбор режима — вопрос того, где нужна производительность, а где важнее скорость изменений. У режимов разработки игр разные границы применимости: движок даёт общий код для двух платформ, нативный модуль — полный доступ к устройству, гибрид пытается совместить оба. Ниже — что каждый закрывает и где начинает мешать.

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

Этапы работы: от прототипа до передачи в поддержку

Этапы разработки игры — не бюрократия, а способ не переделывать. Ошибка в схеме состояния всплывает на середине проекта, а провал по частоте кадров — уже после выпуска, когда переписывать отрисовку дороже всего. Поэтому каждый следующий шаг стартует только на принятом результате предыдущего.

1. Разбор задачи и аудит кода. Если игра уже существует, начинаем с чтения репозитория: как устроен игровой цикл, где живёт состояние, какие места держат кадр. На выходе — карта рисков и решение, что переписываем, а что оставляем.
2. Схема архитектуры. Разделяем логику, состояние, отрисовку и данные на слои, чтобы новый уровень или режим не ломал остальное. Схему согласуем до первой строки кода.
3. Прототип игрового цикла. Собираем минимальную играбельную версию на Flutter: реакция на управление, поведение камеры, темп. Ощущения доводим на серых блоках, без графики и контента, — правки не тянут за собой переделку уровней.
4. Настройка сборки и окружений. Разводим профили разработки, тестирования и выпуска, автоматизируем сборку и подпись — из процесса уходят ручные шаги и связанные с ними ошибки.
5. Проверка производительности игры. Длинные сессии на устройствах нижнего сегмента: память, стабильность частоты кадров, поведение при слабой сети. Узкие места закрываем до передачи, а не после отзывов в магазине.
6. Передача проекта. Репозиторий с историей, документация по сборке и выпуску, доступы к магазинам и аналитике, обучение команды заказчика.

У каждого этапа есть проверяемый артефакт — поэтому проект не застревает в состоянии «почти готово», а приёмка идёт без сюрпризов и повторных доработок.

Артефакты проекта: код, сборки, регламенты и документация

Передача проекта — это не архив с исходниками, а комплект, по которому другая команда инженеров сможет собрать, выпустить и доработать игру без нас. Всё, что появляется в ходе работы — включая проект на Flutter, — живёт в репозитории: настройки, конфигурации, правила. Ниже — что именно переходит заказчику и в каком виде.

• Исходный код игры — полная история изменений и зафиксированные внешние зависимости, чтобы сборка воспроизводилась на любой машине, а не только у автора правки.
• Схема сборки — конфигурация сборочного конвейера: одна команда даёт тестовую сборку и релизную, ключи подписи хранятся в защищённом хранилище, а не в репозитории.
• Правила ветвления — какие ветки считаются релизными, как оформляется правка и что проверяется перед слиянием в основную.
• Документация проекта — схема архитектуры, описание игровых систем, экономики и сохранений, пояснения по нестандартным решениям.
• Регламент обновлений — порядок выпуска версии: проверки перед публикацией и работа с обратной совместимостью сохранений у игроков.
• Инструкция по выпуску — пошаговый путь от сборки до публикации в магазинах с отметками, где нужен ручной шаг.
• Политики доступа — роли в репозитории, права на публикацию, доступы к панелям магазинов и аналитике.
• Регламент поддержки — сроки реакции на сбои, порядок передачи правок и канал для срочных вопросов.

Кейс: убрали просадки и ускорили выпуск обновлений

Проект — казуальная головоломка: разработка игры на Flutter велась на Flame, уровни генерировались процедурно и обновлялись контентом каждую неделю. К третьей крупной ветке функциональности накопились три связанные проблемы: логика и отрисовка шли одним проходом игрового цикла, под каждый уровень создавались новые объекты вместо переиспользования, а релиз пересобирался целиком даже когда менялась только разметка уровней.

Что переписали

Игровой цикл разделили на фиксированный шаг логики и отдельный проход отрисовки — отклик управления перестал зависеть от плавности кадров. Пул объектов заменил постоянные аллокации: сборщик мусора больше не срабатывал посреди уровня и не давал рывков. Ресурсы получили профиль качества — на слабых устройствах отключаются тяжёлые эффекты и часть анимаций, но правила и отклик управления не меняются.

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

Метрики до и после

• Доля вылетов за сессию: снизилась с 7-8% до 1.5%
• Сессии с просадками и рывками: с 20% до 4%
• Полная сборка релиза: с 40 минут до 9
• Цикл выпуска обновления: с трёх недель до 5-7 дней

Отдельно закрепили автоматический сбор отчётов о падениях по устройствам и версиям — регрессии теперь видно до релиза, а не по отзывам.

Чем специализированный движок отличается от обычного приложения

Обычное приложение живёт на событиях: экран построен, ждёт нажатий и перерисовывается только при смене данных. Игре этого мало — нужен непрерывный цикл обновления, где каждый тик пересчитываются позиции, столкновения и анимация, и только потом собирается кадр. Пропущенный тик игрок видит как рывок.

Отрисовка игровой сцены устроена иначе: в кадре одновременно живут десятки объектов, спрайты собирают в атласы, а объекты берут из пула вместо создания новых — иначе сборщик мусора даёт провалы по времени кадра. Приложение оперирует деревом виджетов и перестраивает только изменившиеся узлы, игра — плоским списком слоёв с жёстким порядком вывода.

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

Движок вроде Flame нужен, когда картинка меняется непрерывно: физика, столкновения, много объектов, ровный темп на слабых устройствах. Для форм, лент и списков он избыточен — там достаточно обычного приложения на той же платформе, и поддерживать его проще.

Частые технические вопросы по архитектуре проекта

Пять вопросов обычно всплывают до старта разработки. Ниже — короткие ответы: какое инженерное решение стоит за каждым и где проходит граница его применимости.

Можно ли обновлять игру без повторной публикации?

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

Что будет с кодом, когда автор уйдёт с проекта?

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

Кому принадлежит исходный код?

Заказчику: хранилище кода, сборочные конфигурации и права на аккаунты передаются по акту. Мы не удерживаем проект через доступы.

Что происходит после релиза?

Следим за падениями и удержанием, готовим обновления совместимости с новыми версиями систем. Правки контента идут без сборки, остальное — по циклу релизов.

Обсудим задачу: что нужно для плана и оценки

Чтобы оценка по разработке игры на Flutter опиралась на факты, а не на догадки, нам нужен короткий набор вводных — они напрямую задают объём работ и риски. Ничего экзотического, обычно это то, что уже сформулировано у вас в черновиках или в голове:

• цель игры и основной цикл: что игрок делает в первые минуты и зачем возвращается;
• платформы и ориентация: iOS, Android или обе, портретная или ландшафтная, нужны ли планшеты;
• графика и звук: есть ли готовые спрайты, анимации, музыка или художественную часть готовим вместе с вами;
• механики: уровни, прогресс, сохранения, внутриигровая экономика, реклама и встроенные покупки;
• данные: нужен ли аккаунт, облачные сохранения, таблицы лидеров, сбор аналитики;
• ограничения: сроки, привязки к домену, существующему серверу, магазинам приложений;
• доступы: аккаунты разработчика в магазинах, если публикация на нашей стороне.

В ответ возвращаем схему решения: как разложим игровой цикл по сценам, где пройдут границы между логикой и отрисовкой, как соберём проект под обе платформы и как выпускать обновления без перевыпуска. Рядом — состав работ по этапам, сроки и порядок передачи: исходники, доступы, инструкция по релизу.

Опишите задачу в удобном виде — вернёмся с оценкой и планом работ по игре, после согласования назначаем старт проекта.