Will this function well?

This touches on a fundamental problem of network games: who is authoritative.

Playing a game over the internet can mean a lag of half a second or so for round trip communications.

For the game to feel responsive, the clients need quick feedback - so when they move their paddle, it should immediately move on their screen. When the ball hits their paddle, it should bounce off it.

If the server is authoritative over the position of the ball, then the client will not be able to say if it has bounced until half a second later, by which time it will have missed, and will have to snap back.

Seems like in the limited domain of pong, where the clients do not directly interact. You want the client who is closest to the ball to be authoritative.

Hmm, you could do some cunning time dilation as the ball moves across the screen, so it moves back in time when moving away from "you", and then forward in time when moving back, so you never get visible corrections.

One thing you should definately know. The clients should only send input. The server is authoritative. Use interpolation to smooth the paddle movement out. The ball movement is rather predictable if you use a time base model. So the server will only have to send the the starting position and the velocity.
so it would work like this:
•2 players detected in a game.
•server send the starting position of the ball x and y and the velocity, x and y. •Then the clients receive the position and velocity.
•Game starts and player one send input to move the paddle down.
•The server is running it's own simulation. It processes the data it recieves and notices player 1 wants to move the paddle up, so it set the variable for player one's paddle up to true. The server ticks forward after 20 ms and goes to the next frame and moves the ball.
•Then the server sends the information for both paddles y position and their y velocities. (there is no x position in pong just so you know).
•The clients receive the information and sets the paddles y position if it's y position is off by a lot, and sets the new velocity.
•Player 1 hits lets go of the key telling the paddle to move up.
•Server receives the command and set the up variable to false. After 20 ms the server simulation ticks forward and send out the new paddle y position and velocity.
•Then just repeat until the server detects a victory. Tell the players someone has scored and then reset the ball. When the server's score variable for one of the players is over some amount send to the player a message saying who won. Then just have the clients pop up a box that asks if they want to play again or something. :)

So for all semantics aside the server will have variables for, both players paddle position and a velocity y for each. Then 2 variables each like eventUp and eventDown used to storing the players input which is used when setting the paddles' velocities.

That's pretty much all their is to it. The interpolation is fairly automatic with that system to. However the paddle will overshoot a little sometimes.

The Server only needs to be authoritative in the event of some dispute. If you force the server to decide everything then it's going to be incredibly unresponsive.

Extrapolation is fine if it's something you are not controlling, but you can't extrapolate your own movement, as every time you change direction, it will swing past then snap back.

Well, I don't know I agree that the server should be authoritative in this case. We forget that like with all other decisions, making the server authoritative has a tradeoff of increasing perceived latency. For a twitchy game like pong, a game that likely will never be played by thousands of people, why bother making it impossible for the client program to cheat?

Now, you may be making a pong clone to teach yourself about game networking techniques, in which case yes, you should probably make the server authoritative. Or you might actually plan to release it to a wide audience where cheating might be disruptive, in which case the server should once again be authoritative. But you also might just want to make the best pong game you can for you and a few friends, in which case why not let the clients have some responsibility? But in this case, why do you need a server? Let the clients play peer-to-peer!

Quote:

Original post by Ozymandias43 Well, I don't know I agree that the server should be authoritative in this case. We forget that like with all other decisions, making the server authoritative has a tradeoff of increasing perceived latency.

Not really. You predict by running the same logic on the client as on the server, and if they differ the server can update the client with new data to correct it. If the client does not want to be corrected (as in a cheating or modified client) then it will just stay out of sync with the real simulation since the server is authorative. This has little to do with packet latency.

For instance, this is how they designed Tribes II. HL2 works in the same way mostly, with some differences. There are some really nice papers out there if you google.

Right, but we're not talking about predicting the local client. We're talking about the remote client, and introducing an authoritative server effectively doubles the latency from a client's perspective.

In a client-server environment, we see this:
Time 0, client A presses down, moves mouse, whatever, and a packet is sent to the server.
Time 10, server finds out A moved the mouse, notifies all clients
Time 20, client B finds out A moved the mouse.

In a peer-to-peer connection, we see:
Time 0, client A presses down, packet sent to B.
Time 10, B finds out A moved.

Prediction and extrapolation work pretty well on FPS games, but that's largely because they're not as twitchy as the last few moments of a pong game. Bullets fly invisibly and usually the other person isn't quite where you think he is and he isn't quite aiming at where you are. Throw in that there are dozens of clients that might be behind routers, and doubling the client-client latency is a cheap price to pay that can be partially hidden with prediction and interp/extrap. Don't think that there's NOT a price in latency, though.