Чому прототип на Godot застрягає до публікації
Прототип на Godot збирається швидко: сцена, базовий ігровий цикл, начерки інтерфейсу — і через кілька днів уже є у що пограти.
Саме тут проєкт найчастіше й зупиняється: демонстрація на налагоджувальному стенді та робочий продукт на пристрої замовника різняться сильніше, ніж здається.
Перше вузьке місце — продуктивність. Код, зручний на потужній машині, на бюджетних пристроях дає просідання кадрів і довгі завантаження сцен.
Причина зазвичай не в рушії, а в архітектурі: зайві вузли в дереві сцени, покадрові обчислення в скриптах, ресурси, які тримають у пам’яті повністю.
Друге — збірка під дві платформи. Поки версія одна, експорт робиться вручну і «як-небудь».
Щойно з’являються Android та iOS, ручна збірка перетворюється на окрему роботу: ключі підпису, профілі, різні набори ресурсів і налаштувань, розбіжності між тим, що перевіряли, і тим, що поїхало.
Третє — перевірка в магазинах застосунків. Модерація дивиться на політику конфіденційності, дозволи, віковий рейтинг, оформлення картки; відмова на цьому кроці відкидає проєкт назад на тижні, бо частина зауважень вимагає правок у самому коді.
Жодне з цих місць не пов’язане з геймплеєм — тому про них дізнаються пізно. Нижче розбираємо, як це закривається: від профілювання на реальних пристроях до автоматичної збірки й підготовки до перевірки в магазинах.
Що змінюється після налаштування конвеєра збірки
Проєкт на Godot до налаштування конвеєра збирався вручну: релізна збірка займала від сорока хвилин до півтори години, ключі підпису зберігалися в листуванні, а частина кроків трималася в голові одного інженера.
Після перенесення в конвеєр та сама збірка йде 8–12 хвилин однією командою, а готовий артефакт отримує номер, за яким його можна знайти й порівняти з попереднім.
Найпомітніше змінюється частка відмов після оновлення. Раніше приблизно кожен п’ятий випуск приносив терміновий патч або повторну публікацію наступного дня.
Тепер до викладки проганяються перевірки холодного старту, завантаження сцен і збереження прогресу, збірка спершу йде на закритий канал і лише потім — у загальний.
Швидкість випуску оновлень скорочується з тижня до одного-двох днів, а простій на релізі — до нуля. Збірка йде на виділених агентах паралельно з роботою команди, викладка автоматична, відкат на попередній артефакт займає хвилини замість повторної збірки.
Це не разові цифри під конкретний випуск, а режим: кожна наступна версія проходить той самий шлях за той самий час, і реліз перестає бути подією, до якої команда окремо готується.
Режими збірки на Godot: один код під дві платформи
Godot збирає один проєкт під Android та iOS, але відмінності платформ нікуди не зникають: у магазинах різні платежі, вхід за акаунтом, повідомлення та правила перевірки.
Режим збірки — це те, як відмінності розведені в коді, і від нього залежить трудомісткість випуску та поведінка системи, коли один магазин відхиляє збірку.
Тримати все в одній гілці простіше на старті й ризикованіше в експлуатації: збій однієї платформи спливає у збірці для іншої. Нижче — три схеми збірки під магазини застосунків та умови, за яких кожна себе виправдовує.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Єдина збірка з перевірками платформи на етапі виконання | Відмінності — інтерфейс, платежі, повідомлення; бібліотеки кросплатформні | Платформний код у спільній гілці; тести потрібні на обох платформах під кожен реліз |
| Платформні гілки від спільної основи | Власні модулі магазинів і різна логіка покупок | Основу синхронізують вручну, при розходженні виникають конфлікти правок |
| Роздільні релізні лінії | У платформ свої цикли й строки перевірки | Подвійний прогін тестів і релізних кроків, потрібен регламент перенесення виправлень |
Вибір визначають не розміром гри, а кількістю відмінностей: поки їх менше десятка, єдина збірка дає найкоротший шлях до магазинів.
Коли платформні модулі починають заважати один одному, ми виносимо їх в окремі гілки поверх спільної основи — виправлення переноситься в одну точку, а не дублюється.
Етапи роботи: від перевірки проєкту до релізу
Проєкт на Godot рідко починається з чистого аркуша: частіше це прототип, у який можна грати, зібраний, щоб швидко перевірити ідею. Перед публікацією потрібно зрозуміти, що в ньому можна безпечно змінювати, як він збирається і де ламається під час випуску. Нижче — порядок робіт, за яким проходить кожен проєкт.
- Аудит проєкту. Розбираємо структуру сцен, зовнішні залежності, стан репозиторію та підключені доповнення. На виході — карта вузьких місць: що переписуємо, що залишаємо як є.
- Схема збірки. Фіксуємо цільові платформи й конфігурації, виносимо ключі та адреси сервісів з коду. Схема зобов’язана давати однаковий результат при повторному запуску.
- Автоматизація випуску. Збірка вбудовується в загальний конвеєр: номер версії присвоюється сам, артефакт підписується й іде в закритий канал тестування без ручних кроків.
- Приймальні перевірки. Проходимо чек-ліст на цільових пристроях: запуск, збереження прогресу, покупки в застосунку, поведінка при втраті мережі та згортанні.
- Завантаження в магазини застосунків. Картка, описи, знімки екрана, політика конфіденційності, декларації про зібрані дані, проходження модерації.
- Передача проєкту. Архіви збірок, скрипти випуску, доступи та інструкція, як повторити збірку з нуля на чистій машині.
- Підтримка. Розбираємо падіння зі звітів, випускаємо оновлення під змінні вимоги платформ і тримаємо випуск відтворюваним.
Перші три кроки задають головне — передбачуваність кожного наступного випуску.
Що передаємо разом із релізною збіркою
Збірка, яка збирається на машині одного розробника, — не артефакт передачі. Тому разом із релізом віддаємо відтворюваний набір: конфігурації збірки під кожну платформу, ключі підпису, схему доступів і регламент випуску оновлень.
Через пів року ваша команда або ми збираємо ту саму версію з тегу й отримуємо побітово передбачуваний результат, а не «працювало, поки не перевстановили систему».
- Конфігурації збірки: профілі release і debug, список підключених плагінів, налаштування експорту під кожну цільову платформу, роздільні набори змінних для тестового й бойового середовища.
- Схема складального конвеєра: збірка запускається з тегу, проганяє автотести, пакує артефакт і складає його в сховище — руками нічого не дозбирається.
- Ключі підпису та сховища сертифікатів з описом, хто і коли до них звертається, як ключ відкликається й перевипускається.
- Регламент випуску: від заморозки коду до відправлення в рев’ю стора — з точками погодження й відповідальним на кожному кроці.
- Права доступу: ролі для розробників, реліз-менеджера й власника акаунта стора, включно з доступами до панелей публікації, аналітики та крашлогів.
- Документація проєкту: карта сцен і підсистем, залежності між ними, схема збережень і таблиця сторонніх плагінів з умовами ліцензій.
- Інструкція з відкату: як повернути попередню версію в сторі, якщо рев’ю відхилило оновлення або після публікації зросла частка падінь.
- Реєстр версій із нотатками до релізу й переліком змін між збірками — щоб підтримка розуміла, що саме поїхало в стор.
Кейс: гра з прототипу до публікації
Прототип на Godot уже грався, але до магазинів не доходив: релізну збірку збирали вручну з робочої машини, йшло більше години й повторювалося при збоях. На частині моделей гра падала одразу після логотипа — кожен дванадцятий запуск.
Важкі ресурси підтягувалися по мережі в момент старту, тому на слабкому каналі перший екран надовго зависав.
| Метрика | До | Після |
|---|---|---|
| Збірка релізу | вручну, 60–90 хвилин, залежала від машини | автоматично за міткою релізу, 6–8 хвилин |
| Частка відмов при запуску | 1 з 12 запусків | 1 з 200, усі — у тестовій гілці |
| Вихід оновлення | 2–3 тижні від правки до стора | 2–3 дні разом із перевіркою |
| Статус у магазинах | чернетка, зауваження модерації | стабільні релізи без повернень |
Лагодили причину, а не симптом: рознесли ігрову логіку й дані, важкі ресурси перевели в підвантаження за сценами, збірку винесли на окремий сервер із прогоном перевірок на реальних пристроях.
Перед публікацією тепер проходить один і той самий набір сценаріїв — від входу в акаунт до збереження прогресу після обриву зв’язку.
Збірка перестала бути вузьким місцем: правку перевіряємо того ж дня, а не в кінці циклу.
Частка відмов упала на порядок, оновлення виходять без повернень до попередньої версії — механізм відкату налаштований і залишається доступним, але за час спостережень не знадобився жодного разу.
Чим відрізняється збірка під Android від iOS в одному проєкті?
У проєкті на Godot спільна логіка, сцени й ресурси лежать в одному репозиторії, а платформні відмінності винесені в шар експорту. Збірка під Android і збірка під iOS запускаються з одного вихідного дерева, але беруть різні шаблони експорту й різні платформні обгортки.
Тому розходження починається не в коді гри, а в тому, як артефакт підписується і як його приймає магазин.
Підпис збірки влаштований по-різному. В Android це файл ключа й пароль до нього: команда зберігає їх і передає замовнику, а втрата ключа означає, що оновлення поверх уже встановленого застосунку випустити не можна.
В iOS підпис прив’язаний до акаунта розробника та профілів розповсюдження зі строком дії — їх продовжують заздалегідь, інакше випуск зупиняється задовго до самого релізу.
Вимоги магазинів теж не збігаються. Магазин Android-застосунків суворіший до декларації дозволів і опису збору даних, магазин iOS — до приватності, оформлення картки та правил вбудованих покупок.
Перевірка оновлень іде роздільно: одна й та сама версія може пройти модерацію на одній платформі за добу й застрягти на іншій на тиждень, тому дати випуску планують незалежно.
Практичний висновок — роздільні складальні конфігурації та роздільні секрети в системі безперервної збірки, а не «одна кнопка на все».
Ми налаштовуємо автоматичний підпис, щоб випуск не залежав від одного розробника та його ноутбука, і плануємо поетапне оновлення там, де відкотити версію назад не можна.
Часті технічні заперечення перед стартом
Сумніви перед стартом зазвичай одні й ті самі, і майже всі знімаються на етапі проєктування, а не після релізу. Коротко — про перенесення наявного проєкту, модерацію, оновлення та права на результат.
У нас є прототип на іншому рушії — усе доведеться переписувати?
Переносимо не код, а правила: логіку станів, баланс, математику руху. Сцени та обробка вводу перезбираються під Godot, тому обсяг оцінюємо за кількістю екранів і зв’язків між ними — рішення ухвалюється до старту, а не в середині роботи.
Хто відповідає за перевірку в магазинах застосунків?
Її проходимо ми: метадані, скриншоти, політика конфіденційності, декларації щодо зібраних даних, підписи збірок. Відмову модерації розбираємо й перезбираємо, а чек-ліст вимог обох магазинів тримаємо заздалегідь — правки не перетворюються на зрив дати релізу.
Що відбувається після публікації — як виходять оновлення?
Оновлюємо рушій до актуальної гілки й правимо поведінку на нових моделях пристроїв і версіях системи. Контент, винесений у налаштування й таблиці, змінюється без нової збірки — отже, без повторної модерації та очікування.
Кому належать вихідний код і права на гру?
Вам. Передаємо репозиторій з історією змін, сцени, ресурси, ключі підпису та інструкцію зі збірки — проєкт збирається без нашої участі. Договір фіксує права на результат, а сторонні бібліотеки йдуть під ліцензіями, придатними для комерційного релізу.
Обговоримо вашу гру та план публікації
Щоб повернутися з оцінкою та планом публікації, а не із загальними формулюваннями, потрібен мінімальний набір вхідних даних. Нижче — що надіслати: цього вистачить, щоб оцінити обсяг робіт зі збірки, інтеграцій і випуску в стори.
- Посилання на репозиторій або архів проєкту в актуальній гілці: за структурою сцен, плагінами й налаштуваннями експорту видно, скільки залишилося до збірки. Беремо в роботу проєкти на Godot будь-якого ступеня готовності.
- Цільові платформи — Android, iOS або обидві: від цього залежить склад робіт з підпису, збірки та перевірки на реальних пристроях.
- Поточний стан проєкту: начерк, ігровий прототип або майже готова збірка, і що саме вже працює.
- Опис гри: жанр, тривалість сесії, ключова механіка та 2–3 референси, на які орієнтуєтеся.
- Що готово з контенту — арт, анімації, звук, тексти — і в якому вигляді джерельні файли.
- Доступи: акаунти розробника в сторах, сертифікати й ключі підпису, тестові пристрої — або підтвердження, що оформлювати їх нам.
- Модель монетизації та аналітика: покупки в грі, показ реклами, перенесення прогресу між пристроями — це задає перелік інтеграцій.
- Обмеження: бажаний строк випуску, прив’язка до події, вимоги щодо приватності та обробки даних неповнолітніх.
Після цього повернемося з планом публікації: етапи, склад робіт, порядок перевірок і точки, де потрібні ваші рішення. Опишіть задачу — зберемо оцінку під ваш проєкт.
