# Game server position tracking

How would you go about determining a players position server side based off player input?

The Setup: Player sends packet to server containing the command and view angles. Server takes the direction and multiplies it by speed.

Say a player is going up a hill. How would the server make the players position reflect that the player is going up a hill.

The way i see doing is taking the ground height under the player and calculating if the height change in direction x is too high. However calculating that info for n players say 1000 would be very intense. So what is the proper way of determining a players position based on input with a client/server setup with the server being authorative. There is 10 updates per second.

• Can you change anything about what the player is sending? I think it would be easiest, if the player sends his coordinates like GPS does. Just establish a default height like sea level and let the player send x,y and z coordinates.
– entek
Commented Nov 2, 2011 at 8:01
• The server would be keeping track of the coordinates. Basically the client tells the server they want to move and the server would determine how they move. If the client sent the position it would allow players to cheat.
– Kyle Dumas
Commented Nov 2, 2011 at 8:08
• I'm pretty sure you're already doing it right. Commented Nov 2, 2011 at 14:24
• You haven't read Valve's networking document bit.ly/valveudp you are supposed to understand it, if you're going to do that sort of game.
– o0'.
Commented Nov 3, 2011 at 10:11
• I read that before. I really wanted to know how I could calculate a players position based on objects around the player. At the time of the post the terrain was also a issue but its basically check the height between point a and b. Commented Nov 5, 2011 at 5:00

I think this is actually usually done retroactively; that is, the client sends their position and allows the player to move, anticipating that the server will allow it. The server verifies it, and rejects it/disconnects the user if it's invalid. You can of course calculate speed by taking the difference between two positions and dividing it by the time between the position updates. And the server will also want to check that the position doesn't collide with geometry; this check will need to be mirrored on the client side. Then with the server checking on the client, it's immediately obvious if the client is cheating (i.e. if they send an invalid position) and can be kicked off. For anything that's not blatant cheating, like a collision with a moving object where the object might be in slightly different positions between server and client, the server simply tells the client where it should be, and the client can jump the player to that position (or smoothly but quickly slide them over there; either way, discrepancies need to be handled and they probably aren't going to be pretty).

All in all, this allows for a much more responsive player experience. When they try to walk forward, their character can move forward immediately and the client notifies the server, and then in the rare cases where the client receives a rejection response back, the character can be pushed back to where the server says it needs to be.

This is talked about in some detail in the book Massively Multiplayer Game Development. Also see the question "Synchronizing clients with a server and with each other".

So after reading thousands of posts on how to handle collision server side I have decided to use the bounding box technique. After all for a MMO really all collisions are made between players and static objects. No npc to player or player to player collisions etc.

So what does this mean? Objects are a bunch of boxes.

Example of server side object 1 Main bounding box which surrounds the entire object. Coordinates of the object center Horizontal Distance Max(x,y) Vertical Distance Max (z) List of Boxes Count of objects region identifier

Box Example: Vector3 point1 (x,y,z) Vector3 point2 (x,y,z) Horizontal Max Distance Vertical Max Distance Vector3 Center Point (x,y,z)

Each object can contain multiple boxes that make up its shape. Like a house for example with just a door, no windows and no chimney would have 10 boxes and 1 box around it all. Instead of checking each individual box for every object the player must touch or try to enter the main bounding box.

Basically each movement the server compares the players position to each object in said region. If the player is x distance away from object A and is less than or equal to it then do further checking. If object is too high or too steep for player to get on it then stop the player. Otherwise let the player go on the box. If a player tries to jump on a table or something make sure that the height of said table is less than or equal to players jump height. If not then stop the player from getting on it.

Hmm that sounds like a lot of work if you do that for 300 players 10 times a second?!?!? Well basically the client wont encounter many of the boxes (At least server side). Client side the colliders will be slightly bigger and stop collision client side. So if the client can do it then why does the server have to try? Cheaters. Client side will restrict movement just enough many server side checks shouldn't have to happen. Really the only thing server side will have to check against collision wise most of the time will be whats under a players feet and what a player can jump on along with terrain. 80% of server side collisions will just be there if a client tries to cheat. Think of it this way... You have a chess board right? Server has colliders just outside the board around the whole thing. The client has them just barely on the inside around the whole thing. The client side colliders should stop the player just before they reach the server side colliders. If a client finds a way around the client side ones the server colliders kick in and basically say NOPE. This prevents much of the load actually taking place but its there if needed. This means the server really only has to compare against terrain and object height.

• Ok, this has become more of a collision detection question than a server positioning question. You'll probably need more than just bounding boxes, but you might do ok with them. As for the server checking positions, you will need to check that the player hasn't moved an unfair distance since last time, as well as against colliders. The idea that the client side checks will save you from doing the server side checks is false. You still need to do exactly as many checks on the server because you can't trust the client. Commented Nov 5, 2011 at 13:27