|
Hi everyone,
I was curious about how the movement of the units in SC2 works compared to the actual kinematics laws, so I made several simulations using the Map Editor. I focused my attention on acceleration and deceleration so I didn’t expect to find big discrepancies besides those ones generated by the discretization of the time scale. However, I found something really weird, at least to me.
SETTING UP THE TEST ENVIRONMENT
+ Show Spoiler +The problem of the measure+ Show Spoiler +In order to test the mechanics of motion I first had to find a way to measure distances and timings as best I could. About distances, it’s not too hard to be very accurate because the Map Editor contains all the data required for the job. Timings, on the contrary, could be very difficult to measure because the SC2 build-in clock has only minutes and seconds, and using a chronometer didn’t seem a viable solution to me for the following reasons: - I wanted to carry out my tests using the “faster” game speed in order to reduce the duration of the simulations and also to reproduce a standard-game situation. Perform the conversion between “SC2-faster” seconds and “real-world” seconds would have introduced another source of approximation
- if you try to measure something that is smaller than a second, the normal eye-hand reaction time became comparable with the measure itself, so the error can be huge and (worse) it is not systematic.
So I solved the problem spreading the error of one single timing measure over many movement cycles; the easiest way to obtain this result is to use the resource harvesting cycle of a worker. Carrying five minerals (standard patch) per round-trip, a worker makes 300 times the exact same path. This means that can I distribute my error (one second at worse) over the whole 300 harvesting cycles obtaining a precision of 1/300 seconds for the single round-trip. Since during the harvesting cycle the worker cover the same distance two times (back and forth), we actually have a precision of 1/600, which is more than enough. I chose to use Metalopolis for my tests. There is no specific reason; it’s only one of the most popular maps and one of my favorite. About the race, I picked up Terrans because the Command Center can fly, so it can be easily positioned everywhere on the map, even during the simulation if necessary. I then modified the properties of the SCV as follows: - InnerRadius = 1
- Radius = 1
- Speed = 16
I used the 9 o-clock base, positioning the Command Center 10 tiles far from the mineral patch closer to the vespene geysers. ![[image loading]](http://i.imgur.com/hPuz4.jpg) With this set-up the SCV path is 8 tiles long (10 – 2 * SCV radius). Why 16 for speed and 8 for distance? Well, just to make things simpler, nothing else. Both numbers are a power of 2 (and no other factors), they are not too big and, at the same time, they “fit” well in the equations in the sense that we have fewer decimals to take care of.
ACCELERATION TEST
+ Show Spoiler +For the acceleration test I set the deceleration of the SCV to 1000 in order to simplify the analysis taking off the deceleration from the equation. I made 32 simulations, increasing each time the acceleration by one, from 1 to 32. No other parameters were modified. Just a bit of math+ Show Spoiler +We have the distance (D), the top speed (Vmax) and the acceleration (a). We start calculating the time and the space the SCV needs to reach the top speed: t_Vmax = Vmax / a s_Vmax = Vmax^2 / (2 * a) Now, if D => s_Vmax then the SCV will have the space to accelerate to Vmax and eventually to move farther at the same speed; on the contrary, if D < s_Vmax then the SCV will not be able to reach Vmax. So the theoretical travel time will be: t_travel = t_Vmax + (D – s_Vmax) / Vmax D => s_Vmax t_travel = SQRT(2 * D / a) D < s_Vmax Example+ Show Spoiler +With a = 4, D = 8:
t_Vmax = 16 / 4 = 4 sec
s_Vmax = 16^2 / (2 * 4) = 32 tiles
8 < 32 (D < s_Vmax) so t_travel = SQRT(2 * 8 / 4) = 2 sec
The total amount of time for a single harvesting cycle is: t_cycle = t_travel * 2 + t_harv where t_harv = 3.286 is the time spent by the SCV to collect the minerals: 2.786 harvest time plus 0.5 return delay (see mineral field’s behavior on Map Editor). The total time to deplete the mineral patch will be: t_1500 = t_cycle * 300 The following figure shows the results of the acceleration test: ![[image loading]](http://i.imgur.com/sojTZ.jpg) The theoretical curve (in blue) and the measured data (in red) are substantially the same. The mean difference between to two sets of data is ~0.013 sec (about 0.7%) and the standard deviation is ~0.017.
DECELERATION TEST
+ Show Spoiler +For the deceleration test I run two set of simulations: the first one with the acceleration of the SCV set to 5, the other one with the acceleration set to 10. This time I made 33 simulations (for each of the two sets), increasing each time the deceleration by one, from 0 to 32. No other parameters were modified. Results analysisDidn’t knowing how exactly the deceleration works in SC2, my intention was to try to figure it out running these tests. In the following figure you can see the results: ![[image loading]](http://i.imgur.com/OV7Xb.jpg) The blue curve is the one obtained with acceleration equals to 5, while for the red one the acceleration was 10. For both series, the value represented is: t_travel = ((t_1500 / 300) – t_harv) / 2 (see the acceleration math section for reference) These are the data I can’t really understand. Besides the huge variance, there are two big things that bother me: - what zero deceleration means? It is linked neither to the lowest nor to the highest travel time
- how is it possible that the curves seem, for the most part, like a saw-tooth wave? If the deceleration is always increasing how can the travel time increase, decrease and then increase again?
CONCLUSIONS
+ Show Spoiler +The conclusions I draw from this analysis are the following.
The acceleration seems to be exactly how it should be; measured data curve practically overlaps the theoretical curve. Great.
For the deceleration things are different. The curves have an overall trend but their development is quite erratic. I tried to find an explanation, but really nothing came to me; nothing seems to correlate with it.
Am I missing something? Does anybody have any idea why the deceleration works in this way?
If anyone is interested in this topic, I can post my actual measures in tabular format too.
Please forgive me if my English is not so good, feel free to help me out on this matter too  . Thanks to all the TL community!
|
This is very thorough, great write up!
I do have one idea to explain the deceleration issue, although it's simply speculation. I think the erratic data is better explained by the way the game treats the harvesting mechanic, rather than the difference in the unit's movement speed. The frame at which the harvesting will begin could be decided by some proximity to the mineral, which is rounded and therefore only somewhat determined by the worker's deceleration. I would suggest running some tests on units on patrol to see if the same issue arises.
You did great work on this, I'm really interested on seeing how people will put this information to use.
|
I'd be interested to see this done with a flying unit instead of an SCV. I imagine that *maybe* there is some anti-collision path-finding that takes over, and that the saw tooth we see is the variance in how that path-finding works each time. I don't think its unreasonable that the path-finding in this type of situation would be fast rather than consistent.
|
Interesting find, definitely feels strange.
The only explanation that really comes to mind is that something else determines the deceleration instead of the current speed from which the decelarion begins from. But if that's the case why wouldn't acceleration be affected from it as well, since it seems to be perfectly normal.
Other thing (even though I think it's very unlikely) that could be possible is that the game makes rough estimates when calculating deceleration in order to not stress processor too much, but I don't think that would make much of a difference in processor usage. That could make the results like in the OP but it's unlikely, as they would be random instead of saw-tooth shape. Just throwing the idea out there although I think it's not the case.
Like Selenus said, would be interesting to see if this also occurs on units on normal movement command(or patrol) instead of mining.
|
We need LaTeX to make this kind of thread more readable
|
Thank you all guys.
On August 24 2011 04:50 Selenus wrote:
This is very thorough, great write up!
I do have one idea to explain the deceleration issue, although it's simply speculation. I think the erratic data is better explained by the way the game treats the harvesting mechanic, rather than the difference in the unit's movement speed. The frame at which the harvesting will begin could be decided by some proximity to the mineral, which is rounded and therefore only somewhat determined by the worker's deceleration. I would suggest running some tests on units on patrol to see if the same issue arises.
You did great work on this, I'm really interested on seeing how people will put this information to use.
Thank you. I thought about using the patrol command, but I don't know if the units actually decelerate when they bounce back and forth when they are on patrol. The big issue I have with patrol is that it could be difficult to make a path with a specific length in each test run; moreover, counting the iteration is more difficult (I won’t have a mineral patch doing it for me ). However I’ll try to figure out a way to perform this kind of test too.
On August 24 2011 04:55 Clues wrote:
I'd be interested to see this done with a flying unit instead of an SCV. I imagine that *maybe* there is some anti-collision path-finding that takes over, and that the saw tooth we see is the variance in how that path-finding works each time. I don't think its unreasonable that the path-finding in this type of situation would be fast rather than consistent.
The variance seems too huge to me to be a fluctuation in the path-finding algorithm, considering the perfect alignment of the acceleration data (as Pochtli pointed out). I’m planning to run some test using non only integer values for the deceleration and see what the results are.
|
Ahhh this looks really interesting. I wish I had the patience 
|
This kind of thing is what separates Starcraft from other video games. Really interesting work. Shows us that there are many unknowns about the game that we have yet to explore
|
On August 24 2011 05:33 Torik wrote:Thank you all guys. Show nested quote +On August 24 2011 04:50 Selenus wrote:
This is very thorough, great write up!
I do have one idea to explain the deceleration issue, although it's simply speculation. I think the erratic data is better explained by the way the game treats the harvesting mechanic, rather than the difference in the unit's movement speed. The frame at which the harvesting will begin could be decided by some proximity to the mineral, which is rounded and therefore only somewhat determined by the worker's deceleration. I would suggest running some tests on units on patrol to see if the same issue arises.
You did great work on this, I'm really interested on seeing how people will put this information to use. Thank you. I thought about using the patrol command, but I don't know if the units actually decelerate when they bounce back and forth when they are on patrol. The big issue I have with patrol is that it could be difficult to make a path with a specific length in each test run; moreover, counting the iteration is more difficult (I won’t have a mineral patch doing it for me ). However I’ll try to figure out a way to perform this kind of test too. Show nested quote +On August 24 2011 04:55 Clues wrote:
I'd be interested to see this done with a flying unit instead of an SCV. I imagine that *maybe* there is some anti-collision path-finding that takes over, and that the saw tooth we see is the variance in how that path-finding works each time. I don't think its unreasonable that the path-finding in this type of situation would be fast rather than consistent. The variance seems too huge to me to be a fluctuation in the path-finding algorithm, considering the perfect alignment of the acceleration data (as Pochtli pointed out). I’m planning to run some test using non only integer values for the deceleration and see what the results are.
That's a great point about patrol. If you have the time on you hands, what you could do is place on hold position some distance apart, then queue up move commands for a third unit so he bounces back and forth. I'm pretty sure that would cause the unit to accelerate and decelerate normally, while keeping the distance consistent. I don't blame you if you don't want to sit there queuing up move commands though .
|
Your deceleration figures are seriously strange. Did you redo some of the measurements to get an idea of how large your standard deviation is? Though when comparing this with the first set of data, which theoretically should have similar measurement errors, that probably is not the reason for this strange behaviour, it can not hurt to rule it out explicitly.
What is important is that both the graphs have a similar shape, with spikes and valleys at the same points. I think it is safe to assume that the jumpiness of that graph is a result of some variable not having enough decimals to give a smooth behaviour. The objective should now be to find out which one that is. Because if one only looks at the average of that graph, it behaves roughly as to be expected.
Thus, i propose specific tests to monitor if deceleration is always that jumpy, or only under specific circumstances. One of the main offenders in your tests in my opinion is that you seem to always work with non-completed accelerations, because as far as i understood you use a pretty short distance. It might be interesting to find out whether this behaviour ceses to exist when you have specific seperate acceleration/deceleration movements, compared to what you have now. Because now a higher deceleration also means that the SCV can spend a longer time accelerating, and if either time or distance do not have enough decimals, this would explain that jumpy behaviour. I might do a test of that, but right now it is far too hot here.
|
They certainly are weird results. 
It might be interesting to retest the deceleration with acceleration set to 32, to see if it does have anything to do with the fact that the scvs may not be at their full speed. Or even retesting while varying the acceleration if you really have the inclination.
|
Selenus:
Unfortunately, this either doesn’t work. The SCV do not decelerate when you set a multi-point path.
On August 24 2011 06:01 Simberto wrote:
Your deceleration figures are seriously strange. Did you redo some of the measurements to get an idea of how large your standard deviation is? Though when comparing this with the first set of data, which theoretically should have similar measurement errors, that probably is not the reason for this strange behaviour, it can not hurt to rule it out explicitly.
What is important is that both the graphs have a similar shape, with spikes and valleys at the same points. I think it is safe to assume that the jumpiness of that graph is a result of some variable not having enough decimals to give a smooth behaviour. The objective should now be to find out which one that is. Because if one only looks at the average of that graph, it behaves roughly as to be expected.
Thus, i propose specific tests to monitor if deceleration is always that jumpy, or only under specific circumstances. One of the main offenders in your tests in my opinion is that you seem to always work with non-completed accelerations, because as far as i understood you use a pretty short distance. It might be interesting to find out whether this behaviour ceses to exist when you have specific seperate acceleration/deceleration movements, compared to what you have now. Because now a higher deceleration also means that the SCV can spend a longer time accelerating, and if either time or distance do not have enough decimals, this would explain that jumpy behaviour. I might do a test of that, but right now it is far too hot here.
Yes, I run the test several time using the same data in order to see I was making some huge mistake, but the results were consistent, each time I obtained the same timings.
The only measure which is subject to error is the time. As I said, on this one I have a precision of 1/600 of seconds at worst, so it should be sufficient to have a smooth behavior. The rest of calculations were made without any approximation.
You have certainly a good point about the non-completed accelerations; I’ll surely do what you and IronDoc suggest. I'll eventually also increase the amount of minerals of the patch to increase the precision on the timings. Thank you.
Just to add another piece of information about the “zero deceleration” issue, this does not mean that the unit does not decelerate. I checked it running two SCV on a parallel course: one of them was sent to mine while the other one was instructed to pass over and go to a point beyond the mineral patch. I did this with a regular custom game, without the Map Editor. Saving the replay, slowing it down and zooming in, you can see that the mining SCV actually starts to slow down a little bit before reaching the mineral patch, while the other one continues its course.
Besides, even if zero does not mean “no-deceleration” (actually it’s the opposite, the more the deceleration the less the unit slows down) this coefficient has to be related in some way to physics concept of deceleration.
|
Actually, i would ignore the zero at the moment, and try to get a good idea of how the rest of the deceleration works. The zero seems to do something strange, so it is more important to get the general idea rather than the special cases.
Also, there are a lot of things this deceleration coeffizient could mean, depending on how deceleration works. For example, it is not even totally clear that it works physically sound. It could be that units decelerate to zero in the same time or distance no matter what their starting velocity is.
Also, i noticed that i suck with the map editor, so if you get data, could you post your raw data so one can do some calculations with it?
|
United States12235 Posts
Is there a way to write a script in a map that will mimic user inputs so you can get some more accurate results while removing the element of human error but still producing repeatable deceleration actions? I know very little about the editor unfortunately.
I will say that I believe deceleration is not constant between workers and, for example, air units. Deceleration is also not constant between harvesting workers and workers under a Move command (compare "sockfolding" methods for optimized mineral return that existed in beta and that still exist now). If you could generate such a script, you would be able to get some more predictable results between Move commands for workers and Move commands for air units.
|
On August 24 2011 06:55 Simberto wrote:
Actually, i would ignore the zero at the moment, and try to get a good idea of how the rest of the deceleration works. The zero seems to do something strange, so it is more important to get the general idea rather than the special cases.
Also, there are a lot of things this deceleration coeffizient could mean, depending on how deceleration works. For example, it is not even totally clear that it works physically sound. It could be that units decelerate to zero in the same time or distance no matter what their starting velocity is.
Also, i noticed that i suck with the map editor, so if you get data, could you post your raw data so one can do some calculations with it?
I agree. It's best to leave the zero-case out.
Yes I could post the data, but just now I'm running a simulation with acc=32 and something is wrong. The time for trip from the patch to the CC is not the same from the CC back to the patch (I can see it right now watching the SCV). It seems that the SCV just does not decelerate and stop to deliver the minerals; the CC seems to be just like a point in its path from the mineral patch and back again (a kind of patrol). I didn’t notice this either using the default data in custom games or during my tests; the difference was absolutely not evident.
So I think that, besides the overall timings measure, the other data are no longer significant with these new information. I fear I have still a lot of work to do to try to find the solution .
|
On August 24 2011 07:27 Excalibur_Z wrote:
Is there a way to write a script in a map that will mimic user inputs so you can get some more accurate results while removing the element of human error but still producing repeatable deceleration actions? I know very little about the editor unfortunately.
I will say that I believe deceleration is not constant between workers and, for example, air units. Deceleration is also not constant between harvesting workers and workers under a Move command (compare "sockfolding" methods for optimized mineral return that existed in beta and that still exist now). If you could generate such a script, you would be able to get some more predictable results between Move commands for workers and Move commands for air units.
I'm sorry but I'm not so familiar with the Map Editor to write a script. My knowledge is limited to the units data.
Just like you said and I find out just a few moments ago, the movements from the CC to the minerals and from the minerals to the CC do not work in the same way.
|
United States12235 Posts
Hey what about this? I think deceleration might be the same between Move and Attack (not 100% sure but it seems to be pretty close). What if you queued worker Attack commands back to back from one side to another? Again the most elegant solution would be to just constantly spawn units to be attacked whenever one dies using the editor, but you could just use Zerglings in two parallel lines or whatever instead.
|
On August 24 2011 07:33 Torik wrote:Show nested quote +On August 24 2011 06:55 Simberto wrote:
Actually, i would ignore the zero at the moment, and try to get a good idea of how the rest of the deceleration works. The zero seems to do something strange, so it is more important to get the general idea rather than the special cases.
Also, there are a lot of things this deceleration coeffizient could mean, depending on how deceleration works. For example, it is not even totally clear that it works physically sound. It could be that units decelerate to zero in the same time or distance no matter what their starting velocity is.
Also, i noticed that i suck with the map editor, so if you get data, could you post your raw data so one can do some calculations with it? I agree. It's best to leave the zero-case out. Yes I could post the data, but just now I'm running a simulation with acc=32 and something is wrong. The time for trip from the patch to the CC is not the same from the CC back to the patch (I can see it right now watching the SCV). It seems that the SCV just does not decelerate and stop to deliver the minerals; the CC seems to be just like a point in its path from the mineral patch and back again (a kind of patrol). I didn’t notice this either using the default data in custom games or during my tests; the difference was absolutely not evident. So I think that, besides the overall timings measure, the other data are no longer significant with these new information. I fear I have still a lot of work to do to try to find the solution .
That would not really be a problem, it would just mean that you only have one acc/dec phase per round instead of two, meaning you would have to redo some calculations, if it really keeps the same velocity.
However, obviously best would be if someone who knew how to do that would produce a script that either makes the SCV go to some place, with usual acc/dec behaviour, or return the exact time with good accuracy (1/10th or 1/100th of a second) for the time spend travelling.
Another important thing is to really look at when the units do decelerate, and when they simply ignore all that.
So far:
Patrols keep speed
(Delivering minerals maybe also keeps the speed up)
Queued move orders decelerate at each point
Mining decelerates
|
On August 24 2011 07:45 Excalibur_Z wrote:
Hey what about this? I think deceleration might be the same between Move and Attack (not 100% sure but it seems to be pretty close). What if you queued worker Attack commands back to back from one side to another? Again the most elegant solution would be to just constantly spawn units to be attacked whenever one dies using the editor, but you could just use Zerglings in two parallel lines or whatever instead.
I don't think that there are different "type" of deceleration related to different commands (Move, Attack, Patrol). In my opinion all is related to the path that the unit has to follow. If it has to go simply from one point to another one, then it accelerates and decelerates. Otherwise, if it has to move following more points (or either two only points but back and forth) than the deceleration works in another way.
At this point, the harvesting-movement seems to be a special case because in order to mine the SCV needs to stop (so to decelerate), while when it delivers its cargo it can just slow down but does not need to stop completely.
|
Interesting.
did u forget to add ur integration constant ?
E = M*C^2
Will this equation maybe help?
|
On August 24 2011 08:12 MMXMoto-X17 wrote:
Interesting.
did u forget to add ur integration constant ?
E = M*C^2
Will this equation maybe help?
How incredibly smart and funny. Please share more of your infinite wisdom with us.
|
On August 24 2011 07:48 Simberto wrote:Show nested quote +On August 24 2011 07:33 Torik wrote:On August 24 2011 06:55 Simberto wrote:
Actually, i would ignore the zero at the moment, and try to get a good idea of how the rest of the deceleration works. The zero seems to do something strange, so it is more important to get the general idea rather than the special cases.
Also, there are a lot of things this deceleration coeffizient could mean, depending on how deceleration works. For example, it is not even totally clear that it works physically sound. It could be that units decelerate to zero in the same time or distance no matter what their starting velocity is.
Also, i noticed that i suck with the map editor, so if you get data, could you post your raw data so one can do some calculations with it? I agree. It's best to leave the zero-case out. Yes I could post the data, but just now I'm running a simulation with acc=32 and something is wrong. The time for trip from the patch to the CC is not the same from the CC back to the patch (I can see it right now watching the SCV). It seems that the SCV just does not decelerate and stop to deliver the minerals; the CC seems to be just like a point in its path from the mineral patch and back again (a kind of patrol). I didn’t notice this either using the default data in custom games or during my tests; the difference was absolutely not evident. So I think that, besides the overall timings measure, the other data are no longer significant with these new information. I fear I have still a lot of work to do to try to find the solution . That would not really be a problem, it would just mean that you only have one acc/dec phase per round instead of two, meaning you would have to redo some calculations, if it really keeps the same velocity. However, obviously best would be if someone who knew how to do that would produce a script that either makes the SCV go to some place, with usual acc/dec behaviour, or return the exact time with good accuracy (1/10th or 1/100th of a second) for the time spend travelling. Another important thing is to really look at when the units do decelerate, and when they simply ignore all that. So far: Patrols keep speed (Delivering minerals maybe also keeps the speed up) Queued move orders decelerate at each point Mining decelerates
The point is that since it is not clear how it works it's difficult to isolate a single component. The acceleration seems ok, but there are two different deceleration-effects (approaching minerals and CC). We have two unknown factors into one equation, so the total amount of time of the harvesting cycle could not be used.
I think I'll follow Excalibur_Z and your suggestion about writing a script. I need a better testing environment. I'm reading some documentation about the Galaxy language for the Map Editor. It should not be too hard to write the scripts I need.
|
On August 24 2011 08:37 Torik wrote:Show nested quote +On August 24 2011 07:48 Simberto wrote:On August 24 2011 07:33 Torik wrote:On August 24 2011 06:55 Simberto wrote:
Actually, i would ignore the zero at the moment, and try to get a good idea of how the rest of the deceleration works. The zero seems to do something strange, so it is more important to get the general idea rather than the special cases.
Also, there are a lot of things this deceleration coeffizient could mean, depending on how deceleration works. For example, it is not even totally clear that it works physically sound. It could be that units decelerate to zero in the same time or distance no matter what their starting velocity is.
Also, i noticed that i suck with the map editor, so if you get data, could you post your raw data so one can do some calculations with it? I agree. It's best to leave the zero-case out. Yes I could post the data, but just now I'm running a simulation with acc=32 and something is wrong. The time for trip from the patch to the CC is not the same from the CC back to the patch (I can see it right now watching the SCV). It seems that the SCV just does not decelerate and stop to deliver the minerals; the CC seems to be just like a point in its path from the mineral patch and back again (a kind of patrol). I didn’t notice this either using the default data in custom games or during my tests; the difference was absolutely not evident. So I think that, besides the overall timings measure, the other data are no longer significant with these new information. I fear I have still a lot of work to do to try to find the solution . That would not really be a problem, it would just mean that you only have one acc/dec phase per round instead of two, meaning you would have to redo some calculations, if it really keeps the same velocity. However, obviously best would be if someone who knew how to do that would produce a script that either makes the SCV go to some place, with usual acc/dec behaviour, or return the exact time with good accuracy (1/10th or 1/100th of a second) for the time spend travelling. Another important thing is to really look at when the units do decelerate, and when they simply ignore all that. So far: Patrols keep speed (Delivering minerals maybe also keeps the speed up) Queued move orders decelerate at each point Mining decelerates The point is that since it is not clear how it works it's difficult to isolate a single component. The acceleration seems ok, but there are two different deceleration-effects (approaching minerals and CC). We have two unknown factors into one equation, so the total amount of time of the harvesting cycle could not be used. I think I'll follow Excalibur_Z and your suggestion about writing a script. I need a better testing environment. I'm reading some documentation about the Galaxy language for the Map Editor. It should not be too hard to write the scripts I need.
Good call, make sure you document your findings in the liquidpedia database.
|
|
|
You are absolutely right, Torik. I assumed you meant that there is simply no deceleration at the the CC, but obviously you can't really tell that just by bare eye. The ideal test would be one with large accuracy while minimizing the amount of movements involved. So you should probably avoid any repeated movements, and any interaction with other objects. But i don't think you can get good enough data for the time without repeating the movement some times. Also, when you change your method you need to find another way of measuring distance if you move between unspecific points instead of minerals and CC.
However, if you don't find a good way with scripting, one could test the behaviour at the CC seperately, for example by comparing the movement of one SCV that moves double the amount of spaces and comparing it with one that delivers minerals to a CC half the amount of space away. So far my theory is that there are two types of movement change, one with deceleration, and one where the object simply keeps its movement speed, but i have absolutely no proof at all for that.
Don't you have something more useful to do than coming in here and spouting unrelated nonsense?
|
Just a little update.
I'm running several tests this evening and the big issue seems to be the top speed of the unit. The value I used for my previous simulations (16) is by far greater than the top speed of any units, which for the most part are below 4.5 (the interceptor is the fastest with 7.5).
My first impression is that the engine is not able to handle high speed and a deceleration value different from zero, but I need more data to be sure (or at least "almost" sure...).
I also verified that the Commend Center is not treated like a way-point in the mineral gathering cycle. The anomaly I observed yesterday should be another side effect of the speed too high of the SCV.
About the script for Map Editor, I haven't found yet a method to simulate the user input (mouse or keyboard).
|
I don’t know if there is someone still interested in this argument. Anyway, I did a lot of tests and research on Internet about movement (something I should have done earlier) and I think I found why things appeared so odd.
For what I read, SC2 should use a steering behavior algorithm to control the path and the movement of the units; in particular, in order to simulate the slowing down of a unit when it’s reaching its destination, the arrival steering behavior is used to calculate when the unit needs to start to decelerate. You can find more information about this at http://www.red3d.com/cwr/steer.
So I think that, partially like I wrote in the previous post based only on empirical observation, the system messed up because the speed was too high compared to the distance between the mineral patch and the Command Center. The engine probably couldn’t calculate in the right way how to decelerate the unit properly, so other effects took the control of the movement.
Another confirmation I obtained is that the deceleration value acts like a tweak parameter rather than the actual deceleration; this also explains why all units (besides Motherships and High Templars) have a deceleration value of zero.
Since the units decelerate before stopping, there is for sure a deceleration value defined in some place. May be it is buried into the Map Editor and I haven’t found it yet, or it is simply not available. In this last case I’ll have to figure out a way to measure it.
|
Interesting find, thanks for the update.
So if I understand correctly, things only appeared odd because of the high speed, but in reality they do make sense? Please forgive my lack of scientific knowledge.
|
There is no such thing as deceleration. Only negative acceleration.
|
but can you make air units do a moving shot that's not ridiculous?
|
On August 26 2011 05:48 kushm4sta wrote:
There is no such thing as deceleration. Only negative acceleration.
I think you spend too much in in academia my techie friend. Let's talk practically and not worry about such trivial semantics.
|
On August 26 2011 05:45 AlBundy wrote:
Interesting find, thanks for the update.
So if I understand correctly, things only appeared odd because of the high speed, but in reality they do make sense? Please forgive my lack of scientific knowledge.
Yes, it seems so. In some way the algorithm uses all the parameters (acceleration, top speed and deceleration) to establish how much space a unit needs to accelerate, to move at maximum speed and to decelerate. If one or more of these data is outside a specific bound, then the algorithm does not function properly, I think mainly because other effects become stronger (such as obstacle avoidance or other described at the link I posted).
I too don't know too much on this field, I started reading on this subject just few days ago .
|
If somebody can help me make the leap from this to play....
How does a unit's acceleration affect anything at all? I hear that people complain about the warp prism acceleration, but it moves relatively slowly to begin with, how can a little acceleration change anything?
|
Here is a test you can run so you can see what I mean for "odd" and what make me think that there have to be some safety boundaries for the parameters.
Using the Map Editor set for the SCV:
- Acceleration = 16
- Deceleration = 1
- Speed = 16
- InnerRadius = 1
- Radius = 1
Now test the map, select a bunch of SCV and start to move this group around the map. Don’t make a multi-waypoint path, just click and move them towards a location. If you do this just two or three times, you should see that at some point the SCVs start to freak out when they are reaching the destination, wandering around or bouncing back and forth with each other.
|
On August 26 2011 06:10 Sir Snoopy wrote:
If somebody can help me make the leap from this to play....
How does a unit's acceleration affect anything at all? I hear that people complain about the warp prism acceleration, but it moves relatively slowly to begin with, how can a little acceleration change anything?
A warp prism has an acceleration value of 2.125 (like the observer and the voidray for example) that is quite low. It has a speed of 2.5, so it takes more than a second to reach its maximum speed.
A zealot or a stalker have an acceleration of 1000, which means that they hit the top speed almost immediately.
|
On August 26 2011 06:10 Sir Snoopy wrote:
If somebody can help me make the leap from this to play....
How does a unit's acceleration affect anything at all? I hear that people complain about the warp prism acceleration, but it moves relatively slowly to begin with, how can a little acceleration change anything?
Acceleration is important when you try to micro stuff. For example, when you try to move a mothership so that it does not get hit, while cloaking something beneath it, and the enemy comes at you from different angles. Not only is the mothership extremely slow, it also has a very low acceleration, meaning everytime you want to get away from something it takes some seconds slowly starting to move before it reaches its maximum velocity. This might be an obscure example, but it applies in the same way to every kind of action where you move and stop.
For the Warp prism, you have dropped something, the enemy comes, and you want to get away. You grab your guys and start flying, and since you have a relatively low acceleration it gives the enemy more time to hit you. For example, assuming units accelerate linearly, if you take 1 second to accelerate to your top speed, you are half a second behind the place you would be if you accelerated instantly. Which, in this case, might me where these evil stalkers shoot you in the face as opposed to chilling safely over the sea.
|
|
|
|
|
|
EPT
