# 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 backend simulation responsibilities into smaller planning / faction / combat / logistics modules.

## Network / Multiplayer

The repository now has a split architecture:

- [apps/backend](/home/jbourdon/repos/space-game/apps/backend)
  - authoritative .NET simulation
- [apps/viewer](/home/jbourdon/repos/space-game/apps/viewer)
  - rendering and observer UI
- `GET /api/world`
  - initial snapshot
- `GET /api/world/stream`
  - incremental SSE delta stream

The next networking step is not “move the simulation into .NET.” That is already done for the active runtime.

The next steps are about scaling the transport and authority model cleanly.

Recommended work:

- add client-to-server command submission
  - direct orders
  - automation changes
  - selection / observer commands only where useful
- add persistence
  - saves
  - world seeds
  - reconnect support
- add player ownership / permissions
  - command authority
  - eventually fog of war / restricted information
- harden replication contracts
  - explicit entity lifecycle events
  - versioning
  - reconnect / catch-up semantics

## Interest Management

The current stream is world-wide.

That means every observer receives deltas for the full simulation, even when only looking at one part of space.

Recommended work:

- add observer/view-scoped subscriptions
  - visible systems
  - nearby ships / stations / nodes
  - faction-scoped or player-scoped channels later
- support subscribe / unsubscribe as camera focus changes
- send only relevant deltas per observer
- keep coarse strategic updates available for off-screen context
  - system ownership
  - major combat
  - economy summaries

This is the key step that makes many simultaneous observers practical without broadcasting the entire world to everyone.

## Replication Quality

The backend already sends:

- initial snapshot
- incremental deltas
- event records

Recommended work:

- add stronger event typing
  - spawn
  - destroy
  - dock
  - undock
  - cargo transfer
  - combat hit / kill
- improve interpolation and extrapolation policies per entity type
- add resync handling when a client falls too far behind
- consider switching from SSE to websocket transport if bidirectional command traffic becomes heavy