gijs_pong/.planning/STATE.md

STATE: Super Pong Next Gen

Project Reference

• Core Value: Pong reimagined with juice and depth — spectacular visuals, rich mechanics, complete game experience
• Current Focus: Phase 1 — executing plans
• Key Constraint: Coarse granularity (5 phases max), HTML5 Canvas + vanilla JS, static deployment

---

Current Position

Attribute	Value
Phase	01-foundation
Plan	Plan 2/2 (01-02 next)
Status	Plan 01-01 complete — scaffold, HiDPI canvas, game loop, Player 1 input done
Progress	5% (1/2 plans complete in Phase 1)

[=                   ] 5% — Phase 1: Plan 1/2 complete

---

Performance Metrics

Metric	Target	Status
Phase Coverage	100% (37/37 requirements mapped)	✓ Complete
Success Criteria	2-5 per phase	✓ Complete
Dependency Chain	Linear (P1 → P2 → P3 → P4 → P5)	✓ Validated
01-01 Duration	—	1 min (2 tasks, 1 file)

---

Accumulated Context

Key Decisions Made

1. Coarse Granularity Compression: Research suggested 10 phases; compressed to 5 by merging:

   • Game loop + input + physics = Phase 1
   • Second paddle + AI = Phase 2
   • Menus + audio + pause = Phase 3
   • Visual effects + power-ups + arenas = Phase 4
   • Performance + testing = Phase 5

2. Phase 5 (Release) Has No Requirements: All 37 v1 requirements covered by phases 1-4. Phase 5 is purely validation (cross-browser, performance, pitfall mitigation).

3. Success Criteria Grounded in Research Pitfalls: Each phase's criteria address critical pitfalls from research:

   • Phase 1: DPI scaling, game loop timing
   • Phase 2: Ball tunneling, input lag, AI balance
   • Phase 3: Audio autoplay policy
   • Phase 4: Power-up balance
   • Phase 5: Performance, memory leaks, cross-browser

4. deltaTime Cap at 50ms: Game loop caps deltaTime to prevent physics explosion when tab loses focus and resumes — without this a single large delta would fling the ball off screen.

5. Logical vs Bitmap Coordinate Separation: canvas.width/height = logical * devicePixelRatio; ctx.scale(dpr, dpr) makes all game draw calls use logical pixels — correct HiDPI approach for sharp rendering on Retina displays.

6. Module-Object Pattern Established: GameLoop, Renderer, Input, Physics, GameState are plain JS objects with init() methods in a single script tag. No classes, no modules, no build step — runs directly from filesystem.

7. e.code over e.key for Input: Using e.code === 'KeyW' makes W/S detection layout-independent (works on AZERTY and other non-QWERTY keyboards).

Coverage Validation

Total v1 Requirements: 37

• CORE (8): All mapped to Phase 1-2
• AI (4): All mapped to Phase 2
• SCRN (4): All mapped to Phase 3
• VFX (5): All mapped to Phase 1 (DPI) and Phase 4 (particles/glow/trails/shake)
• PWR (7): All mapped to Phase 4
• ARENA (4): All mapped to Phase 4
• AUD (5): All mapped to Phase 3

Unmapped Requirements: 0 ✓ Coverage: 100% ✓

Research Alignment

• Phase 1 addresses Research Pitfalls: #1 (Game Loop Timing), #2 (Canvas DPI Scaling)
• Phase 2 addresses Research Pitfalls: #3 (Ball Tunneling), #4 (Input Lag), #5 (AI Difficulty Balance)
• Phase 3 addresses Research Pitfall: #6 (WebAudio Autoplay Policy)
• Phase 4 addresses Research Pitfalls: #7 (Power-Up Balance)
• Phase 5 addresses Research Pitfall: #8 (Memory Leaks)

---

Session Continuity

What Just Happened

Plan 01-01 executed: Created index.html with full-window HiDPI canvas, Renderer (devicePixelRatio aware), GameLoop (requestAnimationFrame + deltaTime), Input (W/S keys), Physics skeleton (paddle movement + clamping), and GameState. Player 1 paddle is visible and responsive. Requirements VFX-05 and CORE-07 satisfied.

What Comes Next

1. Execute Plan 01-02 — Ball physics: movement, wall bounce, zone-based angle deflection, per-hit speed increment
2. Continue through phases 2-5 after Phase 1 complete

Known Blockers

None.

Decisions Pending

None.

Last Session

Stopped at: Completed 01-01-PLAN.md (2026-03-10)

---

State initialized: 2026-03-10