Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualSatharis

Posted 21 August 2013 - 01:45 PM

I think his point was more at using dead reckoning in your code to where the client will draw other players based on where it "assumes" their position is, and by timestamping messages from the server you can read them and go "Hrm this player should be here at this point and moving this direction, well if I compare that to his current position then I know he should have been at that spot 400 ms ago, now I can guess where he should be at this second and draw him there. This point relies on the idea that the client still assumes it know what is best and just modifies that based on concrete information received from the server.

To be honest I haven't done much realtime gameplay with networking so I'm not entirely sure what the most common design patterns are for guessing movement in different games, but. Usually with games the client will assume that it is correct and in control and just relay its movements to the server, which checks them for validity and relays that information to other clients.

It's really a bit of a guessing game and this network logic changes quite a bit depending on the type of game, for instance an mmo assumes far less precision of location than does an FPS or something where getting a shot off at the right moment is the difference between terrible and good gameplay.

I'm sure we've all played a shooter that was coded horridly to where you were expected to shoot miles ahead of or behind players because their updating was so awfully designed. Gunz is a good example.

#1Satharis

Posted 21 August 2013 - 01:42 PM

I think his point was more at using dead reckoning in your code to where the client will draw other players based on where it "assumes" their position is, and by timestamping messages from the server you can read them and go "Hrm this player should be here at this point and moving this direction, well if I compare that to his current position then I know he should have been at that spot 400 ms ago, now I can guess where he should be at this second and draw him there. This point relies on the idea that the client still assumes it know what is best and just modifies that based on concrete information received from the server.

To be honest I haven't done much realtime gameplay with networking so I'm not entirely sure what the most common design patterns are for guessing movement in different games, but.

Usually with games the client will assume that it is correct and in control and just relay its movements to the server, which checks them for validity and relays that information to other clients.

It's really a bit of a guessing game and this network logic changes quite a bit depending on the time of game, for instance an mmo assumes far less precision of location than does an FPS or something where getting a shot off at the right moment is the difference between terrible and good gameplay.

I'm sure we've all played a shooter that was coded horridly to where you were expected to shoot miles ahead of or behind players because their updating was so awfully designed. Gunz is a good example.

PARTNERS