Game Economy Simulator

Overview

Game Economy Simulator treats game-economy balancing as a quantitative simulation and optimization problem instead of a spreadsheet exercise. A designer configures gold sources (quests, enemy drops), gold sinks (potions, gear purchases), and a heterogeneous player population, then sees how wealth spreads across player archetypes over time, whether the economy is healthy, inflating, or trapping casual players in poverty, which parameter value approximately hits a target progression milestone, and how the economy behaves under stress scenarios and Monte Carlo variation. Everything runs in a four-tab Streamlit dashboard with no backend, database, or external API calls.

Problem

Most game economies start life as a spreadsheet, which computes deterministic averages well but hides what matters in play: players don't behave uniformly (a Grinder farms far more than a Casual), drops are random (Poisson quest completions and clipped-Normal enemy drops skew wealth), and pacing depends on a cumulative balance over time rather than a single reward-to-price ratio.

Solution

• Dashboard & Health: run the core engine to see wealth curves, archetype breakdowns, and time-to-afford milestones, alongside automated diagnostics (macro flow ratio, Gini coefficient, casual fail rate) with rule-based alert cards and prescriptions.
• Scenario Stress-Test: four economic regimes (Normal, Gold Rush, Economic Crisis, Demographic Shock) side by side.
• Monte Carlo Risk Lab: jitters economy parameters across a configurable number of runs (20–200, default 50) and shows P5–P95 confidence fan charts and empirical risk probabilities.
• Auto-Tuning Lab: a binary-search solver that finds the parameter value that approximately meets a target milestone day.

Architecture & Core Systems

• Configuration: EconomyConfig, SimulationConfig, and archetype profiles (Casual, Grinder, Collector, Optimizer) in config/.
• Simulation core: a vectorized (players × days) engine plus a Monte Carlo risk engine in simulation/.
• Analytics: the diagnostics rule engine and the binary-search auto-tuner in analytics/.
• Presentation: Plotly chart builders and health-card renderers in visualization/, wired into a four-tab Streamlit app.

Technical Implementation

• Vectorized engine: archetypes are assigned with numpy.random.Generator.choice, and the full players × days activity matrices for quests, enemies, and potions are drawn up front, so the only Python loop runs over days, not players.
• Diagnostics: the Gini coefficient is computed with a vectorized Lorenz formula on final balances; each check emits a severity-graded alert with a concrete prescription.
• Auto-tuner: probes run on a smaller population at the midpoint of a search interval, halve the interval on the signed milestone error, and the recommendation is re-validated on the full configured population.
• Reproducibility: all randomness uses numpy.random.default_rng with a configurable seed.
• Testing: a Pytest suite of unit and integration tests, plus a CLI validation script.

Quantitative Methodology

Stochastic model: daily quest completions are Poisson draws and enemy drops are clipped Normal draws, scaled per archetype by quest, enemy, potion, and saving multipliers. Health metrics: macro flow ratio (total income / total spending) classifies the economy as Balanced, Inflating, or a Poverty Trap; the Gini coefficient measures wealth inequality; the casual fail rate is the share of Casual players who never reach the target milestone. Auto-tuning: binary search on one parameter, stopping when the milestone error is within one day or the interval narrows to one gold. It assumes a monotonic parameter-to-milestone relationship, which holds in expectation but not strictly under stochastic noise, so the result is an approximate estimate. Risk analysis: Monte Carlo parameter jitter across 20–200 configurable runs, summarized as P5–P95 fan charts and empirical risk probabilities.

Challenges

• Keeping interactive parameter sweeps and multi-run Monte Carlo studies responsive in Streamlit, solved by pre-computing the full income tensor instead of looping over every player on every day (trading some memory for speed).
• Being honest about the auto-tuner: binary search relies on monotonicity that stochastic noise does not guarantee, so results are presented as approximations and re-validated on the full population.

Results

Deployed on Streamlit Community Cloud and open-source on GitHub, with unit and integration tests and a CLI validation script.