Alright so me and a friend are working on a multiplayer action game using server-client toplogy.
Now obviously player prediction is a definite must in today's games, however this is usually a fairly simple solution for FPS games, however for real-time action games with more complex physics (players can affect other players position & linear/angular velocity, players can move in very high speeds), this approach causes A LOT of snapping when players move in high speeds and hit each other, and one of those players suffer from a latency of >= 100ms.
So that being said:
1. What is the best way to implement player prediction for multiplayer fast paced action games (or is there another approach to these types of games)?
2. How can you perhaps prevent or at least decrease greatly snapping of players (I see myself driving in a car while suddenly someone hits me driving 100mph, due to player prediction and a 100+ latency, I see myself not get hit by him and suddenly get throw down since server saw it as a hit)
3. Iregardless to this topic, can anyone point me to a good reference on how to keep sync of AI actors in games (using server-client random seeds, etc), I'd greatly appreciate it.
Thanks
Multiplayer design question
If you do high speed movement with narrow margins of error, you have to display other players behind in time so that you don't have to guess. Basically, you display something that interpolates between the last two received packets, rather than something that extrapolates into the future.
To make the simulation fair, you may want to make input commands round-trip through the server before they take effect. This does add input lag, but that's the price you pay for being accurate.
If you have to predict forward, then you have to design the game so that either the margin of error is large, or you have to predict forward using some AI algorithm that "guesses right" for what the player will be doing.
This exposes a dirty truth about networked games: Good game networking implementation is as much about game design, as it is about technology. There are things you will want to do, that simply cannot be done over the internet in a straightforward way. The solution lies in game design, not in technology.
To make the simulation fair, you may want to make input commands round-trip through the server before they take effect. This does add input lag, but that's the price you pay for being accurate.
If you have to predict forward, then you have to design the game so that either the margin of error is large, or you have to predict forward using some AI algorithm that "guesses right" for what the player will be doing.
This exposes a dirty truth about networked games: Good game networking implementation is as much about game design, as it is about technology. There are things you will want to do, that simply cannot be done over the internet in a straightforward way. The solution lies in game design, not in technology.
Author
Do you mean a sort of lag compensation like the one described here?
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
If you can stomach the implications you could let each player be authoritative over his own physics, see Gaffer's material:
http://gafferongames.com/2010/03/11/gdc-2010-networked-physics-slides-demo/
However, under that scheme it's slightly scary to consider that interactions of players in differently lagged timestreams are essentially undefined.
http://gafferongames.com/2010/03/11/gdc-2010-networked-physics-slides-demo/
However, under that scheme it's slightly scary to consider that interactions of players in differently lagged timestreams are essentially undefined.
Yes, it does :) And even without cheating, due to each player asserting authority over their controlled character, wild interpenetrations or other physics artifacts might result. I tried it for a while, then returned to traditional server-authoritative + client-predicted physics. However I'm currently not doing anything as demanding as you are, just (relatively slow) moving FPS characters combined with some physics props. I suppose it's one of those "YMMV" things.
Author
Well obviously player prediction is an ingenious solution to FPSes, especially if combined with some lag compensation.
Well testing with player prediction on 2 remote clients connecting to an auhtoratative server with both having around 200ms~ RTT they actually seem to be moving not to badly.
I'm thinking that with <= 100ms, players would barely see any serious snapping.
Well testing with player prediction on 2 remote clients connecting to an auhtoratative server with both having around 200ms~ RTT they actually seem to be moving not to badly.
I'm thinking that with <= 100ms, players would barely see any serious snapping.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
