Адаптивна складність замість статичного балансу рівнів
Статичний баланс рівнів будується на одному припущенні — у всіх гравців однаковий темп навчання. Одна крива складності гри задає фіксовані пороги шкоди, здоров’я та щільності ворогів, і в цей коридор потрапляє лише частина аудиторії.
Новачок упирається в стіну на другому-третьому рівні й іде, вирішивши, що гра «не для нього», а досвідчений проходить ті самі рівні наосліп і кидає з нудьги.
Вручну це погано виправляється. Команда дивиться на логи проходжень і скарги, змінює числа й чекає нової порції даних, щоб побачити ефект.
Кожна правка допомагає одній групі й ламає іншу: послабили ранні рівні — середняки втратили інтерес; підсилили пізні — зросла частка закинутих спроб. Відтік новачків на старті при цьому залишається найдорожчим.
Адаптивна складність замінює константу функцією. Модель зчитує поведінкові сигнали — серію смертей поспіль, час на рівень, частку точних дій, відмови від бою, витрату ресурсів — і за ними підлаштовує параметри під конкретного гравця.
Крива складності стає особистою: у обережного новачка вона м’якша, у досвідченого — крутіша. Підлаштування під гравця працює в заданих рамках — базовий сценарій і ключові бої залишаються незмінними, змінюється лише обв’язка навколо них, тому баланс залишається керованим.
У підсумку новачок доходить до кінця акту, а досвідчений отримує виклик там, де раніше проходив непомітно. Розбираємо, як така система влаштована і що потрібно для її запуску.
Ефект упровадження: утримання, відтік, довжина сесії
Перший крок — базова лінія. До ввімкнення підлаштування знімаємо розподіл сесій за рівнями, частку доведених до кінця, середню довжину сесії та кількість ручних правок балансу за тиждень.
Без цих чисел будь-який ефект спірний, тому телеметрія рівня й спроби збирається заздалегідь — на Unity події надсилаються тим самим рушієм, на якому зібрано проєкт, окремий збирач даних не потрібен.
Далі крива складності прив’язується до спостережуваної поведінки: час на спробу, кількість смертей на сегмент, витрата ресурсів. Якщо гравець двічі поспіль провалює один сегмент, параметри послаблюються у вузькому діапазоні, а не в усій грі. Відсів на перших рівнях падає саме завдяки новачку, який перестає упиратися в стіну на вході.
Протилежна група — сильні гравці. Критерій «сегмент пройдено без втрат кілька разів поспіль» підвищує тиск, і утримання зростає з обох боків: одному не нудно, другому не тяжко. Довжина сесії збільшується не розтягуванням контенту, а тим, що менше сесій обривається на середині.
Навантаження на команду балансу змінюється якісно. Ручна правка чисел після скарг поступається налаштуванню меж і правил: параметр зсувається в межах, заданих дизайнером, а журнал змін показує, хто, коли і за яким сигналом це зробив — і дозволяє відкотити.
Метрики залученості перестають залежати від того, чи знайшовся в когось час на черговий прохід таблицями.
Способи підлаштування параметрів: порівняння підходів
Адаптивна складність тримається на одному питанні: чим саме система підлаштовує параметри і хто ухвалює рішення — заздалегідь прописане правило чи навчена політика. Від цього залежить, що команда зможе пояснити на розборі сесії, а що залишиться непрозорим.
Три робочі варіанти
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та пороги | Метрики гравця обчислюються надійно, реакцію потрібно пояснювати й закривати тестами | Не покриває нестандартні стилі гри; пороги переглядаються вручну; переходи між рівнями гравець помічає |
| Навчаний контур, навчання з підкріпленням | Є потік сесій і метрика, за якою можна довго шукати політику | Довгий вихід на робочу якість, схильність застрягати у вузькому рішенні, рішення важко пояснити |
| Гібрид: правила як каркас плюс офлайн-налаштування політики на накопичених даних | Продакшн з історією сесій, де потрібні і передбачуваність, і плавність | Потрібен стенд для перезбирання й перевірки політики за кожної зміни контенту |
Гібридний підхід дає динамічне підлаштування без ривків: у бою система лише варіює коефіцієнти в межах, заданих правилами, а політика перезбирається офлайн на накопичених даних і проходить набір перевірок перед викладенням.
Етапи розробки: від розбору логів до передачі
Кожен етап закривається артефактом, який можна перевірити до переходу до наступного. Помилки в логіці адаптації випливають на вибірці, а не на всіх гравцях після запуску.
- Розбір логів сесій. Вивантажуємо знеособлену телеметрію й дивимося, на яких відрізках гравці застрягають, де проходять без опору і як поводяться після серії невдач.
- Схема сигналів. Визначаємо вхідні показники — точність дій, час до рішення, кількість провалів на відрізок — і відбираємо ті, що справді описують рівень гравця.
- Налаштування контуру адаптації. Задаємо цільовий коридор складності, швидкість підлаштування й обмежувачі, щоб система не змінювала умови ривками й не знецінювала пройдену ділянку.
- Інтеграція з ігровим циклом. Підключаємо контур до серверної логіки й перевіряємо, що рішення ухвалюються без затримок в управлінні та не конфліктують з поточним балансом.
- Перевірка гіпотез. Ділимо аудиторію на контрольну й тестову групи, порівнюємо частку завершених сесій, глибину проходження й повернення; непідтверджені гіпотези відкидаємо.
- Приймання результату. Звіряємо метрики з цільовими, проганяємо граничні сценарії — новачок, ветеран, нестандартний стиль гри — і фіксуємо поведінку системи в спірних ситуаціях.
- Передача команді. Віддаємо конфігурації порогів, схему сигналів, регламент моніторингу й порядок правки правил складності без перезбирання ядра.
Набір артефактів: конфігурації, схеми, регламенти
Артефакти збираються так, щоб система адаптивної складності залишалася керованою без автора моделі — це головний критерій приймання.
На виході команда замовника отримує не лише робочий модуль, а й комплект, за яким вона сама змінює поведінку системи, пояснює будь-яке рішення й супроводжує його в продуктивному середовищі. Нижче — склад, який ми фіксуємо в прийманні.
- Конфігурації підлаштування: профілі з цільовими метриками складності, вікном спостереження, кроком перерахунку й вагами сигналів — правляться як дані, без перезбирання й релізу.
- Схема сигналів і рішень: які події сесії потрапляють в оцінку навички, як обчислюється поточний рівень і на якому порозі він змінюється.
- Політики обмежень: стеля й підлога складності, максимальна швидкість зміни, обов’язкові вікна затухання — система не йде врознос на викидах.
- Правила для граничних ситуацій: мало сесій у гравця, вихід за межі профілю, обрив зв’язку, аномальні сплески результату.
- Журнал рішень: формат запису, за яким відновлюється, чому конкретна сесія отримала конкретну складність, і як це перевірити на історичних даних.
- Документація системи: опис моделі, зовнішніх залежностей, точок розширення й порядку локального запуску з відтворенням розрахунків.
- Регламент супроводу: які метрики дивитися, з якою періодичністю, що вважається відхиленням, хто і як вносить правку в конфігурацію.
Кейс: як підлаштування змінило поведінку гравців
Проєкт Rift Runner — раннер із хвилями противників і фіксованою таблицею коефіцієнтів складності. Геймдизайнер правив значення вручну за логами: перші хвилі гравці проходили непомітно, а до четвертої упиралися в стіну й закривали гру.
Ми зняли телеметрію по кожній сесії — час до першої поразки, кількість спроб на хвилю, частка виходів після другої поразки поспіль.
На цих даних навчили модель, що підбирає параметри наступної хвилі під поточний темп гравця: адаптивна складність перераховується на кожному чекпоінті, а не раз на добу.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Частка закинутих сесій | 34% | 19% |
| Глибина проходження (медіана) | 4 хвилі | 7 хвиль |
| Ручні правки балансу | ~12 на тиждень | 1–2 на місяць |
Працює не саме підлаштування, а передбачуваність: гравець перестає вгадувати, де автор «намалював» стіну. Слабкі сегменти отримали м’який вхід, сильні — зростання опору, тому утримання зросло саме там, де раніше відвалювалися після другої поразки.
Правки балансу пішли з рутини: крива налаштовується політикою, а не перебором значень у таблиці. Той самий контур ми переносимо на інші проєкти — з логуванням рішень, щоб баланс завжди можна було відкотити до попередньої конфігурації.
Чим адаптивна складність відрізняється від ручного балансу?
Ручний баланс — це таблиці значень, які дизайнер править за звітами: крива шкоди, запас здоров’я, тайминги. Адаптивна складність — замкнутий контур, який зчитує поведінку гравця й сам рухає параметри, утримуючи його в зоні «трудно, але розв’язно». Різниця не в тому, що краще, а в тому, хто вносить правку і як швидко вона доходить до гравця.
Як інженер скажу: чистого вибору тут немає — ми завжди збираємо гібрид. Дизайнер задає коридор допустимих значень і жорсткі стелі, усередині коридору працює автоматичне підлаштування за теорією потоку. Так система не «дарує» перемогу, але й не заганяє гравця в глухий кут на першому ж рівні.
Перевіряємо це телеметрією: частка перевантажених сесій, виходи після третьої поразки поспіль, розкид часу проходження. Стискається розкид і падає відтік на складних ділянках — контур налаштовано правильно; зростає — правимо пороги реакції, а не переписуємо таблиці.
Сумніви щодо впровадження: питання інженерів
Сумніви щодо адаптивної складності майже завжди ті самі, і вони слушні: навчаний контур поводиться інакше, ніж детермінований баланс. Нижче — технічні відповіді на те, що найчастіше порушують на етапі оцінки рішення.
Навчаний контур роз’їдеться чи перенавчиться?
Обмежуємо крок оновлення профілю й уводимо заморожені періоди: крива складності змінюється не кожну сесію, а пачками за накопиченою статистикою. Перенавчання ловимо на відкладеній вибірці — якщо розходження з контрольною групою зростає, оновлення відхиляється автоматично.
Даних для навчання не вистачить?
Холодний старт іде на правилах і ручних кривих, навчаний шар підключається, коли за зрізом гравців накопичилася статистика. Поки даних мало, працює базова крива, а модель поступово її доповнює.
Як відкотити зміну, якщо стало гірше?
Кожна версія налаштування складності — окремий підписаний артефакт. Відкат — це повернення попереднього артефакту, він займає один реліз і не потребує правок коду. Спочатку правки йдуть у тіньовому режимі: рахуються на живому потоці, але гравця не торкаються.
Сильним гравцям не стане нудно?
Аудит якості входить в етап приймання: дивимося розподіл складності за сильними й слабкими, частку закинутих сесій і кількість нечесних піків. Стеля складності й захист від підкрутки в реальному часі залишаються фіксованими — сильний гравець отримує виклик, а не покарання.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінити проєкт з адаптивної складності, нам не потрібен повний доступ до продакшену — достатньо знеособленого зрізу даних і опису цільового ігрового досвіду.
Чим конкретніші вихідні, тим точніша оцінка: розмите «складність має підлаштовуватися» дає широку вилку за строками, а вимірювана крива — зрозумілий план робіт за етапами.
- Цільовий досвід: як складність має відчуватися на різних відрізках сесії — зростання, плато, точки відпочинку, реакція на серію невдач.
- Доступ до даних: журнали ігрових сесій за характерний період — вивантаженням або на читання до сховища, зі знеособленням профілів.
- Що вважаємо в даних: тривалість сесій, результати, кількість поразок поспіль, використання механік, просування за рівнями.
- Профіль гравця: які ознаки допустимо подавати в модель і які обмеження діють на їх зберігання.
- Точка інтеграції: де рішення зчитує стан і куди повертає скориговані параметри — серверна логіка, клієнт або обидва.
- Рамки зміни: які параметри можна рухати автоматично, а які зафіксовані дизайном і чіпати не можна.
- Обмеження продукту: платформи, цільові сегменти гравців, вимоги до чутливості підлаштування.
- Відповідальні: хто затверджує цільову криву складності й приймає результат за етапами.
Натомість ми повертаємося з оцінкою проєкту, схемою робіт і планом за етапами: архітектура контуру підлаштування, склад даних і розмітки, протокол перевірки на накопиченій вибірці, порядок викочування й точки відкату. Опишіть задачу — призначимо розбір з інженерами й покажемо, як це лягає на вашу гру.
