Створення математичної моделі економіки ігор
Коли гравець на третій години сесії перестає витрачати золото — не тому що не хоче, а тому що накопичувати вигідніше — це не випадковість. Це сломана крива інфляції. І виявляється вона не в плейтесті, а в таблиці: якщо порахувати income/expenditure ratio за рівнями прогресії, точка накопичення видна задовго до релізу.
Що таке математична модель економіки гри
Це набір формул, таблиць і симуляцій, що описують: як гравець заробляє ресурси (gold, XP, матеріали, енергію), як витрачає їх, і як ця динаміка змінюється з прогресією. Модель будується в електронних таблицях (Google Sheets або Excel) і перевіряється симуляцією до того, як ці цифри потрапляють у ScriptableObject або базу даних.
Ключові параметри, які повинна описувати модель: earn rate (ресурсів на хвилину активної гри), burn rate (витрата на апгрейди, покупки, втрати), time to next milestone (скільки часу до наступного значимого поліпшення), inflation index (відношення цінності раннього ресурсу до пізнього).
Формульна база: криві прогресії
Три базові типи кривих для XP і вартості апгрейдів:
Лінійна: cost(n) = base + n * step. Передбачувана, але швидко стає незначимою — різниця між рівнями 50 і 51 відчувається так само, як між 1 і 2.
Експоненціальна: cost(n) = base * multiplier^n. Типово для мобільних ігор. При multiplier = 1.15 і 100 рівнях останній апгрейд коштує у 1174 рази дорожче першого. Без джерел пізнього доходу гравець упирається в paywall.
Поліноміальна: cost(n) = a * n^2 + b * n + c. Золота середина для PC/console: зростання прискорюється, але не експоненціально. Коефіцієнти a, b, c підбираються під бажаний час між апгрейдами.
На практиці вартість апгрейдів рідко беруться з однієї формули — використовується ступенчаста модель: перші 10 рівнів по лінійній, потім перемикання на поліноміальну, після точки «prestige» — скидання з бонусним мультипліkatором. Це створює відчувні «глави» прогресії.
Симуляція сесій
Одна таблиця — це статика. Симуляція — це динаміка. У Google Sheets будується «бот»: клітинки, які кожні 10 хвилин ігрового часу обчислюють, скільки ресурсів заробленo, що куплено за алгоритмом оптимального поведінки гравця, яким є баланс. Прогоняється на 40 годин геймплею.
Типічні знахідки симуляції: ресурс B копиться швидше, ніж витрачається, починаючи з години 8 — значить, потрібно або додати sink (витрату), або зменшити earn rate. Або: гравець досягає «стелі» апгрейдів у годину 12 при планованих 20 — крива вартості задрана слабо.
Монетизаційні механіки і їхня математика
F2P ігри будують економіку навколо двох валют: hard currency (за реальні гроші) і soft currency (фармиться). Критично важливо, щоб конвертація hard → soft не порушувала баланс для безплатних гравців. Перевіряється через paying player advantage index: якщо гравець за $10 отримує еквівалент 40 годин фарму, це агресивна монетизація; 10–15 годин — умірена.
Energy/stamina системи математично описуються як leaky bucket: наповнення зі швидкістю regenRate до maxEnergy, витрата при діях. Оптимальний maxEnergy — такий, щоб середньостатистична сесія (20–30 хвилин) витрачала 70–80% від максимуму. Менше — гравець закінчує з запасом і повертається рідше. Більше — сесія обривається на півслові, що дратує.
Інструменти та інтеграція з грою
Підсумкові таблиці значень експортуються в CSV і імпортуються в ScriptableObject через кастомний AssetPostprocessor або Editor скрипт. Це виключає ручний перенос цифр і пов'язані помилки. При зміні балансу дизайнер править таблицю, експортує CSV, Unity автоматично оновлює ассети.
Для runtime-аналітики вбудовується логування ключових економічних подій: ResourceEarned, ResourceSpent, UpgradePurchased з метаданими (рівень гравця, джерело ресурсу, час сесії). Дані йдуть у аналітичну систему (GameAnalytics, Amplitude, або власний pipeline). Через тиждень після м'якого запуску видно реальне поведінка гравців проти смодельованого.
Орієнтовні строки
| Задача | Строк |
|---|---|
| Базова модель прогресії (одна валюта, XP, 30 рівнів) | 3–7 днів |
| Повна модель (кілька валют, крафт, монетизація) | 2–4 тижні |
| Модель + симуляція сесій + інтеграція аналітики | 4–8 тижнів |
Типічні помилки при проектуванні
Симетричні джерела і стоки. Якщо кожен квест дає 100 золота і кожен апгрейд коштує 100 золота, у гравця нема причини щось пріоритизувати. Розмаїтість джерел і стоків створює інтерес до розподілу ресурсів.
Неврахований «ефект накопичення». Гравці, які пропустили кілька днів, повертаються з переповненими ресурсами і кількома рівнями апгрейдів за раз. Якщо це не закладено в модель, їхня прогресія різко порушує баланс мультиплеєрної економіки.
Інфляція без скидання. У довгоживучих онлайн-іграх без sink-механік (податки, порча предметів, крафт з витратою) soft currency накапливається у старих гравців до рівня, який робить фарм для нових бессмисленным. Періодичні события-синки або сезонні скидання — стандартне рішення.