Boundless Vector Arena

Boundless Vector Arena is PixelBullet's first real game product. All five Phase 0 foundation slices and Phases 1 through 4 are complete. Gate C passed for campaign structure and systems viability, including deterministic ordinary waves, perks, drafts, checkpoints, replay, UI integration, differentiated builds, and bounded execution/storage. That decision is not final balance, visual clarity, campaign intensity, boss viability, or release acceptance. The no-argument executable now loads the runtime-authored campaign and opens its startup gate; --single-encounter explicitly selects the unchanged Phase 3 sandbox. --campaign-showcase is a compatibility alias for the same authored campaign, which stops after position 29 at AwaitingPhase5.

The game design document is the normative product and design baseline. Implementation status distinguishes that target from implemented capability and remaining work. The content and asset policy defines product ownership, authoring, provenance, runtime closure, and packaging boundaries.

Product Boundary

Arena is not a replacement fixed-scene wrapper. Repository ownership lives under products/boundless_vector_arena. The public //products/boundless_vector_arena:boundless-vector-arena executable is a genuine product composition root over product-owned arena_core, session_execution, application lifecycle, input and presentation adapters, and explicit narrow HUD and sprite-render support closures. It does not hardcode an authored scene, instantiate ScenePlayLayer, depend on tools/scene_runner, or package the broad shared depot.

BulletSketch Play in Viewport and Run Standalone remain authored-scene workflows, and tools/scene_runner remains their generic standalone companion. They do not run complete Arena sessions. Product assets remain editable with BulletSketch's selected Arena asset base; a future Run Product integration remains optional and deferred.

Current Phase

Phase 0 establishes deterministic session lifecycle, exact 60 Hz headless execution, replay/checksum observability, the interactive composition root, and the minimal status HUD. Phase 1 completes chunk/local logical movement and aim, exact-centered camera/player presentation, origin rebasing with stable world presentation, deterministic dash, supported resize/aspect behavior, and presentation-only camera shake.

Phase 2 completes bounded primary/scatter fire and projectiles, interactive fire/projectile presentation, deterministic broadphase and swept collision, canonical hit/damage/health/death authority, restrained neutral-target and impact/death presentation, minimal player health/armor plus health/armor pickups, and replayable combat-transient cleanup. These systems remain product-owned, checksum/replay covered, and interactive/headless equivalent.

Phase 3 adds bounded Runner, Shooter, Charger, Kamikaze, Splitter, mini-splitter, and Tank roles. Each configured role reuses an existing damageable target for identity, position, collision, health, player-projectile damage, and death. Runner owns pursuit and contact cooldown; Shooter owns preferred-distance approach/retreat/strafe, fixed telegraph and cadence state, and an aim snapshot. Charger owns an approach/acquire/telegraph/commit/recover sequence with one sampled direction; Kamikaze owns direct pursuit, a pulse phase, and one terminal resolution. Splitter owns direct pursuit, active/armed and descendant-resolution state, plus a bounded request that atomically commits two stable mini-splitter target mappings after canonical parent death. Mini-splitters own only pursuit, active state, and parent attribution; they cannot split and ordinary overlap is currently non-damaging. Tank owns slow bounded pursuit and one per-source contact cooldown while canonical target authority still owns its 0.375 WU radius, eight-health baseline, projectile damage, alive state, and death. Hostile projectiles occupy a separate bounded partition of the existing projectile authority and use swept player-circle collision, armor-first damage, dash-invulnerability rejection, stable source attribution, and exactly-once player death. Charger committed contact and Kamikaze terminal contact are also swept and use the canonical armor-first player-damage path. Configured top-level roles now belong to exactly one encounter token, remain inert and hidden before stable pack admission, then become active and armed at their existing configured positions. Neutral dummies remain outside encounter accounting. Mini-splitters exist only as reserved descendants inheriting their parent Splitter token. Canonical death—including Kamikaze self-resolution—is the only defeat source; target removal and purge do not award progress. Descendant creation remains capacity-reserved, deterministic, and atomic.

All seven ordinary roles participate in one bounded product-owned local avoidance pass backed by the existing uniform spatial broadphase. Stable target-ID query order, bounded candidate/result storage, fixed-point accumulation, and a deterministic anti-symmetric fallback for coincident positions reduce stacking without adding navigation or formation logic. Runner and Splitter use moderate separation, Shooter retains its distance-band intent, mini-splitter is light, and Tank is the strongest anchor. Kamikaze uses zero separation to preserve urgency. Charger accepts avoidance during approach and recovery only; telegraph and committed direction remain unchanged.

The representative encounter uses deterministic off-screen placement, visible arming, sector heat, relevance, catch-up, recycling, stable identity, and the existing legitimate-completion predicate. An actively engaging deterministic reference resolves at tick 4546 (75.77 seconds); optimized interactive replay acceptance resolved two runs at ticks 6617 (110.28 seconds) and 6555 (109.25 seconds). R reconstructs the same encounter in the current window. No next encounter starts automatically.

There is still no gameplay ECS. Gamepad input, debug rebase controls, final release balance, rewards, bosses, audio, playable positions 30/31, display/power policy, packaging, and release hardening remain later work. Phase 5 begins with the lockfield, boss scheduling, and Core; none of that boss authority has started.

The repository surface taxonomy remains authoritative in Applications, Tools, Examples, Labs, and Products.