Volatility Forge 2D

• 

  Choose one of 12 risk missions or 6 desk finals with explicit objectives.

• 

  Build an option book while monitoring payoff, Greeks, limits, and execution cost.

• 

  Commit calibrated probability forecasts before the simulated path is revealed.

• 

  Advance the deterministic market, hedge exposures, and handle customer flow.

• 

  Explain results through P&L attribution, calibration, drawdown, and replay.

Inspiration

Options education often stops at formulas. I wanted to turn Delta, Gamma, Theta, Vega, volatility, liquidity, and event risk into decisions that can be felt, tested, and explained. Volatility Forge treats explainability as the core game mechanic: a good run is not just profitable; it is calibrated, risk-aware, and auditable.

What it does

Volatility Forge is a native 2D options-risk training game built in Godot. Every run follows a focused Mission -> Build -> Run -> Review loop:

• Choose a mission with a fixed horizon and explicit risk objectives.
• Build an option portfolio and inspect its Greeks and payoff.
• Commit four probability forecasts before revealing the market path.
• Advance a deterministic simulated market, hedge risk, or quote customer flow.
• Review P&L attribution, transaction costs, drawdown, risk breaches, calibration, and the immutable action replay.

The game includes 12 core missions, 6 desk finals, reproducible seeded challenges, official and practice modes, local progress, and keyboard-friendly controls. All market data is simulated and no brokerage account is connected.

How I built it

The project runs on Godot 4.7 with native Control nodes, custom-drawn charts, and modular GDScript systems. A Black-Scholes engine computes European option prices and Greeks. Separate modules own market simulation, portfolio state, mission objectives, the run ledger, scoring, P&L attribution, procedural challenges, and persistence.

The simulator models spot and implied-volatility moves, event shocks, liquidity, customer flow, and transaction costs. Fixed mission horizons and deterministic seeds make runs comparable. Forecasts use Brier scoring, while replay records keep every market step and priced trade available for review.

How Codex and GPT-5.6 were used

Codex was an active engineering collaborator throughout the build, running GPT-5.6:

• Inspected the original browser prototype and planned the native Godot port.
• Implemented and refactored the engine, game rules, UI, persistence, and smoke tests.
• Reasoned through anti-exploit rules such as forecast-before-reveal, official versus practice runs, fixed horizons, and immutable replay history.
• Configured Godot and Godot MCP, launched the project, inspected debug output, and iterated directly against the running desktop game.
• Translated supplied visual references into the final high-contrast interface and reviewed responsive states.
• Managed Git branches, diffs, verification, and pull requests.

I provided the product direction, options-domain requirements, reference material, and acceptance decisions. The repository README contains the detailed Codex/GPT-5.6 workflow.

Challenges

The hardest part was translating abstract risk measures into short, legible decisions without turning the experience into either a spreadsheet or an arcade game. Other challenges included making dense portfolio data readable in compact windows, preventing scoring exploits, preserving replay integrity through live trades, and keeping native UI behavior testable.

Accomplishments

• A fully native Godot experience with no web runtime.
• Explainable P&L decomposition across Greeks, volatility, carry, costs, and residual.
• Forecast calibration and risk discipline integrated into scoring.
• Deterministic challenge generation and replayable market paths.
• Headless tests covering rules, pricing, integration, and the main gameplay flow.

What I learned

Explainability is a stronger learning loop than raw profit. Asking players to commit probabilities before seeing outcomes exposes calibration errors, while fixed horizons and replay make it possible to distinguish a sound process from luck. I also learned that agent-assisted development is most effective when the model can repeatedly run the real engine, inspect output, and verify behavior instead of only generating code.

What's next

Next steps are signed macOS and Windows exports, a hosted daily challenge and leaderboard, more volatility-surface missions, localization, richer accessibility settings, and additional debrief visualizations.

Built With

• black-scholes
• codex
• gdscript
• godot
• gpt-5.6
• mcp