feat(gamemode): introduce the gamemode registry and ENABLED_GAMEMODES - #815
Open
garrappachc wants to merge 1 commit into
Open
garrappachc wants to merge 1 commit into
garrappachc wants to merge 1 commit into
Conversation
Foundation for multi-gamemode: a closed `Gamemode` enum (6v6/9v9/ultiduo/bball), a registry keyed by it (`getQueueConfig`), and an `ENABLED_GAMEMODES` env list whose first entry is `defaultGamemode`. Adds the bball config (2 soldiers/team). Behavior-neutral. `ENABLED_GAMEMODES` falls back to the legacy `QUEUE_CONFIG` when unset, so existing single-gamemode deployments (and the e2e CI matrix that sets QUEUE_CONFIG) upgrade with no env change. The ~7 call sites that read the one gamemode now route through `defaultGamemode` instead of `environment.QUEUE_CONFIG`, emitting identical values, so no surface is yet multi-gamemode. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
This was referenced Aug 27, 2026
garrappachc
commented
Aug 27, 2026
| return [...new Set(parsed)] | ||
| } | ||
|
|
||
| export const enabledGamemodes: Gamemode[] = parseEnabledGamemodes() |
Member
Author
There was a problem hiding this comment.
drop the reduntant type annotation
| // @deprecated — use ENABLED_GAMEMODES. Kept as the fallback default when | ||
| // ENABLED_GAMEMODES is unset so existing single-gamemode deployments upgrade | ||
| // with no env change. | ||
| QUEUE_CONFIG: z.enum(['6v6', '9v9', 'ultiduo']).default('6v6'), |
Member
Author
There was a problem hiding this comment.
Add bball to this set, too
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #814 (base is that branch — review after it merges; will be rebased onto master). Second PR of the multi-gamemode (5.0.0) stack. Behavior-neutral foundation, no DB change.
Why
Today the instance's one gamemode is a single
QUEUE_CONFIGenv value resolved into a module-level singleton that ~20 sites read directly. Before any surface can serve several gamemodes, we need a first-classGamemodetype, a registry keyed by it, and a way to declare which gamemodes an instance runs — without changing behavior yet.What
Gamemodeenum (6v6/9v9/ultiduo/bball) + registrygetQueueConfig(gamemode).ENABLED_GAMEMODESenv (comma-separated) →enabledGamemodes/defaultGamemode(first entry). Falls back to the legacyQUEUE_CONFIGwhen unset, so existing single-gamemode deployments — and the e2e CI matrix that setsQUEUE_CONFIG— upgrade with no env change.QUEUE_CONFIGis kept and marked deprecated.api/v1/queue) now readdefaultGamemodeinstead ofenvironment.QUEUE_CONFIG, emitting identical values.No collection is gamemode-aware yet; that's the next PR (schema partition + backfill migration).
Verification
pnpm test→ 433 pass ·tsc→ no new errors · prettier + eslint clean.Note: the earlier
feat/multi-gamemodeprototype also had atestgamemode; intentionally omitted here (4 modes per the agreed design).