Titan Game Compiler
Games as compilable, testable, repairable software.
Inspiration
Generative systems can create game code, but generation alone does not prove that the result is playable, balanced, or stable. Titan Game Compiler turns game development into a closed engineering loop: structure the rules, compile them, execute them, measure behavior, diagnose failures, revise the rules, and rebuild.
What it does
The current vertical slice starts from versioned GameplayIR containing a world, phases, acceptance thresholds, and lineage. It:
- validates required fields, semantic versions, unique phase IDs, numeric bounds, thresholds, and lineage consistency;
- compiles phase definitions into an executable runtime graph;
- runs autonomous simulated playtests through an instrumented state machine;
- emits run and phase events, records outcomes, and localizes failures;
- aggregates success rate and each phase's share of deaths;
- evaluates those measurements against explicit acceptance thresholds; and
- supports targeted, versioned rule repair followed by recompilation.
The goal is not simply to generate a game. It is to connect design intent, runtime behavior, evidence, and revision in one inspectable loop.
How we built it
The vertical slice is organized as separate TypeScript modules for the IR validator, compiler, event bus, runtime state machine, autonomous player, telemetry recorder and aggregator, evaluator, and version lineage. It is compiled to browser JavaScript and presented through an HTML/CSS/Canvas interface deployed on Vercel.
The compiler validates the source representation before execution. The runtime emits observable events instead of hiding behavior inside a monolith. The evaluator then reports PASS or FAIL from declared success-rate bounds and maximum phase-death concentration. The autonomous player accepts an injectable random-number source, which gives the test harness a path to controlled seeded runs.
Where AI fits
This build uses an autonomous programmatic player to generate behavioral evidence and an automated evaluator to turn that evidence into bounded diagnoses and targeted rule revisions. It does not claim a trained gameplay model, general repair intelligence, or benchmarked repair performance. The explicit IR and acceptance gates are designed so learned agents can be introduced without giving them unrestricted control over runtime state.
Challenges we ran into
- Turning subjective ideas such as “too hard” into measurable acceptance criteria.
- Keeping source intent separate from the compiled runtime representation.
- Making failures attributable to a phase rather than treating a run as a single opaque result.
- Keeping repair localized, versioned, and auditable instead of rewriting the game blindly.
Accomplishments that we're proud of
- A structured
GameplayIRboundary with concrete validation rules. - A compiler that produces a runtime graph from game phases.
- An event-driven state machine that exposes playtest behavior.
- Automated aggregation of success and phase-level failure evidence.
- Threshold-based diagnosis and a versioned repair/recompile path.
What we learned
The valuable artifact is not one generated game. It is the evidence loop around the game: explicit intent, executable behavior, measurable outcomes, and a controlled next revision.
What's next
- Publish the Titan Game Compiler source in a documented public repository.
- Restore public access to the embedded compiler lab.
- Add fixed-seed replay and a broader corpus of known game defects.
- Publish reproducible measurements for repair success, cycle time, and required human intervention.
- Test learned play and repair agents against the current explicit baseline.
Built With
- canvas-api
- css3
- html5
- javascript
- typescript
- vercel