Jump to content
  • Advertisement
Sign in to follow this  
vivendi

theory about server sided movent / collision

This topic is 2440 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites

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.


You don't need a perfect time sync; you need a clock / physics step number ordering such that events happen in a consistent order.

When connecting, the server could tell the client "my step number is right now X." The client could then advance that step number along with regular time based on its own clock. The client sends "here are the commands for step N." Then server will see that it received the commands too late, and tell the client "your commands were D steps late," and the ceint would add D to its estimate of server step time. This would very quickly converge to a good estimate. Just make sure that a single big delay doesn't forever add 100 steps to the estimated latency...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!