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

Question

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 ?

Answer 1

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:

Mean radius 6,371.0 km Equatorial radius 6,378.1 km Polar radius 6,356.8 km

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.