Создание математической модели экономики игр

Игрок на третьем часу сессии перестаёт тратить золото — не потому что не хочет, а потому что копить выгоднее. Это не случайность, а сломанная кривая инфляции. Мы сталкиваемся с этим на каждом проекте: точка накопления видна в таблице 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. Или в линейном ускорении, которое не даёт ощущения веса. Мы это чиним на этапе прототипа.

Какие услуги геймдизайна мы предлагаем

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

Что входит в работу:

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

Оцените ваш проект — свяжитесь для расчёта сроков. Подход основан на методологии MDA и опыте 50+ реализованных проектов с 2012 года.

Как проектировать боевую систему: глубокий разбор

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

1. Выбор метода hit detection

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

2. Настройка окон атаки

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

3. Построение 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 мс». Мнения без цифр не принимаются. Фиксируем ощущения, меняем цифры, повторяем.

Свяжитесь для консультации — мы оценим сроки и бюджет вашего проекта. Наши заказчики экономят от 2 до 3 недель на итерациях за счёт чёткого процесса.