Author Topic: A Dilemma on Interception Mechanics  (Read 4270 times)

0 Members and 1 Guest are viewing this topic.

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • S
  • Posts: 7122
  • Thanked: 2040 times
    • http://www.starfireassistant.com
A Dilemma on Interception Mechanics
« on: December 09, 2011, 03:28:48 PM »
I have just encountered a problem that I should have foreseen and I am interested in opinions on how I should resolve it.

In Newtonian Aurora, one of the whole points of the game is the inability for fast moving objects to easily change course. This means that missile guidance needs to be based on intercepting the future position of an object rather than simply moving toward its current position, as in Standard Aurora. So take the example of a missile trying to intercept a ship. Based on a combination of the contact information (which provides the current location of the target, its current speed, its current heading and its current acceleration rate) and the missile's own location, speed, heading and acceleration rate, the missile guidance code works out where the two objects will intercept, assuming constant acceleration. The missile then expends delta-V over time to make the necessary course change, adjusting as it goes. As the target changes speed, heading and acceleration, the missile calculates a new interception point and corrects its course (also taking into account that vs other missiles the other missile may not have moved yet in the current sub-pulse). This is tricky :) but it is working. Now the problem:

The underlying mechanics of Aurora are

a) Advance time by an increment from 5 seconds to 30 days
b) Move objects several times during an increment (using anything from 1 to 60 sub-pulses)
c) Within those sub-pulses, objects are moved one at a time using a initiative system, with all missiles moving after ships.
c) Resolve any interceptions, etc.

This is easy in Standard Aurora because objects can change direction and speed at any time. The problem for Newtonian Aurora is that although the missile guidance code puts the missile on the correct course, unless the position of the missile and the ship happen to coincide at the end of a sub-pulse, the ship moves first and then the missile moves through the path of the ship and passes behind it. This is because the missile is expecting to find the ship at the point in its path where the courses intercept but of course that point could be 2.47 seconds into the increment, rather than 5 seconds. Not a problem in Standard Aurora because the missile would just change course but in Newtonian Aurora the course change is not even close to possible. If both objects were moving simultaneously, or with really tiny sub-pulses, the missile would hit. So without changing the fundamental mechanics of the whole movement system - how do I fix this. I have considered four options so far:

1) Change the interception code so the missile will only aim for a location which the target will be in after an amount of time divisible by 5 seconds. This might cause some slight course swapping and additional delta-V use by the missile

2) Add much smaller sub pulses (perhaps 0.1 seconds or less). However, besides the perfomance implications during the increment, any potential missile hits will have to be calculated before the increment begins so the appropriate fractional sub-pulses can be used. This type of thing is done already on a large scale. The major problem though is that all times anywhere in the program are currently assumed to be integers so I could try changing this but there is a risk of a screw-up.

3) Calculate the closest point of both missile and the target during the sub-pulse, based on their movement paths (this is a calculation of both time and space as their paths may cross but it depends on where they are along that path). Detonate if on target or within detonation range and note the exact time of detonation during the sub-pulse. Then check the paths of all objects and resolve damage based on their distance from detonation at that exact point in time during the sub-pulse (so where was every ship 3.16 seconds into the sub-pulse and how far where they from the blast at that exact moment).

4) Calculate closest point of both missile and target during sub-pulse, as in 3). However, actually detonate the missile that distance from the ship on a direct path from the start location of the missile to the end location of the ship rather than the actual detonation point, then assess area damage based on adjusted detonation location and the position of nearby ships at the end of their movement. The difference between this and 3) is that it will be more obvious to the player which ships were in the blast radius.

I would also welcome any other ideas - apart from "entirely rewrite the way Aurora handles movement" :)

Steve
« Last Edit: December 09, 2011, 03:32:25 PM by Steve Walmsley »
 

Offline UnLimiTeD

  • Vice Admiral
  • **********
  • U
  • Posts: 1108
Re: A Dilemma on Interception Mechanics
« Reply #1 on: December 09, 2011, 03:39:35 PM »
Do 3 and 4 work with kinetic kill vehicles?

I think the option of calculating where it will hit, and then detonating it there in the pulse, seems good enough.
 

Offline TheDeadlyShoe

  • Vice Admiral
  • **********
  • Posts: 1238
  • Thanked: 50 times
  • Dance Commander
Re: A Dilemma on Interception Mechanics
« Reply #2 on: December 09, 2011, 03:42:04 PM »
If it's going to be a 'close pass' situation where a ship and missile are likely to intercept in a 5s increment (or in a 1s subpulse?) you could game it out as skill-based evasive maneuvers - crew grade/movement initiative/ECM VS thrust and homing ability of the missile. However, that may not really get what you want in terms of determining where the big ol kaboom occurs.  

I favor 3.  4 is more clear but it seems ...futzy? gamey?   Worst case you could generate a graphic for each missile detonation...lol :D
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • S
  • Posts: 7122
  • Thanked: 2040 times
    • http://www.starfireassistant.com
Re: A Dilemma on Interception Mechanics
« Reply #3 on: December 09, 2011, 03:43:01 PM »
Do 3 and 4 work with kinetic kill vehicles?

I think the option of calculating where it will hit, and then detonating it there in the pulse, seems good enough.

Once I solve this for missiles, I will use it for railguns as well.

Steve
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • S
  • Posts: 7122
  • Thanked: 2040 times
    • http://www.starfireassistant.com
Re: A Dilemma on Interception Mechanics
« Reply #4 on: December 09, 2011, 03:47:58 PM »
If it's going to be a 'close pass' situation where a ship and missile are likely to intercept in a 5s increment (or in a 1s subpulse?) you could game it out as skill-based evasive maneuvers - crew grade/movement initiative/ECM VS thrust and homing ability of the missile.

These are objects moving at over 1000 km/s so there are extremely few 'close passes' with 5 or even 1 second increments. They can easily miss by 3000 km/s or more. Think of an area of twenty-five million square kilometers. Two objects dash across it from different directions and pass through in less than five seconds. How often will they pass within detonation range, which is maybe one kilometer for nukes and 50-100 km for laser heads.

Steve
 

Offline chuckles73

  • Chief Petty Officer
  • ***
  • c
  • Posts: 37
Re: A Dilemma on Interception Mechanics
« Reply #5 on: December 09, 2011, 04:05:41 PM »
I like 2 a lot, but at high enough speeds you'd need smaller and smaller subpulses. (eg at 5000km/s with .1 second subpulses, you'd still be covering 500km in that subpulse)

4 would be nice for ease of understanding's sake, but it could screw up who's getting hit in certain situations. For perpendicular courses, the missiles could be blowing up pretty far from where they should. Assume 5000km/s again, for the missile and the target. Assume they would actually meet immediately at the start of the pulse and that their courses are perpendicular. The missile end up exploding roughly 25,000km from where it should be with a pulse length of 5 seconds.

I think 3 would be a good solution.
 

Offline PTTG

  • Sub-Lieutenant
  • ******
  • Posts: 125
Re: A Dilemma on Interception Mechanics
« Reply #6 on: December 09, 2011, 04:11:09 PM »
This problem sounds fundamentally similar to a common problem with 3D physics engines. I'm not familiar with how it's handled, but the problem may already have been resolved (or at least mitigated) there in a way you can reuse.

I suppose that my approach might be to, every tick, find out when and where the missile will cross/has crossed the path of the ship, then see if the ship is at the same place (or within detination distance) at that time. On reflection, that sounds much like 3.

I must say, solution 1 sounds like the most robust from a programming standpoint. It does drop some accuracy, but it'll be just as fast and stable as what we currently have.
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • S
  • Posts: 7122
  • Thanked: 2040 times
    • http://www.starfireassistant.com
Re: A Dilemma on Interception Mechanics
« Reply #7 on: December 09, 2011, 04:17:31 PM »
I like 2 a lot, but at high enough speeds you'd need smaller and smaller subpulses. (eg at 5000km/s with .1 second subpulses, you'd still be covering 500km in that subpulse)

4 would be nice for ease of understanding's sake, but it could screw up who's getting hit in certain situations. For perpendicular courses, the missiles could be blowing up pretty far from where they should. Assume 5000km/s again, for the missile and the target. Assume they would actually meet immediately at the start of the pulse and that their courses are perpendicular. The missile end up exploding roughly 25,000km from where it should be with a pulse length of 5 seconds.

I think 3 would be a good solution.

I am considering another option to combine 2 and 3, which would effectively be to replay the pass in slow motion. If the missile crosses the path of the target object, I rerun them both in a mini-increment of their own with really tiny sub-pulses (0.0001 seconds?) and check their distance at each point. Because I am doing this for those two objects alone, it doesn't cause any problems with using fractional seconds for the rest of the program. After the recheck is done, I detonate the warhead at the closest point, and assess every other potentially-affected object by checking its location at that exact fraction of a second. I already track start and finish positions for every objects in an increment so the necessary information is already available.

Hmm! Although another complication just occured to me. What if the nuclear detonation takes out another missile that exploded slightly later in the increment. I guess I will have to save all possible nuclear detonations until after all movement then check them all in exact order of detonation and see if any were destroyed before they exploded. With that level of detail I probably need to also track how long it would take the blast wave to arrive.

Although 1 looks more attractive now because at least everything would happen simultaneously :)

Steve
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • S
  • Posts: 7122
  • Thanked: 2040 times
    • http://www.starfireassistant.com
Re: A Dilemma on Interception Mechanics
« Reply #8 on: December 09, 2011, 04:18:48 PM »
This problem sounds fundamentally similar to a common problem with 3D physics engines. I'm not familiar with how it's handled, but the problem may already have been resolved (or at least mitigated) there in a way you can reuse.

I suppose that my approach might be to, every tick, find out when and where the missile will cross/has crossed the path of the ship, then see if the ship is at the same place (or within detination distance) at that time. On reflection, that sounds much like 3.

I must say, solution 1 sounds like the most robust from a programming standpoint. It does drop some accuracy, but it'll be just as fast and stable as what we currently have.

LOL this is almost identical to the post I just made - you beat me to it by 6 minutes :)

Steve
 

Offline byron

  • Rear Admiral
  • **********
  • b
  • Posts: 883
  • Thanked: 28 times
Re: A Dilemma on Interception Mechanics
« Reply #9 on: December 09, 2011, 04:35:23 PM »
I'm not sure where I fall in this.  For kinetics (and anything else that doesn't have a blast radius) you can skip this, and simply figure out if it would have hit during that increment.  For nukes, option 3.
This is Excel-in-Space, not Wing Commander - Rastaman
 

Offline UnLimiTeD

  • Vice Admiral
  • **********
  • U
  • Posts: 1108
Re: A Dilemma on Interception Mechanics
« Reply #10 on: December 09, 2011, 05:12:00 PM »
So, in that case, wouldn't a sentient race have all their nukes set so they communicate and detonate at once?
It might not do much, but it's better than to just disappear.
 

Offline chrislocke2000

  • Captain
  • **********
  • c
  • Posts: 454
  • Thanked: 16 times
Re: A Dilemma on Interception Mechanics
« Reply #11 on: December 09, 2011, 05:24:02 PM »
The replay in smaller ticks makes sense to me. I guess that rather than rerunning the whole thing in tiny steps you can just do increasingly small reruns. Ie replay the 5 sec tick at 1 sec increments and find in which tick it crosses and not calculating for any ticks after that. The replay that tick in .1 sec increments. I assume, (probably wrongly!) that that would allow you to get to a very precise point whilst limiting the total number of ticks you need to check.
 

Offline Vanigo

  • Lt. Commander
  • ********
  • V
  • Posts: 295
Re: A Dilemma on Interception Mechanics
« Reply #12 on: December 09, 2011, 06:03:05 PM »
I am considering another option to combine 2 and 3, which would effectively be to replay the pass in slow motion. If the missile crosses the path of the target object, I rerun them both in a mini-increment of their own with really tiny sub-pulses (0.0001 seconds?) and check their distance at each point. Because I am doing this for those two objects alone, it doesn't cause any problems with using fractional seconds for the rest of the program. After the recheck is done, I detonate the warhead at the closest point, and assess every other potentially-affected object by checking its location at that exact fraction of a second. I already track start and finish positions for every objects in an increment so the necessary information is already available.

Hmm! Although another complication just occured to me. What if the nuclear detonation takes out another missile that exploded slightly later in the increment. I guess I will have to save all possible nuclear detonations until after all movement then check them all in exact order of detonation and see if any were destroyed before they exploded. With that level of detail I probably need to also track how long it would take the blast wave to arrive.
Wouldn't the proposed combination of 2 and 3 almost take care of this already? Just run the micro-pulse reruns in parallel, instead of one at a time. Then, when the first blows, you can easily examine the current location of other nearby missiles and take them off the list as appropriate. I suppose once in a blue moon you'd see two missiles go off in the same micro-pulse, but not often enough to worry about, I think.
« Last Edit: December 09, 2011, 06:05:05 PM by Vanigo »
 

Offline TheDeadlyShoe

  • Vice Admiral
  • **********
  • Posts: 1238
  • Thanked: 50 times
  • Dance Commander
Re: A Dilemma on Interception Mechanics
« Reply #13 on: December 09, 2011, 06:47:24 PM »
Question: If AMMs have nuclear warheads, arn't you going to have to run these calcs for all AMM intercepts?  Hopefully it won't take epic amounts of time.
 

Offline UnLimiTeD

  • Vice Admiral
  • **********
  • U
  • Posts: 1108
Re: A Dilemma on Interception Mechanics
« Reply #14 on: December 09, 2011, 06:53:23 PM »
Maybe create a second thread (aka a mini-program) that does nothing else but micropulses? ;)
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53