Мобильная игра на Godot: от прототипа до публикации в сторах

Почему прототип на Godot застревает до публикации

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

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

Второе — сборка под две платформы. Пока версия одна, экспорт делается вручную и «как-нибудь». Как только появляются Android и iOS, ручная сборка превращается в отдельную работу: ключи подписи, профили, разные наборы ресурсов и настроек, расхождения между тем, что проверяли, и тем, что уехало.

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

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

Что меняется после настройки конвейера сборки

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

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

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

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

Режимы сборки на Godot: один код под две платформы

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

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

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

Этапы работы: от проверки проекта до релиза

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

1. Аудит проекта. Разбираем структуру сцен, внешние зависимости, состояние репозитория и подключённые дополнения. На выходе — карта узких мест: что переписываем, что оставляем как есть.
2. Схема сборки. Фиксируем целевые платформы и конфигурации, выносим ключи и адреса сервисов из кода. Схема обязана давать одинаковый результат при повторном запуске.
3. Автоматизация выпуска. Сборка встраивается в общий конвейер: номер версии присваивается сам, артефакт подписывается и уходит в закрытый канал тестирования без ручных шагов.
4. Приёмочные проверки. Проходим чек-лист на целевых устройствах: запуск, сохранение прогресса, покупки внутри приложения, поведение при потере сети и сворачивании.
5. Загрузка в магазины приложений. Карточка, описания, снимки экрана, политика конфиденциальности, декларации о собираемых данных, прохождение модерации.
6. Передача проекта. Архивы сборок, скрипты выпуска, доступы и инструкция, как повторить сборку с нуля на чистой машине.
7. Поддержка. Разбираем падения из отчётов, выпускаем обновления под меняющиеся требования платформ и держим выпуск воспроизводимым.

Первые три шага задают главное — предсказуемость каждого следующего выпуска.

Что передаём вместе с релизной сборкой

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

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

Кейс: игра из прототипа до публикации

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

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

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

Чем отличается сборка под Android от iOS в одном проекте?

В проекте на Godot общая логика, сцены и ресурсы лежат в одном репозитории, а платформенные различия вынесены в слой экспорта. Сборка под Android и сборка под iOS запускаются из одного исходного дерева, но берут разные шаблоны экспорта и разные платформенные обёртки. Поэтому расхождение начинается не в коде игры, а в том, как артефакт подписывается и как его принимает магазин.

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

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

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

Частые технические возражения перед стартом

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

Кто отвечает за проверку в магазинах приложений?

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

Что происходит после публикации — как выходят обновления?

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

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

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

Обсудим вашу игру и план публикации

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

• Ссылку на репозиторий или архив проекта в актуальной ветке: по структуре сцен, плагинам и настройкам экспорта видно, сколько осталось до сборки. Берём в работу проекты на Godot любой степени готовности.
• Целевые платформы — Android, iOS или обе: от этого зависит состав работ по подписи, сборке и проверке на реальных устройствах.
• Текущее состояние проекта: набросок, играбельный прототип или почти готовая сборка, и что именно уже работает.
• Описание игры: жанр, длительность сессии, ключевая механика и 2–3 референса, на которые ориентируетесь.
• Что готово из контента — арт, анимации, звук, тексты — и в каком виде исходники.
• Доступы: аккаунты разработчика в сторах, сертификаты и ключи подписи, тестовые устройства — или подтверждение, что оформлять их нам.
• Модель монетизации и аналитика: покупки внутри игры, показ рекламы, перенос прогресса между устройствами — это задаёт перечень интеграций.
• Ограничения: желаемый срок выпуска, привязка к событию, требования по приватности и обработке данных несовершеннолетних.

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