FIGHTEX — симулятор игровой экономики и токеномики

Задача: проверить экономику как связанную систему

Награды, крафт, торговля и турнирные выплаты влияют друг на друга. Проверка отдельных формул не показывает, что произойдёт при изменении активности игроков, появлении мультиаккаунтов или недостаточной ликвидности рынка. Нужен был единый симулятор для сравнения продуктовых гипотез и анализа финансовых последствий.

Почему здесь недостаточно таблицы с формулами

FIGHTEX — fantasy-игра с коллекционными картами бойцов и турнирной механикой. Экономический симулятор нужен для исследования её правил: от появления карты и начисления наград до торговли, участия в турнире и вывода средств.

Сложность возникает на стыке механик. Изменение награды влияет на накопление игровой валюты, её расходование — на спрос на карты, а оборот карт — на комиссии и финансовые потоки платформы. При этом результат зависит от того, как ведут себя игроки. Привлекательная формула отдельной механики ещё не показывает устойчивость всей системы.

Ключевой инженерный вопрос: можно ли объяснить, почему получился именно такой результат, и повторить расчёт после изменения правил?

Что моделирует платформа

Один движок для трёх интерфейсов

DashboardController, CLI и MCP обращаются к SimulatorService. Сервис валидирует сценарий, проверяет ресурсные лимиты и передаёт расчёт в runner. Математическое ядро отделено от интерфейсов и базы данных: формулы не дублируются между каналами доступа.

От результата — к исходным данным

Каждый запуск связан с версией движка и конфигурации, хэшем параметров, seed, происхождением спортивных данных и digest результата. Неизменяемый снимок сохраняет параметры и их источники; журнал запусков хранит историю. Проверки инвариантов и сверка потоков помогают обнаруживать ошибки учёта.

AI объясняет результаты, Python выполняет расчёты

MCP предоставляет структурированный доступ к модели, параметрам и сохранённым результатам. Доступ к отчётам, изменению сценариев и новым запускам зависит от серверной политики. Авторизация проверяется шлюзом для каждого вызова; режим только чтения может отключать вычисления.

Очередь, ресурсы и границы доступа

В серверном режиме расчёты выполняются в пуле отдельных процессов с ограниченной очередью и лимитами ресурсов. До запуска оценивается стоимость эксперимента. Nginx обеспечивает HTTPS и ограничения запросов; SQLite и внутренние компоненты остаются в закрытом контуре.

Как проходит исследование одного сценария

1. Собрать условия эксперимента

   Исходная конфигурация хранит правила и происхождение значений. Из baseline создаётся производный сценарий: изменения не перезаписывают исходную основу сравнения.

   Baseline · происхождение параметров

2. Проверить параметры и объём работы

   Pydantic проверяет типы и взаимосвязи значений. Сервис оценивает ресурсы до запуска, чтобы слишком большой эксперимент не занял очередь без контроля.

   Валидация · preflight

3. Выполнить модель по дням

   Движок последовательно обрабатывает события экономики: активность, истечение карт, награды, покупки, крафт, торговлю и выплаты. Порядок событий влияет на доступные активы и следующие операции.

   Python · дискретная симуляция

4. Сверить результат

   Проверки сопоставляют выпуск и расход игровой валюты, движение карт, комиссии и денежные потоки. Итог содержит таблицы, сводные метрики, предупреждения и контрольные проверки.

   Инварианты · reconciliation

5. Сравнить и сохранить доказательства

   Сценарии сравниваются при зафиксированных условиях. Снимок конфигурации, seed и digest позволяют вернуться к основанию вывода, а экспорты JSON, CSV и XLSX — продолжить анализ вне интерфейса.

   Сравнение · снимок · экспорт

Где находится основная инженерная сложность

Жизненный цикл карты меняет экономику

Карта участвует сразу в нескольких процессах: хранении, стейкинге, крафте, торговле и составе команды. Её истечение должно последовательно отражаться на инвентаре и связанных механиках. Поэтому жизненный цикл вынесен в отдельную часть модели, а не сводится к одной поправке в итоговой таблице.

Цена актива не равна деньгам от продажи

Для мультиаккаунтной стратегии мало умножить количество оставшихся карт на расчётную цену. Рынок может не поглотить весь объём. Модель разделяет реализованную прибыль, результат с учётом распродажи за ограниченное окно и теоретическую стоимость остатка. Это позволяет исследовать зависимость стратегии от ликвидности.

Прибыль, касса и обязательства требуют раздельного учёта

Начисленный приз и фактический вывод происходят в разные моменты. Операционный результат, движение денег и резерв отвечают на разные вопросы. Финансовый модуль разделяет эти представления и проверяет согласованность потоков, чтобы один показатель не подменял другой.

Случайный удачный прогон может ввести в заблуждение

Один seed задаёт одну реализацию. Для турниров используются Monte Carlo-эксперименты, для исследования мультиаккаунтных стратегий — повторения с разными seed. При интерпретации важно отличать результат отдельного запуска от распределения по серии.

Согласованность расчёта ещё не подтверждает предпосылки

Контрольные проверки могут показать, что учёт сошёлся, но не доказать выбранную конверсию или активность игроков. Поэтому параметры сохраняют происхождение, а неопределённости рассматриваются явно. Анализ чувствительности помогает найти допущения, при которых меняется вывод.

Почему интерфейсы не содержат собственных формул

Пользователь может работать через дашборд, запускать эксперимент из CLI или обращаться к результатам через AI-клиент. Если каждый интерфейс рассчитывает показатели самостоятельно, правила постепенно расходятся. В FIGHTEX эти каналы используют один сервисный слой и один runner.

Это решение упрощает проверку изменений: обновляется математическая модель, а интерфейсы получают структурированный результат. Дашборд отвечает за исследование и визуализацию; MCP — за разрешённый доступ к данным; SQLite — за сохранение сценариев и истории.

MCP: от вопроса к проверяемому ответу

AI-клиент может получить описание модели, источники параметров и разрешённые результаты, а затем объяснить их человеку. За каждым численным выводом должен стоять выполненный Python-расчёт. Предположение о новом сценарии нельзя выдавать за результат движка, пока такой сценарий не рассчитан.

Права задаются на сервере. Шлюз проверяет вызов инструмента независимо от того, был ли он показан в списке доступных функций. Представления для заказчика ограничивают выдаваемые данные до ответа AI-клиенту; режим только чтения позволяет обсуждать сохранённые материалы без запуска новых вычислений.

Как проверяется такая система

В проекте используются pytest и Hypothesis: обычные сценарные проверки дополняются проверками свойств модели. Для такого движка важно проверять не только ожидаемое число в одном примере, но и отношения между величинами: сохранение учёта, согласованность потоков и целостность доказательств расчёта.

Отдельное направление — воспроизводимость и одинаковый расчётный путь для интерфейсов. Метаданные запуска связывают результат с входами и версией движка. Снимки защищаются от изменения и проверяются по контрольной сумме при чтении. Такая проверка позволяет различать ошибку реализации, повреждённый результат и чувствительность самой модели к исходным условиям.