mirror of
https://github.com/openfrontio/OpenFrontIO.git
synced 2026-07-16 21:11:52 +00:00
3a5fba2e12
## Description: Implements 2v2 ranked matchmaking end-to-end against the matchmaking API's 2v2 queues (API PR #419): core team pinning, the server's second checkin loop and game creation, and the client UI. ## Core — deterministic team pinning The matcher's assignment specifies exactly who plays with whom (`teams: [[a,d],[b,c]]`), but team assignment previously only did clan/friend balancing and could scramble the ELO-balanced split. - `PlayerSchema`/`PlayerInfo` gain an optional **`teamIndex`** — a server-stamped index into the game's team list, part of `GameStartInfo` so it's identical on every client (same category as `clanTag`/`friends`, which already feed deterministic team assignment). - `assignTeams` honors pins **unconditionally** — before clan/friend grouping and past `maxTeamSize` (the matcher's balancing is authoritative) — and seeds the counts that balancing of any unpinned players sees. Pinned players still participate in the friend graph, so an unpinned friend is pulled toward a pinned player's team. - publicIds never enter core: the game server resolves publicId → teamIndex per client at game start. ## Server - **One checkin long-poll per mode.** Both loops send `mode` explicitly (the API deployed ahead of the client, so no omit-for-back-compat needed). - **`get2v2Config()`**: Team mode, `playerTeams: 2`, `maxPlayers: 4`, always-compact map, donations enabled (matching public team games), `rankedType: "2v2"` (the API's 2v2 ingestion has shipped; `RankedType` gains `TwoVTwo`). - **The assignment payload is now used** (it was previously discarded): `players` → `allowedPublicIds` so only the matched accounts can take the slots (also hardens 1v1), and `teams` → `teamIndex` stamps at game start. A malformed assignment logs a warning and falls back to creating the game without pins rather than stranding matched players. - The 3-clients-per-IP cap on public games applies to matchmade games too (an allowlist doesn't stop one person multi-tabbing multiple accounts). It is now skipped in dev, where local testing (multi-tab, the 4-player e2e) is inherently same-IP — matching the existing dev/prod gating of Turnstile and the duplicate-account kick. ## Client - Ranked modal's 2v2 card is enabled; it passes the mode through `open-matchmaking` (dispatchers without a detail — homepage button, requeue URL — still mean 1v1). - Matchmaking modal joins with `&mode=1v1`/`&mode=2v2`, shows a 2v2 title (`matchmaking_modal.title_2v2` in en.json), and shows the real 2v2 ELO from the new `leaderboard.twoVtwo` field in `/users/@me` (the ranked modal's 2v2 card does too). - WinModal shows requeue for any ranked game and carries the mode back into the right queue (`/?requeue=2v2`). - 2v2 ranked stats surface in the player stats tree (labeled via `player_stats_tree.ranked_2v2`). ## Harnesses (`tests/matchmaking/`) - Contained: the fake server captures the `mode` query param; asserts each queue sends its mode explicitly. **10/10.** - E2E: `MM_MODE=2v2` runs four real browser players through the real local worker's 2v2 queue and rides the flow into the started game. Asserts same gameId for all four, the 2v2 config, allowlist admission, and a **deterministic 2 vs 2 in-game split read from each client's GameView** (the software-WebGL gate is spoofed in test pages only). **8/8.** 1v1 e2e still **6/6.** ## Verification - `npm test`: 2,053 tests pass, including 7 new (6 `assignTeams` pinning unit tests + a full-game pinned-split test through `setup()`). - `npx tsc --noEmit`, ESLint clean. - Live e2e against a local `wrangler dev` API worker: 1v1 (6/6) and 2v2 (8/8) as above. 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory (UI changes — the ranked modal's 1v1/2v2 cards — were verified with before/after screenshots in the live app during development.) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Matchmaking integration harnesses
Two harnesses for the matchmaking client integration (the matchmaking-modal
close-code/reconnect contract from the matchmaking API handoff). Neither runs
as part of npm test — they drive a real headless browser.
Contained — npm run test:matchmaking
Integration test against a fake matchmaking server (fakeServer.mjs, an
in-process ws server speaking the documented protocol). The browser's
WebSocket for /matchmaking/join is redirected to it, so real close-code
semantics apply. Covers:
| Scenario | Expected client behavior |
|---|---|
| join after connect | {type:"join", jwt} sent |
| abrupt drop (deploy/restart, 1006) | reconnect + rejoin (backoff) |
1008 Invalid session |
reconnect + rejoin, fresh token |
match-assignment |
gameId recorded, socket done |
1000 Replaced by newer connection |
message shown, no retry |
| intentional close (user backs out) | no retry, no message |
Prerequisite: npm run dev (app on :9000). No API worker needed.
E2E — npm run test:matchmaking:e2e
Real integration against the API worker on localhost:8787. Two browser
players join the real queue through the real modal; the dev game server's
/matchmaking/checkin long-poll receives the assignment and creates the
game; the test asserts all players get the same gameId, dispatch
join-lobby once the game exists, that the game carries the mode's config,
and that the allowedPublicIds allowlist admits every matched player.
Modes:
- default: 1v1 with two players
MM_MODE=2v2 npm run test:matchmaking:e2e: four players into the 2v2 queue; additionally rides the real flow into the started game and asserts the in-game team split is 2 vs 2 and identical on every client.
Prerequisites:
npm run dev(app + game server on :9000; the game server polls checkin on :8787 out of the box in dev)- the API worker running locally:
wrangler devin the API repo (port 8787)
On failure the harness dumps both players' browser consoles — close code
1008 means the worker rejected the play token; no assignment usually means
the worker rejected the game server's x-api-key checkin.