This is a submission for the GitHub Finish-Up-A-Thon Challenge
What I Built
3D Quantum Chess — a fully playable chess game in the browser that layers
three quantum mechanics on top of standard chess rules:
Quantum Superposition: Split any piece into two simultaneous positions.
The ghost copy exists as a wavefunction until attacked — then it collapses,
either disappearing or materializing depending on probability.Wormhole Portals: Two linked spatial portals are placed randomly on the
board each game. Move a piece onto a wormhole entrance and it teleports
instantly to the exit — changing the entire strategic geometry of the board.Chronos Drive (Time Reversal): Each player has 3 charges to rewind the
last 3 half-moves. Triggered a blunder? Collapse a superposition at the wrong
moment? Rewind it. The board literally rolls back with a scanline animation.
The entire game renders in WebGL — a floating 3D board in space, rotating
portals with particle effects, glowing ghost pieces, and a starfield background.
Built with React + Three.js + chess.js.
This project means a lot to me because it started as a "what if chess had
quantum rules" sketch and grew into something I genuinely couldn't stop
building. The intersection of classical game theory and quantum weirdness turns
out to be endlessly fascinating.
Demo
🔗 Live Demo: https://quantum-chess-seven.vercel.app/
📸 Screenshots:


🎥 Walkthrough: [link to video if you have one]
The Comeback Story
This project sat at roughly 50% completion for weeks. What existed:
✅ Already done:
- Full project scaffold (Vite + React + Three.js)
-
gameConfig.js— all constants, colors, sizing tokens -
quantumStore.js— the entire Zustand state machine - All 5 engine files:
chessEngine.js,superposition.js,timeReversal.js,wormhole.js,aiEngine.js -
index.csswith glassmorphism styles and Tailwind config
❌ What was missing (and what I finished):
- The entire 3D rendering layer —
Board3D.jsx,Square3D.jsx,Piece3D.jsx,Wormhole3D.jsx— the game had a brain but no body - All four UI overlays —
QuantumHUD.jsx,TimelineHUD.jsx,GameInfo.jsx,WinScreen.jsx -
App.jsxwiring everything together - The gap between "logic exists" and "playable game" was enormous
The hardest part of finishing wasn't writing new code — it was understanding
the contract between the store and the 3D components. The store emits state;
the components must react to it precisely. Getting ghost piece click-through,
FEN-to-3D coordinate mapping, and the superposition collapse animations all
synchronized took real debugging effort.
Key fixes made during finish-up:
- Ghost pieces were blocking click events on squares beneath them — fixed with raycast visibility toggling
-
useFramerefs were being accessed before mount — added null checks throughout - The wormhole teleport was modifying FEN incorrectly for edge-rank squares —
rewrote the coordinate translation in
chessEngine.js - Framer-motion variants were missing
initialstates causing flash-of-content on the HUD panels
My Experience with GitHub Copilot
Copilot was most useful in two specific situations during this finish-up:
1. Boilerplate acceleration on repetitive 3D geometry
Writing Piece3D.jsx meant defining 6 different piece shapes, each as a
composite of 2-3 Three.js geometries. Copilot autocompleted the geometry
argument patterns (CylinderGeometry, SphereGeometry args) consistently
and correctly, saving significant lookup time in the Three.js docs.
2. Catching the store contract
When I started writing QuantumHUD.jsx, Copilot suggested the correct Zustand
selector pattern by inferring it from the already-written store file in context.
It correctly suggested useQuantumStore(state => state.quantumMoves) rather
than the whole-store subscription pattern — a meaningful performance difference.
Where I had to override it:
The quantum mechanics are non-standard. Copilot kept trying to simplify the
superposition collapse logic to a coin-flip, when the actual design calls for
deterministic collapse based on attack vectors. I had to be explicit in comments
to keep it on track for those sections.
Overall: Copilot is a strong finisher. For a project where the architecture is
already defined and you're filling in implementation, it dramatically reduces
the gap between "knowing what to build" and "having it built."

Top comments (0)