I do doubt very much that many games deal with rules like this, but it is kind of a fun problem, and since I missed out on the "always have some prostitutes ready" thread, I have to fill in where I can. So to speak.  

I think I have a "deploy ready" guidance system. I won't try to use it in game yet, but the next game won't be for nearly a year so there's plenty of time to continue to test and refine. 

The sensor system on the missile has magic knowledge of the true position and velocity of its target, something a real missile would not have. It might be worthwhile trying to simulate a semi-active radar system (radar from the ground station with the seeker head in the missile tracking the reflection of that), and provide the guidance algorithm no more than the inputs from that and leave it to itself to attempt to determine position and velocity - we do actually do something like that for space combat (though we presume optical tracking). But that aside, the problem I was having is something akin to the problem Kepler once had, and I solve it through iteration: the guidance system transforms the target's position and velocity vectors into its own reference frame, computes the vector that would be needed to intercept the target given the initial time to intercept and then iterates several times, recomputing a new intercept time and thus a new vector on each iteration. 4 iterations are enough, but realistically it should continue to iterate until the change between iterations is within some error bars. 



I've tried several target initial conditions from low velocity to high velocity to diving and level flight and climbing, here's one of them: 

https://i.imgur.com/7FJYB1f.gifv

Once again, time is real time, 1 sec = 1 sec. Scale in meters. Circle represents the guidance estimate of where the intercept will be, which is constantly changing because the target is accelerating. A slightly smarter guidance system would sample the acceleration of the target as well - or rather relative acceleration, but because acceleration is also constantly changing as air friction changes (that is to say, jerk (or the third derivative of position over time) is non-zero) I don't know that it would help all that much, and the guidance solution is recomputed on each iteration of the ODE solver anyway - as long as the target is within the performance envelope of the missile I think an intercept is fairly likely. More testing is needed and I have to transition the model into the larger scale model that we use for space combat and solar system simulations. 

The lesson here though is that a single guidance solution iteration is not enough, which is probably obvious to the CS and math people in the crowd. And this is one of the values of traveller in simulation mode, when you have your 15-16 year old players design the guidance systems of the missile systems, they learn this kind of thing. It might be something they theoretically knew from school, but this gives it a better hands-on feel and allows them to internalize the knowledge a bit more. I think, anyway.

The problem with that is that even a TL6 civilization would actually be able to put out both better guidance systems and better avoidance systems than any single player or referee is likely to be able to write, so just rolling dice based on probabilities may actually be more realistic. But dice won't produce charts and graphs! 

It's also interesting to know that I think that TL6 weapons are about the minimum necessary to have a chance at hitting a free trader that doesn't want to be hit. I'm not sure what a TL5 civilization would do about a starship, except perhaps a lucky shot with artillery when the ship is at low altitude. 

At any rate, covert action teams inserting on TL6 and higher worlds should not use direct insertion, they should set down away from Theatre air and missile defense coverage and hike in to the target area overland.