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

Tank classes / loadouts

Open
  • Is something wrong?
#115 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
typescript
Domain
full-stack, game-dev

Research direction

Start by reading server/src/types/bot.ts, server/src/types/app.ts, and services/AppService.ts to trace how bot stats are set and stored. Then follow the listed stat use through botTurret.ts, botRadar.ts, simulation.ts, arenaStatus.ts, and the UI mirrors, along with the API and MCP endpoints. Define class presets and update each layer consistently; done means the three loadouts have distinct stats that stay in sync in server simulation and UI, with per-class tests covering the new field and behavior.

Written by the indexing model from the issue text.

Description

enhancement priority: medium

Scout (fast, fragile), heavy (slow, armored), sniper (long range, slow reload) — tradeoffs that make team composition matter.

Effort: M

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

Implementation notes

Priority: medium — High fun/strategy value and touches core simulation, but it's an additive gameplay feature, not a stability/security fix or a blocking core-path gap.

Purpose

Today every Bot is identical (server/src/types/bot.ts: speedMax=5, speedAcceleration=2, health=100; botTurret.ts reload +=2/tick, hit damage -=25; botRadar.ts scan range 300). Letting a team pick a scout/heavy/sniper loadout per app gives players a real tactical lever (team composition, counter-picking) and is the kind of differentiation that makes multi-bot arenas more interesting to build for and watch.

Implementation approach
  • Add a TankClass concept (e.g. scout | heavy | sniper, maybe a default) — likely a new field on App (server/src/types/app.ts, services/AppService.ts, persisted column, hydrate) since a class is a property of the bot's code/build, not the arena membership.
  • Define per-class stat presets in one place (new small module, e.g. server/src/util/tankClasses.ts) covering speedMax, speedAcceleration, starting/max health, turret loaded increment (reload rate), bullet damage-per-hit, and radar scan range/cone — replace the hardcoded literals in bot.ts constructor, botTurret.ts (fire/reload), botRadar.ts (scan's distance < 300), and simulation.ts (bot.health -= 25 etc.) with lookups against the bot's class.
  • Bot constructor (server/src/types/bot.ts) must read the class off this.process/App and set instance fields accordingly instead of literal defaults.
  • arenaStatus.ts already forwards speedMax/speedAcceleration per bot — extend it to include health-cap/class so ui/src/util/arenaReducer.ts (currently hardcodes health: 100 at line ~167) and ui/src/util/simulate.ts stay correct mirrors; simulate.ts already reads accel/max generically so it should Just Work once the wire payload varies per bot.
  • No bot-facing compiler.ts API changes needed unless bots should introspect their own class (optional: expose via bot.getStats()/arena metadata).
Key details to plan
  • DB: adding a class/tankClass column to app — no migration framework yet (#142 tracks that gap); use an ALTER TABLE ... ADD COLUMN IF NOT EXISTS alongside the existing lazy CREATE TABLE IF NOT EXISTS pattern in AppService.ts.
  • REST/MCP: create_app/set_app_source-adjacent endpoints (api/app.ts, mcp.ts) need a way to set/read class; keep MCP tool caps in sync with REST per CLAUDE.md.
  • Determinism: class stats are static config, not randomized, so the seeded PRNG (util/random.ts) is unaffected — but rebalance any class-specific placement/spawn logic carefully if added later.
  • Testing: extend test/tankTypes.test.ts-equivalent (actual file covering Bot/BotTurret/BotRadar) and simulation.test.ts with per-class assertions (mock tanks with different classes); extend api.test.ts for the new field; arenaReducer.test.ts for non-100 health.
  • Depends on #142 (migrations) for a clean rollout; effort M as scoped, risk moderate — touches shared physics constants used by both server (simulation.ts) and UI (simulate.ts), so keep them in lockstep.
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.