Skip to content

feat(gamemode): make skill and whitelist config per gamemode - #823

Open
garrappachc wants to merge 1 commit into
feat/gamemode-e2efrom
feat/gamemode-config
Open

garrappachc wants to merge 1 commit into
feat/gamemode-e2efrom
feat/gamemode-config

Conversation

@garrappachc

Copy link
Copy Markdown
Member

Part of the multi-gamemode (5.0.0) stack. Base: #822.

Why

Three config keys are inherently gamemode-specific — a 6v6 and a 9v9 queue want their own skill threshold, default skill and whitelist. Until now configuration.get(key) was global.

What

  • Per-gamemode config storagegames.whitelist_id, queue.player_skill_threshold, games.default_player_skill now hold an independent value per gamemode (no shared base — each falls back to the schema default). Stored under the bare key for the default gamemode (existing data + single-gamemode instances unchanged) and key#gamemode for the rest; all other keys stay global. configuration.get(key, gamemode?) resolves the storage key (configuration/gamemode-scoped-keys.ts).
  • Runtime reads pass the gamemode in scope — queue join skill check → the slot's gamemode; game creation + rcon configure → the game's gamemode.
  • Deferred routing bits from feat(gamemode): route queue pages per gamemode #821 finished — the "Clear queue" button and DELETE /queue/players act on the viewed gamemode (?gamemode), and GET /api/v1/queue accepts ?gamemode (default = instance default, so backward-compatible).

Scope

  • Admin editing stays on the default gamemode for now — a dedicated per-gamemode admin-editing PR follows (per the agreed split). Behaviour-neutral for single-gamemode instances.

Verified: net-new tsc = 0, unit suite green without .env (438, +2 new scoped-key tests), lint clean.

Make the three gamemode-specific configuration keys — games.whitelist_id,
queue.player_skill_threshold, games.default_player_skill — hold an independent
value per gamemode, so a multi-gamemode instance can gate each queue and
configure each game server on its own settings. A scoped key is stored under
its bare name for the default gamemode (existing data and single-gamemode
instances are untouched) and namespaced as `key#gamemode` for the rest; every
other key stays global. `configuration.get(key, gamemode?)` resolves it.

Runtime reads now pass the gamemode in scope: the queue join skill check uses
the slot's gamemode, game creation and rcon configure use the game's. Admin
pages still edit the default gamemode's value — per-gamemode editing is a
follow-up.

Also finishes the routing bits deferred from the queue-pages PR: the "Clear
queue" button and `DELETE /queue/players` act on the viewed gamemode, and
`GET /api/v1/queue` accepts `?gamemode` (defaulting to the instance default).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

Playwright test results

passed  251 passed
flaky  1 flaky

Details

stats  252 tests across 48 suites
duration  12 minutes, 21 seconds
commit  1b236f2

Flaky tests

chromium › 20-game/01-configure-game-server.spec.ts › configure game server @6v6 @9v9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant