4 ms·
I don't think that 'poor programming' is too harsh in this situation at all. You call it the obvious solution, but really there is only one solution worth spend
by coderdude 15y ago
I don't think that 'poor programming' is too harsh in this situation at all. You call it the obvious solution, but really there is only one solution worth spending your time on. The correct solution is to simulate the game on the server and update each client with only the information it is allowed to know.
The client should not make any decisions and should only ask for permission. If the player wants to move forward then the client sends a request to the server to move forward. The server will respond with new player position data if the move was allowed. If the player asks to move through a wall then the server will not comply.
The server should also never send clients data about other players not in their field of view (or in the immediate area, all depends on the game). To send the client any information it shouldn't have or to allow the client to make any decisions that the server takes and runs with is absolutely poor programming in the multiplayer game space.
You just have to ask yourself if it's worth it to possibly save some time at the expense of introducing a systemic flaw in your client and server that allows cheating to occur. For a competitive multiplayer game I think it's worth the time to make sure you're not sending clients the position data of invisible players.
Edit:
The client will most likely also calculate some of these changes at the same time it requests a move though. This is called client-side prediction and it's done to keep the gameplay smooth over unreliable and slow networks. The clients will interpolate and extrapolate certain game moves and sync with what the server says as the data becomes available. That's why sometimes in Counter-Strike (for example) you can run in one direction for a second or two and then suddenly be in another location altogether, because the server corrected the client's increasingly inaccurate extrapolation of position.
Some reading if this sort of stuff interests you:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking http://developer.valvesoftware.com/wiki/Source_Multiplayer_N...
http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization http://developer.valvesoftware.com/wiki/Latency_Compensating...
http://www.gamers.org/dEngine/q3suggest/final/generic.html http://www.gamers.org/dEngine/q3suggest/final/generic.html
http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tr... [pdf]
http://gafferongames.com/game-physics/networked-physics/ http://gafferongames.com/game-physics/networked-physics/
http://gmc.yoyogames.com/index.php?showtopic=415538 http://gmc.yoyogames.com/index.php?showtopic=415538
- Shenglong 15y agoThe server should also never send clients data about other players not in their field of view (or in the immediate area, all depends on the game). To send the client any information it shouldn't have or to allow the client to make any decisions that the server takes and runs with is absolutely poor programming in the multiplayer game space. That's the key point. I don't see any advantage in sending all that information, other than to correct for another bug which should never have been there.