146 lines
4.3 KiB
Markdown
146 lines
4.3 KiB
Markdown
# 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
|