WARPATH: NEON FRONTIER — Roblox Feasibility Study

Question: could the remake be built on Roblox instead of the web/PixiJS stack? Short answer: yes — and it would be more faithful to 1997's multiplayer chat-room soul — but it is a different product with different economics, a different audience, and zero code shared with the web plan. This doc specifies that product so both paths are on paper.

1. What changes at product level

Design pillars survive unchanged. The one that gets stronger is the original's social identity: humans + bots on both sides, radio chatter, betrayal — that's native Roblox culture.

2. Architecture on Roblox

2.1 Topology

• One Roblox server = one galaxy = one match. 8 captain slots (humans join/leave; bots hold or take over abandoned slots — the 1997 "join = spectate" flaw becomes drop-in bot-takeover for free).
• Server-authoritative everything: galaxy sim, economy, combat resolution. Clients send intents (thrust vector, fire, dock, invest), receive replicated state. Never trust the client with credits or allegiance.
• Matchmaking: default public servers via Roblox discovery; private servers for friends-only galaxies (free or Robux-priced — our call); reserved servers (TeleportService:ReserveServer) for future ranked/daily modes.

2.2 Server sim (Luau)

• Port of the deterministic sim design from doc 04, relaxed: determinism matters less because the server is the single authority — no lockstep needed. Keep seeded galaxy-gen (daily seed = same layout across servers) but let combat run on ordinary server time.
• Galaxy tick at 10 Hz (planets, empires, AI captains, events) on Heartbeat accumulator; combat/projectiles at frame rate server-side with client-side visual smoothing.
• Modules: GalaxyGen (seeded sector graph + biome templates), EconomySim (population, tek, allegiance, dividends), EmpireAI + CaptainAI (bots use the same intent API as players — one code path), CombatResolver, EventDirector, RecapBuilder.
• Physics: do not use Roblox physics for ships. Kinematic movement integrated in scripts (CFrame updates), simple sphere/ray hit tests. Roblox physics adds jitter, exploitable mass-pushing, and network ownership headaches; a top-down arcade game needs none of it.
• Set projectile/ship network ownership to server; client renders predicted local ship movement for feel, server reconciles (standard Roblox action-game pattern).

2.3 Client

• Camera: scriptable camera locked top-down (CameraType.Scriptable, CFrame above ship, slight zoom/lead juice per doc 03). World is 3D low-poly ships/planets on a flat plane — reads as 2D, lights beautifully.
• HUD in Roblox UI (ScreenGuis): the doc 03 design system ports well — chamfered frames via 9-slice images, mono text via Roblox's monospace-ish fonts (or custom font upload), tabular layout by hand. The Radio = custom scrolling frame fed by server events plus native TextChatService channels for actual player chat (moderation compliance for free).
• VFX: Beams/Trails/ParticleEmitters + Bloom/ColorCorrection post-effects cover the neon grammar (trails, shield ripples, explosion flash-ring-debris). Neon material on emissives is literally called Neon — the art direction was made for this.
• Input: Roblox handles KB+M, touch (ContextActionService + custom floating stick per doc 02 §controls), and gamepad natively — the one-thumb auto-fire mode ports as designed.

2.4 Persistence & services

2.5 Tooling

• Rojo + Git for real source control (the docs repo pattern continues; Roblox Studio alone is not acceptable for a project this size).
• roblox-ts is optional: it lets us keep TypeScript habits, but adds a toolchain layer and community friction. Recommendation: plain Luau with strict typing (--!strict) + Rojo; the sim design transfers as architecture, not code, either way.
• Testing: TestEZ (or Jest-Lua) unit tests on the sim modules headless in CI via Lune/run-in-Roblox.

3. GDD deltas (what to edit in doc 02 if we go this way)

1. §Core loop: macro loop unchanged; add "server lifecycle": galaxy ends → recap for all → 60 s hangar lobby → same server reseeds. Mid-match joiners take over a bot captain.
2. §Monetization: replace entirely — F2P, cosmetics-only game passes, optional desktop Paid Access supporter tier; keep the no-pay-for-power / no-consumables / no-FOMO clauses verbatim.
3. §Progression: Insight economy unchanged, but rebalance recap payouts for shorter sessions; add first-session onboarding inside a live match (spectate-free: you spawn as a protected Pathfinder in the safe pocket with radio-guided objectives).
4. §Controls: unchanged (Roblox covers all three input classes).
5. §Campaign: demote to post-launch; multiplayer skirmish + daily seed are the launch product. Solo = private server with bots (works day one).
6. §Roadmap: Phase 0 (4 wk) one-sector combat+dock feel with 2 players; Phase 1 (8 wk) full Small galaxy, 8 slots, bots, recap; Phase 2 (6 wk) meta-progression, daily seed, cosmetics; Phase 3+ events, campaign, console polish.
7. §Risks: add platform risks below.

4. Roblox-specific risks

5. Recommendation

Both paths are honest products:

• Choose Roblox if the primary goal is people playing multiplayer Warpath soon, free, with zero infrastructure — accept F2P cosmetics economics and platform dependence. Launch order flips to multiplayer-first, which is arguably truer to 1997.
• Choose the web/PixiJS plan (docs 02/04) if the primary goal is owning a premium indie game with Steam/App Store identity and the no-IAP promise intact.
• Hybrid sequencing is viable because the design layer is engine-agnostic: prototype the conquest loop on Roblox as a live playtest (fast feedback, real multiplayer), then build the owned premium version on the web stack once the loop is proven — at the cost of two implementations.

Decision owner: you. The docs are written so no path is foreclosed.