Розробка мобільних ігор: де ламається генерація рівнів
Вузьке місце контенту проявляється на другому-третьому тижні після релізу.
Гравець проходить 20–40 рівнів за перші сесії, а автор рівнів вручну збирає 5–8 головоломок на тиждень: чим глибший прогрес, тим дорожчий кожен наступний — потрібно перевірити розв'язність, єдиність розв'язку та відсутність тупикових гілок. Команда або зупиняє прогрес штучними обмеженнями, або випускає рівні нижче планки якості.
Процедурна генерація рівнів знімає це обмеження, але лише за однієї умови — детермінізму.
Те саме зерно випадковості має давати ідентичну сітку, набір елементів і розв'язок на будь-якому пристрої та в будь-який момент часу: інакше лідерборди, збережені проходження та скарги «у мене не так, як у друга» стають нерозв'язним завданням підтримки.
Друге слабке місце — баланс складності головоломки. Генератор видає формально валідні рівні, але розподіл розв'язків розповзається: частина дощок проходиться одним очевидним ходом, частина потребує перебору.
Тому поряд із генератором ставиться розв'язувач, який рахує кількість шляхів, глибину пошуку та мінімальну кількість ходів, а також метрики проходження з аналітики.
Третє — розбіжність поведінки на платформах. Різна арифметика й округлення під час перевірки умов дають рівні, які на частині пристроїв стають нерозв'язними.
Лікується цілочисельною логікою генерації та перевіркою кожної партії на всьому парку цільових конфігурацій перед публікацією.
Далі розбираємо, як це закривається в розробці мобільних ігор: від архітектури генератора й кривої складності до конвеєра випуску рівнів і відкату невдалої партії.
Процедурна генерація рівнів у грі: що змінюється
Рівень не малюється вручну, а збирається зворотним проходом: генератор спочатку будує коректний розв'язок, потім знімає підказки до заданої щільності й перевіряє розкладку на розв'язність.
Зерно генератора фіксує конкретний рівень, тому дефект відтворюється одним рядком конфігурації, а не «іноді на третьому екрані». Крива складності задається набором параметрів — щільність підказок, глибина логічних зв'язок, допустима кількість тупиків.
Wave Function Collapse застосовуємо як один із режимів складання розкладки, коли потрібна варіативність поля зі збереженням структури. Основний контур залишається детермінованим: інваріанти перевіряються на кожному кроці, і рівень відбраковується до потрапляння у збірку.
Ефект вимірюється напряму. Одна налаштована гілка параметрів дає тисячі розрізнюваних рівнів без розширення команди дизайнерів, а нова порція для оновлення головоломки збирається прогоном генератора, а не місяцями ручної роботи.
Пакет автотестів перевіряє розв'язність, відсутність хибних тупиків і досяжність кожної гілки — клас помилок «рівень не проходиться» закривається до релізу.
Правка складності стає налаштуванням, а не перемальовуванням: змінюємо параметри гілки, проганяємо пакетну валідацію й отримуємо новий набір зі збереженою прогресією.
У розробці мобільних ігор це і є контент без зростання команди — масштабується кількість рівнів, а не кількість людей.
Режими генерації рівнів та їхні обмеження
Три режими генерації рівнів відрізняються не якістю, а тим, хто відповідає за баланс — алгоритм чи дизайнер.
Повна генерація дає необмежений потік рівнів із зерна, але розв'язність доводиться доводити окремим перевіряльним алгоритмом, а складність зростає статистично, а не за авторським задумом.
Ручний дизайн рівнів тримає контроль над ритмом і навчанням гравця, зате трудовитрати на кожен рівень високі, і контент закінчується раніше, ніж інтерес.
Гібридна генерація знімає цю суперечність: генератор збирає каркас і розкладку, дизайнер задає допустимі комбінації, критичні точки та правила ускладнення. Обмеження генератора описуються декларативно, тому їх правлять без перезбирання логіки рівнів.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повна генерація | Нескінченний режим, щоденні завдання, перевірка гіпотез на обсязі | Потрібен окремий контроль розв'язності; складність розподіляється статистично; періодично трапляються тривіальні розкладки |
| Гібридна генерація | Основна кампанія, сезонні набори, довга дистанція | Потребує бібліотеки шаблонів і налаштування правил; помилка в правилах тиражується на весь потік рівнів |
| Ручний дизайн рівнів | Навчання, ключові та сюжетні рівні, фінали розділів | Високі трудовитрати на рівень; масштабування впирається в людей; правка балансу зачіпає кожен рівень окремо |
Режими не взаємовиключні: навчальні рівні залишаються ручними, щоденні завдання генеруються повністю, а кампанія збирається гібридно. Перемикання між ними не потребує переписувати логіку, якщо формат опису рівня спільний.
Етапи розробки головоломки з генерацією рівнів
Роботу починаємо з формалізації правил: які елементи беруть участь у рівні, які комбінації допустимі, де закінчується комфортна складність.
Від цих правил залежить схема генерації рівнів — детермінований алгоритм, який за номером рівня видає одну й ту саму розкладку в усіх гравців.
- Розбір завдання та правил генерації: фіксуємо набір елементів, обмеження на їхні комбінації, темп зростання складності та потрібний обсяг контенту на старті.
- Проєктування схеми генерації рівнів: ділимо алгоритм на фази — розстановка, перевірка зв'язності, підстановка цілі, — задаємо зерно й заборону тупикових стартових станів.
- Перевірка прохідності: кожен згенерований рівень проганяємо через розв'язувач, який шукає розв'язок у межах заданої кількості ходів; розкладки без розв'язку відбраковуються автоматично.
- Балансування складності: будуємо криву за кількістю ходів і кількістю варіантів розв'язку, щоб зростання йшло плавно і на середині шляху не з'являвся рівень-стіна.
- Складання оболонки та зв'язки з генератором: інтерфейс, збереження прогресу, робота без мережі, підказки на основі того самого розв'язувача.
- Приймання та передача проєкту: прогін автотестів на масиві рівнів, документація з правил і алгоритму, доступи до збірки та вихідників.
На прийманні показуємо звіт: скільки рівнів згенеровано, яка частка пройшла перевірку прохідності, як розподілилася складність за прогресією.
Передача проєкту включає не лише вихідники, а й опис правил — команда замовника може додавати свої механіки та змінювати криву складності без нас.
Артефакти проєкту: правила генерації та документація
Проєкт закінчується не релізом у магазинах застосунків, а набором артефактів, з якими команда замовника працює далі сама. Усе це лежить у репозиторії замовника з першого дня: вихідний код, конфігурації, скрипти збірки та документація — а не вивантажується в кінці одним архівом.
- Правила генерації рівнів — формальний опис: які параметри задають запас ходів, щільність перешкод і криву складності за розділами, які обмеження гарантують розв'язність. Поруч — сама конфігурація правил, яку правлять без зміни логіки.
- Таблиці балансу — нагороди, темп появи механік і складність винесено у файли даних. Правка чисел не потребує перезбирання застосунку, результат видно одразу на тестовому прогоні.
- Автоперевірка рівнів — прогін партії згенерованих рівнів: відсікає нерозв'язні та тривіальні, віддає звіт щодо розподілу складності. Захист від того, що після правки коефіцієнта гра стала занадто легкою.
- Збірки під дві платформи — релізні збірки під обидві цільові платформи, профілі та ключі підпису, скрипти збірки. Випуск версії — одна команда замість ручної послідовності кроків.
- Регламент оновлень — порядок випуску контенту: гілки, перевірки перед релізом, критерій і спосіб відкату на попередню версію, вікно доставки сезонних наборів рівнів.
- Документація проєкту — архітектура, схема збереження прогресу, інструкція «як додати нову механіку цілком» із розбором на вже наявній.
- Набір тестових сценаріїв — фіксовані початкові значення генератора та збережені стани прогресу, на яких скарга гравця відтворюється за один прогін, а не за день пошуків.
Кейс: головоломка на двох платформах без переписування
Головоломка виходила одразу на двох платформах: спільна логіка поля й правил, відмінності — лише в шарі введення та покупок. Рівні при цьому набирали руками: дизайнер збирав сітку, проганяв її на розв'язність і заливав у спільний формат опису. Пакет із 60 рівнів займав 4-6 тижнів, а сильні гравці проходили його за три вечори й ішли.
Що було вузьким місцем
Утримання на 7-й день трималося близько 18%, на 30-й падало до 6% — контент закінчувався швидше, ніж його встигали робити. Правки балансу вимагали перезбирання всього пакета, а частина рівнів усе одно поверталася зі скаргами «немає розв'язку».
Та сама сітка на телефоні й планшеті відчувалася по-різному, і розбір кожної такої ситуації з'їдав час команди.
Що змінили
Логіку рівня перенесли в генератор: він збирає сітки за набором правил — допустимі фігури, щільність перешкод, ліміт ходів — і перевіряє розв'язність до потрапляння у збірку.
Непрохідних ситуацій у релізі більше немає, а складність задається кривою: перші рівні навчають механіки, далі зростає кроками.
Метрики після
Випуск у Google Play і App Store став одним циклом: генератор і правила спільні, відрізняються лише шари платформи. Потік рівнів перестав бути вузьким місцем — щоденний набір збирається під конкретного гравця, а баланс правиться параметрами, а не перезбиранням пакета.
Утримання на 7-й день зросло з 18% до 31%, на 30-й — з 6% до 12%, частка сесій зі скаргою «застряг» упала втричі.
Чим процедурна генерація рівнів відрізняється від ручного дизайну
Пряма відповідь: це не конкуруючі підходи, а різні інструменти під різні завдання. Ручний дизайн рівнів виграє там, де гравець навчається механіки: перші сесії, введення нових елементів, ключові віхи прогресу.
Процедурна генерація виграє там, де потрібен обсяг — щоденні завдання, нескінченні режими, середина кампанії.
Різниця в ціні помилки. Ручний рівень проєктується під конкретну криву складності, і дизайнер відповідає за кожну пастку, але людино-години зростають лінійно з кількістю рівнів.
Генератор видає сотні конфігурацій за хвилини, зате без правил легко отримує нерозв'язні розкладки й одноманітні послідовності.
| Підхід | Де сильніший | Обмеження |
|---|---|---|
| Ручний дизайн рівнів | навчання механік, перші 10–15 рівнів, сюжетні віхи | час дизайнера зростає лінійно, дорого масштабувати після релізу |
| Процедурна генерація | маса рівнів, щоденні завдання, реіграбельність | нерозв'язні конфігурації, слабка крива складності, повтори |
| Гібрид: каркас вручну + керована випадковість | сезонний контент і підтримка після запуску | потрібна обв'язка: валідатор, метрики проходження, ручна доводка |
Керована випадковість — це генератор, затиснутий у правила: фіксоване зерно на рівень, набір шаблонів кімнат, ліміт на кількість допустимих розв'язків і цільовий коридор складності.
Кожен згенерований рівень проганяється розв'язувачем: якщо шлях коротший або довший за заданий, розкладка відбраковується й зерно перераховується. Додатково перевіряємо, що стартові ходи не підказують розв'язок і що підказка не відкриває тупик.
На практиці ми закладаємо в такі проєкти валідатор як частину збірки — частка відбракованих розкладок тримається в межах 5–10%, розкид складності всередині розділу не виходить із коридору, а час до першого розв'язку в нових гравців не просідає.
Типовий розклад: ключові рівні малюються вручну, середина та щоденні режими йдуть із генератора з ручною доводкою. Обговоріть завдання — повернемося з оцінкою, якій частці рівнів потрібен дизайнер, а якій достатньо правил.
Технічні питання щодо генерації та кросплатформи
Генератор рівнів — не чорна скринька: кожна заготовка проходить автоматичну перевірку розв'язності, а крива складності звіряється з цільовим профілем. Нижче — сумніви, які найчастіше розбираємо перед прийманням.
Як відсікаються непрохідні рівні?
Згенеровану головоломку розв'язує автоматичний розв'язувач за обмеженої кількості ходів. Якщо розв'язку немає або він довший за ліміт, заготовка відбраковується, а генератор отримує новий набір параметрів.
Додатково рівень проганяється з різних точок старту — так відсікаються тупики за невдалої послідовності дій.
Чи не стануть рівні передбачуваними?
Кожен рівень будується від зерна генерації: одне зерно дає одну розкладку. Це потрібно для відтворюваності помилок і повторного проходження, але грається неоднаково — пул шаблонів і набір допустимих ходів змінюються разом зі складністю. Окремо контролюємо, щоб на середніх рівнях не скупчувалися однотипні розв'язки.
Що з відмінностями між платформами?
Збираємо обидві версії зі спільної кодової бази на Unity, але поведінку перевіряємо на живих пристроях: емулятор не передає реальну чутливість жестів. Тестуємо безпечні зони екрана, паузу фонових процесів і збереження прогресу при перериванні.
Якість генерації перевіряємо за зрізами: частка розв'язуваних заготовок, розкид кількості ходів до перемоги, точки виходу гравців. За цими даними правимо параметри генератора, а не окремі рівні.Обговоримо завдання: що потрібно для оцінки вашої головоломки
Щоб оцінка розробки головоломки спиралася на механіку, а не на «середню ціну за ринком», потрібен вхідний набір даних.
Чим конкретніші ввідні, тим менше припущень у розрахунку і тим чесніший план етапів: поле фіксованого розміру з перевіркою розв'язності та нескінченний генератор зі зростанням складності — це різний обсяг робіт, хоча обидва називаються «головоломкою».
- Правила рівня: розмір поля, набір елементів, умови перемоги й поразки, ліміт ходів або часу.
- Логіка процедурної генерації: що має бути випадковим, а що задано жорстко; чи потрібна перевірка розв'язності та єдиності розв'язку на кожному рівні.
- Режими та прогресія: нескінченний режим, послідовність рівнів зі зростанням складності, щоденні завдання, порівняння результатів гравців.
- Платформи та цільові пристрої: де запускаємо в першу чергу, обмеження за обсягом інсталяційного пакета та за роботою без мережі.
- Матеріали з візуалу: макети або приклади-орієнтири, опис стилю, вимоги до анімації та звуку.
- Обмеження проєкту: бажані строки, хто на вашому боці ухвалює рішення зі спірних місць, чи вже є напрацювання або прототип.
У відповідь повернемо технічне завдання на гру з описом механіки та точок контролю, оцінку, розбиту за етапами — прототип, генератор рівнів, інтерфейс, збірка та публікація, — і план запуску з відкритими ризиками. Опишіть завдання, і ми повернемося з оцінкою та планом.
