ChessWess is a multiverse timeline-based chess game where every move creates history. Players can rewind, branch alternate realities, and win across multiple timelines simultaneously.
Core Concept: "What if chess had Git branches?"
- React + TypeScript — Complex UI state management
- TailwindCSS — Fast styling
- React Flow — Timeline DAG visualization
- Zustand — Game state management
- Framer Motion — Timeline animation effects
- Go (recommended)
- WebSockets (Socket.IO or native ws)
- PostgreSQL — Persistent history graph
- Redis — Realtime state & timeline caching
- chess.js — Legal moves, validation, checkmate
- Stockfish WASM — Evaluations & analysis
- Docker — Containerization
- Vercel — Frontend deployment
- Railway/Fly.io/Render — Backend deployment
Establish a solid foundation with standard online chess before introducing timeline mechanics.
- User authentication & sessions
- Game rooms & matchmaking
- Real chess.js integration
- Legal move validation
- Game timers (5min, 10min, unlimited)
- Basic WebSocket communication
- Board rendering (React + simple styling)
- State Management: Zustand for game state
- Database: PostgreSQL with basic schema
- Realtime: WebSocket connection per room
- Move Validation: chess.js on both client & server
CREATE TABLE users (
id UUID PRIMARY KEY,
username VARCHAR UNIQUE,
created_at TIMESTAMP
);
CREATE TABLE games (
id UUID PRIMARY KEY,
white_player_id UUID,
black_player_id UUID,
status ENUM('pending', 'active', 'completed'),
created_at TIMESTAMP
);- Playable online chess game
- 2-player real-time sync
- Move history (linear list)
- Basic UI mockups implemented
- Backend: 8-10 hours (rooms, validation, WebSocket)
- Frontend: 10-12 hours (board, moves, timers)
- Database: 2-3 hours
- Two players can play a full game
- Moves sync instantly
- No race conditions
- Checkmate/stalemate detected correctly
Build the foundation for timelines by storing every move as an immutable node in a graph structure.
- Game state as DAG (Directed Acyclic Graph)
- Immutable GameNode structure
- Move tree visualization (simple)
- Replay any point in history
- Branch detection UI
type GameNode = {
id: string; // Unique node ID
parentId: string | null; // Linear history parent
childrenIds: string[]; // Branches from this node
boardState: Board; // FEN representation
move: Move; // Chess move (e.g., e2e4)
timelineId: string; // Which timeline owns this
turnNumber: number; // Turn within timeline
createdBy: Player; // Who made the move
metadata: {
check: boolean;
checkmate: boolean;
evaluation: number; // Stockfish score
};
createdAt: Date;
};CREATE TABLE game_nodes (
id UUID PRIMARY KEY,
game_id UUID REFERENCES games(id),
timeline_id UUID,
parent_node_id UUID REFERENCES game_nodes(id),
board_state TEXT (FEN), -- Fenstring
move_san VARCHAR, -- Move notation (e2e4)
turn_number INT,
created_by UUID REFERENCES users(id),
created_at TIMESTAMP
);
CREATE TABLE node_children (
parent_id UUID REFERENCES game_nodes(id),
child_id UUID REFERENCES game_nodes(id),
PRIMARY KEY (parent_id, child_id)
);- Every move stored as immutable node
- Move tree reconstruction working
- Replay system (click any node, board updates)
- FEN serialization for all nodes
- Backend: 6-8 hours (node storage, tree queries)
- Frontend: 4-6 hours (replay UI, node inspection)
- Database Migration: 3-4 hours
- Can replay any move sequence
- Graph structure is queryable
- Zero data loss on rewind
- Performance acceptable for 100+ nodes
Introduce the core innovation: rewind and create alternate realities.
- Rewind Move — Go back X turns, create branch
- Timeline Creation — Each rewind creates new timeline
- Timeline DAG Visualization — React Flow timeline graph
- Branch Inspection — Click any branch, see board state
- Active Timeline Switching — Select which timeline is "active"
Timeline A: Move 1 → Move 2 → Move 3 → Move 4 → Move 5
↓
[REWIND TO MOVE 3]
↓
Timeline B: Move 1 → Move 2 → Move 3 → Move 3B → Move 4B
- Timeline Graph (React Flow)
- Nodes represent board states
- Edges represent moves
- Color-coded by status (winning/losing/neutral)
- Board State Inspector
- Select any node, see current board
- Timeline Heatmap
- Highlight strong vs weak branches
- Branch Control Panel
- Rewind button + turn selector
- Timeline switcher
CREATE TABLE timelines (
id UUID PRIMARY KEY,
game_id UUID REFERENCES games(id),
root_node_id UUID REFERENCES game_nodes(id),
created_at TIMESTAMP
);
-- Link nodes to timelines
ALTER TABLE game_nodes ADD timeline_id UUID REFERENCES timelines(id);- Rewind creates new timeline
- Timeline graph renders correctly
- Both players see same branching
- Board stays consistent across switches
- Backend: 8-10 hours (timeline logic, branching queries)
- Frontend: 12-15 hours (React Flow setup, animations)
- Visualization: 6-8 hours (layout algorithms, heatmap)
- Players can rewind and branch
- Up to 50 timelines render smoothly
- No timeline data corruption
- Winning conditions evaluate per-timeline
Make switching between timelines fluid and intuitive.
- Jump Between Timelines — Instant switch, continuous gameplay
- Timeline Labels — Name branches (e.g., "Sacrificial Queen", "Defensive Hold")
- Breadcrumb Navigation — Show active path from root
- Divergence Highlights — Visualize where timelines split
- Performance Optimization — Lazy load large graphs
- Minimap of timeline graph
- Zoom/pan controls
- Hotkeys for timeline jumping
- Timeline sidebar showing stats (material count, evaluation)
- Seamless branch switching
- Timeline labels persisted
- Graph renders efficiently (1000+ nodes)
- UX polished for competitive play
- Backend: 4-5 hours (optimization queries)
- Frontend: 6-8 hours (UX polish, hotkeys, minimap)
- Can switch timelines in <100ms
- No lag with complex graphs
- Intuitive navigation for new players
Introduce strategic depth through resource management.
- Time Energy Pool — Players get limited rewinds per game
- Energy Costs
- Rewind to N turns ago = costs N energy
- Jump timeline = costs 1 energy
- Branch Locking — Spend energy to freeze a timeline (opponent can't rewind into it)
- Time Collapse — If 30+ timelines, weakest collapses (auto-deletion)
- Paradox Penalties — Contradictions weaken timelines gradually
Time Energy Pool: 15 (per player, per game)
Actions:
- Rewind 1 turn: 1 energy
- Rewind 5 turns: 5 energy
- Jump timeline: 1 energy
- Lock timeline: 3 energy
- Paradox created: -2 energy (penalty)
Win Condition Options (configurable):
1. Checkmate in ANY timeline
2. Control majority timelines (>50%)
3. Score-based: Checkmate + Timeline control = points
CREATE TABLE timeline_metadata (
timeline_id UUID PRIMARY KEY REFERENCES timelines(id),
locked_by_player_id UUID REFERENCES users(id),
is_locked BOOLEAN DEFAULT false,
energy_cost_to_create INT,
stability_score INT (0-100)
);
CREATE TABLE player_energy (
game_id UUID,
player_id UUID,
energy_remaining INT,
PRIMARY KEY (game_id, player_id)
);- Energy system fully functional
- Timeline locking prevents edits
- Collapse system removes old timelines
- UI shows energy & costs clearly
- Backend: 6-7 hours (energy logic, collapse system)
- Frontend: 4-5 hours (energy UI, cost indicators)
- Energy prevents infinite branching
- Gameplay becomes strategic
- Locking mechanic creates tension
- Collapse prevents performance degradation
Create replay cinematic experience for sharing & learning.
- Spectator Mode — Watch live multiverse battles
- Replay Engine — Rewatch any stored game
- Branching Playback — Animate moves along timeline graph
- Divergence Highlights — Show "what-if" moments
- AI Commentary (placeholder for Phase 7)
- Export Replay — Share as GIF or link
- Timeline graph with animated piece movement
- Show board state at each node
- Highlight critical divergence moments
- Speed controls (1x, 2x, 4x)
- Jump to interesting moments
- Can replay any completed game
- Smooth animations across timelines
- Export to shareable link
- Spectator mode functional
- Backend: 4-5 hours (replay API, export)
- Frontend: 8-10 hours (animations, playback UI)
- Replays are smooth & engaging
- Shareable links work correctly
- Competitive scene can broadcast
Add intelligent analysis and guidance.
- Stockfish WASM Integration — Evaluations per timeline
- Best Move Suggestions — Per timeline, per turn
- Branch Scoring — Which timelines are winning?
- Evaluation Graph — Show material advantage over time
- AI Narrator (optional)
- Example: "White sacrifices reality to save the queen."
// Evaluate all timelines
async function evaluateTimelineGraph(gameId: string) {
const nodes = await getGameNodes(gameId);
const evaluations = {};
for (const node of nodes) {
const score = await stockfish.evaluate(node.boardState);
evaluations[node.id] = score;
}
return evaluations;
}- Stockfish evaluations cached in Redis
- Per-timeline strength displayed
- Suggestion engine working
- No lag in UI from analysis
- Backend: 6-8 hours (Stockfish integration, caching)
- Frontend: 4-5 hours (evaluation UI)
- Evaluations <500ms per timeline
- Suggestions contextually relevant
- Cache prevents redundant computation
Production-ready competitive system.
- ELO Rating System — Traditional chess rating
- Ladder & Leaderboards — Player rankings
- Tournaments — Seasonal competitive events
- Replay Archive — Searchable game database
- Performance Monitoring — APM metrics
- Moderation Tools — Report/ban system
- Time controls: Bullet (1+0), Blitz (3+0), Rapid (10+0)
- ELO adjustments based on opponent rating
- K-factor: 32 for most players, 8 for 2000+ rated
- Anti-cheat: Detected engine use → ban
CREATE TABLE user_ratings (
user_id UUID PRIMARY KEY,
elo INT DEFAULT 1600,
games_played INT,
wins INT,
losses INT,
updated_at TIMESTAMP
);
CREATE TABLE tournaments (
id UUID PRIMARY KEY,
name VARCHAR,
status ENUM('signup', 'active', 'completed'),
created_at TIMESTAMP
);- ELO calculation working
- Leaderboard updated in real-time
- Tournament bracket system
- Player profiles complete
- Backend: 8-10 hours (ELO, tournaments, moderation)
- Frontend: 6-8 hours (profile pages, leaderboards)
- DevOps: 4-6 hours (monitoring, scaling)
- 1000+ concurrent players
- <50ms latency
- Fair ELO distribution
- Community engagement
| Phase | Duration | Focus | Key Deliverable |
|---|---|---|---|
| 1 | 3 weeks | Foundation | Playable chess |
| 2 | 3 weeks | Architecture | Immutable history |
| 3 | 3 weeks | Core Magic | Timeline branching ⭐ |
| 4 | 2 weeks | UX Polish | Smooth navigation |
| 5 | 3 weeks | Gameplay Depth | Energy system |
| 6 | 3 weeks | Virality | Replay system |
| 7 | 3 weeks | Intelligence | AI analysis |
| 8 | 4 weeks | Competition | Ranked ladder |
| Total | 24 weeks | ~6 months | Full product |
Phase 1 (Chess)
↓
Phase 2 (History Graph)
↓
Phase 3 (Branching) ← MVP LAUNCHES HERE
↓
Phase 4 (Navigation)
↓
Phase 5+ (Feature layers)
Milestone: Phase 3 completion = MVP ready for early users.
- ✅ Multiplayer chess (Phase 1)
- ✅ Timeline branching (Phase 3)
- ✅ Basic graph visualization (Phase 3)
- ✅ Replay system (Phase 6, simplified)
- ❌ AI features
- ❌ Quantum mechanics (Phase 2+ feature)
- ❌ Ranked ladder (Phase 8)
- ❌ Cosmetics & skins
- ❌ Tournament system
MVP Pitch: "Chess with branching timelines. Rewind your blunders. Win across multiple realities."
Every game node is frozen forever. Never mutate old board states.
Each timeline's move validation is independent. One timeline's moves don't affect others.
- Timeline state cached in Redis
- Evaluation scores cached per node
- Graph structure cached (refreshed on new branch)
- Lazy load timeline graph (don't render 1000 nodes upfront)
- Virtual scrolling for node lists
- Minimap for quick navigation
Replay any timeline sequence and get identical board state.
Problem: Both players must see identical graphs, no race conditions.
Solution:
- WebSocket emits events in order
- Server processes moves atomically
- Redis maintains canonical timeline state
- Client replicates server state
Problem: Storing full board per node = massive database.
Solution:
- Store only FEN strings (compact)
- Store only the move (not full board diff)
- Derive board state from path: Root → Node
- Compress old timelines after completion
Problem: Same position reached via different paths = valid in both?
Solution:
- Validate moves in current timeline context only
- Each timeline has independent move history
- Piece positions derived from move sequence, not global state
Problem: 10,000 node games become slow.
Solution:
- Implement timeline pruning (collapse unused branches)
- Use B-tree index on (game_id, timeline_id, turn_number)
- Cache heatmap calculations in Redis
- Lazy-load graph UI (viewport-based rendering)
Problem: Large DAGs become spaghetti.
Solution:
- Use Sugiyama layout algorithm (hierarchical)
- Implement minimap for quick orientation
- Use zoom/pan with performance budget
- Color-code nodes by strength (green = winning, red = losing)
- Excellent out-of-box for graph visualization
- Handles 1000+ nodes efficiently
- Built-in zoom/pan/select
- Active community
- Redux has too much boilerplate for game state
- Zustand: simple, fast, perfect for multiplayer
- Easy to sync with WebSocket updates
- Better concurrency (goroutines)
- Faster WebSocket handling
- Lower memory footprint
- Perfect for state-heavy apps
- Relational graph queries are complex in MongoDB
- Need ACID for move integrity
- FEN strings are simple text (no NoSQL advantage)
- 1 Backend Lead (Go/WebSocket/DB architecture)
- 1 Frontend Lead (React/visualization/UX)
- 1 DevOps/Infrastructure (Docker, deployment)
Solo Development: Expect 12-18 months instead of 6. Prioritize MVP first.
- 100+ games completed (Phase 3 launch)
- Average 5 rewinds per game (branching adoption)
- 50% of replays viewed by non-players (virality)
- <100ms move latency (P99)
- <500ms timeline graph render
- <50ms rewind operation
- 1000+ concurrent users (EC2 scale test)
- 10,000 MAU by end of Year 1
- 95% positive reviews/ratings
- Successful tournament with 100+ players
- All Phase 1-3 features working
- Database migrations tested in production
- Load testing (simulate 100 concurrent games)
- Security audit (no SQL injection, CORS correct)
- UX testing with 10+ beta players
- Mobile responsive design (basic)
- Closed beta with 100 players
- Collect feedback
- Fix critical bugs
- Optimize performance
- Marketing campaign
- Press release
- Community Discord/Reddit
- Content creator outreach
ChessWess/
├── frontend/
│ ├── src/
│ │ ├── components/
│ │ │ ├── Board/
│ │ │ ├── Timeline/
│ │ │ ├── ReplayPlayer/
│ │ ├── store/
│ │ │ └── gameStore.ts (Zustand)
│ │ ├── utils/
│ │ │ └── chess.ts
│ ├── package.json
│ └── README.md
├── backend/
│ ├── main.go
│ ├── server/
│ ├── models/
│ │ ├── game.go
│ │ ├── timeline.go
│ │ └── node.go
│ ├── db/
│ │ └── migrations/
│ └── go.mod
├── docker-compose.yml
├── .env.example
└── PLAN.md (this file)
- Set up project repo (GitHub)
- Create frontend & backend project structure
- Set up PostgreSQL locally
- Initialize Redis
- Create initial database schema
- Implement chess.js integration
- Build WebSocket server
- Create game rooms logic
- Build basic React board component
- Deploy to staging
Begin immutable graph implementation...
- Team: Solo or team? (Affects timeline: 6 months vs 12-18)
- Infrastructure: Self-hosted or cloud? (AWS, Vercel, Railway?)
- Monetization: Free forever or premium? (Affects Phase 8 design)
- Scope: Full Phase 8 or stop at MVP (Phase 3)?
- Time Commitment: Full-time or side project? (Affects feasibility)
- React Flow docs: https://reactflow.dev/
- Zustand docs: https://github.com/pmndrs/zustand
- chess.js docs: https://github.com/jhlywa/chess.js
- PostgreSQL graph queries: Window functions, CTEs
- Local: Docker Compose (Postgres + Redis)
- Staging: Vercel (frontend) + Railway (backend)
- Monitoring: LogRocket (frontend), DataDog (backend)
This is not a side project. ChessWess is a 6-month full-time commitment or 12-18 months part-time.
The magic moment happens in Phase 3 when branching works. That's when people will understand the vision.
Every other phase builds on that foundation.
Start small, launch MVP, iterate with users.
The innovation is the timeline graph. Everything else is execution.
Good luck. This is going to be incredible. 🚀