Difference between revisions of "Talk:Movement (EU2012)"

From UFOpaedia
Jump to navigation Jump to search
(→‎Diagonals: Updated the correct conversion factor. All tile values are now correct and verified in-game.)
Line 15: Line 15:
 
Now, getting down to business.  The referenced [http://gaming.stackexchange.com/a/94286/35810 page here] correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point.  That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them.  The exact factor is closer to 0.667, as we will see.  In order to further narrow down the correct factor, I did some in-game testing.  I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data.  Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down).  The factor of 0.625 predicts some of the tile values but not most.  The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.   
 
Now, getting down to business.  The referenced [http://gaming.stackexchange.com/a/94286/35810 page here] correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point.  That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them.  The exact factor is closer to 0.667, as we will see.  In order to further narrow down the correct factor, I did some in-game testing.  I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data.  Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down).  The factor of 0.625 predicts some of the tile values but not most.  The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.   
  
So after trying out several different factors in an attempt to match the observed data with calculations, I narrowed down the exact factor to 0.666, with no fewer than three decimal 6’s.  Values of 0.665 or 0.667 predict most but not all of the observed data; only 0.666 predicts ALL observed straight-line and diagonal tile movement values.  Also, any number of trailing 6’s can be added without any effect on the results.  I don’t know the floating-point precision used in the game, but for calculation purposes a value of 0.666 works fine.   
+
So after trying out several different factors in an attempt to match the observed data with calculations, I narrowed down the exact factor to 0.666, with no fewer than three decimal 6’s.  Values of 0.665 or 0.667 predict most but not all of the observed data; '''only 0.666 predicts ALL observed straight-line and diagonal tile movement values'''.  Also, any number of trailing 6’s can be added without any effect on the results.  I don’t know the floating-point precision used in the game, but for calculation purposes a value of 0.666 works fine.   
  
 
It becomes apparent from these observations that the ‘intended’ scaling factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...)  In reality this ratio is an irrational number, which can’t be programmed in the game as such.  If the game could hypothetically use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility of 12.  But since 12*0.666 = 7.99, it gets rounded down to 7 for blue move and 15 for dash.   
 
It becomes apparent from these observations that the ‘intended’ scaling factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...)  In reality this ratio is an irrational number, which can’t be programmed in the game as such.  If the game could hypothetically use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility of 12.  But since 12*0.666 = 7.99, it gets rounded down to 7 for blue move and 15 for dash.   

Revision as of 09:25, 2 April 2017

Diagonals

There's a bit more to this (diagonals for instance are a puzzle for me to figure out) but the 0.625 value is close to the truth, although I've seen a lot of discussion on this.

If you set that each game square costs 1.625 and the diagonal costs 2.298 points to move then it matches the ingame results (7 squares straight, 5 squares on a diagonal).

It would be nice to have also a summary of the different items/armor and how much extra points/squares they give. Sprinter is described to add 3 extra tiles (or squares) movement, so that would correspond to 4.875 movement points, for instance. Hobbes 10:36, 8 December 2013 (EST)

The difficulty is compounded by the fact the page announces two different ratios: Multiplying the movement stat by 0.625 is equivalent of each tile costing exactly 1.6 movement; while the formula "each tile costs 1.625" is equivalent to multiplying the movement stat by about 0.615 Medinoc (talk) 16:52, 14 January 2016 (EST)


Finding the exact scaling factor for #tiles per mobility stat

The movement page (before this edit) provides a few different scaling factors in the various sections, which is inconsistent. For example, it states that for “conversion purposes” it uses a ratio of 1.625 mobility points per game tile, which corresponds to 1/1.625 = 0.615 tiles per mob point. However, in the calculation for Dashing, a factor of 0.625 was used instead of 0.615. Later, in the “diagonal movement” paragraph, a value of 1.65 is used instead of 1.625, which corresponds to yet another scaling factor of 1/1.65 = 0.606 tiles per mob point. All this is guesswork, and none of these factors correctly predict the actual movement in the game (details below).

Now, getting down to business. The referenced page here correctly states that the scaling factor has to be between 0.625 and 0.667 tiles per mobility point. That much is true because the factor of 0.625 underestimates most tile values, while 0.667 overestimates some of them. The exact factor is closer to 0.667, as we will see. In order to further narrow down the correct factor, I did some in-game testing. I counted tiles for single and double moves (dashes) for both straight and diagonal movement for mobility values between 3 and 28, and recorded the data. Then, I compared the hard data with values calculated using the scaling factors suggested on this page (fractional tile values are rounded down). The factor of 0.625 predicts some of the tile values but not most. The other two factors - 0.606 and 0.615 results in values, most of which are off by 1 or more.

So after trying out several different factors in an attempt to match the observed data with calculations, I narrowed down the exact factor to 0.666, with no fewer than three decimal 6’s. Values of 0.665 or 0.667 predict most but not all of the observed data; only 0.666 predicts ALL observed straight-line and diagonal tile movement values. Also, any number of trailing 6’s can be added without any effect on the results. I don’t know the floating-point precision used in the game, but for calculation purposes a value of 0.666 works fine.

It becomes apparent from these observations that the ‘intended’ scaling factor is a ratio of 2/3 (that is 1 tile per 1.5 mobility points), which equals 0.666(6...) In reality this ratio is an irrational number, which can’t be programmed in the game as such. If the game could hypothetically use the intended value of 2/3, instead of a truncated 0.6666…, it would result in exactly 8 blue tiles and 16 yellow tiles for a mobility of 12. But since 12*0.666 = 7.99, it gets rounded down to 7 for blue move and 15 for dash.

Based on these findings the tabulated data posted on this page is off, since it was calculated using a factor of 1/1.625 = 0.615. E.g. mobility stat of 8 in the table was assigned a value of 4.92 tiles, which rounds down to 4 tiles for a blue move, and double value of 4.92*2 = 9.84 rounds down to 9 tiles for a dash, but these values don’t match the actual in-game movement of 5 tiles for a blue move and 10 tiles for a dash. But if we use a factor of 0.666, we get the correct tiles values of 5/10 tiles.

I added more columns to the table for straight and diagonal moves, for half moves and dashes. Hazardass (talk) 02:17, 02 April 2017 (PST)