|
I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number.
For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates
2.25 speed multiplied by 1 = 2.25.
When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates
(2.25 multiplied by 0.981211) + (2.25 x 0.019121)
to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike.
I can be wrong, but at least I'll know why if you explain
|
Hungary422 Posts
On February 21 2015 10:14 linuxguru1 wrote:
*mind blown*
EDIT:
I was always under the impression that overlords travelling southwest were faster. I thought it was only my imagination, but there seems to be truth to it. So my question is: do all units have the same absolute speed-increase when travelling south-west or is it relative to their actual moving speed?
I don't know this, but I might test it later. I'm guessing they should have the same increase in absolute value, if this phenomenon is caused by some rounding error. At least the amplitude of the regression sine function is very similar for the SCV and the Stalker speed, both about 0.0026...
On February 21 2015 10:54 ZackAttack wrote:
This is very well done. I am surprised that this is the case, that things accelerate faster in different directions. It seems obvious that this would be true of the other units as well. Did you test this with any other unit?
I tested only with a Stalker beside the SCV, and it had the same result. (This is only valuable information for the top speed value though, as stalkers accelerate instantly.)
On February 21 2015 13:36 varsovie wrote:Show nested quote +On February 21 2015 08:03 Sholip wrote:
[*]They spend more time travelling because they have to travel a shorter distance.
[*]They spend more time travelling because they travel faster in some cases. How would it take more time to travel shorter distance when moving faster??? It feels like an hypothesis made AFTER the research was concluded. But yeah the fact unit pathing and movement is radian dependant isn't new in a video game. It's a propriety of nearly all pathing that it will favor one side over the other, maybe in this case the engine only refreshes one direction before the other in a cyclic way. Or it may simply be rounding "error" with either the sin/cos functions or the vector additions. But out of curiousity, wouldn't it mean minimg imbalance of mineral too in diferent patches disposition/orientation? Can you also test few military units (spine crawler, marine, slow/speedling, mamacore, medevac) to see if the acceleration difference is consistant there too? Anyway thank man for the !!science!!. *If I may suggest for table 2 to use the same ammount of precision on all values of Total T (add the missing 0s).
Of course you are right, I meant to write less. I must have already had the result in my head.  Corrected!
Since minerals are approximately as close as geysers, this should, in fact, mean that mineral mining is imbalanced as well.
*As for the table precision, yeah, it was kinda sloppy  .
On February 22 2015 02:39 etofok wrote:I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number. For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates 2.25 speed multiplied by 1 = 2.25. When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates (2.25 multiplied by 0.981211) + (2.25 x 0.019121)to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike. I can be wrong, but at least I'll know why if you explain
That video is quite interesting. While I am no expert of this topic, I believe this problem does not have much to do with pathfinding itself, rather it could be the result of rounding, as you also suggested.
|
I didn't really read your post because im not one to complain about balance even if there is scientific evidence behind it. You would probably do good in some sort of job involving economics, especially if you enjoy doing things like this with your free time. ^^
|
Hungary422 Posts
On February 22 2015 03:57 life617 wrote:
I didn't really read your post because im not one to complain about balance even if there is scientific evidence behind it. You would probably do good in some sort of job involving economics, especially if you enjoy doing things like this with your free time. ^^
It wasn't meant to be a complaint, just some surprising facts. And, unfortunately, I'm really not interested in economics.
|
Oh, what a flawless well designed game Starcraft truly is.
|
I would be honest right here... that guy did an incredible job with his research... but everyone look into yourself and ask yourself "did you ever notice it?" nope... do you press your upgrades right after they finished not when 8x3 drones mines 16 gas more? nope.. Your opponens lings were in position in 0.0250 faster... there is no way this is noticable in probler 1v1 ladder game !
But still good job if they fix it they will do it in LoTV because this is engine issue
|
Hungary422 Posts
On February 22 2015 06:09 PharaphobiaSC2 wrote:I would be honest right here... that guy did an incredible job with his research... but everyone look into yourself and ask yourself "did you ever notice it?" nope... do you press your upgrades right after they finished not when 8x3 drones mines 16 gas more? nope.. Your opponens lings were in position in 0.0250 faster... there is no way this is noticable in probler 1v1 ladder game ! But still good job if they fix it they will do it in LoTV because this is engine issue
Well, people did notice the difference it causes in mining rates years ago, so I wouldn't say this is entirely true. I agree, though, that other than that, it can't be noticed anywhere.
|
In warcraft 2 towers used to fire from the top left hex within them, so that they had longer range north than they did south. It could be similar to that with refineries.
|
give this guy his icon already!
|
On February 22 2015 02:39 etofok wrote:I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number. For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates 2.25 speed multiplied by 1 = 2.25. When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates (2.25 multiplied by 0.981211) + (2.25 x 0.019121)to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike. I can be wrong, but at least I'll know why if you explain
Yeah and since each unit is a singularity in the coordinate system, this zick-zack effect in diagonal movements - similar to graphics when using anti-aliasing - is impossible to get rid of. So even if this is at a very small scale in sc2 which allows for this very fluid movement, it´s probably to be accounted for that blizzard has not included seperate factors to ensure movementspeeds are as wanted through small acceleration boosts.
|
On February 22 2015 02:39 etofok wrote:I'll try to have some input on topic: Pathfinding works because each map has a grid: when you go diagonally the numbers fluctuate a bit, because it is no longer a straight number. For example in Cartesian system (x,y) as (1,0) sets you at UP position and the game calculates 2.25 speed multiplied by 1 = 2.25. When you go diagonally it sets you somewhere like (0.981211, 0.019121) or whatever, because of the angle and how normalization of vectors works, meaning the game calculates (2.25 multiplied by 0.981211) + (2.25 x 0.019121)to move the unit as a player desires. When engine rounds up this number to 2 decimals it will be shown as 2.25, but actually is going to be 2.249452 or alike. I can be wrong, but at least I'll know why if you explain
I agree with your interpretation. I literally just wrote A* for a game in Unreal Engine 4 last week, and you need to realize that the units need to have their position in a grid. You simply cannot escape small fluctutations
|
Nice!
Some questions:
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
Good job, cheers.
|
Hungary422 Posts
On March 02 2015 22:36 Cascade wrote:
Nice!
Some questions:
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
Good job, cheers.
I will try to answer these questions as best as I can
1) In the tests I always made the SCV face the direction it was supposed to move in before ordering it to move. This way it didn't have to turn; always moved in one direction. If it changes direction before accelerating to maximum speed, I assume it will continue accelerating with a different acceleration.
2) There is always a sudden boost at the very beginning of the movement. See here, on Page 3, Figure 3, the yellow graph. The value of that boost is hard to say, because it rather seems to be a simple boost to position (like a tiny teleportation), rather than acceleration. It is possible that this value is also greater in diffrerent directions. Other than that, yes, the acceleration values themselves, at every tick, are uniformly greater in certain directions than in others.
3) That's true, the sum of the accelerations back and forth would be constant in every direction with the sine dependance. However, the time it takes to complete the trip wouldn't.
Consider you have to travel 1 m with 2 m/s and then back 1 m with 2 m/s again. This would take t = 1/2 + 1/2 = 1 s in total. Now if you have to travel with 1 m/s there and 3 m/s back, it takes t = 1/1 + 1/3 = 1.333 s, not 1 s, although the sum of the speed values was the same in both cases. Similarly with acceleration, but a bit more complicated (squares in the formulae and stuff). The point is, even though the sum of the accelerations there and back is constant, the time to go there and back will change (I hope I was clear enough).
On the other hand, the function is obviously not a sine function; there are quite big fluctuations in it, so it can lead to even greater differences.
4) With an acceleration of 1000, the SCV should be at its maximum speed immediately. So the only way acceleration can factor in is through the sudden boost at the beginning, which might be different at different angles.
5) Yes, I can. In fact, that is exactly what I did. Workers always spend 32 ticks (2 gs) in the Refinery, so that can't be the source of the difference. Also, in one particular case that I observed, the SCV travelled slightly more in slightly less time than in the other direction. This leaves only the possibility of the SCV moving faster in certain directions than in others.
I hope I managed to answer your questions.
If you are still interested, I can share the test map I used, so you can try these for yourself.
|
I always send workers to mine the southern geysers first these days, because of these threads.
My winrate has gone up. 8/8 blizzard
|
Impressive work as always Sholip!
Have you looked into Zerg's extractor trick? It was discussed in today's SPL cast and I immediately thought about you.
|
On March 03 2015 03:05 Sholip wrote:Show nested quote +On March 02 2015 22:36 Cascade wrote:
Nice!
Some questions:
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
Good job, cheers. I will try to answer these questions as best as I can 1) In the tests I always made the SCV face the direction it was supposed to move in before ordering it to move. This way it didn't have to turn; always moved in one direction. If it changes direction before accelerating to maximum speed, I assume it will continue accelerating with a different acceleration. 2) There is always a sudden boost at the very beginning of the movement. See here, on Page 3, Figure 3, the yellow graph. The value of that boost is hard to say, because it rather seems to be a simple boost to position (like a tiny teleportation), rather than acceleration. It is possible that this value is also greater in diffrerent directions. Other than that, yes, the acceleration values themselves, at every tick, are uniformly greater in certain directions than in others. 3) That's true, the sum of the accelerations back and forth would be constant in every direction with the sine dependance. However, the time it takes to complete the trip wouldn't. Consider you have to travel 1 m with 2 m/s and then back 1 m with 2 m/s again. This would take t = 1/2 + 1/2 = 1 s in total. Now if you have to travel with 1 m/s there and 3 m/s back, it takes t = 1/1 + 1/3 = 1.333 s, not 1 s, although the sum of the speed values was the same in both cases. Similarly with acceleration, but a bit more complicated (squares in the formulae and stuff). The point is, even though the sum of the accelerations there and back is constant, the time to go there and back will change (I hope I was clear enough). On the other hand, the function is obviously not a sine function; there are quite big fluctuations in it, so it can lead to even greater differences. 4) With an acceleration of 1000, the SCV should be at its maximum speed immediately. So the only way acceleration can factor in is through the sudden boost at the beginning, which might be different at different angles. 5) Yes, I can. In fact, that is exactly what I did. Workers always spend 32 ticks (2 gs) in the Refinery, so that can't be the source of the difference. Also, in one particular case that I observed, the SCV travelled slightly more in slightly less time than in the other direction. This leaves only the possibility of the SCV moving faster in certain directions than in others. I hope I managed to answer your questions. If you are still interested, I can share the test map I used, so you can try these for yourself.
Thanks!
Regarding 3, the effect you refer to exists, but is second order, in the sense that small changes in speed/acceleration will give a small^2 contribution to the travel time. Your difference in travel time the first second is around 4%, meaning that the expected total difference in time in a cycle will of the order 4%^2 which is nowhere enough to explain the difference in mining rate you see. Increase in speed and acceleration should give the same effect on mining time, as distance traveled is linear with both.
All in all, I don't think excluding other possibilities and then assuming the last one is the reason is enough. Specially when the last one also doesn't show nearly enough difference to explain the mining rate. If acceleration is indeed the difference, it should be easy for you to directly observe it with your data, which would give a much better case for your point.
|
Hungary422 Posts
On March 03 2015 06:58 Cascade wrote:Show nested quote +On March 03 2015 03:05 Sholip wrote:On March 02 2015 22:36 Cascade wrote:
Nice!
Some questions:
1) does the direction the scv face when starting influence the acceleration?
2) as you track every tick, what part of the accelerating is faster? Is it a boost at the very start, or uniformly faster acceleration over the first second?
3) the scv goes back and fourth to the gas, and it seems like the sum of the trip would be constant with a sin dependence. Fastest there would mean slowest back. Doesn't the scv accelerate in both directions during a trip?
4) the difference for 1000 acceleration is ridiculously small. Are you sure it is still not related to acceleration? It would be interesting to see more acceleration values, and how the sine amplitude depends on it. Also, could you try with 10 second travel instead of one, to get the speed. You wouldn't need to try all 360 degrees, just 4 directions would be plenty.
5) can you confirm the acceleration hypothesis from the tick-by-tick data of the mining? Take a cycle and plot the total distance traveled against time for the two gas positions. That would clearly show which of the three possibilities explain the difference.
Good job, cheers. I will try to answer these questions as best as I can 1) In the tests I always made the SCV face the direction it was supposed to move in before ordering it to move. This way it didn't have to turn; always moved in one direction. If it changes direction before accelerating to maximum speed, I assume it will continue accelerating with a different acceleration. 2) There is always a sudden boost at the very beginning of the movement. See here, on Page 3, Figure 3, the yellow graph. The value of that boost is hard to say, because it rather seems to be a simple boost to position (like a tiny teleportation), rather than acceleration. It is possible that this value is also greater in diffrerent directions. Other than that, yes, the acceleration values themselves, at every tick, are uniformly greater in certain directions than in others. 3) That's true, the sum of the accelerations back and forth would be constant in every direction with the sine dependance. However, the time it takes to complete the trip wouldn't. Consider you have to travel 1 m with 2 m/s and then back 1 m with 2 m/s again. This would take t = 1/2 + 1/2 = 1 s in total. Now if you have to travel with 1 m/s there and 3 m/s back, it takes t = 1/1 + 1/3 = 1.333 s, not 1 s, although the sum of the speed values was the same in both cases. Similarly with acceleration, but a bit more complicated (squares in the formulae and stuff). The point is, even though the sum of the accelerations there and back is constant, the time to go there and back will change (I hope I was clear enough). On the other hand, the function is obviously not a sine function; there are quite big fluctuations in it, so it can lead to even greater differences. 4) With an acceleration of 1000, the SCV should be at its maximum speed immediately. So the only way acceleration can factor in is through the sudden boost at the beginning, which might be different at different angles. 5) Yes, I can. In fact, that is exactly what I did. Workers always spend 32 ticks (2 gs) in the Refinery, so that can't be the source of the difference. Also, in one particular case that I observed, the SCV travelled slightly more in slightly less time than in the other direction. This leaves only the possibility of the SCV moving faster in certain directions than in others. I hope I managed to answer your questions. If you are still interested, I can share the test map I used, so you can try these for yourself. Thanks! Regarding 3, the effect you refer to exists, but is second order, in the sense that small changes in speed/acceleration will give a small^2 contribution to the travel time. Your difference in travel time the first second is around 4%, meaning that the expected total difference in time in a cycle will of the order 4%^2 which is nowhere enough to explain the difference in mining rate you see. Increase in speed and acceleration should give the same effect on mining time, as distance traveled is linear with both. All in all, I don't think excluding other possibilities and then assuming the last one is the reason is enough. Specially when the last one also doesn't show nearly enough difference to explain the mining rate. If acceleration is indeed the difference, it should be easy for you to directly observe it with your data, which would give a much better case for your point.
For the reasons I already mentioned, the only possible reason is that the SCV moves faster in certain directions. This is pure logic, there can't be any other case.
The thing is, I assumed moving faster means greater max. velocity or acceleration, as these are the parameters that should describe the unit's movement. This also assumes the basic laws of physics are true.
However, as you point out, the difference in acceleration does not seem great enough to cause a difference that great in travelling time/distance travelled in given time. In fact, I did try to calculate back the acceleration values from the measured distance values, and those seemed to be very different in different situations, confirming the suspicion that much greater differences in acceleration values would be required to cause this phenomenon (I can approximately determine the acceleration from the tick-by-tick coordinates).
This leads me to believe that the SCV does not follow move with a constant acceleration, as it should, but rather starts with a boost, as I already said. How great this boost is may also depend on the angle of the unit, and this, combined with the difference in speed and acceleration (which do exist, that is fact) may cause the difference in travelling time/distance travelled in given time.
To sum up, excluding other possibilities and then assuming the last one is the reason is enough, if you consider all possibilities, which I might not have.
|
Yes. You thought you has excluded all other possibilities, yet your experiments didn't show the expected difference in the last factor.
What you SHOULD do at that point is to realise that you must have missed something somewhere, not publish your results as if the last experiment had confirmed your hypothesis.
But I'm overly critical, sorry. I can't expect scientific rigour on a gaming forum. Great work collecting data anyway!
|
|
|
|
|
|
EPT
