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

Arena hazards & terrain

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
javascript, typescript
Domain
game-dev

Research direction

Start with server/src/util/simulation.ts and the terrain generation and rendering files ui/src/util/terraformer.tsx and ui/src/components/arena/arenaTerrain.tsx. Trace how Environment.random() and buildArenaStatus carry seeded arena state to the UI, then compare server movement with ui/src/util/simulate.ts. Done means terrain affects movement, bullets and damage consistently on both sides, with the layout reproducible from a fixed seed and tests covering collisions and determinism.

Written by the indexing model from the issue text.

Description

enhancement priority: medium

Walls/obstacles that block movement and line-of-fire, damage zones, or speed-altering terrain (the renderer already draws terrain tiles). Adds spatial strategy.

Effort: M

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

Implementation notes

Priority: medium — Adds valuable tactical depth and touches core simulation/determinism code, but it's a new gameplay feature, not fixing a stability/security/core-UX gap for existing users.

Purpose

Turns today's purely decorative terrain (ui/src/util/terraformer.tsx, ui/src/components/arena/arenaTerrain.tsx) into a gameplay-affecting layer — walls that block movement/fire, damage zones, and speed-altering ground — adding tactical depth (cover, chokepoints, hazards) that many bot authors will want to design around.

Implementation approach
  • Terrain must become server-authoritative: today generateTerrain() runs client-side with plain Math.random() on mount, fully decoupled from the server's seeded PRNG (server/src/util/random.ts mulberry32, Environment.random()/setSeed) — this breaks the "seed reproduces a match" guarantee (set_arena_seed, speedDeterminism.test.ts) unless hazard layout is generated server-side (e.g. in Environment/Arena, server/src/types/arena.ts, server/src/types/environment.ts) from env.random() at arena creation/restart and shipped to the client instead of regenerated locally.
  • Add a hazard/tile grid to Arena (or a new types/terrain.ts), included in util/arenaStatus.ts (buildArenaStatus) so the UI and MCP arena_status see the same layout; arenaTerrain.tsx/arena.tsx render from that data instead of calling generateTerrain() locally.
  • Physics changes belong in server/src/util/simulation.ts alongside the existing boundary check (newX < 16 || ... env.getArena().getWidth() - 16, ~line 184) and bullet-hit loop (~line 130): add hazard collision (block movement, emit Event.COLLIDED), speed multiplier application, and periodic damage while occupying a zone; bullets need a blocked-by-wall check before the existing hit-distance test.
  • ui/src/util/simulate.ts must mirror the same movement/collision math (it currently has no boundary/hazard clamp at all) to keep client interpolation consistent with the server tick, per CLAUDE.md's explicit warning.
Key details to plan
  • No bot-facing compiler.ts API changes are strictly required for MVP (hazards are environmental), but consider exposing hazard awareness via radar.scan()/events later.
  • New/changed SSE events need ui/src/util/arenaReducer.ts handling (e.g. a terrainHit/hazardDamage event or reusing botDamaged/botStop), tested like arenaReducer.test.ts.
  • Determinism: hazard placement must derive from env.random(), not Math.random(), and regenerate identically on restart()/fixed seed — extend simulation.test.ts/simulationIntegration.test.ts (wall/hazard collision cases similar to the existing "fires COLLIDED when a bot drives into a wall" test) and speedDeterminism.test.ts.
  • No migrations system exists yet (#142); if layout is persisted (vs. regenerated per run), keep it in the in-memory Environment/lazy CREATE TABLE IF NOT EXISTS pattern, not a real migration.
  • Depends conceptually on any future arena-customization/editor issue; effort M is reasonable but risk is medium-high given the client/server terrain desync that must be fixed first.
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.