Jump to content
  • Advertisement
Sign in to follow this  
jujumbura

Basic FPS Client Server Model?

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

Hello all, Networking is probably my least familiar subject in game development, and computer science in general. I've taken a few courses in school and implemented some basic TCP-based applications, but nothing worth writing about. I'm curious as to what the high-level overview of the Client Server Model is for modern FPS games. I'm sure it differs qutie a bit from game to game, but I'd love to know if anybody has answers for a few questions I have. So here goes: 1) What kind of state is sent over the network? In RTS games, I know that most of the data sent is actually the actions of the users as opposed to game state. Then these actions are used to generate perfectly in-sync simulations on each machine. But I don't believe FPS games do this ( or do they? ). I'd imagine the basics have to be sent over; positions, velocities, steering parameters, and any spawned projectiles. But what about animation? It seems like the local client is the only one who knows his true animation state at any given time, but it also seems unlikely that you could send data quickly enough to make your animation look smooth to other players. Yet, if other players are "guessing" as to what your animation state is, couldn't this result in innaccurate limb hits? In what ways is this handled? 2) How far does the server trust the clients to simulate? In one scenario, I can imagine that the server might be completely distrustful of the clients, and perform the entire simulation itself. In this fashion, you would send "desired" state updates for yourself, but the server would verify them, and then send you back the "true" state for yourself and everything else around you. This might be the "safest" but it certainly seems inefficient. On one hand, you could never break the rules of the game by running modified client code ( the server would just reject your state ), and any players who were lagging significantly wouldn't stop the server from updating their actor regularly ( no "jittering" players ). But on the other hand, the amount of computations for the server to perform would be enormous for a complex, high-prescision FPS, as would be the amount of state data it would need to send over the network. Furthermore, you have the potential that your own "desired" state becomes greatly different than your "true" state if lag gets high, which would be extremely frustrating to play with. Do any games use this strict model? In another secneario, I can imagine a hybrid model where the clients perform a fair amount of the simulation locally, and just report the results back to the server. The server might "verify" your update to some extent, but it wouldn't re-process it. For example, you might always do your own movement and collision testing against the world, and report back to the server where you are. A sketchier example would be for shooting: you do the bullet raycast and locally, and report back to the server what you hit. ( However, this screams for aiming and "shoot through walls" hacks, even with some validation ) You would also be able simulate objects locally which are completely deterministic ( a non-guided projectile for example ) after the initial spawning. In this model the server would perform relatively little simulation, and only send out the state for players other than the client's local player. However lag could be catostrohpic, allowing you to report completely innaccurate results. Do many games use this model, and to what extent do they let the client report simluation results? 3) What kind of LOD is done for state transmission? In a large battlefield, there's really no reason for a client to know what's going on far away from the local player's position. The server could save the burden of transmitting state for distant players and objects that cannot affect the client. Yet, this means that the server would need to simulate objects which might previously have been up to the client ( such as the deterministic projectiles ), because it may need to suddenly "inform" a client of objects that have moved into it's "sphere of influence". This also seems like, while it might make for better performance on the average case, the worst case could be a huge spike in which all players are suddenly duking it out in the same location. Do games try to LOD this at all? I know I'm making a lot of assumptions with these questions, so please feel free to correct me on anything. Thanks much for reading, and I look forward to your insight!

Share this post


Link to post
Share on other sites
Advertisement
This should help:

http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

1. Animations most always fall into the category of "the client can handle it and synchronization is not a concern". Just given the velocity of a character, a lot of assumptions can be made about the animation without the server having any part in it. I don't think theres many, if any, multiplayer shooters out there that actually go as far as to track what limb was hit. Theres enough of a problem with trying to hit a box around the target, hitting limbs goes to a level of such accuracy that it would be impossible to purposely hit a moving limb unless you have the Ping of The Gods. The exception is headshots, and often times this is just a smaller hit box attached to the body hit box. The relative position is just about always the same, and when it is not, the offset is very slight. This is probably why we have no
">Night at the Roxbury FPSes. ;)

2. The server typically keeps track of what is going on. If the client's simulation is wrong, it is eventually correct. Any attempts to alter the simulation is probably just going to make things worse and result in your view of the world being different from what it actually is. Only advantages this really brings is wallhacks, but this isn't usually how they're done.

3. I believe most games will count the amount of solid surfaces between the characters to see if they need to know about each other. In games where the maps are so large you can't see across the whole map even with no obstruction, I'm not sure - never played a game like that. If there is just one object obstructing the view, the client should probably know about the character. This way, if they run out from around the corner, the clients will already know the other character was there. Things get more complicated with windows and such. Not something I want to even think about without having a few months of free time. ;)

Share this post


Link to post
Share on other sites
Wow. Spodi thank you so much for that link, that article answered a ton of questions that were running around in my head. I never would have guessed that they did hit detection backwards in time in order to compensate for a delayed view on the client. Very cool.

Do you happen to know how closely this model describes other FPS's out there? It did seem to mention Counterstrike a lot, and it actually made a lot of sense for the context of Counterstrike particularly. It's a very fine-grained, accuracy-based shooter with no projectiles or vehicles. Do you know of any writeups like this for a more "open-space" FPS like Battlefield or Quake Wars?

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!