It feels like FD took the fixed Point of Interest code from early PB (for combat zones and Resource Extraction Sites) and harnessed it up to a random encounter table with some entries dependent on system state and player mission state. This is correct, but the current implementation just splats dynamic USS PoIs 10 travel-seconds somewhere in front of the player whilst in supercruise.
This gives rise to some rather game-y behaviour that doesn't match the believability of the rest of the environment:
Analysis of current USS implementation:
Recommendations to improve USSen
This gives rise to some rather game-y behaviour that doesn't match the believability of the rest of the environment:
Analysis of current USS implementation:
- USS are either there, and visible, or they are not. There is no in-game rationale or mechanism for detecting them.
- USS are unique to each player and not replicated. There can be no competition between players to reach a USS first.
- USS spawn in a predictable location
- USS are no longer there after dropping and reentering supercruise.
- USS do not expire unless you leave their vicinity
- There's a timer that waits until you have been in SC for a while before the first USS spawns, then more USSen are generated periodically. Because of SC deceleration rates, braking to visit the first USS takes a constant 45s or so from whatever velocity, so the second and subsequent USSen appear 10 travel-seconds away, i.e. close to the first one. This clustering triggers our brains' pattern recognition, and we try to make sense of it where there is no in-game reason to find. Evidence for this are forum posts where players suggest that "to complete a mission you have to go to the second USS that appears close to the first one".
- Missions' destination systems that spawn USSen don't respect the system type. An example: on a 'Kill Pirate' mission in a zero population anarchy with no planets, you can be thousands of Ls away from a star and a USS will spawn with two pirates attacking a trader. No reason is given in the ship chatter for the trader being there. The only believable reason for a trader to be in such a system is to scoop fuel at a star, if the system is on a trade route. Otherwise, we need another reason for the trader/pirates to be there - a hidden starport or cache of pirate booty.
Recommendations to improve USSen
- Be present on the scanner like other SC objects. Now that the SC scanner shows heavenly bodies, it should show USSen in some more or less definite form depending on size, distance and ship sensors. Iain M Banks' readers will be familiar with ships detecting expanding shells of electromagnetic radiation that could turn out to come from a battle, a wreck, or an unfortunate floating in a suit. USS should be initially visible as large but weak emission blobs, then as unresolved blips and then as hard contacts that can be locked on to. SC space should be noisy on the scanner; stars and hotter planets will belch emissions that fade out when approached instead of resolving into points of interest.
- The same USS should be visible (subject to the above) to all players in SC in a system and change state as players affect them. Just like NPC ships. Supercruising NPCs should interact with USS too.
- Spawn all over the system
- Fade/expire after some timeout to reward skilfully SC piloting to a faint USS before it fades
- Still be present (subject to above timeout) upon dropping and reentering SC.
- Only spawn where their content has a reason to be, and the mission generator should not site missions in systems where the mission object would not be found.
- A nice touch added recently is the NPC departing the USS scene of the crime. These NPCs should form part of the encounter. If we can find out the nature of the USS before entering it (spectral analysis of the emission signature) then player can decide whether to eg pursue a pirate or rescue a Remlok'ed victim, or look for goods to scavenge or chase a smuggler. For assassination missions, the target might actually be the ship fleeing the USS.
