Inspiration
Grinding LeetCode alone is miserable. It's silent, repetitive, and easy to quit, yet real technical interviews are the opposite: a clock, pressure, and another person in the room. We asked what would happen if practice felt like a ranked match instead of homework.
That became C.O.D.E.L: Compete Online: Debug, Execute, LARP. It's a real-time 1v1 fighting game where your only weapon is knowing how to code. Our hackathon prompt asked how technology can help people build in-demand skills and meaningful networks, and we think a shared fight beats a cold message every time.
What it does
Two players pick a pixel-art fighter and get the same question at the same moment. The first correct answer lands the hit, and the faster you are, the harder it lands:
$$ \text{damage} = b_t \cdot \left(1 + 0.5 \cdot \frac{t_{\text{left}}}{T}\right) $$
Here \( b_t \) is the base damage for tier \( t \), \( t_{\text{left}} \) is the time remaining, and \( T \) is the round length. Win three in a row and your next hit can fire an ultimate for 2.5x damage. If both players miss, both take chip damage.
Matches climb through six tiers, from variables and syntax up to recursion, trees, SQL joins, and time complexity. Across 115 questions in Python, JavaScript, and SQL, players fill in blanks, name concepts, predict output, spot bugs, and rewrite broken code. Afterwards, every question is reviewed with an explanation, so even a loss teaches you something.
How we built it
We split into clear ownership areas and agreed on a typed contract before writing features:
- Shared contract: TypeScript types, socket events, and game constants, imported by both client and server through npm workspaces.
- Server: Node, Express, and Socket.IO. The server is authoritative: it runs the timers, judges every answer, and owns all game state. The battle rules are pure functions, separate from networking, which makes them easy to test.
- Question engine: a validated question bank, a selector that balances question types and avoids repeats, and an answer grader.
- Client: Vite and TypeScript, with custom stage videos, character sprites, transitions, and music.
Accepted answers never reach the browser. Players only ever receive a public version of each question.
The grader was the most interesting piece. Instead of comparing raw text, it tokenizes code, so spacing doesn't matter, while Python's indentation still does. It uses edit distance to forgive small slips like retrun, but never when the "typo" is actually a real variable name, or a singular/plural swap like item for items. For typed answers, a near miss earns a one-time "Did you mean?" hint, which never counts as correct on its own.
We also refused to trust our own answer key. We ran the code from our questions in real Python, Node, and SQLite to confirm the outputs, and proved each buggy snippet actually fails while every accepted fix passes.
Challenges we faced
- Grading code fairly. Our first grader rejected perfectly valid fixes: single quotes instead of double, a missing
{, or a swap using atempvariable. Being too strict feels terrible mid-fight, and being too lenient breaks the game, so we tested it with the inputs real players would actually type. - Randomness that feels random. Uniform selection let common question types crowd out rare ones. Balancing by type fixed that but over-exposed questions in thin categories, which taught us to measure with thousands of simulated matches instead of trusting intuition.
- Pacing. Long questions need time, but past 60 seconds the speed bonus stopped mattering. We capped rounds and accepted short, targeted fixes as well as full rewrites.
- Building in parallel. With several people changing the same game at once, small contract changes could ripple everywhere. Clear ownership, reviewed pull requests, and CI kept us moving.
What we learned
We learned that fairness is a feature, and that it has to be tested from the player's side. We learned how much a typed contract speeds up parallel work, why a real-time game needs one authoritative server, and that the difference between a quiz and a game is mostly feel: timing, feedback, and a fight worth winning.
