Arena

Last Horizon 1) Concept summary A minimalist space survival + exploration game where the player pilots a small craft between celestial bodies, managing fuel/energy, using gravity wells for slingshots, and surviving hazards. The experience is short-session, skill-based, and readable at a glance (clean UI, simple shapes, strong audio feedback). Design pillars Simple controls, deep mastery (thrust + gravity). Readable physics (predictable, consistent). Fast iteration (data-driven levels/parameters). Mobile-friendly (touch-first, low GPU cost). 2) Target platform & tech stack Platform: Web (desktop + mobile browser), optional PWA. Rendering: three.js with OrthographicCamera (2.5D look) or Perspective with a flat plane + billboards. Language: TypeScript. Build tooling: Vite + npm/pnpm. Audio: WebAudio API (or a small helper library). Persistence: LocalStorage (save progress, settings). Optional: postprocessing (bloom/vignette), particles. 3) Core gameplay loop Spawn near a body (planet/station). Player chooses a trajectory and burns fuel to adjust velocity. Gravity pulls craft; player uses slingshots. Land/dock to refuel/repair/upgrade. Travel to next objective (node/planet), avoid hazards. Repeat; difficulty increases; unlocks expand route options. Win/lose Lose: run out of fuel/health, hit hazard, drift beyond bounds (optional). Win: reach final node/goal or achieve score target in “endless” mode. 4) Player controls & feel Desktop Hold/drag to aim thrust vector (or WASD/arrow thrust). Click/tap interactions with nodes (dock/launch). Mobile One-finger drag to set thrust direction; hold to thrust. Optional two-button UI: “Thrust” + “Brake” for accessibility. Movement model (arcade-physics, deterministic) Player has position, velocity, fuel. Thrust applies acceleration while input is active: v += thrustDir * thrustPower * dt fuel -= fuelBurnRate * dt Gravity from bodies: a += dirToBody * (G * bodyMass / (r*r + softening)) Important: tune constants for fun, not realism. Use softening to avoid infinite acceleration. 5) World objects & interactions Celestial bodies (Planets/Moons) Gravity source. Landing zone radius: inside it, speed must be below threshold to “dock/land”. Provide fuel/repair; optionally upgrades. Stations/Checkpoints No gravity (or low), safe refuel and upgrade points. Acts as save checkpoint. Hazards Asteroids/debris (moving circle colliders). Mines (proximity trigger). Radiation zones (damage over time). Black hole (strong gravity + kill radius). Collectibles (optional) “Scrap” or “energy” pickups used for upgrades. 6) Progression & balance Difficulty curve Early: 1–2 bodies, light hazards. Mid: tighter windows, moving hazards, longer gaps. Late: multiple gravity wells and route planning. Upgrades (examples) Fuel tank size Thrust efficiency Hull/health Docking assist (bigger docking radius, velocity forgiveness) Map/trajectory preview (accessibility + mastery) 7) Camera, UI, and readability Camera Orthographic camera centered on player with smooth follow: camPos = lerp(camPos, playerPos, followSmooth) Zoom adjusts based on speed or proximity to bodies (clamped). Optional screen shake on impact. UI (recommended: HTML overlay) Fuel bar, health bar, current objective. Minimal icons, large touch targets. Pause/settings, restart. Visual style Clean silhouettes (circles, triangles), subtle glow, starfield background. Use a few strong colors for: player safe docks hazards objective 8) Physics & collision approach Update loop Use a fixed timestep for consistent physics: Accumulate real time from requestAnimationFrame. Step physics at fixedDt = 1/60 (or 1/90 on high refresh). Collisions Use 2D circle vs circle tests (even in Three.js): Player: radius rp Body/hazard: radius rb collision if distance(player, obj) < rp + rb Broadphase (performance) Spatial hash/grid for hazards in large scenes. Only check nearby objects. Docking / landing If within docking radius AND speed < dockingSpeedMax, trigger dock state. 9) Technical architecture (recommended) Scene structure (Three.js) Scene BackgroundLayer (stars, nebula) WorldLayer (bodies, hazards, pickups) PlayerLayer (ship + exhaust particles) EffectsLayer (post FX sprites) UI in DOM overlay. Game code pattern Use an Entity-Component approach (lightweight) or a clear OOP model. Core modules Game (boot, loop, state transitions) Renderer (three.js setup, resize, camera) World (level loading, spawn) Physics (integrator, gravity, collision) Input (mouse/touch + gamepad optional) UI (HUD, menus) Audio (SFX/music) Save (settings/progress) State machine Boot → MainMenu → Playing → Docked → Paused → GameOver Keep state transitions explicit and testable. 10) Data-driven level design Define levels as JSON so designers can tweak without code changes. Example schema: { "id": "level_03", "playerSpawn": { "x": 120, "y": -40, "vx": 0, "vy": 0, "fuel": 80 }, "bodies": [ { "id": "p1", "x": 0, "y": 0, "radius": 60, "mass": 9000, "dockRadius": 85 }, { "id": "p2", "x": 420, "y": 220, "radius": 45, "mass": 6000, "dockRadius": 65 } ], "hazards": [ { "type": "asteroid", "x": 210, "y": 60, "radius": 10, "vx": 25, "vy": -10 } ], "objective": { "type": "reachBody", "bodyId": "p2" } } 11) Rendering implementation notes (Three.js) 2D-in-3D approach (fastest) Use OrthographicCamera. Represent objects as: Sprite with a simple texture or Mesh (CircleGeometry) with MeshBasicMaterial Keep everything on z=0 and avoid heavy lighting. Particles (exhaust, impacts) Use instanced sprites or a small particle pool. Avoid per-frame allocations. Background Big quad with star texture. Parallax: move background slightly opposite camera. Postprocessing (optional) Subtle bloom + vignette for atmosphere (guard with a “low-power” toggle).