Acceleration values

I don’t know if there’s a thread where the actual values for Acceleration are mentioned. Here’s what I’ve found in testing though.

Every 2 points in Acceleration for a ship displays as 1 point in-game on the Player Info dialog, and corresponds to a rate of change of Speed equal to 1 point per second.

Recall that each point in Speed represents 0.01 pixels per frame, and there are 30 frames per second. Thus every point in Accel (which would display as half a point if half-points would display) gives an acceleration of (1/6000) pixels per frame², or 0.15 pixels per s². For a more useful figure, every 20 points in Accel (which displays as 10 points) gives 0.1 pixels per frame per second, which is 3 pix/s². So 200 points in Accel gives 1 pixel per frame per second, or 30 pix/s².

A ship with Speed 300 and Accel 300 (which displays as 150 in-game) will take 2 seconds, or 60 frames, to reach max speed from a standstill.

Note: any pilot that is not on strict play will have a bonus of 50% more speed than displays in-game. Thus a non-strict play pilot in a ship with 300 Speed and 300 Accel will actually have 450 speed despite what is displayed, so it will take 3 seconds, or 90 frames, to reach max speed from a standstill.

With Speed S and Accel A, the number of frames F that it takes to reach max speed from a standstill is given by F = 60S/A. If you want the time T in seconds, use T = 2S/A.

If you want it to take F frames to reach Speed S from a standstill, a ship needs Accel given by A = 60S/F. If instead you give the time T in seconds then A = 2S/T.

Finally, there is one other thing besides ships in the game that accelerates, namely Freeflight Rockets. I have not been able to nail down exactly how fast they accelerate, but I have a pretty good idea. From my tests, a rocket takes approximately a constant amount of time to transition from its initial speed to its final speed. Perhaps due to flaws in my testing method, it seems to take slightly longer when the rocket has to go through a greater speed change, but not much longer.

When the speed change is around 200, it takes about 3s. When the speed change is around 1000, it takes about 3.5s. When the speed change is around 10000, it takes about 4.5s. I expect that my low-speed-change tests actually underestimate the time, because once the rocket is pretty close to the final speed it can be difficult to tell exactly when it reaches that speed. I timed how long it took until the rocket appeared to reach a constant speed, which through magic of my testing methodology was always exactly the speed of my ship at the time, and I had circular range rings around my ship so I could see exactly how far away the rocket was and thus judged when it stopped getting closer.

If I had to put forth an hypothesis, I’d say the freeflight rocket uses an Accel equal to half its speed, so the total time of acceleration is always 4 seconds (120 frames). But this could be off by quite a bit for a number of reasons. If you have any ideas for more accurate testing methods, please let me know.

Further testing reveals that rockets do not accelerate at a constant rate. My new hypothesis is as follows.

Let v i be the current velocity of the rocket, and let v f be the final velocity the rocket will accelerate toward. Then the next frame the rocket will have velocity v i+1 = c v i + (1-c) v f, for some constant c. My tests put c somewhere most likely between 0.95 and 0.97.

If this model is correct, it means that for a rocket launched with initial velocity v 0 and accelerating toward final velocity v f, its velocity after n frames will be v n = cn v 0 + (1-cn) v f.

Note that these are vector equations. However, they separate into components exactly as expected, so each component follows the same equation. In other words, if each velocity is written as v = x î + y ĵ , then as each frame takes place we’ll have xi+1 = cxi + (1-c)xf, and the same for y. Similarly, on the nth frame xn = cnx0 + (1-cn)xf, and the same for y.

Also note that the final velocity of the rocket is equal to its speed (as given by its weapon resource) pointing in the direction it was facing at launch.

If my equations seems accurate after further tests, I’ll try to nail down the exact value of c.

Here is my latest testing method. I take an inertialess ship and give it two weapons with speed 0. One is a homing missile and one is a freeflight rocket. Both fire with the primary trigger, they use the same exit point and have the same graphic. I accelerate to top speed, tap the trigger once, then slow to a stop and measure the distance between the two shots in pixels after the rocket comes to a halt.

That distance appears to grow linearly with my ship’s initial speed. When my speed is 1000, the two shots end up around 106 pixels apart. When my speed is 2000, they end up 212 pixels or so apart. When my speed is 500, they end up about 53 pixels apart.

Here are the predictions from my model, when the rocket travels in a straight line:

The rocket will travel d0 = 0 pixels when it first appears on screen. Each subsequent frame, the total distance in pixels the rocket will have traveled from its launch point is di+1 = di + vi/100. Recall that vi = civ0 + (1-ci)vf.

Together these reveal dn = d0 + (v0 + v1 + v2 + ⋯ + vn-1)/100 = d0 + ((1 + c + c2 + ⋯ + cn-1)(v0-vf) + nvf)/100.

That sum of powers of c can be collapsed by multiplying by (1 - c)/(1 - c), which yields dn = d0 + ((1 - cn)/(1 - c))(v0 - vf)/100 + nvf/100. Note that a homing missile with the same speed as the rocket will travel, after n frames, a total of nvf/100 pixels. So the distance between the two after n frames is just kn = dn - nvf/100 = d0 + ((1 - cn)/(1 - c))(v0 - vf)/100.

Now plugging in d0 = 0 and vf = 0 we find kn = (v0/100)(1 - cn)/(1 - c). Then taking the limit as n grows without bound, and assuming 0 ≤ c < 1 so that cn → 0, we see k = v0/(100*(1 - c)). Thus the distance does grow linearly with initial speed, just as observed.

Solving that last equation for c we find c = 1 - (v0/100)/k. Plugging in the first experimental value of k = 106 for v0 = 1000 gives c = 1 - 10/106 ≈ 0.90566. This is somewhat lower than my previous guess, but is derived from more accurate measurements, namely those of distance rather than time. My next test will provide exact pixel measurements, and I will take multiple samples at each speed and utilize statistical regression.

More precise experiments reveal that if my model is correct then c = 0.9. My confidence on that number is quite high.

We may calculate how long this model predicts it should take for a shot to get close enough to its final velocity that the difference is within 1 pixel per second. Starting with vn = cnv0 + (1 - cn)vf and substituting v0 = 0 we have vn = (1 - cn)vf. Plugging in vn = vf - 100/30 we get 10/3 = cnvf. Then n = ln(10/(3vf) / ln. Using vf = 1000 and c = 0.9 we see n = ln(1/300) / ln(0.9) ≈ 54.136. This is only about half the number of frames I observed it to take for the shot to appear at rest when flying at the same speed as the weapon’s max speed.

I’m not sure what causes that discrepancy. Perhaps my model is wrong. Perhaps some rounding occurs every frame, and that accumulates to leave the weapon traveling faster than it would if full-precision calculations were used.

But regardless of all that, my distance-measuring experiments were definitive. When a rocket and a missile both with speed v are fired simultaneously from a ship at rest relative to the starfield, the missile will get ahead of the rocket by an amount approaching v/10 pixels.

If/when I have time/feel like it, I may run further tests to check how these numbers change based on the speed of the launching ship, and possibly the relative directions of the rocket and its initial motion.

This post has been edited by Qaanol : 31 July 2011 - 04:25 PM

It would be nice to dig around in the guts of the engine and see exactly how this is coded. But, I salute your commitment and enthusiasm in figuring this out!

I am now extremely confident in my model. Every frame a rocket’s velocity is adjusted to be 0.9 times its previous velocity plus 0.1 times its target velocity.

v i+1 = 0.9 v i + 0.1 v f

Thus on the nth frame,

v n = 0.9n v 0 + (1 - 0.9n) v f

This gives straight-line distance traveled equal to

dn = nvf + 10(1 - 0.9n)(v0 - vf)/100

Or, at least, something extremely close to that. The predictions appear to be off by about 2 pixels, which I suspect may be due to rounding errors. Specifically, the predictions show the rocket should be 2 pixels further back from where it actually is, but only starting around frame 4. For the first 3 frames or so the predictions are spot-on, then they’re off by about 2 pixels for the duration.

Here is a graph of my test data, showing the actual and predicted distances between a rocket and a missile with the same top speed of 1000 fired from a ship at rest, as a function of how many frames they were allowed to fly.

Here are the data from those tests in tabular form:

frames	Measured	Predicted	diff	diff plus 2
1	11	10	1	3
2	19	19	0	2
3	28	27	1	3
4	32	34	-2	0
5	40	41	-1	1
6	44	47	-3	-1
7	51	52	-1	1
8	55	57	-2	0
9	59	61	-2	0
10	63	65	-2	0
11	66	69	-3	-1
12	69	72	-3	-1
13	70	75	-5	-3
14	74	77	-3	-1
15	76	79	-3	-1
20	85	88	-3	-1
25	92	93	-1	1
30	94	96	-2	0
35	94	97	-3	-1
40	97	99	-2	0
45	98	99	-1	1
50	98	99	-1	1
75	98	100	-2	0
100	99	100	-1	1
150	97	100	-3	-1
200	98	100	-2	0
300	98	100	-2	0

At some point I may rerun the numbers to take into account rounding at each frame, to see what that does.

This post has been edited by Qaanol : 31 July 2011 - 11:52 PM

This is awesome!

Thanks for the encouragement.

The model doesn’t quite line up with what I observe for shots launched at an angle though. The type of curve is pretty close, but the parameters end up being off by a significant amount. Notably, the rocket actually ends up going faster than its target speed, and oscillates above and below that speed.

For my tests, I made a gun that shoots at -150 inaccuracy, from an exit point off the port side of my ship, so every shot would come out facing the same direction as my ship, and moving 150º back and to the left from where I was facing. That weapon had Speed 1500, and submunitioned into a rocket with Speed 2500.

Actually, I made two different setups, identical as above, one that subbed into a rocket that made blue sparks, and one that subbed into a rocket with Count 1 that recursively submunitioned into itself and made green sparks. Firing these together showed that the paths were indistinguishable. A rocket’s motion is the same whether the rocket flies along for a while or whether it submunitions into itself repeatedly.

So I took the recursively submunitioning rocket, gave it an Explosion that is just a single pixel dot sitting in place, and fired it several times. That way there would be a dot at the location of the rocket every frame. For completeness, I made the initial gun also make such a dot to mark the origin of the rocket.

For my tests I faced directly to the right of the screen to the best of my ability. By which I mean I set up two planets 5000 pixels apart horizontally, and both at the same vertical coordinate in the system. I made a mission put an immobile ship on the planet to the right, and I landed on the planet to the left. Then I used autopilot to face directly toward the other ship. If I do it again I’ll remember to fire some turrets and guns to make sure they both go in exactly the same direction, but I didn’t think of that at the time so the result might not be exactly 150º from horizontal.

Indeed, the actual paths of the rockets start out at around 144º. The next image shows the paths and the predicted path for 150º. If I do the predictions for 144º instead, that follows a bit closer but still curves more tightly than the actual rockets.

Of course, it bears mention that there is a lot of randomness showing up somewhere. I repeated my test 12 times in the same game, without turning nor moving. All I did was fire the self-subbing rocket, wait for its explosions to appear, take a screenshot, wait for the explosions to disappear, and repeat. Even so, the initial explosion where the first shot ended (which was not a rocket, just a gun) moved around a bit. I cropped and cleaned up the screen shots, and moved them so the initial rockets all show up in the same spot. Even still, they do not follow quite the same trajectory. Perhaps some of that might be explained as the initial angle and velocity being different for some reason, seeing as they inherit those properties from the first shot and that didn’t go to the same place every time.

In any event, here are the 12 trajectories of identical rockets fired back to back, with initial angle supposed to be 150º, initial speed supposed to be 1500, final angle supposed to be 0º, and final speed supposed to be 2500, put into a gif animation:

I have no explanation for why the final few dots tend to be more than 25 pixels apart, some of them 28 or more apart, when the rocket is supposed to approach a speed of 2500, meaning 25 pixels per frame.

All I can think is perhaps the game is performing some more complicated procedure that approximates the results of my formula, but with some randomness and/or rounding that occurs.