Aurora 4x
VB6 Aurora => VB6 Mechanics => Topic started by: AbuDhabi on October 09, 2013, 06:18:01 PM
-
(Not sure if this goes here, Rules, the Academy or Bugs.)
During an inspection of the database file following fixing some erroneously null-ified fields, I've noticed that the system bodies appear to have their current X and Y listed right there. It seems as thought these values are periodically recalculated and saved there.
Why?
-
I suppose it does form the center coordinate for their satellites and gives a physical location for the body for a ship to fly towards? They are shown on the map so the map needs to know where to put the dot.
-
That would be the obvious explanation. I've checked the predefined Sol system coordinates with the coordinates a game - they are completely different, which lends credence to the this. But that's what's so weird!
Because you don't need to know the incrementally calculated position of the system body to know where it is. Since the orbits are perfect circles, you can use uniform circular motion formulas (http://www.chem.ox.ac.uk/teaching/Physics%20for%20CHemists/Rotation/Circular.html). Given the body's initial position, its speed, radius and amount of time passed we can determine where it is at any point in time without needing to calculate where it was at any previous point in time.
Indeed, I think these formulas are already being used. But why does the game need to save the current coordinates?
-
In databases you have to consider (and is know its BAD deisign!) lookuptimes vs. calculation times. If your lookup is even a little bit faster then calculating the position say for each ship then you should have it in the database for better performance.
It could be better for aurora thought if the positions would go into an struct or something like that instead of the database itself.
-
In databases you have to consider (and is know its BAD deisign!) lookuptimes vs. calculation times. If your lookup is even a little bit faster then calculating the position say for each ship then you should have it in the database for better performance.
It could be better for aurora thought if the positions would go into an struct or something like that instead of the database itself.
There is also another consideration.
The current system (as I imagine it working, judging the the database, gameplay and my extrapolations) requires that every position be recalculated at least every time the game is paused. Possibly every sub-pulse, too, because otherwise there might occur significant deviations in flight times for ships. And every time it is recalculated, it is saved to the database (again, if my understanding is correct).
This seems very inefficient.
Consider the case where calculation is done on an ad-hoc basis only - systems which are devoid of ships do not need to be calculated at all. Further, system bodies of no interest (such as those which aren't the destination of any ships and have no colonies on them) might not be required to be recalculated, either. The only time when uninteresting bodies' coordinates need to be calculated is when the player is looking at the system map.
-
The current system (as I imagine it working, judging the the database, gameplay and my extrapolations) requires that every position be recalculated at least every time the game is paused. Possibly every sub-pulse, too, because otherwise there might occur significant deviations in flight times for ships. And every time it is recalculated, it is saved to the database (again, if my understanding is correct).
no, body locations only needed to be re-saved every five days.
-
no, body locations only needed to be re-saved every five days.
Because they are recalculated in 5-day increments, yes? (That's the way it seems from Steve's explanation of how turns work.) So what happens when a ship's travel is shorter than that? Do they simply use the stored information, which only changes every 5 days?
-
I can't speak as to the architecture. The ship only needs to know where the body will be in the five day increment that it reaches it.
Hell, the stored data might only be for some obscure function anyway, like displaying the X,Y on the system map. It might not be used in pathing at all.
-
It should be noted that it is not necessarily every five days. Orbital motion calculations are performed every production cycle (whatever you have that set to) and the body positions updated then.
The reason that the X/Y coordinates are stored is so that you can have one function that sets where a TG is moving (or a mineral packet / missile /etc is being sent). That function just looks up the X/Y position of whatever target object (lots of tables in the game have an X/Y coord, and many also have a "last x" / "last Y" so that you can draw the movement trails as well).
As for the question about what happens if a planet / body moves when a ship is trying to go there, it depends on what order things happen during the production cycle. If planets move first, there is no problem, as the X/Y for the body will be updated before the ship tries to figure out how to get there. I would assume body motion comes first for this reason, but it's possible it may not. Just watch a slow conventional engine freighter trying to catch up with a planet and you will see that they aren't doing any kind of predictive motion interpolation. They just head directly for the body.
As for why to store X/Y for each object rather than calculate it on the fly each time, that should be obvious. Performing a calculation is almost always going to be slower than a simple DB lookup. When you compound this with potentially thousands of calcs/lookups every increment, it can get slow pretty quick.
-
The reason that the X/Y coordinates are stored is so that you can have one function that sets where a TG is moving (or a mineral packet / missile /etc is being sent). That function just looks up the X/Y position of whatever target object (lots of tables in the game have an X/Y coord, and many also have a "last x" / "last Y" so that you can draw the movement trails as well).
This can be done with on-the-fly calculations as well. Simply calculate positions for t1 and t2, and draw those. The last time increment is a known value.
As for the question about what happens if a planet / body moves when a ship is trying to go there, it depends on what order things happen during the production cycle. If planets move first, there is no problem, as the X/Y for the body will be updated before the ship tries to figure out how to get there. I would assume body motion comes first for this reason, but it's possible it may not. Just watch a slow conventional engine freighter trying to catch up with a planet and you will see that they aren't doing any kind of predictive motion interpolation. They just head directly for the body.
That's terrible.
As for why to store X/Y for each object rather than calculate it on the fly each time, that should be obvious. Performing a calculation is almost always going to be slower than a simple DB lookup. When you compound this with potentially thousands of calcs/lookups every increment, it can get slow pretty quick.
No.
Performing a cheap calculation (as is the case here) will almost always be faster than a "simple DB lookup". Trigonometry stopped being calculationally expensive more than a decade ago. Even with solid-state drives, it is unlikely that accessing disk-bound data would be faster.
-
it is unlikely that accessing disk-bound data would be faster.
I would think it's in memory.
-
yes memory and most likely relative stationary so issuing an GetAddress(x) is faster then on the fly calcs.
-
So the database gets loaded into memory? That would be faster, yes.
-
So the database gets loaded into memory? That would be faster, yes.
The DB is loaded into memory objects at the start of a movement cycle, so that it is NOT accessing disk during each interval. There should be a post from Steve in Mechanics that's 4-6 years old talking about this optimization when it was done.
John
-
That's terrible.
This is extremely helpful.
-
This is extremely helpful.
Are you saying it is not terrible that pathfinding does not do any prediction for where the target they're headed for is going to be considering their speed?
-
The single biggest reason for the chase the planets implementation is its simplicity, no need to create extra hassle when not needed.
-
Are you saying it is not terrible that pathfinding does not do any prediction for where the target they're headed for is going to be considering their speed?
For the vast majority of the game, it doesn't matter. Your ships move so much faster than the planets that you're not really losing much by direct chase. For the portion where it does matter (extremely slow, conventionally-engined commercial vessels in the early game), you can work around it by placing waypoints. That's what you have to do when trying to intercept enemy task groups, and I haven't heard anyone complain about having to manually work out those intercepts. In fact, that's a major part of games like this.
While it would be nice if the game predicted planetary positions and moved toward those, in most cases, it just doesn't matter. So I wouldn't call it "terrible," so much as "inconvenient." If you have an alternative implementation ready to go, why not submit to the Pulsar 4x group? The base functionality of Aurora is unlikely to be changed, especially in marginal cases like this.
-
For the vast majority of the game, it doesn't matter. Your ships move so much faster than the planets that you're not really losing much by direct chase. For the portion where it does matter (extremely slow, conventionally-engined commercial vessels in the early game), you can work around it by placing waypoints. That's what you have to do when trying to intercept enemy task groups, and I haven't heard anyone complain about having to manually work out those intercepts. In fact, that's a major part of games like this.
While it would be nice if the game predicted planetary positions and moved toward those, in most cases, it just doesn't matter. So I wouldn't call it "terrible," so much as "inconvenient." If you have an alternative implementation ready to go, why not submit to the Pulsar 4x group? The base functionality of Aurora is unlikely to be changed, especially in marginal cases like this.
It's also partly because a lot of the potential intercepts are far from simple. If your destination is a moon orbiting a planet that is orbiting a star that orbits another star which in turn orbits a third star (while taking lagrange points into account), then working out an intercept course is tricky. I found this when I had to do exactly that calculation in Newtonian Aurora (because constantly changing course is expensive in fuel) and also allow for acceleration and deceleration of a ship that is constantly losing mass (and therefore changing acceleration rate). As noted above, it isn't often an issue so it seemed like a look of effort to solve a minor issue.
Steve
-
It's also partly because a lot of the potential intercepts are far from simple. If your destination is a moon orbiting a planet that is orbiting a star that orbits another star which in turn orbits a third star (while taking lagrange points into account), then working out an intercept course is tricky. I found this when I had to do exactly that calculation in Newtonian Aurora (because constantly changing course is expensive in fuel) and also allow for acceleration and deceleration of a ship that is constantly losing mass (and therefore changing acceleration rate). As noted above, it isn't often an issue so it seemed like a look of effort to solve a minor issue.
Steve
That makes sense. Thanks.
-
Wow, you waited for the wrong time to reply on this one, Steve's actually made this exact change in the next patch :p.
Thank you steve, and thank you belasco commune for playing tag with those silly Russian Oscar class destroyer commanders.
-
Wow, you waited for the wrong time to reply on this one, Steve's actually made this exact change in the next patch :p.
Thank you steve, and thank you belasco commune for playing tag with those silly Russian Oscar class destroyer commanders.
Actually I made the change for ships/missiles intercepting moving fleets. There is still no intercept movement for planets for the reasons I mentioned above.
And you're right it was the Belasco Commune that persuaded me to finally sort this out :)
Steve
-
What exactly happened with the Belasco Commune?