Number Sliding Puzzle PvP
Up to four players race the same board in real time — coordinated by Redis, settled by the server.
Overview
Players race on identical 4×4 boards; consecutive correct placements fire combo attacks — cloud, vanish, shuffle — at opponents. AI players fill empty seats within ±200 rating, humanized with tempo variation, pauses, and plan deviation so they read as people.
The client moves optimistically; the server owns the truth. Room admission, game start, finish ordering, forfeits, disconnects, timers, and rating finalization are all decided on a server-authoritative TypeScript backend — never trusted to clients.
Full stack
- Flutter · Riverpod · GoRouter (~15.1k lines Dart)
- Node.js 20 · TypeScript · Express (~10.7k lines)
- Socket.IO 4 + Redis adapter (cross-node fanout)
- Redis (snapshots, locks, scheduled tasks)
- Firebase Auth · Firestore · AWS S3 presigned uploads
- Jest + Supertest (148 tests, 19 suites) · flutter_test
- Docker multi-stage + docker-compose · GitHub Actions
Engineering highlights
The parts a code review would find interesting.
01Distributed coordination that survives restarts
Room and game snapshots recover from Redis on boot; distributed locks guard start/timeout/disconnect/AI-fill paths; and a custom Redis-backed scheduled-task system replaces process-local timers with cross-instance failover.
02Chaos-tested, literally
A dedicated chaos suite verifies lock contention admits a single holder, scheduled tasks execute exactly once across competing scheduler instances, reconnect races keep the latest socket owner, and canceled disconnect tasks never fire.
03AI opponents with lookahead
Bots run depth-limited search with Manhattan-distance + linear-conflict heuristics, difficulty-scaled depth, and humanization parameters — including repeated-state loop detection so they never visibly thrash.
04Multiplayer Glicko, from scratch
A simplified pairwise Glicko engine for 2–4 player matches: RD-weighted expected scores against each opponent, normalized deltas, tier-based RD caps, and time-based RD growth for inactivity.
05Operational surface built in
Liveness/readiness/metrics endpoints expose runtime counters, active rooms, Redis adapter state, and latency budgets for HTTP, scheduler lag, and socket emits. Release hygiene: gitleaks in CI, helmet + rate limiting, signed-release validation, multi-stage Docker.