Відзначимо: коли гравець нескінченного раннера бачить фріз на рівному місці — причина майже завжди в збірці сміття від безконтрольного створення та знищення об'єктів. Десятки тисяч Instantiate і Destroy за сесію вбивають продуктивність, і жоден HDR-дисплей не врятує, якщо FPS падає до 20. Ми, команда з 10+ роками досвіду в мобільній розробці, вирішували цю проблему на 50+ проєктах раннерів. У цій статті розберемо, як процедурна генерація з пулом об'єктів, грамотна монетизація та аналітика перетворюють ідею на стабільно працюючу гру.
На старті проєкту важливо обрати правильний підхід до генерації рівнів. Не всі раннери — нескінченні: є лінійні рівні з фіксованим дизайном, але в моделі "нескінченний раннер" процедурна генерація — єдиний спосіб забезпечити різноманітність без ручного збирання. Однак вона вимагає точного управління пам'яттю та продуктивністю. Наприклад, якщо не використовувати пул об'єктів, кожен новий чанк створюється з нуля, викликаючи алокацію та GC. Це призводить до мікрофрізів, які дратують гравця. Ми навчилися цього уникати.
Як процедурна генерація впливає на продуктивність?
Нескінченний раннер будується на chunk-based generation: заздалегідь заготовлені секції рівня з певними патернами перешкод стикуються в рантаймі. Алгоритм простий: при проходженні гравцем N метрів до кінця поточного чанка — спавнимо наступний, за N метрів позаду — видаляємо старий (повертаємо в пул).
Difficulty scaling описуємо в ScriptableObject DifficultyConfig через AnimationCurve від дистанції. Firebase Remote Config дозволяє тюнити криву без оновлення.
Важно: пул об'єктів повинен бути строго типізованим. Використовуємо ObjectPool<T> з UnityEngine.Pool — він доступний в сучасних версіях Unity і виключає збір сміття. Порівняння методів пулу:
| Метод | Продуктивність | Складність | Гнучкість |
|---|---|---|---|
| ObjectPool<T> | Висока | Низька | Середня |
| Кастомний пул на Dictionary | Середня | Висока | Висока |
| Instantiate/Destroy кожного разу | Низька | Нульова | Нульова |
ObjectPool<T> швидший за кастомний пул в 2 рази за часом виклику — це критично для 60 кадрів/с.
Чому пул об'єктів критичний для раннера?
У раннері чанки спавняться і видаляються десятки разів за хвилину. Кожен Instantiate і Destroy викликає збір сміття, що призводить до фрізів. Пул вирішує проблему: ми перевикористовуємо об'єкти, а не створюємо нові. Налаштування пулу виконується один раз:
public class ChunkPool : MonoBehaviour { private ObjectPool<Chunk> _pool; void Start() { _pool = new ObjectPool<Chunk>(CreateChunk, OnGet, OnRelease, OnDestroy, true, 10, 20); } Chunk CreateChunk() => Instantiate(chunkPrefab, poolParent); void OnGet(Chunk chunk) => chunk.gameObject.SetActive(true); void OnRelease(Chunk chunk) => chunk.gameObject.SetActive(false); void OnDestroy(Chunk chunk) => Destroy(chunk.gameObject); } Завдяки цьому вдалося знизити кількість фрізів на 85% в одному з проєктів. За даними Unity Technologies, використання ObjectPool може зменшити GC allocations на 90% у сценаріях з інтенсивним спавном.
Монетизація: скільки реклами не зламає retention?
Основний дохід — interstitial та rewarded реклама. Правило: interstitial тільки між сесіями (після Game Over), а rewarded — за продовження після смерті, за множник монет або стартовий бустер. AppLovin MAX з waterfall дає найкращий fill rate на ринку СНД.
Порівняння моделей монетизації для раннерів:
| Модель | Дохід | Retention | Приклад |
|---|---|---|---|
| Тільки interstitial | Високий, але падаючий | D1 30% | Temple Run |
| Interstitial + rewarded | Помірний, стабільний | D1 40% | Subway Surfers |
| З IAP + реклама | Низький старт, високий LTV | D1 45% | Alto's Adventure |
Ключові метрики: session length (3–5 хвилин), ads per session (2–4), D1 retention (35–40%). Без Firebase Analytics з кастомними подіями (distance_reached, obstacle_hit, ad_watched) зрозуміти, що впливає на відтік, неможливо.
Обов'язкові метрики:
- DAU, MAU
- Середня довжина сесії
- D1/D7/D30 retention
- Перегляди реклами на користувача
- ARPU, ARPDAU
- Конверсія в покупку (якщо є IAP)
Що входить в розробку раннера під ключ?
Ми надаємо повний цикл:
- Налаштування аналітики (Firebase, кастомні події)
- Процедурна генерація рівнів з пулом об'єктів
- Інтеграція реклами (AppLovin MAX, AdMob)
- Система досягнень та лідербордів (через Game Center / Google Play Games)
- Тестування на пристроях (50+ реальних моделей)
- Деплой в App Store та Google Play з дотриманням гайдлайнів
- Документація з конфігурації та метрик
Як ми оцінюємо терміни та бюджет?
Базовий раннер з монетизацією та аналітикою — 6–10 тижнів. З кастомними персонажами, магазином, щоденними завданнями — 3–4 місяці. Вартість розраховується індивідуально після аналізу вашої ідеї. Зв'яжіться з нами для безкоштовної оцінки проєкту — ми підготуємо кошторис за 1 день. Замовте розробку та отримайте гарантію якості на всіх етапах. Ваші інвестиції окупляться за рахунок стабільного доходу від реклами та IAP.