Как мы спроектировали игровую экономику для Telegram Mini App

Перед запуском стояла задача не просто реализовать игровую механику, а спроектировать устойчивую игровую систему, которая:

• удерживает пользователя в продукте
• масштабируется на сотни тысяч игроков
• управляет экономикой без перекосов
• исключает возможность абуза
• готова к интеграции с Web3 (токенизация)

Ключевое ограничение — Telegram:

• короткие пользовательские сессии
• ограниченный UX
• высокая конкуренция за внимание

Поэтому игра должна была “цеплять” с первых секунд и удерживать через систему решений и прогрессии.

Задача формулировалась не как “сделать игру”, а как создать управляемую систему поведения пользователя.

Что это означает на практике:

• пользователь должен возвращаться 3–4 раза в день
• каждое действие должно иметь смысл
• экономика должна быть контролируемой
• прогресс не должен ломать баланс

Фактически:
мы проектировали цифровую экономику с прогнозируемыми последствиями действий

Работа строилась в 3 этапа:

1. Декомпозиция поведения игрока

Разложили пользователя на сценарии:

• быстрый игрок (заходит на 2–3 минуты)
• вовлечённый (20–30 минут сессии)
• “абузер” (пытается фармить максимум)

1. Моделирование сценариев

Для каждого типа:

• сколько действий в день
• сколько ресурсов получает
• как быстро растёт

1. Балансировка

Подгоняли формулы так, чтобы:

• никто не “улетал” по прогрессу
• не было стагнации

сохранялся интерес

Событийная модель. Игра построена как цепочка:

Событие → Выбор → Результат → Изменение состояния

Пример:

• игрок попадает в локацию:
• вариант A → +100 монет, риск штрафа
• вариант B → +50 монет, без риска
• вариант C → буст, но с затратой

Это создаёт:

• стратегию
• вариативность
• вовлечённость

Пример сценария. Игрок выбирает рискованный вариант:

Reward = 100
PenaltyChance = 20%
Penalty = -150

Ожидаемое значение:

EV = 0.8 * 100 + 0.2 * (-150) = 80 — 30 = 50

=> по математике равно “безопасному” варианту,
но психологически воспринимается как более выгодный.

Прогрессия игрока. Контролируем рост через нелинейную формулу:

XP_required = base * level^1.6

Это даёт:

• быстрый старт
• замедление на высоких уровнях
• удержание

Расчёт наград.

Reward = Base * Difficulty * LevelModifier

Пример:

• Base = 50
• Difficulty = 1.4
• LevelModifier = 1.2
• Reward = 50 * 1.4 * 1.2 = 84

Контроль экономики. Главное правило:

Эмиссия ≤ Сжигание + Контролируемый рост

Где:

• эмиссия — все выданные награды
• сжигание — траты (бусты, апгрейды)

Баланс действий.

NetGain = Reward — Cost — Risk

Если NetGain слишком высокий:
→ игрок ломает экономику

Если слишком низкий:
→ игрок уходит

Ограничение фарма

Actions_per_hour ≤ 120
Reward_per_hour ≤ MaxLimit

При превышении:

• снижение награды
• soft-ограничения

Мы проверяли:

Сценарий 1 — “быстрый игрок”

• 10–15 действий
• должен чувствовать прогресс

Сценарий 2 — “залипающий”

• 100+ действий
• не должен ломать экономику

Сценарий 3 — “абузер”

• пытается фармить максимум

должен упираться в ограничения

Разберем основные ошибки, которые могли убить игру.

Ошибка 1 — линейная прогрессия

XP = base * level

Проблема:

• игрок слишком быстро растёт
• ломается баланс

Ошибка 2 — завышенные награды

Если:

Reward >> Cost

→ инфляция
→ обесценивание

Ошибка 3 — отсутствие ограничений

Если нет лимитов:

→ игроки начинают:

• кликать бесконечно
• автоматизировать действия

Ошибка 4 — “наказание без смысла”

Сильные штрафы без компенсации:
→ пользователь уходит

Ошибка 5 — одинаковые сценарии

Если все события одинаковые:
→ падает удержание

Ошибка 6 — отсутствие вариативности

Если игрок всегда выбирает один вариант:
→ система не работает

После внедрения модели:

• игроки возвращаются 3–4 раза в день
• средняя сессия: 20–30 минут
• отсутствуют кейсы “поломки экономики”
• нет массового абуза
• прогресс ощущается, но контролируется

Это не геймдизайн в классическом смысле.

Это:

• математическая модель поведения
• управление вниманием пользователя
• проектирование цифровой экономики

Фактически:
система, которая управляет действиями пользователя через числа