Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Game modes beyond deathmatch

Open
  • Is something wrong?
#112 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
javascript, typescript
Domain
game-dev

Research direction

Start by reading server/src/util/matchSummary.ts and server/src/types/environment.ts to trace the current win condition, then review server/src/types/arena.ts and the simulation tests named in the issue. The issue outlines several modes with different requirements; choose one mode and check its dependencies before estimating the work. Done means that mode’s scoring and state are exposed through the server and UI, with the relevant tests passing.

Written by the indexing model from the issue text.

Description

enhancement priority: medium

Last-team-standing (current), king-of-the-hill (hold a zone), capture-the-flag, target-practice/time-trial, survival-vs-waves. Modes give different strategies a reason to exist.

Effort: M each

Migrated from ENHANCEMENTS.md (§2 Gameplay & fun).

Implementation notes

Priority: medium — Meaningful content/engagement value and touches core shared logic (win-condition, matchSummary), but it's new optional content rather than a fix to core-path stability or correctness — existing deathmatch mode is unaffected until adopted.

Purpose

Every arena today is hard-wired to one win condition — last-app-standing, decided by deriveMatch in server/src/util/matchSummary.ts and the "all apps dead" check in Environment.tick (server/src/types/environment.ts). Additional modes (king-of-the-hill, capture-the-flag, target-practice/time-trial, survival-vs-waves) give bot authors new tactical problems to write against and make the arena replayable beyond raw combat, directly extending the game's core content loop.

Implementation approach
  • Add a gameMode concept to Arena (server/src/types/arena.ts, currently just id/userId/width/height) and thread it through ArenaService.ts — persisted per arena, so schema changes here should ride with the pending migrations work (#142) rather than another ad hoc ALTER TABLE.
  • Extract the win-condition/scoring logic that's currently inlined in Environment.tick (the appHealth/running=false block) and in matchSummary.ts's deriveMatch/compareForRank into a mode-strategy layer so Simulation.run stays mode-agnostic; each mode supplies its own scoring inputs (e.g. zone-hold ticks, flag captures, wave number) alongside the existing health/eliminatedAt fields.
  • Zone/flag modes need new arena objects with position + ownership state, tracked in Environment and surfaced via buildArenaStatus (util/arenaStatus.ts) and buildMatchSummary/buildMatchStatus (util/matchSummary.ts) so the SSE stream and MCP tools expose them.
  • New bot-facing API surface belongs in compiler.ts's existing arena.* pattern (next to arena.createMarker, _arena_getWidth/_arena_getHeight) — e.g. arena.getZone()/flag position queries — following the established native-_bot_*-function-plus-thin-JS-wrapper bridge; must stay read-only/no new attack surface for the isolate.
  • Survival-vs-waves needs a spawner concept (NPC/AI targets) distinct from Process/Bot teams — likely a lightweight non-isolate entity type in simulation.ts, since spinning up real isolates per wave enemy would blow the per-arena isolate budget.
  • Server + UI must move together: any new physics (zone capture radius, flag pickup/drop, wave spawn movement) added to simulation.ts needs a matching mirror in ui/src/util/simulate.ts; new event types (zoneCaptured, flagPickedUp, etc.) need ui/src/util/arenaReducer.ts cases and ui/src/App.tsx rendering (SVG for zones/flags).
Key details to plan
  • REST/MCP: api/arena.ts needs a mode-select route (arena creation/config), and match_summary/arena_status MCP tool schemas (api/mcp.ts) must document mode-specific fields for AI callers.
  • Determinism: zone/flag/wave placement must derive from the seeded env.random() (mulberry32, util/random.ts), matching the existing computeSpawns pattern, so setSeed/set_arena_seed still reproduces a match.
  • Testing: extend simulation.test.ts (mock-tank mode-logic cases per mode), simulationIntegration.test.ts for a full isolate+sim smoke test of one new mode, api.test.ts for the new config route, and arenaReducer.test.ts for new event types.
  • Depends on #142 (DB migrations) if gameMode/mode-config becomes persisted arena state; each mode is independently shippable (M effort each), king-of-the-hill/target-practice are lowest-risk (no new team semantics), capture-the-flag and survival-vs-waves are higher-risk (new entity types, cross-team object state).
  • Risk: touching Environment.tick's win-condition and matchSummary.ts's ranking is shared, well-tested core logic — regressions there affect every existing deathmatch arena, so the mode-strategy extraction should preserve deathmatch as the default/no-op path with focused new tests before adding others.
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
8m
Merged PRs (30d)
8

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LeeAdcock/robocodeJs.com

All issues in LeeAdcock/robocodeJs.com

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.