# What data should I use to track the player position on a world at the same size of the earth in a multiplayer game?

I guess this kind of game or simulator already exist somewhere, but I'm not sure...

Let's imagine I'm making a game where the proportions of the planet earth and the humans beings on it are the same as in the reality. I can't only use longitude/latitude with float because when being far away from the origin, precision would be lost: when the float exponent gets too high, the digit at the right would be rounded and thus, not considered. Or to say it simpler, float are not precise enough to position an object on earth using longitude/latitude while keeping smooth movements.

Since there is a need to track each player's position in an homogenous way, I'm thinking about dividing the world map into indexed subparts (thus integers), and then precisely position the player using a float or double.

This would look like this:

struct position_on_earth
{
int sector_x, sector_y;
float pos_x; pos_y;
};


Is it potentially faster to use this kind of data instead of using doubles ?

• Take a look at the answers found here: gamedev.stackexchange.com/questions/3935/… – Nailer Oct 3 '10 at 16:16
• In fact, I asked this question. – jokoon Oct 3 '10 at 16:26
• Haha. Oops =D Didn't notice that ;) – Nailer Oct 3 '10 at 21:07

Earth's Surface Area ~ 5.1×10^14 square meters

If the world were flat, you would have enough precision from making pos_x and pos_y 32bit integers to divide the entire world into a uniform sub-millimeter grid. Depending on the scale of your simulation, this might well be enough precision.

If you're going for a spherical world, however, you're going to need a different kind of coordinate system.

EDIT: In fact, just using a dumb 32bit int grid still isn't all that bad if you move to a sphere! Some more details about earth:

Lets say we put our model earth in a cube with sides 13,000 km in length. If we use 32bit ints for x, y and z coordinates, we still get sub-centimeter precision. As an added bonus, we don't need to handle altitude / depth as a separate special case anymore (although this might be viewed as a disadvantage, since we will need to check the direction to the planet's center when we apply gravity).

• +1 Assuming the stats are correct, then it would seem that there is no precision problem. – 5ound Oct 3 '10 at 19:38

Earth-Centered, Earth-Fixed

ECEF

Edit: don't worry about the gravity vector, it's always easy to get a unit vector to the origin. Doubles will do your XYZ units just fine.

As I said in my other answer to your other very similar question, you should read "The Continuous World of Dungeon Siege". He does indeed suggest dividing the world up into a "relational node-based coordinate system, in which each chunk of geometry (Siege Node) has its own coordinate space". Your struct seems to mirror this, so I think you're doing fine.

• The Dungeon Siege paper is good reading, but may be overkill. The grid-based system jokoon proposed is still an absolute coordinate space; Dungeon Siege had no absolute coordinates. This lets you do much cooler things, but is also a lot less straightforward to think about. – user744 Oct 3 '10 at 19:53
• yes, but the implementation is a little more sophisticated. I like the kiss principle :) – jokoon Oct 3 '10 at 21:32
• It's also worth noting that the author now recommends people take a different approach. See the notes at scottbilas.com/games/dungeon-siege – Kylotan Oct 5 '10 at 13:01
• What does he mean by "the 'giant bricks' model of world subdivision"? (if it's in the paper just say so, I haven't read it yet) – Ricket Oct 5 '10 at 13:14

Your structure is potentially faster as long as nothing which needs a position (this includes path finding or finding out the distance to places halfway across the planet) crosses the section boundaries all that often - in other words, if all your algorithms and procedures have a strong locality to them. If your use case is the other way around, I'd suggest storing the position in precise, global uint32 values (which would have about a centimetre precision) and storing a float (or even just float16 if your hardware supports it) displacement value from this position for display on screen, local physics simulation and similar cases.