Розробка мобільної 3D-гри: повний цикл від прототипу до публікації

Розробка мобільної 3D-гри: де ламається прототип

Прототип мобільної 3D-гри майже завжди збирається на одному пристрої — робочому, де все рівно: сцена завантажується, кадри йдуть, ефекти на місці.

На пристроях замовника й у реальній вибірці гравців картина інша: просідання плавності на масових сценах, вильоти під час перемикання між екранами та рівнями, завантаження рівня, під час якого користувач встигає згорнути застосунок. Формально гра готова, фактично — до неї не доходить половина тих, хто встановив.

Причина майже завжди одна й та сама — архітектура завантаження й пам’яті, а не графіка. Ресурси рівня піднімаються одним куском і висять у пам’яті до виходу, хоча половина потрібна лише на перших секундах. Об’єкти поза межами видимості продовжують обраховуватися фізикою.

Шейдери збираються в момент першого показу ефекту, тому ривок припадає рівно на найвражаючіший момент бою. Збирач сміття спрацьовує на піку, коли в кадрі максимум персонажів.

Вузьке місце проєкту визначається не на стенді розробника, а на слабкому пристрої: там обмежений і обсяг пам’яті, і кількість об’єктів, які можна відмалювати за кадр.

Знайти його без замірів неможливо, і команда починає правити візуал — різати ефекти, спрощувати моделі, втрачаючи те, за що гру обрали.

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

Ціна такої помилки — ті, хто відвалився під час першого запуску, повернення й переробка завантаження вже після релізу, коли змінювати структуру сцен найдорожче.

Далі розбираємо, як це закривається: від розбиття контенту на завантажувані блоки до замірів і профілів під конкретні класи пристроїв.

Що дає керований ігровий цикл та оптимізація сцен

Ігровий цикл — це порядок, у якому кадр проходить введення, симуляцію, анімацію та відмалювання.

Поки введення й фізика оновлюються в тому самому такті, що й відмалювання, плавність анімації провалюється на слабкому пристрої: коротке просідання частоти кадрів ламає і керування, і влучання в ціль.

Ми розводимо такти — симуляція йде з фіксованим кроком, відмалювання інтерполює стан, тому поведінка гри не залежить від того, скільки кадрів встиг пристрій.

Оптимізація сцен починається з того, що рівень перестає бути одним монолітом. Завантажувальна сцена, ігрові зони та елементи інтерфейсу підвантажуються адитивно й вивантажуються, коли перестають бути потрібними.

Час завантаження рівня скорочується в рази: у пам’ять потрапляє лише те, що гравець побачить у найближчі секунди, а не весь контент гри одразу.

На розмір збірки працює та сама логіка. Спільні матеріали й текстури збираються в атласи, дублі ресурсів вирізаються, важкий контент розноситься за наборами під різні класи пристроїв.

Збірка перестає зростати з кожним новим рівнем, а встановлення й оновлення займають у гравця помітно менше часу — частина аудиторії відвалюється саме на цьому кроці.

Окремий ефект — зникнення класу відмов «виліт під час переходу між сценами». Він виникає, коли об’єкти та посилання живуть довше за свою сцену.

Ми фіксуємо контракт: сцена володіє своїми ресурсами, звільнення пам’яті детерміноване, а заміри на кожному переході входять до регламенту перевірок перед публікацією. Рушій на кшталт Unity дає для цього інструменти, але порядок задає архітектура, а не інструмент.

Варіанти реалізації 3D-проєкту: рушій, гібрид, збірка

Режим реалізації обирають не за смаком, а за тим, де в продукті проходить межа між тривимірною сценою та рештою логіки.

Якщо інтерфейс, каталог, акаунт і платежі живуть поза сценою, їх дешевше тримати окремо й підключати 3D як вбудовуваний шар, а не збирати весь продукт усередині ігрового рушія.

Різниця особливо помітна на слабких пристроях і в довгій підтримці: нативна графіка дає максимум контролю над частотою кадрів і пам’яттю, але потребує окремої кодової бази під кожну платформу. Нижче — чотири режими, між якими реально обирають.

Вибір фіксуємо на прототипі: одна сцена збирається у двох режимах, знімаємо заміри — час завантаження, частоту кадрів на слабкому пристрої, обсяг збірки. Далі рішення ухвалюється за цифрами, а не за обіцянками.

Етапи роботи над проєктом: від аудиту до передачі

Інженерна послідовність важливіша за швидкість: правка графіки на середині шляху перекроює схему сцен і відкочує вже ухвалені рішення.

Тому порядок робіт фіксуємо до старту, а кожен етап закриваємо вимірюваним результатом — що перевірено, на якому парку пристроїв і з яким запасом.

1. Аудит прототипу. Розбираємо, що вже зібрано: як влаштовані сцени, де просідає кадровий ритм, що утримує пам’ять. На виході — список вузьких місць із пріоритетом.
2. Схема проєкту. Розкладаємо структуру сцен, реєстр ресурсів і правила найменування так, щоб рівень довантажувався частинами й не тягнув за собою весь контент.
3. Налаштування графіки. Задаємо рівні якості: що вимикаємо на слабких пристроях, яке світло рахуємо заздалегідь, а яке — у реальному часі.
4. Приймання на пристроях. Перевіряємо не в редакторі, а на реальному парку: слабкі моделі, середній сегмент, свіжі апарати. Дивимося кадровий ритм, нагрів, пам’ять і час запуску рівня.
5. Оптимізація за замірами. Правимо лише те, що підтвердилося цифрами: атласи текстур, кількість об’єктів на сцені, частоту оновлення логіки. Після кожної правки — повторний прогін.
6. Передача проєкту. Віддаємо сховище коду з історією, інструкцію зі збірки, профілі якості, доступи до магазинів застосунків — і навчаємо команду замовника випускати реліз самостійно.

Передача — не формальність, а точка, після якої проєкт живе без нас. За потреби залишаємося на супроводі: стежимо за метриками випущених збірок і долучаємося до правок.

Що залишається у замовника: збірки, схеми й регламенти

Передача проєкту — це не архів файлів і не папка, яку збере лише автор. Ми оформлюємо репозиторій, правила збірки й документацію так, щоб стороння команда випустила оновлення й відкотила його без листування з нами.

• Вихідники в репозиторії замовника. Повна історія змін, гілки під задачі та мітки релізів; доступ у власника проєкту, а не в нас.
• Схеми сцен і структура проєкту. Карта рівнів, зв’язків модулів і налаштувань графіки під різні класи пристроїв.
• Правила збірки. Скрипти й інструкція: як відтворити середовище з нуля і які ключі підпису потрібні під кожну платформу.
• Регламент випуску й відкату. Порядок підготовки версії, перевірки перед публікацією та кроки повернення до попередньої версії.
• Документація. Опис модулів, схеми даних, точки підключення аналітики, платежів і рекламних мереж, журнал відомих обмежень.
• Доступи й права на матеріали. Публікаційні кабінети, сертифікати підпису та ліцензії на моделі, текстури, звук і шрифти з підтвердженням комерційного використання.

Кожен пункт перевіряємо на прийманні: якщо збірка не відтворюється на чистій машині за інструкцією, робота не вважається зданою.

Кейс: як прибрали вильоти під час перемикання сцен

Проєкт — казуальна 3D-гонка на Unity з десятьма трасами й перемиканням сцен між заїздом і меню. На пристроях нижнього цінового сегмента під час повернення в меню застосунок закривався: частка таких сесій сягала 7%, а у відгуках повторювалося «вилітає після гонки». На флагманах проблема не відтворювалася, тому її списували на слабке залізо й відкладали.

Діагностика показала інше: нова сцена завантажувалася до вивантаження старої, пік споживання пам’яті впирався в ліміт системи, і процес знімався примусово.

Ми перевели переходи на асинхронне завантаження з явним звільненням ресурсів, розбили важкі текстури й звук на підвантажувані пакети та додали прогрів матеріалів ще в меню. Об’єкти на трасі тепер беруться з пулу, а не створюються заново на кожному колі.

Стабільність підтвердили на реальних пристроях, а не лише в емуляторі: прогнали по 200 переходів між сценами на кожній моделі нижнього й середнього сегмента.

За словами замовника, потік звернень до підтримки щодо вильотів припинився, оцінка в магазині зросла з 3,8 до 4,5, а утримання після першої сесії — на третину.

Що робити, якщо є прототип, але проєкт не масштабується?

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

Проєкт упирається в стелю — плавність просідає на нових рівнях, а кожна нова механіка ламає дві наявні.

Перевикористовується при цьому більше, ніж здається. Математика керування, правила балансу, відчуття персонажа, схеми прогресії — це результат десятків ітерацій, і його не переписують, а виносять в окремий шар, що не залежить від відмалювання. Навколо нього й будується робоча версія.

Переписується шар представлення й робота з контентом. Рефакторинг графіки — це не «зробити красивіше», а розкласти ресурси за призначенням: спільні атласи, рівні деталізації, підвантаження в міру руху гравця. Матеріали та моделі приводять до єдиних правил, щоб нові рівні додавалися без правки коду.

Масштабування проєкту ведуть поетапно, зберігаючи іграбельну збірку на кожному кроці. Спочатку розділяють логіку й відображення, потім переносять контент, далі налаштовують збірку під різні класи пристроїв. Це і є переробка без втрат: гра залишається на екрані, а не перетворюється на піврічний котлован.

У підсумку прототип і робоча версія перестають бути різними проєктами. Терміни не подвоюються, вартість володіння теж: нові механіки додаються передбачувано, а вузькі місця видно на замірах до того, як їх помітить гравець.

Часті питання: інтеграції, оновлення, підтримка

Нижче — питання, які найчастіше задають перед стартом і в перші місяці після релізу. Вони стосуються не самої гри, а того, як проєкт живе далі: оновлюється, стикується із зовнішніми сервісами і що в підсумку залишається замовнику.

Як випускаються оновлення гри?

Контент — рівні, баланс, події — виносимо в серверні налаштування й змінюємо без перезбірки застосунку. Нові механіки та правки клієнтської частини виходять плановими релізами, із сумісністю минулих версій.

Як вбудовуються оплата, аналітика, авторизація?

Кожен зовнішній сервіс підключаємо окремим модулем з єдиним інтерфейсом. Зміна платіжного провайдера або системи аналітики не зачіпає ігрову логіку — правиться лише модуль інтеграції.

Кому належать права на вихідники?

Замовнику. Передаємо репозиторій з історією змін, конфігурації збірки, доступи до магазинів і серверної частини, документацію з архітектури — проєкт не залишається прив’язаним до нас.

Чи можна передати проєкт іншій команді?

Так. Код не залежить від наших внутрішніх сервісів, збірка відтворюється за інструкцією, передача займає кілька днів разом із розбором архітектури й поточного стану.

Обговоримо задачу: повернемося з оцінкою та планом робіт

Опишіть задачу — жанр, референси, цільові пристрої та те, що для вас вважається успіхом.

Ми повернемося з оцінкою проєкту й планом робіт: не із загальним «зробимо за кілька місяців», а з розбивкою за етапами, складом команди й точками приймання, де результат видно у збірці, а не в презентації.

Ділова розмова займає один дзвінок: уточнюємо ігровий цикл, профіль навантаження на сцені, вимоги до частоти кадрів на слабких пристроях і обмеження майданчиків публікації. За підсумками ви отримуєте:

• Склад команди: дизайнер механік, програміст ігрової логіки, інженер із графіки та продуктивності, 3D-художник, тестувальник — з ролями й завантаженням за етапами.
• Етапність: вертикальний зріз одного рівня, потім виробництво контенту, оптимізація й підготовка збірок до публікації.
• Точки приймання: робоча збірка на живому пристрої з профілюванням — фіксуємо, яку частку часу тримаємо цільовий поріг кадрів і скільки займає завантаження сцени.
• Формат звітності: збірки за розкладом, короткий список змін і відкритих ризиків, доступ до трекера задач із вашого боку.
• План робіт за термінами: тривалість етапів, залежності між ними і що може зсунути дату публікації.
• Що потрібно від вас: рішення щодо монетизації та цільових платформ, доступи до акаунтів магазинів, референси й пріоритети.

Така оцінка проєкту спирається на обсяг контенту й продуктивність, а не на здогадки.

Далі фіксуємо склад команди й першу точку приймання, стартуємо з вертикального зрізу: прототип потрапляє вам до рук раніше, ніж розгорнеться повне виробництво, і рішення щодо механік ухвалюються на робочій збірці, а не на словах.