ChronoChess

Chess, evolved with abilities.

Comment

ChronoChess

Prototype disclaimer: This is an early prototype with lots of bugs and rough edges. Not all systems are fully implemented or balanced yet, and there are many features planned. The focus was proving the core loop and architecture during the Code with Kiro Hackathon.

Inspiration

Chess is timeless, but what if we layered it with idle progression and evolution paths—without losing its strategic clarity? The Code with Kiro Hackathon’s call to turn ideas into production code with spec‑driven development felt like the perfect frame to explore that idea. I wanted a “thinking game” shaped by thinking tools—where specs lead, and code follows.

What it does

ChronoChess blends classic chess with:

  • Idle resource generation that progresses while you’re away
  • Piece evolution trees that change how chess is played
  • A 3D board you can feel via Three.js + physics
  • Solo mode vs AI with auto‑battle support

It’s built to feel strategic yet serene: meaningful choices layered over a familiar grid, with systems that reward planning.

How I built it

  • Frontend: React 18 + TypeScript + Vite
  • Chess Logic: chess.js with custom rule/ability extensions
  • 3D & Physics: Three.js + Cannon.js, decoupled simulation and rendering
  • State: Zustand slices with typed contracts
  • Save: IndexedDB local saves; optional Supabase cloud sync
  • Tooling: ESLint, Prettier, Husky, Vitest; Docker dev/prod

The codebase is intentionally modular:

  • engine/ — chess core + ability hooks
  • evolution/ — evolution graphs, costs, constraints
  • resources/ — idle generation, transactions, offline accumulation
  • rendering/ — Three.js scene orchestration
  • physics/ — Cannon.js simulation and effects
  • save/ — persistence, migrations, compression
  • audio/ — ambient + feedback systems

Two light math beats guided tuning:

1) Evolution state space (rough upper bound): with \(n \) pieces and branch factors \(b_i \):

$$ \text{strategies} \lesssim \prod_{i=1}^{n} b_i $$

A toy example: \(6^{16} \approx 2.82\times10^{12} \) (constraints prune it, but the space is rich).

2) Resource ticks with bounded multipliers:

$$ R_t = R_{t-1} + \alpha_r\,\cdot\, f(\text{board_state},\; \text{evolutions}) $$

Caps/soft knees prevent runaway growth while keeping progression satisfying.

How Kiro was used

  • Spec‑driven development: I collaborated with Kiro to turn prompts into requirements and interface contracts (e.g., ResourceManager, EvolutionTreeSystem, engine extension points), then used those specs to scaffold modules, reducers, and typed selectors/tests.
  • From chat to specs to code: I prototyped interactions (e.g., physics cues) in chat, then captured decisions in specs and refactored implementations to match the contracts.
  • Repo structure: The project includes a .kiro/ directory (at repo root) for specs/steering in line with hackathon submission guidelines.

Challenges I ran into

  • Preserving chess clarity with abilities: new mechanics risk cognitive overload; I kept engine decisions deterministic and treated abilities as composable rules with tests.
  • Performance in 3D: culling, batching, and decoupled simulation ticks were needed to keep input snappy.
  • Save integrity: Cloud + local fallback led to edge cases; versioned snapshots and “last good” recovery helped.
  • Scope in hackathon time: specs/roadmap constrained the build to the core loop first.

Accomplishments I’m proud of

  • A clear, replaceable systems architecture (engine/evolution/resources/rendering/physics/save)
  • Moment‑to‑moment feel: captures and checks land with weight thanks to physics + audio
  • Evolution hooks into engine rules in a testable way
  • Optional cloud saves with local fallback

What I learned

  • Specs amplify AI: Kiro is best as a partner when fed real contracts.
  • Idle systems must enrich turn‑based tension, not erase it.
  • Testing thrives at boundaries; visuals need smoke tests and manual sanity checks.

What’s next

  • Evolution balance and an intuitive planning UI
  • Future: narrative beats that encourage strategic diversity
  • Audio polish and procedural stingers
  • Performance presets for low‑end devices
  • More tests for engine/evolution invariants
  • Multiplayer exploration after single‑player polish
  • Real 3D piece models per rank (e.g., Pawn L1 classic, L2 upgraded with lineage features, L3 distinct “soldier” variant), with LODs and instancing/batching for performance
  • and much more...

Built With

Share this project:

Updates