Розробка merge-гри: де ламається економіка проєкту
Merge-механіка здається простою: поле, ланцюжок злиттів, ресурс на ходи. Саме ця простота й обманює — економіка тут пов'язана в один контур, де поле, випадання нагород і таймери відновлення тягнуть одне одного.
Помилка в одному вузлі проявляється не відразу, а на другому-третьому тижні, коли переробка коштує найдорожче.
Перша типова точка відмови — розсинхрон поля й нагород. Якщо таблиця випадання не перерахована під фактичну сітку й вартість ходу, гравець отримує предмети, яким немає місця, або впирається в порожнє поле. Прогрес зупиняється, і механіка втрачає довіру раніше, ніж гравець доходить до платного контенту.
Друга — знецінення валюти до середини прогресії. Внутрішньоігрові накопичення дешевшають швидше, ніж зростають ціни на покращення, і покупки перестають відчуватися рішенням.
Лікується це не підкруткою одного коефіцієнта, а перезбиранням кривої нагород і вартості злиттів на всьому горизонті.
Третя й найдорожча — обрив ігрового циклу на третьому-четвертому рівні. Гравець доходить до першої стіни, бачить, що наступний крок вимагає очікування без зрозумілої мети, і йде.
Провал утримання в merge-грі починається саме тут, а відтік платників іде слідом: платять ті, хто вже встиг вкласти час.
Розробка merge-гри під ключ починається з цих вузлів, а не з оформлення. Ми рахуємо симуляцію прогресії, перевіряємо криві на горизонті тижнів і лише потім фіксуємо механіку — розбираємо, як це закривається в робочому релізі.
Що дає прорахована merge-механіка проєкту
Прорахована механіка починається не з сітки й перетягування, а з моделі: скільки предметів видає кожне джерело за годину ігрової сесії, скільки коштує наступний крок ланцюжка і що гравець отримує натомість.
Економіка merge-гри живе в таблицях — вартість рівня, дохід, інтервал відновлення енергії, шанси випадання рідкісних предметів. Поки ці числа зібрані в один набір параметрів, баланс merge-механіки правиться за години, а не переписуванням ігрової логіки.
Перший вимірюваний ефект — швидкість виходу оновлень. Правка нагород за щоденний вхід, темпу ланцюжка або умов пізніх рівнів перетворюється на зміну значень і прогін перевірок на прогрес, а не на хірургію по коду.
Оновлення виходить без ризику зачепити сусідні механіки, тому нові рівні й події додаються помітно частіше.
Другий ефект — частка гравців, які доходять до пізніх рівнів. Події за кожним кроком ланцюжка збираються в Firebase і розкладаються у воронку прогресу: видно, на якому саме рівні зупиняється основна маса і чого їй не вистачає — енергії, часу відновлення чи зрозумілої нагороди.
Третій — зникає цілий клас відмов: «глухий кут» на середині, коли прогрес упирається в недосяжну вартість наступного предмета і гравець кидає гру.
Четвертий — зростання утримання гравців: рівна крива складності тримає темп, повернення на другий і сьомий день зростають, бо перед гравцем завжди стоїть досяжна наступна мета.
Варіанти роботи: повний цикл, прототип, доопрацювання
Формати роботи над грою різняться не обсягом завдань, а точкою входу — тим, що вже є в замовника: гіпотеза на папері, порожній аркуш або чужий проєкт у проді.
Від цього залежить, що робимо першим: перевіряємо механіку на прототипі merge-гри, збираємо продукт цілком або розбираємо наявний код і економіку перед правками.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Прототип merge-гри | Потрібно перевірити гіпотезу: сітка злиття, ланцюжки прогресії, генератор предметів, витрата енергії | Арт і мета-шар мінімальні, метрики утримання на довгій дистанції не збираються — прототип відповідає лише за механіку |
| Повний цикл розробки гри | Запуск з нуля: механіка, економіка, мета, івенти, монетизація, збірки під магазини | Довше до першого релізу, вимагає зафіксованого бачення продукту й готовності до ітерацій за аналітикою |
| Доопрацювання чужої гри | Робочий проєкт: нові рівні та івенти, перебалансування економіки, вбудовані покупки й рекламні покази | Залежить від читабельності чужого коду й конфігів; частина завдань спочатку йде в аудит і оцінку ризиків |
Вибір режиму визначається стадією проєкту. Якщо зв'язка генератора предметів, енергії та вартості відновлення ще не перевірена, починати повний цикл ризиковано: помилку в балансі дешевше знайти на прототипі, де правка економіки займає години, а не релізний цикл.
Доопрацювання чужої гри завжди стартує з розбору: дивимося, де зберігаються дані гравця, чи винесено баланс у конфігурації, чи можна змінювати ціни й нагороди без перезбирання збірки.
Якщо проєкт збирається і конфіги читабельні, ми вбудовуємося в наявний процес і працюємо ітераціями. Якщо ні — чесно називаємо, які вузли доведеться переписати, і в якому порядку, щоб не зупинити поточні оновлення.
Етапи впровадження: від схеми поля до сезонних подій
Порядок робіт фіксуємо до старту: у merge-грі баланс зав'язаний на вміст поля, і правка одного множника ламає всю прогресію. Тому йдемо від моделі до даних, а не навпаки — кожен ступінь спирається на заміри попереднього, і жоден етап не починається «на око».
-
Аудит і постановка моделі. Розбираємо напрацювання й орієнтири, фіксуємо очікувану тривалість сесії та метрики приймання. На виході — опис поля, джерел предметів і цілей, до яких зведемо результат.
-
Проєктування поля та правил злиття. Задаємо сітку, генератори й ланцюжки предметів, обмеження за ресурсами. Усі параметри виносимо в таблиці конфігурації, щоб правка не вимагала випуску нової версії застосунку.
-
Налаштування балансу гри. Рахуємо криві вартості та ймовірності випадання, проганяємо модель на довгому горизонті. Так глухі кути й завищені вимоги видно до релізу, а не у відгуках.
-
Перевірка механіки на гравцях. Збираємо тестову групу й дивимося телеметрію: час до першого злиття, частка тих, хто дійшов до ключових рівнів, точки відтоку. Криві правимо за цими цифрами, а не за відчуттями.
-
Сезонні події в грі. Налаштовуємо календар і окремі гілки нагород так, щоб подія вмикалася й знімалася однією конфігурацією — без збірки й модерації оновлення.
-
Запуск, передача та підтримка. Виводимо метрики економіки на панель спостереження, віддаємо регламент випуску контенту й документацію з балансу. Далі ведемо сезони разом із вашою командою.
Конфігурація балансу, схеми поля та регламенти оновлень
Результат роботи — не лише зібрана гра, а й комплект матеріалів, за якими проєкт живе без нас. Баланс тримається не на відчуттях, а на таблицях: ціни, нагороди та видача ресурсів винесені в окремий шар конфігурації, тому правки не вимагають перезбирання застосунку.
- Таблиці балансу й нагород — ціни покращень, вартість будівель, криві досвіду та енергії, розкид випадання предметів: один формат, поля з поясненнями, версіонування правок.
- Правила видачі ресурсів — що нараховується за завдання, які ліміти діють на добу, за яких умов видається бонус і як це зміщує прогрес за рівнями.
- Схеми поля та генерації — стартовий стан, правила появи предметів, дерево злиттів, набір заготовок рівнів різної складності.
- Опис ігрового циклу — шлях від входу до повернення: де точка першого успіху, як відновлюється енергія, що повертає гравця наступного дня.
- Документація з гри — карта механік, зв'язки між економічними параметрами, словник сутностей: новий гейм-дизайнер входить у проєкт без усних пояснень.
- Регламент оновлень — як готується випуск, де зберігаються версії, що змінюється на ходу без оновлення застосунку, а що вимагає викладки в магазини.
- Передача проєкту замовнику — доступи до коду, збірки, аналітики та панелі керування контентом, інструкції для підтримки, план перших самостійних правок.
Такий комплект знімає головний ризик підрядної розробки — залежність від людей, які робили гру.
Кейс: як проєкт вийшов із просідання утримання
Проєкт прийшов до нас на етапі, коли гра вже була в сторах, але утримання першого дня трималося на 28% за мети вище 40%.
Гравці проходили 6-8 рівнів і йшли: злиття на старті давалися повільно, поле заповнювалося швидше, ніж очищалося, і до п'ятого рівня виглядало безнадійно забитим.
Розбір воронки за логами GameAnalytics дав три причини: медіана до першого злиття — 90 секунд, частка глухих генерацій, де новий предмет нема чим злити, на рівнях 5-8 сягала 14%, а ціни апгрейдів зростали швидше за дохід. Найсильніше це било по перших двох заходах — там втрачалася половина новачків.
У поле злиття та економіку внесли точкові правки:
- стартову сітку скоротили, щоб перші чотири злиття гравець робив за 30 секунд;
- генератор отримав правило: при заповненні понад 70% клітинок випадає предмет, який гарантовано зливається;
- переписали криву цін перших рівнів і винесли підказки на окремий витратний ресурс;
- нагороду за рівень зробили змінною — за довгі серії злиттів платять більше.
| Метрика | До правок | Після |
|---|---|---|
| Утримання першого дня | 28% | 41% |
| Утримання сьомого дня | 9% | 16% |
| Медіанний рівень за захід | 7 | 14 |
| Частка гравців із покупками | 1,4% | 3,2% |
Правки вносили хвилями й порівнювали когорти однакового трафіку, щоб не сплутати ефект із сезонним сплеском. Зник цілий клас відмов — «застряг, нема чим злити, закрив гру»: його частка у звітах упала з 14% до 3%. Це підтвердило, що просідання було не в залученні, а в економіці перших заходів.
Що робити, якщо механіку вже зібрано, але економіка не сходиться?
Економіка merge-гри майже ніколи не розходиться в одній цифрі — вона ламається на стику джерел валюти (генератори, завдання, щоденний вхід), стоків (енергія, прискорювачі, слоти поля) і кривої прогресії.
Тому переробка merge-механіки починається не з правки коефіцієнтів, а з аудиту наявного проєкту: знімаємо телеметрію за фактичними діями — скільки злиттів за сесію, на якій ланці ланцюжка гравець застрягає, який ресурс зростає без стоку.
Аудит зазвичай показує, що ядро здорове: сітку поля, правила злиття й таблицю переходів між рівнями перезбирати не потрібно. Перезбирають стоки й темп — вартість енергії, нагороди за замовлення, ліміт активних генераторів.
Ці вузли живуть у конфігураціях, а не в коді, тому економіку можна виправити без нової збірки й без ризику для випущеної версії.
Далі гіпотези проганяємо на моделі: кілька прогонів на 30–60 ігрових днів показують, де ресурс іде в надлишок, а де гравець упирається в стіну раніше, ніж відкривається наступна гілка злиттів. Модель дає розподіл за рівнями й дозволяє порівняти варіанти кривих до правок у живому застосунку.
Прогрес гравців переносимо через версіонування формату збереження: старий запис читається, значення перераховуються за відображенням у нові, випалі сутності компенсуються нагородами.
Нову механіку вмикаємо спочатку на частині аудиторії, зберігаючи можливість повернутися до попередніх конфігурацій.
Порядок правок важливіший за їхній обсяг: спочатку стоки й темп, потім нагороди, лише потім нові гілки злиттів — так кожна хвиля залишається відкочуваною, магазин продовжує працювати, а економіка приходить до заданого темпу.
Технічні сумніви: генерація поля, захист даних, перенесення прогресу
Сумніви на етапі оцінки стосуються не механіки злиттів, а того, що навколо неї: передбачуваності розкладів, чесності нагород, перенесення прогресу й доступу до даних. Нижче — прямі відповіді на запитання, які найчастіше ставлять до старту.
Як генерація поля обходиться без глухих розкладів?
Поле будується зворотним ходом — від цільового ланцюжка злиттів, а не випадковим засипанням. Кожен кандидат проганяється через симуляцію партій із різними стратегіями, і в реліз іде лише розклад, який проходиться кількома маршрутами й не впирається у відсутність ходів.
Розклад зберігає вихідне зерно генератора, тому звернення гравця розбирається за відтворюваною послідовністю.
Як рахуються нагороди і що заважає накрутці?
Нагороду нараховує сервер: клієнт надсилає лише дію, а баланс, випадання предметів і прогрес змінює авторитетна сторона за журналом подій.
Перевірки правдоподібності — темп дій, швидкість зростання ресурсів, повторювані патерни — позначають аномалії для розбору, а не блокують гравця одразу. Економіка винесена в конфіг, тому баланс правиться без випуску нової збірки.
Як переноситься прогрес і чи захищені дані?
Прогрес прив'язаний до акаунта, а не до пристрою: збереження йдуть у хмару з версіонуванням і міграціями під актуальну схему даних, вхід — через акаунт платформи, включно з App Store. При розсинхроні конфлікт вирішується за журналом дій.
Персональних даних збираємо мінімум; обмін шифрується, доступ розмежований за ролями, дії адміністраторів пишуться в журнал.
Обговоримо завдання і повернемося з планом робіт
Щоб розмова була предметною, а оцінка проєкту — не «за відчуттями», зберімо вхідні дані по ядру, економіці та мета-прогресії. Чим конкретніші вихідні дані, тим менше припущень у плані робіт над грою і тим точніші строки.
- Ядро: що з чим об'єднується, дерево предметів, розмір поля, умови появи нових гілок і правило, за яким ланцюжок закривається.
- Економіка: джерела та стоки ресурсів, енергія, таймери відновлення, що обмежує прогрес на ранньому й пізньому етапі.
- Мета-прогресія та контент: зони, сезонні події, як часто плануються оновлення і хто відповідає за баланс після запуску.
- Монетизація: набір вбудованих покупок і рекламні точки — як вони вбудовані в цикл, щоб не ламати темп гри.
- Аналітика: які події потрібно фіксувати, як рахуємо прогрес за час відсутності гравця, що показуємо у звітах.
- Стан проєкту: чи є прототип, чи потрібне перенесення напрацювань, цільові платформи й категорії пристроїв.
- Доступи: якщо гра вже випущена — до репозиторію, збірок, кабінетів магазинів і панелі аналітики.
Під час розбору ставимо зустрічні запитання: як швидко гравець виходить на першу значущу нагороду, який відтік вважаємо неприпустимим, які правки балансу мають вноситися без випуску нової збірки.
Повертаємося з планом: етапи робіт, склад команди на кожному, оцінка строків за етапами, порядок випуску оновлень і критерії приймання. Опишіть завдання — повернемося з оцінкою та планом робіт.
