Налаштування процедурної генерації рівнів в іграх

Настройка процедурної генерації рівнів в іграх

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

Ключові підходи до генерації

BSP (Binary Space Partitioning). Рекурсивне ділення простору на прямокутні секції, в кожній — кімната, між кімнатами — коридори. Класика dungeon crawler: Rogue, NetHack. Плюс — гарантована прохідність. Мінус — прямокутна монотонність без додаткового post-processing.

Wave Function Collapse (WFC). Алгоритм, що використовує обмеження сумісності між тайлами. Кожна клітинка має набір допустимих станів; при виборі стану сусідні клітинки отримують обмеження. Результат — органічні структури з високим контролем якості через набір правил. Працює з 2D-тайлами та 3D-воксельними структурами. У Unity готові реалізації на GitHub (mxgmn/WaveFunctionCollapse), є підтримка в руху через TilemapRule.

Noise-based terrain. Для відкритих світів — Perlin Noise, Simplex Noise або більш сучасний Domain-Warped FBM (Fractional Brownian Motion). Unity Terrain з TerrainData.SetHeights() приймає 2D float array — генерація висот через шум в 30 рядків коду. Складність починається з біомів: переходи між біомами, розміщення об'єктів по біому, контроль щільності.

Grammar-based генерація. Для нарративних рівнів з обов'язковими событіями: граф прохождения описується через правила (start → combat → loot → boss → exit), генератор будує рівень, що забезпечує цей граф. Застосовується в action-roguelite, де важливі драматургія прохождения, а не тільки різноманіття.

Найскладніша частина — контроль якості

Генерація працює, але не кожен згенерований рівень «хороший». Три проблеми, які виникають завжди:

Гарантія прохідності. Flood fill або pathfinding (A*) від точки входу ко всім ключовим точкам (вихід, обов'язкові предмети, боси). Якщо pathfinding не знайшов шлях — перегенерація. Важливо: перегенерація повинна бути швидкою (< 16ms на мобільному), інакше гравець видит затримку при завантаженні.

Надмірна рівномірність. WFC та BSP без додаткових правил дають «прісний» результат — нема акцентів, нема цікавих місць. Рішення: явні «якорні» точки (anchor rooms): стартова кімната, босс-кімната, таємна кімната — генеруються по фіксованим шаблонам та розміщуються в обов'язкових позиціях. Решта — процедурно.

Занадто пусті або занадто заповнені рівні. Розміщення об'єктів (ворогів, предметів, пасток) не можна робити pure random — вийде або пустиня, або непрохідне скупчення. Робочий підхід: Poisson Disk Sampling для рівномірного розподілу з мінімальною дистанцією між об'єктами + ваги по типу кімнати та дистанції від старту.

Приклад реалізації на Unity

Типова архітектура для 2D dungeon-генератора:

LevelGenerator
├── RoomGenerator        — BSP / шаблони
├── CorridorConnector    — з'єднання кімнат
├── ValidityChecker      — flood fill прохідності
├── PopulationSystem     — розстановка об'єктів
└── TilemapPainter       — запис в Tilemap

LevelGenerator приймає LevelConfig (ScriptableObject з seed, розмірами, параметрами) та повертає LevelData — граф кімнат з метаданими. TilemapPainter рендерит LevelData в Tilemap з потрібним набором тайлів. Розділення генерації та рендерингу дозволяє використовувати один генератор для різних візуальних тем (dungeon, cave, ship).

Seed для воспроизводимости. Random.InitState(seed) перед генерацією — та ж seed завжди дає той же рівень. Це потрібно для: шерингу рівнів між гравцями (Daily Run у roguelite), дебаггингу конкретного рівня, серверної валідації прохождения.

Продуктивність генерації

На мобільних пристроях генерація повинна вміщуватися в екран завантаження. Орієнтири:

• 50×50 тайловий рівень (BSP + population) — 5–20ms на середньому Android
• 200×200 тайловий рівень — вже потребує розбивки на chunks з async генерацією
• Terrain 512×512 через Perlin Noise — 50–200ms, обов'язково в async/Thread

Unity Job System дозволяє винести вичисленні noise-генерації в burst-компільований job — прискорення в 5–10 разів порівняно з managed кодом.

Етапи роботи

1. Аналіз вимог — тип генерації під жанр та механіки
2. Прототип алгоритму — швидка перевірка підходу без фінального арту
3. Контроль якості — валідатор рівнів, ітерація правил
4. Інтеграція контенту — тайлсети, шаблони якорних кімнат
5. Продуктивність — профілювання, async, Job System
6. Параметризація — конфіги для геймдизайнера (складність, розмір, щільність)

Вартість визначається після аналізу жанру, платформи та вимог до різноманіття рівнів.