I''ve just started looking at networking with making a simple racing game. I''m considering the following two methods for synchronisation... A)Send the keys pressed by the player or the actions they want e.g ''accelerate''. B)Send position + velocity of cars apparently A is difficult to implement with quick enough response, but B accepts the possibility that machines have different views of the world, which means two machines could think different people won the race! Disaster! I''ve no idea how many ''frames'' per second one can transmit from modem to modem (assume normal 56K modems as minimum), or how long it takes to send a signal and get it returned. Having no-one to actually test it on apart from a nertwork (way to fast for these problems to manifest hopefully) means I need a lot of knowledge before writing the code.

I'd say do both intermittently. Try various combinations and try to find a happy medium with what works in your given design.

The full updates will clean up packet loss and sending controls will allow more bandwidth becasue you are sending a smaller packet.

For accuracy, send a session time along with the position and velocity of the vehicles. Let the server make that decision.

(By session time, I mean have everyone synchronize to session time 0 as best you can when the session starts, and send session time to the other machines. Key everything off session time, not CPU time. Get it?)

I'm not a total guru, but that's how I would handle it.

[edited by - Waverider on June 5, 2002 10:57:48 PM]

ok well.
1/ If you send only the keys pressed, the other player can determine the position of the other car, so it''s note necessary to send the position and the velocity
2/ A good way to synchronized a game:
You estimate the lag between the 2 players.
you send a message at time H1, the receiver receive the message at time H2, you receive the confirm response at H3
then you can calcuting the lag time: (H3 - H1) / 2
Now when you send a command to the other player you know the time after witch you can execute the command (lag). and you adjust the lag after every messages.

conclusion:
estimate the lag
send message :
wait lag and execute message on your machine
adjust lag

I think I decided that sending key-pressses is a bad plan because unless you can guarantee that every machine gets every press, then actions can be missed on some machines resulting in a horrible mess!

It becomes easier if you go with a client-server model:
Send keypresses from client to server.
Send positions and velocities from server to all clients.

If you want to be sure that you''ll never have any inconsistencies, I think you will need to have one computer as the ''server'', even if this fact is hidden from all the players.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]

Yeah I can see that might work, but it makes an imbalance in how much work is done. Typically the server is one client''s machine, you don''t want to force that machine do all the work finding positions of every single player.

Yes you do. Thats why you make the server the fastest machine with the best average ping to the other clients.

?? why you don''t have the guaranty that the message "keypressed" is receive ?? the TCP protocol garanty that the message is receive.