201 lines
6.0 KiB
Markdown
201 lines
6.0 KiB
Markdown
# Next Steps
|
|
|
|
## Galaxy / Viewer Fit
|
|
|
|
The world is now much larger and more varied:
|
|
|
|
- roughly galaxy-scale system counts
|
|
- elevated system height variance
|
|
- procedural orbital metadata
|
|
- moons, rings, binary stars, asteroid belts, gas clouds
|
|
- special-case `Sol` system content
|
|
|
|
The next step is not “make the map larger.” That is already done for the current runtime.
|
|
|
|
Recommended work:
|
|
|
|
- tune galaxy readability at scale
|
|
- better starfield depth cues
|
|
- stronger color/size differentiation for star classes
|
|
- improved system label decluttering
|
|
- add galaxy navigation affordances
|
|
- jump-to-system search
|
|
- constellation / region overlays
|
|
- bookmarks for notable systems such as `Sol`
|
|
- tighten viewer performance
|
|
- reduce orbit/moon draw cost when zoomed out
|
|
- pool or simplify distant celestial meshes
|
|
- profile high-system-count scenes
|
|
|
|
## 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
|
|
- make resource type differences matter
|
|
- ore belts vs gas clouds
|
|
- gas-aware logistics and production choices
|
|
|
|
## 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 viewer-scale performance controls for the larger galaxy.
|
|
2. Add faction production heuristics based on current economy and losses.
|
|
3. Make pirate target selection explicitly prefer economic targets.
|
|
4. Surface faction stocks, throughput, and build priorities in the HUD/debug views.
|
|
5. Expand the order/behavior set with higher-value RTS actions like `hold-here`, `attack`, and `defend-area`.
|
|
6. 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 per-layer presentation tuning in the viewer
|
|
- smoother fade bands between local / system / universe
|
|
- better visual density control at galaxy scale
|
|
- moon/orbit LOD based on zoom level
|
|
- add resync handling when a client falls too far behind
|
|
- consider switching from SSE to websocket transport if bidirectional command traffic becomes heavy
|
|
|
|
## Celestial Depth
|
|
|
|
The current celestial layer is procedurally rich, but still mostly decorative outside of resource nodes.
|
|
|
|
Recommended work:
|
|
|
|
- add authored moon metadata when needed
|
|
- labels
|
|
- resource-bearing moons
|
|
- special landmarks
|
|
- support multiple belts / cloud bands per system explicitly
|
|
- add stellar gameplay hooks
|
|
- hazardous neutron-star systems
|
|
- high-value binary systems
|
|
- rich-gas outer systems
|
|
- expose notable-system summaries in the viewer
|
|
- star class
|
|
- resource profile
|
|
- moon count
|