7
\$\begingroup\$

I believe I've got my head round CSP after reading Gabriel Gambetta's blog, Valve article and buildnewgames.com but having an issue understanding the time execution of everything.

So if a player holds the right arrow key down. I move the sprite by (speed * deltaTime) where deltaTime is the time between frames so speed is the same on differing frame rates.

My questions are:

  1. Do I send a command to move right every frame?
  2. How does the server correctly calculate this movement as it does not know the deltaTime of the client?

Really appreciate some guidance on this one. I'm using HTML5, javascript, node.js with socket.io.

Improve this question
\$\endgroup\$
  • \$\begingroup\$ Hi there. If you have two questions, ask two separate questions. \$\endgroup\$ – Sean Middleditch Feb 17 '13 at 20:18
4
\$\begingroup\$

Use a fixed time step to start. Fix Your Timestep

The server/client need to estimate the RTT (round-trip time) of the connection to correct times. The server is receiving commands from the (very recent) past. Its simulation needs to account for that. It knows where the client was and wanted to move to, not where the client is and wants to move to. The server needs to account for different clients potentially having very different RTTs.

Generally the server needs enough information to know where a client was X milliseconds ago to figure out bullet collisions and such.

Networking is hard. A lot of multiplayer hobbyist/indie/student games ignore most of the RTT issues by only claiming to support wired LAN play, where latencies are small enough to ignore for most games. Wireless and the Internet force you to deal with variable, large latencies that you have to work around to get satisfying play in an action game.

The Valve article covers that in a bit more detail. Ignore their advice on frame times; it's ridiculous.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thanks for this, this makes sense. There's a few conflicting methods to do things which confuses the issue. I'll plough on, the hard stuff feels good once you've got your head round it! \$\endgroup\$ – dolyth Feb 18 '13 at 19:56
  • \$\begingroup\$ Your job as a programmer is to find the method that works best for your game. That's why game net coders are in high demand and get paid a lot - it's a hard job, more so than many other parts of game programming which are more rote. There generally aren't any ready-made solutions for the problems you run in to. \$\endgroup\$ – Sean Middleditch Feb 18 '13 at 21:14
8
\$\begingroup\$

Do I send a command to move right every frame?

Sure. Why not? As long as the player is moving right, of course. If that's spamming the server too much, you could of course just send the command to move right and the command to stop moving right, but you're risking some troubling behavior if you miss the "stop moving" command. You could compromise between those two approaches. Send the command to move right periodically and send the stop command. Have the server keep moving right as long as it's received the command recently and stop when asked to stop OR when it hasn't received a keep moving right in a while.

How does the server correctly calculate this movement as it does not know the deltaTime of the client?

The server shouldn't care about the internal delta framerate of the client. It SHOULD care about the time that a command is sent to it. If your game is sufficiently deterministic to allow for client-side prediction, then the relative frame-rates shouldn't matter. To be deterministic, for example, the server would need to know something like, what is the speed of this character. Here's what I mean:

The idea is the server has its own delta time. Here's an example, using minutes instead of milliseconds to make the concept more clear. Say I'm supposed to go 60 miles and hour. That's the same thing as 1 mile per minute. Lets say we were moving the car based on an elapsed time that varies. So we might get something like the following:

  • 10 minutes. (Multiply 10 (minutes) by 1 (mile) means we move the car 10).

  • 8 minutes. (Another 8 minutes have passed, so we move the car 8).

  • 12 minutes. (12 minutes * 1 mile, add another 12).

So our total is 30 miles. Now on the server side, it might not be polling at the same times, but it's going to move the car the same amount if it's always multiplying the speed by the delta. So for example, say the server only polled every 15 minutes:

  • 15 minutes (Multiply 15 (minutes) by 1 (mile) and we're at 15.)
  • 15 minutes (do it again, we're at 30.)

Both the server and the client know the car has moved 30 miles, although they don't know the various delta frame rate of the other (and they don't need to know). Hope this example made it make sense.

Implementation Strategy

Based on the comments below, I'd like to suggest the following strategy to implement client-side prediction: Start by not having any. Let the server handle where the location of the player. Send your commands, right left, etc., have the server calculate the position and then have the server reply back with the player's new location. On the client side, use the player location to set the location of the player. This will work, but it'll create some lag that you won't like. Now, attempt to do some client-side prediction. Update the client position with where you think the player should be before it hears back from the server. When it hears back from the server the actual location, update the player to actually be in that location (i.e., let the server "win" when they disagree). Now you can work toward letting your prediction code do a better of predicting correctly so that the end product results in minimum correction "jumping".

In short, right now some of your questions suggest you're struggling a bit with the basic set-up of having the server calculate player location. So break this down into steps, get that working first, and then work on the prediction code happening.

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thanks for that, so this delta (1 mile per minute in this case) is known on both client and server? \$\endgroup\$ – dolyth Feb 17 '13 at 0:13
  • \$\begingroup\$ Well, I'd call that the "speed," not the delta. Delta is referring to the elapsed time between frames. \$\endgroup\$ – Cameron Fredman Feb 17 '13 at 0:14
  • \$\begingroup\$ Cool. I must admit I'm still confused about how this ties in with key-pressing and holding down the key with the rate at which messages are sent to the server. \$\endgroup\$ – dolyth Feb 17 '13 at 0:18
  • \$\begingroup\$ Unfortunately, doing something like this complicates rewinding/replaying when corrections need to be made (timesteps are different, so it's hard to extrapolate which frame to use). What I do is send an ID and how long the last frame took to the server. The server sets a "totaltime" variable equal to that, and updates in chunks of that time. After the totaltime has been depleted, it sends the position that it believes the player should be at. \$\endgroup\$ – untitled Feb 17 '13 at 0:43
  • 1
    \$\begingroup\$ I guess you are referring to the server keeping a track of time between packets? But what if some packets have a couple of seconds vs milliseconds just by the nature of someone lifting off the controls. I wish there were more diagrams on this subject sowing actual key presses and data packet examples. \$\endgroup\$ – dolyth Feb 18 '13 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.