FIGHTEX — game economy and tokenomics simulator
Case study · Python · economic simulation · MCP
A platform for testing game economy decisions through simulation. It models player behavior, card circulation and financial flows, compares scenarios, and exposes results through a dashboard, CLI and MCP.
The challenge: test an interconnected economy
Rewards, crafting, trading and tournament payouts affect each other. Checking individual formulas does not reveal the consequences of changing player activity, multi-account strategies or limited marketplace liquidity. The project needed a shared simulator for comparing product hypotheses and their financial implications.
Why a spreadsheet of formulas is not enough
FIGHTEX is a fantasy game built around collectible fighter cards and tournaments. Its economic simulator studies the rules across the entire lifecycle: card issuance, reward accrual, trading, tournament participation and withdrawals.
The challenge lies in interactions. Reward changes affect currency accumulation; spending affects card demand; card circulation affects fees and platform finances. Player behavior adds uncertainty. A plausible formula for one feature does not establish the behavior of the combined economy.
The engineering question: can we explain why a result occurred and reproduce the experiment after the rules change?
What the platform models
Daily economy
Player arrivals and activity, card lifecycles, staking, rewards, purchases and crafting form a sequential simulation.
Marketplace and liquidity
Supply and demand matching, prices and fees. Theoretical inventory value is kept separate from proceeds achievable through sales.
Tournaments and Monte Carlo
Sports scores, team composition, outcome distributions and multiplier effects are explored through repeated stochastic experiments.
Multi-account strategies
The model compares costs, prizes and inventory liquidation. Multiple seeds help describe variation in outcomes.
Financial scenarios
Revenue and expenses, cash movements, liabilities and reserves are accounted for separately. Sensitivity analysis reveals dependence on assumptions.
Dashboard, CLI and MCP
Streamlit for parameter exploration and tables, a CLI for repeatable runs, and MCP for authorized AI client access.
One engine, three interfaces
DashboardController, the CLI and MCP use SimulatorService. The service validates scenarios, checks resource limits and delegates calculations to the runner. The mathematical engine is independent of presentation and persistence, keeping formulas consistent across interfaces.
Trace each result to its inputs
Runs carry engine and configuration versions, a parameter hash, seed, sports-data provenance and a result digest. Immutable snapshots preserve effective parameters and their sources; a run ledger retains execution history. Invariant checks and flow reconciliation help detect accounting errors.
AI interprets results; Python calculates them
MCP exposes structured model information, parameters and stored results. Access to reports, scenario changes and new calculations depends on server policy. An authorization gateway checks every invocation; a read-only mode can disable computation.
Bounded jobs and access boundaries
In server mode, calculations run in separate worker processes with a bounded queue and resource limits. Workload is estimated before execution. Nginx provides HTTPS and request limits; SQLite and internal components remain within the private application boundary.
Following one scenario through the system
Define the experiment
A versioned baseline preserves the rules and parameter provenance. Custom scenarios derive from it without overwriting the original comparison point.
Baseline · provenanceValidate inputs and workload
Pydantic checks types and relationships. Resource preflight estimates work before admitting an experiment to the compute service.
Validation · preflightAdvance the daily model
The engine processes activity, card expiry, rewards, purchases, crafting, trading and payouts. Event order affects available assets and subsequent operations.
Python · discrete simulationReconcile the output
Checks cover currency issuance and spending, cards, fees and financial flows. Structured results include tables, summary metrics, warnings and checks.
Invariants · reconciliationCompare and retain evidence
Controlled scenario comparisons are linked to snapshots, seeds and digests. JSON, CSV and XLSX exports support further analysis.
Comparison · snapshots · export
Where the engineering becomes difficult
A card lifecycle affects several systems
A card can participate in inventory, staking, crafting, trading and a tournament team. Expiry must consistently affect the relevant mechanics. A dedicated lifecycle model captures these interactions rather than adjusting only the final totals.
Asset prices are not sale proceeds
Valuing remaining cards at a reference price ignores whether buyers can absorb that volume. Multi-account analysis separates realized profit, liquidation-adjusted results over a bounded selling window and theoretical inventory value.
Profit, cash and liabilities are different views
A prize accrual and its withdrawal occur at different times. Operating results, cash movements and required reserves answer different questions. The finance model separates these views and reconciles their flows.
One favorable run can mislead
A single seed produces one realization. Tournament studies use Monte Carlo experiments; selected multi-account studies support multiple seeds. Interpretation must distinguish an individual result from a distribution across repeated experiments.
Consistent accounting does not validate behavior
Passing reconciliation cannot establish a conversion or activity assumption. Parameter provenance and explicit uncertainties preserve this distinction; sensitivity experiments reveal assumptions that can change a conclusion.
Finding the assumptions that matter
One-factor sensitivity studies complement full scenario comparisons. They perturb selected parameters and measure changes relative to a reference result, including whether a meaningful threshold was crossed.
This helps prioritize further evidence gathering. If a conclusion depends strongly on unverified marketplace demand, that dependency belongs in the interpretation. A shared seed makes comparisons more controlled, while small differences can still reflect stochastic path effects.
Why interfaces do not own the formulas
Users may explore the dashboard, run the CLI or discuss results through an AI client. Separate calculations in each interface would invite divergence. FIGHTEX routes these entry points through one application service and runner.
The mathematical model produces structured output. Presentation, authorized MCP access and SQLite persistence retain their own responsibilities, making changes easier to inspect and verify.
MCP: from a question to traceable evidence
An AI client can retrieve authorized model information, parameter sources and computed results, then explain them. A numerical engine claim must refer to an actual Python calculation; an uncomputed hypothetical remains a hypothetical.
Server-side policy controls permissions. The gateway authorizes each invocation independently of tool discovery. Customer views restrict data before it reaches the AI client, while read-only operation allows discussion of stored evidence without enabling new computation.
Verifying a simulation platform
The project uses pytest and Hypothesis, combining scenario checks with property-based testing. Beyond a single expected number, important checks cover accounting relationships, flow consistency and the integrity of calculation evidence.
Reproducibility and the shared calculation path are separate concerns. Run metadata ties output to inputs and engine versions; immutable snapshots are verified by checksum when read. These checks help distinguish implementation errors, damaged evidence and the model’s sensitivity to its inputs.
Technology and engineering choices
Outcome and status
The system connects product rules, explicit assumptions and computed results. It supports economy comparisons, sensitivity experiments and tracing conclusions to a specific parameter set. The public repository documents the architecture; proprietary simulator code and customer financial results are excluded.
Outputs depend on the supplied data and assumptions. They do not guarantee economic performance, and reproducible calculations do not establish customer acceptance of the model. This case makes no claim of verified commercial gains or completed production deployment.
Frequently asked questions about economic simulation and MCP
Is this the game or a simulator?
This case covers the independent FIGHTEX economic simulator and analysis tools. Game mechanics are modeled to study their effects; this is not a claim to have delivered the player-facing game.
Why not ask an LLM to calculate the economy?
Numerical experiments need defined inputs, repeatability and checks. Python performs the calculations; an AI client uses MCP to explore and explain the evidence.
What makes a result reproducible?
A seed is only part of the context. Parameters, engine and configuration versions, and input data also matter. Snapshots and digests connect the result to that context.
Why use multiple seeds?
Rare wins and stochastic trajectories can dominate an individual experiment. Repeated runs expose variation rather than relying on one favorable realization.
Can rules change without editing Python?
Parameters live in configuration. Supported interfaces can create derived scenarios when access policy permits it, while preserving the baseline.
Can every MCP client run simulations?
No. Authorization, server policy, read-only mode and resource limits control available operations. An MCP connection does not grant infrastructure access.
Does the model prove profitability?
It evaluates specified rules and assumptions. Business interpretation requires evidence for those assumptions, scenario comparisons and sensitivity analysis; simulation is not a guarantee of future returns.
What is public on GitHub?
Architecture documentation covering the engine, MCP and reproducibility. Proprietary source code, customer parameters and confidential financial results are excluded.
Can this approach support another product?
The approach suits systems with interconnected rules, flows and uncertainties. Another product requires its own entities, events, parameter sources, checks and outcome criteria.
Python · NumPy · SciPy · Pandas · SQLite · Streamlit · Monte Carlo · MCP · Docker