In a game such as Star Wars Galaxies, Planetside, and Warcraft how would server-side collision/terrain navigation work?

Question

I'm trying to learn some advanced topics in multiplayer networking for fun and education, specifically how server-side collision/terrain navigation works in MMOs and/or any online game.

Personally, I have a nice little test server where I can move two units around a plane and they can collide with one another, no big issue, then I started to think about real terrain. Features such as mountains, rivers, cliffs, etc.

I know that a map can be chunked out and I could use spatial partitioning to narrow my collision detection down to small chunks, however, I'm a bit stumped if the server and client would be running the exact same physics calculations (gravity, physics, etc).

I'm assuming the server would need to have an exact duplicate of the map-data that the player is seeing client side to perform the appropriate collision/terrain calculations to make sure nothing nefarious is going on - such as a way to prevent map hacks and hiding in walls/mountains.

This is all assuming the player has direct control over the movement/direction of their character ala WoW/SWG/Planetside, and not like a MOBA/RTS game.

My question boils down to this (as I know implementation details vary) what does the server-side need in order to properly keep track of players in a varied terrain world?

Answer 1

what does the server-side need in order to properly keep track of players in a varied terrain world?

The same things a single-player game would need to do this. The server in a client-server relationship generally only differs from a single-player game in that it has to deal with sending information to clients periodically (which comes with a raft of scaling problems, of course). Conceptually things work mostly the same.

Thus, the server would keep authoritative information on the locations of all player's collision capsules (or however collision is represented, but capsules are common). The server would also need all the other collision primitives near the players, however those are represented, and the collision information for the terrain (typically a height map or one such converted to a triangle mesh).

Essentially the server needs to keep the entire physics world around, at least near the players, to be able to authoritatively simulate the world and handle player collisions.

This is where scale can become an issue relative to a single player game, because a single player game will generally only need to keep the immediate area around one player in memory, whereas a server may need to keep many such areas. Depending on the scale of the game this will involve more aggressive optimizations, more expensive hardware, or actually splitting the simulation up into discrete chunks with boundaries between them (such as "map travel" points) so multiple server processes across multiple pieces of hardware can bear the load.

---

It is true that the client and the server generally have exact copies of the map and collision data. This lets clients do local simulation and interpolation of the game state while they wait for authoritative updates from the server; this hides latency.

This itself doesn't really prevent map hacks. The real major roadblock to map hacks and such is simply having the server keep a tight rein over the information it sends to any one client. Generally, it is not necessary to send the position of every entity on the map to any one client. A client only needs to know about stuff it can see nearby, as determined by the server. If the server instead just sends everything, any enterprising hacker can modify the client to produce a "wall hack" using that information.