131 lines
4.0 KiB
Markdown
131 lines
4.0 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 [src/game/GameApp.ts](/home/jbourdon/repos/space-game/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
|