Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I even heard J. Carmack quickly talk about it...

How a software can track a player's position so accurately, being on a such huge world, without loading between zones, and on a multiplayer scale ? How is the data formatted when it passes through the netcode ?

I can understand how vertices are stored into the graphic card's memory, but when it comes to synchronize the multiplayer, I can't imagine what is best.

share|improve this question
up vote 26 down vote accepted

Scott Bilas worked on Dungeon Siege and wrote a paper, "The Continuous World of Dungeon Siege". While Dungeon Siege is not a MMO, it does have a world, and he talks about player positioning in his paper. I found it to be a great read. Here is the relevant section:

The Precision Issue

From the beginning, the engineering team knew that the continuous world was going to significantly affect the engine and content design, and the core issue was numerical stability. Imagine two characters walking in formation two meters apart heading east away from the origin. At some point, the distance from each other is overwhelmed by the distance from the origin, and the characters will appear to be “at the same location”.

With floating point, the further you get from the origin, the more precision you lose, which can cause all manner of nasty problems. Things don’t sort right, cracks appear between adjacent meshes, space starts to quantize, and cats and dogs start living together. Dungeon Siege uses the FPU in single precision mode for the obvious performance benefits, and to match the native precision of the video hardware. However, even if we increased the precision, it ultimately could never solve the problem because the world was planned to be, and ended up, incredibly large.

The precision problem meant it would not be possible to have a unified world coordinate space like most other games. Instead, the solution was to segment the continuous world into a set of independent coordinate spaces, and switch among them periodically to reset the precision. A variety of ideas were tried out within these constraints, and we eventually settled on a variation of a standard portal system.

Our solution consists of a relational node-based coordinate system, in which each chunk of geometry (Siege Node) has its own coordinate space, and is linked spatially to neighboring geometry via the doors it shares in common with those neighbors. The arrangement of nodes connected by doors forms a continuous graph that represents the entire world map. This node system evolved over time from its original goal of maintaining FPU precision to become the primary method of efficiently subdividing space, and the root of countless optimizations.

In order to encapsulate the concept of a 3D position relative to a specific node, the traditional (x,y,z) vector had to be augmented with a node ID (x,y,z,node) and represent an offset from the origin of a specific node instead. This 4-tuple is encapsulated as a Siege Node Position, or SiegePos. Later on, we added a SiegeRot (quaternion,node) in order to handle comparisons between orientations across nodes.

The phrase “there is no world space” became a mantra to the team, although it literally took years for everyone to fully grok what it meant.

You can see more of his papers on Dungeon Siege here.

share|improve this answer
That seems to be a very goo answer ! Thanks ! I would have wondered if today's game would use limbed numbers like gmp's integers do. – jokoon Sep 18 '10 at 20:24

For a huge zoneless world I would either go for a double precision vertex, or floating point with smaller chunks dividing the land.

Each chunk would have it's own coordinate system. When you cross the border to each of these chunks you would transform everything to that coordinate system. That's how they do it in flight sims anyway.

If you have small zones, I guess float will be enough.

share|improve this answer
Double precision quickly incurs huge performance and memory benefits. (x, y, z, zone) is 16 bytes; (x, y, z) doubles will be at least 24. You can't do fast math on them, and you can't use them on a graphics card. – user744 Sep 18 '10 at 19:57
Well, Fermi cards can use double precision ;) But yeah, the chunked approach is what the answer suggests anyway. – Nailer Sep 18 '10 at 22:35

I'd say a for actual location it's a vector of 3 floats. But there would also be a zone index associated with the player as well. (But not part of the location because everything handled by that zone server is in the same zone and hence doesn't need to be in the same data structure.)

Remember there are at least 4 zones. The 4 major continents. I don't think any one of those is more than about 10km on a side. For example, this blog pre the latest expansion calculates the entire travel-able area as 41 square miles. All of the battlegrounds, all of the instances, are each with-in their own zone and coordinate space as well.

Using the LUA API you can get the position of the player GetPlayerMapPosition() returns two floats each from 0 to 1 as a proportion along the entire world map.

share|improve this answer

For WoW, I expect that they use a simple float x/y/z - but relative to a specific 'zone'

This would help to handle 'moving zones', for example, boats and zeppelins

share|improve this answer

Usually online games such as Wow, Tibia etc. Store the player pos. using three variables X + Y + Z in the SQl player meta table. Runescape does it without the Z - that way the player is always rendered on the top the top of the ground mesh.

share|improve this answer
what is a meta table ? I really doubt it'd store it in a DB, it needs to be used in real time... – jokoon Nov 17 '12 at 20:24
(1) The meta table in that case is the DB table with the basic character data, for eg. Gender, position xyz, amount of health, cash in bank etc and whatever else there might be. (2) I have been hosting open Tibia servers, in there the player pos is stored in the server cache. But... every 30~s there is a server save on the and the player's POS will be added to the Players meta data. So if the server gets shut down/it crashes the players position will come back to the DB position :) – Mikolaj Marcisz Nov 17 '12 at 20:59

A float? Well, an array of 3 floats for a 3D game. At least for us we use feet as units so all you need is 3-4 decimal places to be at the point that float noise isn't a problem. If a big zone is only a mile or two on a side, its not all that big a deal. As for transparent zoning in MMOs, thats a different question altogether. In the grand scheme of difficult problems in an MMO, storing position is pretty low on the list.

share|improve this answer
We had floating point precision issues in some of the large STO zones during development. I don't know what became of them. It may not be top priority, but it does need to be considered early enough to actually make levels. – user744 Sep 18 '10 at 19:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.