space-game/NEXT-STEPS.md

Next Steps

Economic Growth

The current economy already supports:

1. mining ore
2. hauling to refining
3. refining / fabricating goods
4. spending those goods on ships and outposts

The next step is not “invent a use for refined goods.” That use already exists.

The next step is to make faction growth more intentional and legible.

Recommended work:

• make shipbuilding priorities reactive
  • build more miners / haulers when ore throughput is low
  • build escorts when industrial losses rise
  • build warships when frontier pressure rises
• make expansion logic consume the economy more visibly
  • use industrial stock to claim and fortify central systems
• expose production pressure in UI
  • show ore throughput
  • show fabricated goods
  • show queued faction priorities

Pirate Harassment

Pirates already exist and can raid, fight, and destroy ships.

What they are missing is sharper industrial harassment behavior.

Recommended work:

• prioritize miners, haulers, and refinery approaches as pirate targets
• add local threat weighting around:
  • resource nodes
  • refinery docking lanes
  • undefended transport routes
• force empires to react by:
  • escorting miners
  • patrolling refinery systems
  • building defensive stations sooner

This will make the industrial loop produce strategic tension instead of just passive growth.

High-Value Gameplay Sequence

The most useful short-term gameplay loop to solidify is:

1. miners feed refining
2. refining feeds ship production
3. pirates harass industry
4. empires respond with escorts, patrols, and new outposts
5. stronger economies produce stronger military presence
6. system control shifts based on industrial strength and protection

That turns the simulation into a real strategy loop.

Concrete Implementation Order

1. Add faction production heuristics based on current economy and losses.
2. Make pirate target selection explicitly prefer economic targets.
3. Surface faction stocks, throughput, and build priorities in the HUD/debug views.
4. Expand the order/behavior set with higher-value RTS actions like hold-here, attack, and defend-area.
5. Break src/game/GameApp.ts into smaller planning / faction / combat / logistics modules.

Migration To .NET

If the long-term goal is multiplayer, scale, persistence, or server authority, a .NET migration is a sensible next architectural track.

Recommended direction:

• keep the current Vite / Three.js client for rendering and input
• move simulation authority into a .NET backend
• treat the browser client as a renderer + command UI

Suggested migration phases:

1. Define a shared simulation contract.

   • ship state snapshots
   • orders
   • behaviors
   • assignments
   • combat / economy events

2. Extract the pure simulation model from the Three.js runtime.

   • separate rendering state from simulation state
   • remove direct scene dependencies from game logic

3. Rebuild the simulation core in .NET.

   • Order
   • DefaultBehavior
   • Assignment
   • ControllerTask
   • faction economy
   • combat resolution

4. Add server-driven ticking.

   • authoritative world step on the server
   • deterministic or near-deterministic update model
   • event stream / snapshot replication to clients

5. Add persistence and multiplayer infrastructure.

   • saves
   • world seeds
   • reconnect support
   • eventually player ownership / fog / permissions

Suggested .NET stack:

• ASP.NET Core for API / realtime transport
• SignalR or custom websocket layer for simulation updates
• PostgreSQL for persistence
• background hosted service for world ticks

Suggested immediate prep before migration:

• isolate simulation data structures from rendering objects
• isolate faction AI from UI code
• isolate travel / docking / mining / combat systems into separate modules
• make event emission explicit and serializable

The key rule for the migration is:

• do not port Three.js-shaped code into .NET
• first separate the simulation from rendering in TypeScript
• then move the pure simulation into .NET cleanly