Skip to main content

​
Current Status

Snake

Proof of Concept: Complete95% physical validity, 100% rule validity. Model learns movement, growth, and collision rules from event sequences.

Pac-Man

Status: DesignedSpecification complete. Ready for implementation.

Survivor

Status: FantasizingConcept stage. Will test massive entity scale.

Chess

Status: AlphaGoneThe final boss. No physics, turn-based, two-player.

​
Game Progression

The system is game-agnostic by design. Each game in the roadmap tests the event grammar approach at increasing complexity:
#GameStatusTests
1Snake✅ Proof of ConceptMovement, growth, conditional self-collision
2Pac-Man🎨 DesignedMulti-entity, enemy AI, buff-conditional rules
3Survivor💭 FantasizingMassive entity scale, build paths, wave structure
4Chess👻 AlphaGoneNo physics, turn-based, two-player
If chess works, the system is genuinely game-agnostic — not just “action-game-agnostic.”

​
Snake (Complete)

What it tests: Core event-driven mechanics
  • ✅ Movement physics: One cell per tick, grid-based
  • ✅ Conditional growth: Eating → body length increases
  • ✅ Self-collision: Death when head hits body
  • ✅ Legal actions: Cannot reverse direction
  • ✅ Event sequences: INPUT → MOVE → EAT → GROW → FOOD_SPAWN
Results: 31K parameters, 200 episodes, 5000 training steps
  • Physical validity: 95% — moves are adjacent cells, positions stay in bounds
  • Rule validity: 100% — EAT→GROW+FOOD_SPAWN, DIE→EOS
  • Loss: 4.47 → 0.25 (random baseline: ln(74) ≈ 4.3)
The model learned Snake’s grammar without explicit rules. This validates the core premise.
See the Snake documentation for full implementation details.

​
Pac-Man (Designed)

What it tests: Multi-entity coordination and buff-conditional rules

​
Key Challenges

  1. Multiple enemies: Four ghosts with different AI behaviors (Blinky, Pinky, Inky, Clyde)
  2. Buff system: Power pellet temporarily reverses predator/prey relationship
  3. Conditional rules:
    • Normal state: Ghost collision → DIE
    • Powered state: Ghost collision → EAT_GHOST → SCORE
  4. Entity identity: Events must distinguish between ghosts by name
  5. Simultaneous agents: Player + 4 ghosts act on same tick

​
Expected Events

  • INPUT_U/D/L/R — Player directional input
  • MOVE — Player or ghost moves
  • EAT_PELLET — Player eats small pellet
  • EAT_POWER — Player eats power pellet
  • POWER_START — Buff activates
  • POWER_END — Buff expires
  • EAT_GHOST — Player eats frightened ghost (powered state)
  • GHOST_RESPAWN — Eaten ghost returns to base
  • DIE_GHOST — Ghost collision while unpowered
  • SCORE — Score update event

​
Why Pac-Man?

Pac-Man tests whether the model can learn:
  • State-dependent rules: Same collision, different outcome based on power-up state
  • Multi-agent coordination: Predicting ghost movements alongside player
  • Entity tracking: Remembering which ghost is where
If the model learns that POWER_START changes collision semantics, that’s conditional rule emergence — a Tier 2 validation.

​
Survivor (Fantasizing)

What it tests: Massive entity scale and build systems

​
Concept

Inspired by Vampire Survivors:
  • Player moves freely in 2D space
  • Waves of enemies spawn over time
  • Player collects XP to level up and choose upgrades
  • Build synergies emerge from upgrade choices

​
Key Challenges

  1. Massive entity count: 100+ enemies on screen
  2. Upgrade trees: Conditional abilities that modify event sequences
  3. Wave structure: Enemy spawning follows time-based patterns
  4. Build paths: Different upgrade sequences create distinct playstyles

​
Expected Events

  • WAVE_START — New wave begins
  • ENEMY_SPAWN — Enemy enters field
  • ATTACK — Player weapon fires
  • HIT — Projectile hits enemy
  • ENEMY_DIE — Enemy defeated
  • XP_DROP — XP spawns at death location
  • XP_COLLECT — Player picks up XP
  • LEVEL_UP — Player gains level
  • UPGRADE_SELECT — Player chooses upgrade

​
Why Survivor?

Survivor tests whether the model can:
  • Scale to high entity counts: Track 100+ entities without collapse
  • Learn build paths: Recognize that certain upgrade sequences create synergies
  • Predict wave structure: Anticipate spawn patterns over long time horizons
This is where archetype discovery becomes essential. Different upgrade paths should emerge as distinct statistical patterns.

​
Chess (AlphaGone)

What it tests: Turn-based, no-physics, two-player games

​
Key Challenges

  1. No physics: Movement is rule-based, not collision-based
  2. Turn-based: Players alternate instead of acting simultaneously
  3. Two-player: Opponent actions must be predicted, not just observed
  4. Complex rules: Castling, en passant, promotion, check/checkmate
  5. Long-horizon planning: Good moves depend on 5+ turns ahead

​
Expected Events

  • MOVE — Piece moves from A1 to A4
  • CAPTURE — Piece takes opponent piece
  • CASTLE — Special king+rook move
  • PROMOTE — Pawn reaches back rank
  • CHECK — King under attack
  • CHECKMATE — Game ends

​
Why Chess?

Chess is the final test of game-agnosticism:
  • No collision physics (unlike Snake, Pac-Man, Survivor)
  • No real-time coordination (pure turn-based)
  • Opponent modeling required (two-player zero-sum)
If the transformer can learn chess rules from event sequences, the approach is truly general.
Training data could come from Lichess API — millions of annotated games in PGN format, easily converted to event sequences.

​
Complexity Progression

Each game adds new capabilities:
CapabilitySnakePac-ManSurvivorChess
Movement physics✓✓✓✗
Collision rules✓✓✓✗
Multi-entity✗✓✓✓
Conditional rules✓✓✓✓
Buff system✗✓✓✗
Upgrade trees✗✗✓✗
Turn-based✗✗✗✓
Two-player✗✗✗✓
Entity count25100+32
This progression ensures that each game validates new aspects of the event grammar hypothesis.

​
The Endgame: Archetype-Driven Progression

The long-term vision is to identify player archetypes from learned event grammar and use them to drive progression systems.

​
Concept

Instead of hand-designing progression systems, let the model discover how players naturally play, then offer skills that complement their style. 
1. Player plays normally
2. Event stream records gameplay
3. Trained model classifies trace → archetype
4. Game offers skills that complement their natural style

​
Example: Snake Archetypes

From the README, here are hypothetical archetypes the model might discover:

Wall Hugger

Pattern: Moves parallel to walls frequentlyUnlock: “Wall Slide” — speed +1 when moving parallel to a wall

Food Chaser

Pattern: Moves toward food aggressivelyUnlock: “Scent” — directional arrow toward food from anywhere

Coiler

Pattern: Coils body tightly in small areaUnlock: “Phase” — pass through your own tail once per life

Space Filler

Pattern: Long straight runs without turningUnlock: “Momentum” — every 5th move without turning is free
These archetypes aren’t hand-labeled. They emerge as statistical regularities in the learned grammar. The model finds the pattern.

​
Why This Matters

Imagine this applied to a real game:
Call of Duty: Zombies that gives you piercing bullets if you’re a trainer or longer mags if you’re camping behind claymores. Of course at that point we could buff the mobs to break the train or jump claymores, too.
The game adapts to how you naturally play, without you filling out a survey or choosing a class.

​
Implementation Roadmap

From the project README:
  • Snake game + event stream
  • Hybrid keyframe+delta tokenizer (74 tokens)
  • GameGPT transformer (31K params, pure Python)
  • Train on Snake traces — Tier 1 (valid behavior): 95% physical, 100% rule
  • Evaluate Tier 2 (conditional rule emergence)
  • Evaluate Tier 3 (play style / archetype emergence)
  • Visualizers
  • Performance optimization
  • Ouroboros (model plays against itself)
  • Pac-Man implementation and training
  • Archetype-based progression system prototype
  • Survivor implementation
  • Chess (Lichess data integration)

​
Contributing

The most valuable contributions right now:
  • Feedback on tokenization approaches — this is the core unsolved problem
  • Alternative games that would test capabilities not yet considered
  • Connections to related work (world models, player modeling, event sourcing)
  • Experience reports from applying similar ideas
See the main README for contribution guidelines.

Build docs developers (and LLMs) love

Get started for freeTalk to us