I'm working on a FPS game which is currently only client sided. I need to port some functionality to the server. But i would like some advise on this matter.

One thing i'm thinking about is the movement of the character. The way i'm currently moving my character forward (and any other direction) is with physics.

But how do i translate that to the server? I can't have an exact copy of the 'client world' on the server with all of the players that are currently connected. That means that whenever a person on the client moves forward, then the server should be notified too and it should start moving the 'cloned' version of me on the server too. But this will easily cause differences in positions because of latency. This method is obviously an idea to prevent speedhacking. But doesn't seem like the best way...

So now im actually wondering how other games are doing this, like Call of Duty and Battlefield. Do they also move their characters with physics? And how do they prevent speedhacking?

Another thing that troubles me is collision detection. Again there is something like a maphack, where players can walk through buildings and other objects. Is it possible to do some sort of check on the server? Again, how do other games prevent this from happening?


Any ideas / thoughts are welcome.

Speed-hacking is relatively easy to detect, you just have to check if a change in position in a certain time frame is not too big of a velocity. It gets more complicated when players can get blasted away at high velocities by explosions and such. I'd simulate explosions server side to check this.

Map-hacking is a lot more costly to do. You could simulate everything server side and when the client decides it's positioned somewhere and the server says nay you correct the client's position. However, this will increase the load on your servers. To reduce the load you could simplify the server side to just check if the clients position is in a simplified volume of the level and warp it back to a previous position if it's not.

Speed-hacking is relatively easy to detect, you just have to check if a change in position in a certain time frame is not too big of a velocity. It gets more complicated when players can get blasted away at high velocities by explosions and such. I'd simulate explosions server side to check this.

Map-hacking is a lot more costly to do. You could simulate everything server side and when the client decides it's positioned somewhere and the server says nay you correct the client's position. However, this will increase the load on your servers. To reduce the load you could simplify the server side to just check if the clients position is in a simplified volume of the level and warp it back to a previous position if it's not.

Thanks for you answer.

Your solution to prevent speedhacking and simulating explosions on the server sounds like a good idea. I had the same idea with the 'bullets'. Bullet hits are also calculated on the server.

I'm not sure if i understand your idea about preventing maphacks. What do you mean with checking if the clients position is in a simplified volume of the level?

Well lets say you have a level that consists out of a square and a complex statue in the centre. A map-hacker might use that statue to hide in it by removing it on his client. If the server were to check all collisions, the hacker wouldn't be able to get to that centre position to hide inside the statue. However, this is very costly computational wise. If you instead make a simplified mesh of the statue, the volume, the server can check whether the client position lies in or outside the volume much less computationally intensive. You could either make volumes that clients are allowed to be in or volumes they're not allowed to be in.

Well lets say you have a level that consists out of a square and a complex statue in the centre. A map-hacker might use that statue to hide in it by removing it on his client. If the server were to check all collisions, the hacker wouldn't be able to get to that centre position to hide inside the statue. However, this is very costly computational wise. If you instead make a simplified mesh of the statue, the volume, the server can check whether the client position lies in or outside the volume much less computationally intensive. You could either make volumes that clients are allowed to be in or volumes they're not allowed to be in.

Ahh i get it now, thanks for the explanation.

[quote name='vivendi' timestamp='1323781102' post='4893476']
I [s]can't[/s] can have an exact copy of the 'client world' on the server with all of the players that are currently connected. That means that whenever a person on the client moves forward, then the server should be notified too and it should start moving the 'cloned' version of me on the server too. But this will easily cause differences in positions because of latency. This method is obviously an idea to prevent speedhacking. But doesn't seem like the best way...

That is exactly how it's done in the standard FPS networking models. The client sends their inputs to the server and the client and server both run the same code (movement physics). The server sends the results to each client, and the client's local state is overridden by the server's state. Latency is hidden via prediction, smoothing and time-compensation. The server's version of the simulation is always correct, the client's version is only used as prediction, to fill in the gaps between server updates (nothing can be hacked on the client, because only the server's decisions count).


https://developer.va...ayer_Networking
http://trac.bookofho...uake3Networking
https://developer.va...nd_Optimization
http://udn.epicgames...ngOverview.html
http://www.pingz.com...rking_model.pdf
http://gafferongames...worked-physics/
http://www.gamasutra...hiding_for_.php
http://blog.wolfire....Halo-networking
[/quote]

Thanks for your explanation. That was how i initially thought of it. Another problem i had with that idea was the synchronizing part. If both the client and server run on the exact same date/time, then it's easy to send a packet from the client to server with a timestamp (up to miliseconds). That way you can easily calculate how much time it took to send the packet to the server and vice versa. This makes the prediction alot easier. But it's probably not possible to sync the time of two computers up to the miliseconds... But on the other hand, the answer to this problem is probably somewhere in one of the articles you posted. I'll start reading those now, thanks for the links.