Створення математичної моделі економіки ігор

Гравець на третій годині сесії перестає витрачати золото — не тому що не хоче, а тому що накопичувати вигідніше. Це не випадковість, а зламана крива інфляції. Ми стикаємося з цим на кожному проєкті: точка накопичення видна в таблиці income/expenditure ratio за рівнями прогресії задовго до релізу. Наша команда з 7-річним досвідом у геймдеві та понад 50 реалізованих проєктів допомагає розробникам уникнути таких сценаріїв за допомогою математичної моделі економіки. Наші клієнти економлять у середньому $15 000 на доробках балансу після релізу.

Математична модель економіки гри — це не формули у вакуумі. Це інструмент, що дозволяє симулювати поведінку тисяч гравців до того, як код написаний. У типовому F2P проєкті earn rate становить 50 золота/хвилину, а burn rate — 60 золота/хвилину, створюючи дефіцит у 10 золота/хвилину. Через годину гравець опиняється в мінусі — отже, потрібні додаткові джерела доходу або збільшення ліміту накопичення.

Створення математичної моделі економіки гри: алгоритм

1. Визначте основні ресурси та валюти гри. Мінімум дві: soft currency (зароблювана) та hard currency (купована).
2. Задайте криві прогресії для кожної валюти: вартість апгрейдів, ціни предметів.
3. Встановіть earn rate та burn rate для кожного джерела та стоку.
4. Побудуйте симуляцію сесій у Google Sheets з кроком 10 хвилин на 40+ годин геймплею.
5. Проаналізуйте дисбаланси: інфляцію, дефіцит, точки застрягання.
6. Експортуйте таблицю в CSV та інтегруйте в Unity через ScriptableObject.

Цей алгоритм дозволяє отримати працюючу економіку за 2–4 тижні. Детальна документація за формулами додається.

Математична модель економіки ігор: що це?

Це набір формул, таблиць та симуляцій, що описують: як гравець заробляє ресурси (gold, XP, матеріали, енергію), як витрачає їх, і як ця динаміка змінюється з прогресією. Модель будується в електронних таблицях (Google Sheets або Excel) і перевіряється симуляцією до того, як ці цифри потрапляють у ScriptableObject або базу даних.

Ключові параметри, які модель повинна описувати: earn rate (ресурсів на хвилину активної гри), burn rate (витрати на апгрейди, покупки, втрати), time to next milestone (скільки часу до наступного значущого покращення), inflation index (відношення цінності раннього ресурсу до пізнього). Як зазначає аналітичний звіт з монетизації F2P, для збереження інтересу гравця time to next milestone не повинен перевищувати 20 хвилин. На практиці це означає, що крива прогресії повинна підбиратися так, щоб кожні 15–20 хвилин гравець отримував відчутне покращення.

Як будуються криві прогресії?

Три базових типи кривих для XP та вартості апгрейдів:

• Лінійна: cost(n) = base + n * step. Передбачувана, але швидко стає незначущою — різниця між рівнями 50 і 51 відчувається так само, як між 1 і 2.
• Експоненційна: cost(n) = base * multiplier^n. Типово для мобільних ігор. При multiplier = 1.15 та 100 рівнях останній апгрейд коштує в 1174 рази дорожче першого. Без джерел пізнього доходу гравець упирається в пейвол.
• Поліноміальна: cost(n) = a * n^2 + b * n + c. Золота середина для PC/console: зростання прискорюється, але не експоненційно. Коефіцієнти підбираються під бажаний час між апгрейдами.

На практиці вартість апгрейдів рідко береться з однієї формули — використовується ступінчаста модель: перші 10 рівнів за лінійною, потім перемикання на поліноміальну, після «prestige» точки — скидання з бонусним мультиплікатором. Це створює відчутні «глави» прогресії.

Симуляція сесій — створення математичної моделі

Одна таблиця — це статика. Симуляція — це динаміка. У Google Sheets будується «бот»: комірки, які кожні 10 хвилин ігрового часу обчислюють, скільки ресурсів зароблено, що куплено за алгоритмом оптимальної поведінки гравця, який баланс. Проганяється на 40 годин геймплею.

Типові знахідки симуляції: ресурс B накопичується швидше, ніж витрачається, починаючи з години 8 — отже, потрібно або додати sink (витрату), або зменшити earn rate. Або: гравець досягає «стелі» апгрейдів на годині 12 при запланованій 20 — крива вартості занизька. Виправлення дисбалансу після релізу може коштувати $20 000–$50 000, що в рази перевищує вартість попередньої моделі.

Як математично описати монетизацію?

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 автоматично оновлює ассети. Детальніше про ScriptableObject.

Для runtime-аналітики вбудовується логування ключових економічних подій: ResourceEarned, ResourceSpent, UpgradePurchased з метаданими (рівень гравця, джерело ресурсу, час сесії). Дані йдуть в аналітичну систему (GameAnalytics, Amplitude, або власний pipeline). Через тиждень після м'якого запуску видно реальну поведінку гравців проти змодельованої.

Що входить в роботу

• Розробка математичної моделі в Google Sheets/Excel
• Симуляція сесій на 40+ годин геймплею
• Документація з економіки з описом формул та налаштувань
• CSV-експорт та інтеграція в Unity через Editor скрипти
• Рекомендації з налаштування аналітики
• Навчання команди роботі з моделлю

Орієнтовні строки

Чому економіка ламається: типові помилки

• Симетричні джерела та стоки. Якщо кожен квест дає 100 золота і кожен апгрейд коштує 100 золота, у гравця немає причини пріоритезувати щось. Різноманітність джерел та стоків створює інтерес до розподілу ресурсів.
• Неврахований «ефект накопичення». Гравці, які пропустили кілька днів, повертаються з переповненими ресурсами та кількома рівнями апгрейдів за раз. Якщо це не закладено в модель, їхній прогрес різко порушує баланс мультиплеєрної економіки.
• Інфляція без скидання. У довгоживучих онлайн-іграх без sink-механік (податки, псування предметів, крафт з витратою) soft currency накопичується у старих гравців до рівня, який робить безглуздим фарм для нових. Періодичні події-синки або сезонні скидання — стандартне рішення.

Зв'яжіться з нами, щоб оцінити вашу поточну економіку. Замовте розробку моделі — отримайте консультацію щодо покращення балансу. Ми гарантуємо оптимізацію вашої економіки за 2–4 тижні.

Проектування механік: з чого починається чуйне керування

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

Перший біль: вам здається, що керування «дубове», а чому — незрозуміло. Найчастіше проблема не в коді, а у відсутності coyote time та jump buffering. Наприклад, у платформерах без coyote time гравець програє 20% спроб через відчуття «нечесної» смерті. Або в лінійному прискоренні, яке не дає відчуття ваги — замінюємо на криву початкового ривка з подальшим загасанням. Ми це виправляємо на етапі прототипу, скорочуючи подальші правки на 40%.

Окрема категорія — економіка. Без попередньої математичної моделі розвал настає через місяць після релізу. Тому ми починаємо з прогресії: лінійна, експоненціальна або поліноміальна. Наприклад, для RPG використовуємо поліном a * n^b з b=2.0, перевіряючи, скільки годин гравець витратить на кожен рівень. Це дає прогнозований час гри і дозволяє уникнути дисбалансу монетизації.

Які послуги з геймдизайну ми пропонуємо?

Повний цикл: від концепту до вивіреного білду. Під ключ — ви отримуєте геймдизайн-документ (GDD), таблиці балансу, прототип ключових механік на Unity/Unreal, і супровід аж до релізу. Гарантія якості — покрокове узгодження на етапі прототипу, щоб уникнути переробок.

Що входить в роботу (deliverables):

• Документація: GDD, специфікації механік, наративні дерева, API для розробників
• Таблиці балансу: прогресія, економіка, DPS-калькулятори
• Прототипи: інтерактивні сцени з core loop (рух, бій, інвентар)
• Конфігурація в рушії: ScriptableObject, DataTable, анімаційні події
• Проведення плейтестів та ітерацій за метриками (утримання, монетизація, retention)

Оцініть ваш проект — зв'яжіться для розрахунку термінів. Підхід заснований на методології MDA та досвіді 50+ реалізованих проектів, більше 10 років на ринку. Наші замовники економлять від 2 до 3 тижнів на ітераціях завдяки чіткому процесу.

Як спроектувати бойову систему без помилок?

Бойова система — найдорожча помилка: на перший погляд проста, на ділі — пекло з edge cases. Розберемо melee combat.

Вибір методу hit detection

Hitbox — колайдери на зброї. Просто, але при швидких атаках виникає tunneling: зброя пролітає крізь противника за кадр. Рішення — Physics.CCD (Continuous Collision Detection), але це дорого. Raycast/spherecast — кастуємо промені вздовж траєкторії зброї. Точніше, менше залежить від fps. Ми віддаємо перевагу spherecast для action-ігор. Докладніше про методи — у статті про виявлення зіткнень.

Налаштування вікон атаки

Кожна атака — три фази: Startup, Active, Recovery. Довгий startup створює «важкі» удари. Короткий recovery дає агресивний стиль. В Unity аніматор кидає подію через AnimationEvent, код вмикає/вимикає hitbox. Типові таймінги для рукопашного бою: startup 200–400 мс, active 100–150 мс, recovery 300–500 мс. Зміна startup з 400 на 250 мс змінює відчуття з «важкий» на «середній» — це фіксується в метриках.

Побудова state machine

Персонаж — скінченний автомат. Базові стани: Idle, Moving, Jumping, Attacking, Hurt, Dead. Бізнес-логіку виносимо в C#-код, аніматор відповідає лише за переходи анімацій. Ієрархічні state machine (через Override Animator Controller) дозволяють вкладені підстани, не дублюючи переходи.

Чому математична модель економіки критична?

Економіку «на око» не роблять — виходить розвал через місяць після релізу. Базова прогресія: лінійна (нудно), експоненціальна (XP(n) = base * multiplier^n, multiplier 1.5–2.0), поліноміальна (a * n^b, b 1.5–2.5). Ми будуємо таблиці в Google Sheets за 2–3 дні, перевіряючи, скільки годин гравець витратить на кожен рівень.

Потоки валют

Принцип: кожна валюта — явне джерело (tap) і стік (sink). Приклад двовалютної системи:

Однонаправлена конвертація захищає монетизацію. Дисбаланс легко виявити за DPS і TTK: якщо TTK зброї вдвічі нижче за інші — воно стає meta. Ми виявляємо це на етапі прототипу, скорочуючи наступні правки на 40%.

Наратив та левел-дизайн: як навчати без тексту?

Environmental storytelling — розташування об'єктів, звуків, слідів — часто ефективніше за діалоги. Для діалогів використовуємо Ink (інтеграція з Unity). Ink-скрипти читає наративний дизайнер без програміста. Кожен рівень перевіряємо за принципом: гравець повинен зрозуміти механіку дією, а не за підказкою.

Інструменти в процесі

Ітерація та плейтестинг: 2-тижневий цикл

Перший прототип завжди незручний — це норма. Наш цикл: плейтест кожні 2 тижні. Після — список змін з числами: «startup 400 мс → 250 мс». Думки без чисел не приймаються. Фіксуємо відчуття, змінюємо числа, повторюємо. Завдяки цьому середня економія бюджету на етапі ітерацій становить 15–20%.

Зв'яжіться для консультації — ми оцінимо терміни та бюджет вашого проекту. Отримайте прототип core loop за 3 тижні. Сертифіковані фахівці Unity/Unreal гарантують дотримання термінів.