Jump to content
  • Advertisement
Sign in to follow this  
Lumberjack

Transmission types and networked games collision effects

This topic is 3986 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

Hi! I have two questions regarding network programming that I hope some of you could give me your view's on. 1. What kind of transmission types (guaranteed, non-guaranteed, most recent state) do you use in your games and why? 2. How does modern client/server games handle effects such as sparkes etc. triggered by collision? Are collisions detected on the client and used for effects only or are they detected on the server and sent to the clients? Thanks in advance! /LJ

Share this post


Link to post
Share on other sites
Advertisement
Largely latest-state unreliable, because it's the best trade-off with latency.

Collision between actors is the big hard question in all distributed simulation. DIS solved it back in the days by having each entity detect collisions for itself, and broadcast those interactions to others. However, that doesn't work in a game where the user can cheat.

Generally, you want the outcome to be server controlled, but you want the collision to have low latency on the client for good responsiveness.

Share this post


Link to post
Share on other sites
It's really hard to have decent networked physics that is both bandwidth efficient and not too ropey. If you look at the modern games, even them have very little in terms of object interactions in multiplayer games. Counterstrike cheats with dynamic objects, they seem to have a force field that similate very rough physical interactions. Everyone hates barrels in that game :)

At work, We are looking at it but it's not a problem that is easily solved. Gaffer has an article on networked physics but I have my doubts on its efficiency when you consider dynamic objects, either complex or in large numbers.

However, it's great for character controls, and in fact, it's the method generally accepted for fast paced server-client games, it provides a minimum amount of latency and a decent amount of security (server has the authority, client has only limited prediction capabilities).

By all means, have a look at it and play around with the demo.

As for the transport protocols, it's usually state based, packets wrapped around unreliable UDP, with some form of basic aknowledgement or delta-compression to overcome packet loss.

Share this post


Link to post
Share on other sites
Gaffer's description is fine. However, that doesn't do anything (good or bad) about the hardest part, which is actor/actor interaction. In CS/S, you will notice that running close to a team-mate will make both you and him keep rubber-banding backwards, because you keep getting server corrections.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!