Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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.
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
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.
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.
