Розробка мобільної гри Match-3: від алгоритмів до монетизації

Розробка match-3: де ламається ігровий цикл

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

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

Причина зазвичай у генераторі. Він розкладає фігури й перевіряє стартове поле на наявність ходу, але не перераховує розв'язність після каскаду й добору: поле доходить до стану, де збігів немає, а допустимого ходу теж.

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

Другий шар — порядок кроків ігрового циклу головоломки. Перевірка на наявність ходів, поставлена в кінець, виявляє глухий кут уже після анімації ходу.

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

Баланс рівнів match-3 і крива складності зазвичай збираються вручну за відчуттями: ліміти ходів, цілі та набір перешкод фіксують до появи даних про реальні проходження.

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

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

Що дає переробка ядра: утримання та прохідність

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

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

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

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

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

Після переробки сітки частка тих, хто доходить до кінця навчального блоку, зросла, а відвал на середніх рівнях перестав бути обривом.

Стабільність анімації — окрема гілка робіт.

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

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

Варіанти розробки match-3-гри та їх обмеження

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

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

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

Етапи роботи: від розбору механіки до релізу

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

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

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

Артефакти проєкту: вихідні коди, баланс-таблиці, регламенти

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

• Вихідний код гри — репозиторій з історією комітів, інструкцією зі складання та налаштуваннями середовищ; гілка релізу відокремлена від гілки розробки, доступи видаються вашим інженерам.
• Таблиці балансу — конфігурації в читабельних форматах (CSV, JSON): нагороди за рівень, вартість бустерів і підказок, криві складності за епізодами. Правляться без перезбирання застосунку.
• Правила генерації рівнів — опис алгоритму розкладки фішок, критеріїв розв'язності та каскадів, а також самі скрипти генератора й валідатора з прикладами прогонів.
• Схеми економіки та прогресії — потоки валют, точки монетизації, зв'язки між складністю рівня та утриманням гравця на першій сесії.
• Документація проєкту — архітектура клієнта та серверної частини, формати збережень, перелік зовнішніх сервісів та їхня роль в ігровому циклі.
• Регламент оновлень — порядок випуску версій, правила сумісності збережень між збірками та порядок відкату на попередній реліз.
• Інструкції з приймання та моніторингу — порядок тестування нових рівнів, набір метрик воронки та налаштування оповіщень про збої на проді.

Такий комплект дозволяє розвивати гру своєю командою або передати її іншому підряднику без відновлення логіки за непрямими ознаками.

Кейс: перезапуск сітки рівнів у діючій грі

Кейс мобільної гри: сітка на кілька сотень рівнів вийшла в реліз, але прохідність падала ступенями, а не плавно. На частині рівнів частка перемог трималася 12-18%, гравці вигорали до тридцятої-шістдесятої спроби й закривали застосунок.

Вивантаження подій у GameAnalytics показало: близько 70% відвалу припадає на двадцять «вузьких» рівнів із усієї сітки — тобто справа була не в складності загалом, а в конкретних розкладах поля.

Як переробили рівні, не зупиняючи гру

Розібрали сітку за кривою складності: для кожного відрізка задали цільову частку перемог (75-80% на перших рівнях, 45% у середині, 25% на піках) і звірили з фактичною.

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

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

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

Результат: частка перемог на проблемних рівнях зросла до 46%, відвал у середині сітки скоротився майже вдвічі, повторні сесії наступного дня додали дев'ять відсоткових пунктів. Розробка match-3 після релізу — це робота з балансом, а не наздоганяюче виправлення контенту.

Чим відрізняється каскадна сітка від чесної фізики падіння?

Каскадна сітка та фізика падіння фігур розходяться в тому, що відбувається після усунення фігур. У каскадній моделі поле — матриця цілих координат: елемент зник, верхні зсунулися на рядок, зверху долилися нові, і наступний каскад розв'язується в той самий такт.

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

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

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

Другий наслідок — відчуття чесності. У каскаді гравець бачить, у яку колонку що впаде, і планує на два-три ходи вперед, а програш читається як своя помилка.

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

Вибір зазвичай зумовлений механікою. Якщо ядро — головоломка з плануванням і рейтингами, беруть каскад: стан поля відтворюється в повторі, перевіряється на сервері й захищено від підміни результату.

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

Часті питання щодо механіки, балансу та підтримки

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

Чи доведеться переписувати баланс після запуску?

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

Чи можна перенести прототип з готового конструктора?

Так. Розбираємо сцени та механіку прототипу, переносимо логіку на актуальну гілку Unity і звіряємо з оригіналом за контрольними партіями. Баланс і рівні зберігаються; переписуємо архітектуру збережень і аналітики.

Що входить у передачу підтримки?

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

Як підключається аналітика?

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

Обговоримо задачу: механіка, обсяг, склад команди

Щоб повернутися з оцінкою обсягу робіт і планом етапів, потрібні ввідні — без них будь-яка оцінка перетворюється на широку вилку за строками та складом команди.

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

Що надіслати і що уточнити на старті:

• Платформи та охоплення пристроїв: тільки смартфони чи ще планшети, орієнтація екрана, мінімальна підтримувана версія системи — від цього залежить обсяг адаптації інтерфейсу.
• Матеріали прототипу: начерки рівнів, схеми ігрового поля, приклади візуального стилю, опис механік підбору та падіння фішок. Якщо є грабельний макет — розбираємо його першим.
• Правила рівня: розмір поля, набір фішок і бонусів, умови перемоги та програшу, ліміт ходів і поведінка поля, коли збігів немає.
• Монетизація: реклама між рівнями, внутрішні покупки, підписка або їх поєднання — від цього залежить схема прогресу та крива складності.
• Склад команди: які ролі закриваєте ви (гейм-дизайн, арт, аналітика), а які беремо на себе. Це напряму визначає план етапів і точки погодження.
• Обмеження та старт проєкту: бажані строки, вимоги майданчиків публікації, готові акаунти розробника, доступи до ваших систем.

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