Author Topic: NPR AI and timestep size  (Read 3644 times)

0 Members and 1 Guest are viewing this topic.

Offline schroeam

  • Lt. Commander
  • ********
  • s
  • Posts: 217
  • Thanked: 7 times
  • "Let's try a new strategy, let the Wookiee win"
Re: NPR AI and timestep size
« Reply #15 on: April 16, 2009, 04:00:51 PM »
Quote from: "Father Tim"
How about just adding an 'undo' button, so that when my nice, presumed-peaceful 5-day increment ends with an NPR fleet three-and-a-half days inside my planetary sensor envelop I can 'go back' those five days and choose a one day time advance instead.  Then when I do legitimately spot the NPR a few hours later (with my three-hour updates) my fleet can react appropriately.

That would be rather difficult with Access and would vastly increase the size of the database by using internal backup fields to store the previous turn's data.  I'm not sure how Steve is going to handle this, or if he even is (he may be satisfied with the performance right now, effort vs benefit and all), but it will probably have to be in the coding of how each increment is performed.

Adam.
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: NPR AI and timestep size
« Reply #16 on: April 16, 2009, 09:10:36 PM »
Quote from: "SteveAlt"
Hmm! I probably should have studied harder in maths :-)
Quote
Even so, assuming I did manage to get my head around it, I am still going to have to calculate all of the sensor ranges for every object against every other object and then run the above calculation in a matrix for every combination of two objects. It just seems that will take an awful long time in performance terms
I'll say more in another response, but I think the underlying optimization is that, even though you might do more calculation in the first time step, you can take much longer timesteps and you only have to re-calculate the intercept time for things that change state.  So subsequent updates only require the calculation for N_changed_state rows and columns of the matrix.  This takes it (calculating the intercept times for a timestep update after the first) from quadratic time to linear time in the number of objects in the system, assuming that only a few things change state at one time.

Best,
John
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: NPR AI and timestep size
« Reply #17 on: April 16, 2009, 09:57:07 PM »
Quote from: "SteveAlt"
Quote from: "sloanjh"
Shift the updating strategy in Aurora from a fixed time-step driven paradigm to a variable "advance by time to next event" paradigm.  I realize that this is probably a huge rearrangement of the code, but I think it will scale much better with number of NPRs, ships, systems, etc.  Here are a few ideas on how it might work:

Every mover (a fleet or a missile salvo) looks at its order list and estimates "time at which current command will complete, or when a detection is possible".  This is inserted into a priority queue, with the earliest event having the highest priority.  When it's time to do a timestep, figure out how long to make it by peeking at the highest priority (earliest) mover, and choose the timestep to take the clock to his event time, or by some maximum timestep time (e.g. a day) that you throw in for stability purposes.  The big advantage here is that the computer is doing the micromanaging of the timestep interval size (the lower row on the F3 screen), rather than me; it can use its omniscience to know that nothing is going to happen for about 1 hour, 22 minutes, and 35 seconds, so it can just jump to that time.  Processing a timestep consists of doing all the stuff that's done now (like figuring out if CargoFlt003 is done loading those 10 automated mines); any mover whose estimated time to completion changes (e.g. because they've gone on to a new order) updates their priority in the queue.  Those whose estimated time hasn't changed don't need to do anything in the queue, since it's using absolute time, not time remaining.
Essentially what you are talking about there is running the movement phase without actually moving anything so I can work out when things will happen and then running it again but broken into timesteps that correspond to when things do happen. My first reaction is that this would take a lot of effort but is possible. However, it is going to take a LOT longer to run an increment than it does now. The "run movement without moving" won't take much less time than it does now and then there will be several new movement steps, each of which take as long to execute as a regular timestep and there could be a lot more of them. Also, none of the above will affect the ability to interrupt when a precursor is detected because detection would still only take place after each step and most detection will be of fleets in motion rather than at the end of a step, so I am not sure what we gain. I am not saying that the intelligence of movement can't be improved but I not sure if this is the way to do it.
Response below, to the "only work out the first move of each fleet".
Quote
Quote
The second idea here (once you've got the first one coded up :). I may not intially agree with everything but they always get me thinking.

Going back to the initial idea of working everything out first, I guess I would only really need to work out the first move of each fleet, not all the moves, and I wouldn't need to physically change any records except the movement records so that would be quicker. In fact, an alternative might simply be to run through all of the existing first moves for every fleet and then just advance time by the shortest amount then repeat the process, rather than trying to work out a queue system. It still comes back to the problem though that detection is the main issue and this doesn't solve that any better than the existing timestep system, unless I am missing something.

Yes, this (only working out the first move) is exactly the idea.  You wouldn't even have to change the movement records - all you'd need to change is a (new) "time of next status change/event" field.  The shortest time in the DB for this new field would be exactly the "shortest" amount that you mention.

As for detection, I have two observations (based on reading some of the other posts):

1)  If everyone already has a "time of next event" field calculated, then you only need to recalculate it if either that time went by during the last timestep (by which I mean sub-pulse) or if the object's or a potential target's orders/speed/... changed (due to either the time going by or the player/AI changing orders) or if the object was hit by weapons.  I'm operating on the assumption that such a status change is very rare - maybe 10% for a "large" (e.g. 1-day) update and probably <10 objects for a "tiny" (e.g. 5 second, 30-second, etc. sub-pulse).  Let's assume that only 1 object changed state during the last timestep.  Then I have to do two calculations:

A) For every other object in the system, find the next time-of-intercept, and put the smallest of these in the object's "time of next event" field.

B) For every other object in the system, find the next time-of-intercept (hey!! I just realized that's the same quantity!!) - if it's earlier than the other object's time-of-next-event update the other object with the new time-of-next event.

So it's even cheaper than I thought - for everything that changed, loop over all the other objects and update the time-of-next-event field for both the thing that changed and the other object, as necessary.

Another thing I just realized - most systems (except maybe Sol in a multi-power game) won't have multiple races present simultaneously, so most of the time you won't have to do any detection.  And Sol shouldn't be that bad, since most of the traffic generating events will be civilian, and so will have transponders on which means they don't need to view detection as an event.

2)  Even if each timestep works out to be somewhat more expensive, the big advantage comes because (I suspect) you can get away with a LOT fewer timesteps - a player doesn't have to be afraid of doing 1-day or 5-day (or even 20 minute) increments.  This comes back to your idea of looking at first moves.  I'm beginning to think that the only thing you have to worry about is detection events.  So how about this: you only play this trick in systems with multiple races.  In other systems, things can just go as they do now.

More in othe replies....

John
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: NPR AI and timestep size
« Reply #18 on: April 16, 2009, 10:07:04 PM »
Quote from: "SteveAlt"
It isn't really a bug; more of a feature :-)  I'm 99% sure that the Precursors had detected me - they were on a reciprocal heading and actually already past me when they appeared, plus I'm pretty sure I was inside their planetary sensor's detection envelope.

2)  For a given pair of objects, you only need to use the sensor range that's biggest when calculating the intercept time - I don't think you need to redo the calcuation for each sensor type.

John
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: NPR AI and timestep size
« Reply #19 on: April 16, 2009, 10:25:52 PM »
Quote from: "SteveAlt"
Quote from: "Paul M"
The problem also lies in the time stepping as basically you need to determine if a hostile task force will end up inside the detection range of an object at the end of the current move, if so then stop the time at the point just where it would.  This is seriously unfun to even consider how to do.  If the game ran in real time with compression (such as harpoon did) it would be easier as might be fixed time intervals but with user defined one then it just gets messier and even worse so when a fleet goes from outside detection range to inside combat range inside of one time step.

A possibility is to add a routine that calcualtes the ending seperation of two forces at the end of the requested time step if the current forces are undetected now.  If no detection then it keeps the time step if there would be detection then it defaults to the next lowest time step and checks again, if no detection then it uses that one, if not it tries with the next lower time step until it reaches a time step that doesn't result in detection.  It executes that time step and posts a message up about switching time due to pending contact in system x by task force y.

This allows the player to find the unit in question and manually set the time to allow for the encounter to play out, without hopefully adding in much computing overhead.  It is a serious issue; however, as I have goofed and hit the wrong time step sometime or otherwise didn't expect combat only to have aliens show up at extremely close range to my ships.  This is also important for a SM who has to advance the game until something happens...and a warning to the SM that hostile fleets occupy the same system would also be useful.

But the trouble is...this is likely computationally much more difficult then I suspect it is as you have to make a detection matix and then apply a test to see if the sum of the matrix is 0 or ?1.  Again all of this is easier for a game like harpoon which is real time.
Harpoon is a great game and there is a lot of influence from that game on Aurora. The problem for me is that Aurora handles much larger timescales. For a pure-tactical battle you could run the game with perhaps 30 minutes increments and 5 second or 30 second sub-pulses and you would have something very close to Harpoon because the sensors are checked every increment. Perhaps the real way to tackle this is for me to concentrate on optimising the movement and sensor code so it executes more quickly and therefore allows a large number of small sub-pulses to be executed quickly.

EDIT - maybe I load everything into memory and run the sub-pulses then update the database at the end of the increment. Or on a smaller scale, at least retain the sensor information for each ship in memory because at the moment it is recreated during every sub-pulse. There must be a lot of mileage in this area.

Steve

More random comments :-)

    I'm pretty sure that, under the covers, the problems that Steve and Harpoon have to face are the same (or even identical).  I suspect one big difference is that Steve has to handle a LOT more units than Harpoon ever did - I doubt that a typical Harpoon game ever had more than 50-100 platforms.  In addition, as Steve says he has a much bigger dynamic range than Harpoon (~100 years total elapsed time vs. 1 week, which is 3 or 4 orders of magnitude).  I think I remember it taking quite a while to run off significant amounts of game time in Harpoon, even at high acceleration values.  That being said, my recollection is that Harpoon was able to calculate when the next detection event would take place within an impulse and stop time there.

    It occurred to me that this problem is very similar to a nasty issue when trying to write code to simulate the orbits of comets.  The problem is that, when the comet is near the sun, you need to take VERY small timesteps in order to avoid numerical errors.  If you try to use the same size timestep while the comet is in the Oort cloud, however, you'd end up spending all your CPU doing an unnecessarily fine-grain simulation of it wandering around out there.  The solution is to develop and algorithm that knows when it needs to take small time steps, but that takes large ones when it's safe to do so.

    You shouldn't stop time exactly at the time the weapon enters the detection range - you should stop it at some random time within the decision cycle.  In other words, you should round up to the next 5-second interval (at least before interrupting), even if that means that a Precursor missile hits your ship because it blew through the sensor envelope before you even noticed that it was there.  (Note that this is different from the point-defense envelope - for point-defense, you can plan your shot.)

    I was wondering how much of the data in the movement impulses is being driven off the database.  That might be what's making the sensor checks prohibitively expensive (especially if it has to pull the info off the disk rather than some in-core version of the DB).  I think trying to keep some of the info in memory and then update the DB is probably a really good performance idea.

John
 

Offline Paul M

  • Vice Admiral
  • **********
  • P
  • Posts: 1437
  • Thanked: 61 times
Re: NPR AI and timestep size
« Reply #20 on: April 17, 2009, 06:30:26 AM »
Looking at this there is a simple fix, it is un-elegant in the extreme but it has the advantage of being workable.  If I understand Steve's response detection is only checked at the end of each time increment this results in the problem that you do a 5 day update and get told that your world/fleet was wiped out before you could even respond.  The solution that looks best to me at this point is to check if the ship ends its movement in a the detection radius of something if it does then don't play with the time but move the ship backwards along its bearing until it is (30 + 30(1-crewgrade*0.01)s)*velocity km inside the detection radius.

Where this gets complicated is if it ends up in multiple detection radius:
1. check against all detection radii
2. if inside longest ranged one calculate its position if backed up
3. check if backed up position is inside any other detection radius (excluding the 1 alread checked against)
4. if so back it up against that detection radius
5. check if backed up position is inside any other detection radius (excluding the 2 alread checked against)
6  if so back it up against that detection radius
7  check if the backed up position is inside any other detection radius (excluding the 3 alread checked against)
8  repeat until you check yields no other possible detections at this point this is the final position of the TG at the end of the movement increment.

The other possibility is calculate the intercept time of the fleets.  Check that against the time increment and reduce the time increment to a step where such an intercept (defined as one force entering the detection radius of another) no longer occurs.  Pup a "combat immenant" message in the events.

I am still not convinced this will work and it clearly can be exploited.  The issue here is the time increment when you don't expect combat can be large (5 days for example) so its hard to figure out how to deal with this and to not bollux up combat scale increments which the above would do in all likelyhood.  An engaged flag could be used to disable it so that once a unit was involved in combat these checks don't occur (active FC would do this).

Anyway this looks to me to be the best way to deal with it...it is in effect an automatic "undo until detection range."

What could bollux it up is that the civillians show as red on my screen all the time even though I have them set to neutral in the race.

Another idea would be to only use this on time increments greater than 3 hours (8 hours, 1 day, 5 days and 30 days) this would make it not an issue in a combat situation removing the need for a combat flag...even 8 hours is iffy.  But clearly 1 day, 5 days and 30 days are "peace time" advance rates and here is where the real effort needs to be put in.
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: NPR AI and timestep size
« Reply #21 on: April 18, 2009, 05:47:15 PM »
Hi Steve,

  Something just occurred to me.  You said that the sensor detection algorithm does essentially N^2 comparisons, where N is the number of ships in a system.  Does this mean that 30-40 civilian fleets running around in my home system is going to kill performance, since I've got another 20-30 ships (with sensors) in parking orbit?

Thanks,
John
 

Offline mikew

  • Chief Petty Officer
  • ***
  • Posts: 36
  • Thanked: 1 times
Re: NPR AI and timestep size
« Reply #22 on: April 19, 2009, 10:21:06 AM »
Here is something that *may* be a little more workable in determining intra-interval detection without any "higher math"  For each group of ships determine the range to each other "group" in the system and compare against longest range sensor(s).  For the next turn, determine the range again and compute a closing speed (range rate) by simply dividing the range difference by the time between checks.  If you presume that these will remain relatively constant, you can then determine with a fair amount of confidence whether the groups will enter detection range in the next interval.  This would only have to be done for fleets in systems with other potential targets.  If ships reach a turnpoint, transit a warp point, etc., you'd have to restart calculations of course, since that changes the range rate criteria.  At any such event, you can simply assign arbitrary range rates to other groups of ships equivalent to the maximum possible closing speed to determine whether a detection might be possible- once you run the first interval, you then have an actual rate for future calculations.

  When the numbers indicate a potential detection range arrival, calculate positions of the ships/populations/whatever involved, recalculate the range rate, and determine whether to continue and for how long, and begin again.  Eventually, your algorithm will bring you down to the shortest possible interval and your ships then enter detection range, at which point player interaction is called for as necessary.  This iterative process will likely result in somewhat longer processing times, as it will at some point or another shorten the interval to check for detections which don't actually occur, and will likely do so multiple times during approach to actual contact, but it WILL get you to the correct point of first detection.  With straight line movers, closing range rates will decrease as the range drops, so you will never have a ship manage to unexpectedly appear inside detection range.

  This will be complicated if fleets are spread out over a large areas, but if they vessels are clumped relatively close together, only the best sensors need to be checked on the basis that short range sensors won't make the initial detection in any case.  Based on what I've read so far, though, fleets won't be excessively large, and there won't be that many ships in any single system, so the overhead of calculating intevals shouldn't be that great.  The slowdown will occur when the system starts running the shorter intervals as ships approach detection range.  I don't know how long a typical update takes, so I can't estimate how much this will slow everything down- you might just be grabbing a soda from the fridge, or you might be cooking dinner- it depends on how long your normal intervals take to calculate.

  So, bottom line - you'll end up breaking your intervals down more often when multiple ships are in the same system.  You'll always do new calculations when ships transit to new systems (I imagine that happens now anyway), and if potential targets are in the system you'll need shorten intervals when ships approach waypoints to turn or change speed, and in addition when ships are calculated to potentially enter detection ranges based on previous closing speeds.  You will NOT have to retain any additional data on previous positions, nor use any new formula.  It should only result in significant slowdowns when vessels are actually in systems with possible targets, and then only when either approaching to contact or if vessels are maneuvering during the turn.

Mike
 

Offline ShadoCat

  • Commander
  • *********
  • Posts: 327
  • Thanked: 1 times
    • http://www.assistsolar.com
Re: NPR AI and timestep size
« Reply #23 on: April 19, 2009, 01:47:04 PM »
Mike's solution looks workable.  It'll give what you need without too many extra clock cycles.

The key is data pruning.  The more potential interactions you can toss out, the faster you will be.

If you combine with Paul's trig (which I understood after I dusted off the brain sells that shut down when I hit "transformations between non-linear vector spaces").  

You can use the trig figure out which interactions you need to consider.  In fact, you can even use it to determine which sub pulse you need to look at the interaction.  Thus, if the equations says that you won't enter into detection envelopes, then the interactions are never checked again until courses are changed, so only check again if courses change.  If they say that there will be an interaction in 4 pulses, only check again after 4 impulses.

Offline SteveAlt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 820
  • Thanked: 8 times
Re: NPR AI and timestep size
« Reply #24 on: April 27, 2009, 08:03:29 AM »
Quote from: "sloanjh"
Hi Steve,

  Something just occurred to me.  You said that the sensor detection algorithm does essentially N^2 comparisons, where N is the number of ships in a system.  Does this mean that 30-40 civilian fleets running around in my home system is going to kill performance, since I've got another 20-30 ships (with sensors) in parking orbit?
It's not as bad as it might seem at first. Although theoretically each of the 30 ships will attempt to detect each of the other 30, as soon as a ship is detected the check for other sensors of the same type is ignored.

Steve
 

Offline SteveAlt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 820
  • Thanked: 8 times
Re: NPR AI and timestep size
« Reply #25 on: April 27, 2009, 08:38:55 AM »
Rather than respond to each of the posts above, all of which contain a lot of very good suggestions that it will take me a while to assimilate properly, I thought I would provide on update on what I have been up to over the last week. I have decided that due partly to my fear of math :)

Steve
 

Offline ShadoCat

  • Commander
  • *********
  • Posts: 327
  • Thanked: 1 times
    • http://www.assistsolar.com
Re: NPR AI and timestep size
« Reply #26 on: April 27, 2009, 05:07:35 PM »
Steve, if you want any help with the math or the algorithms, just ask.

I don't know the new versions of VB or Access but I can pseudo code something up for you.

Offline SteveAlt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 820
  • Thanked: 8 times
Re: NPR AI and timestep size
« Reply #27 on: April 29, 2009, 09:17:59 AM »
Quote from: "ShadoCat"
Steve, if you want any help with the math or the algorithms, just ask.

I don't know the new versions of VB or Access but I can pseudo code something up for you.
Thanks for the offer. John has already sent me some excellent code to tackle the prediction option but I am not going to work through it for the moment. I am saving it as a backup, or potential bonus, for the current recoding exercise. As with so many Aurora projects, this one is turning out to be huge. It is amazing how many parts of the program are being affected. Any part of the program that requires data access to fleets, ships, sensors, fleet orders, contacts and missiles during movement and detection or access to contacts at any time has to be rewritten to access the object model instead. I am currently working on converting missile movement to objects, which affects everything concerning point defence or point defence assignments, including fire control assignments and missile detection. If I had realised how large it was, I may not have started but there is no turning back now.

Steve
 

Offline ShadoCat

  • Commander
  • *********
  • Posts: 327
  • Thanked: 1 times
    • http://www.assistsolar.com
Re: NPR AI and timestep size
« Reply #28 on: April 30, 2009, 01:48:01 AM »
Quote from: "SteveAlt"
I am currently working on converting missile movement to objects, which affects everything concerning point defence or point defence assignments, including fire control assignments and missile detection. If I had realised how large it was, I may not have started but there is no turning back now.

Heh.

If guys thought out how much effort interesting ideas would take, people on this side of the Atlantic would still be speaking dozens of native languages....