🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Timing in multiplayer games

Started by
1 comment, last by F104 22 years, 5 months ago
Hi, we''re going to implement the network system for our little game. We thought to use a client-server architecture (we have our own server machine). What is very difficult to understand for us is the timing. Clients send messages (UDP or TCP) to the server which broadcast them. Ok, but if a client send a message at time 0:0:1 that is received by the server at time 0:0:2 and then sent to the other clients at time 0:0:3 or 0:0:4... how could a client do the actions described in the message at the right time? I''ll explain better: all the clients must be exactly synchronized? Or it''s not relevant? Or is the server keeping the global time? Example: say that all the clients are NOT exactly synchronized; client A fires a missile at time 0:0:1, but the message is received by other cilents at different times... so client B sees message is referred to time 0:0:1 and "changes" its simulation to take care of it... here''s the problem: client B hasn''t the SAME clock time of client A, so the time 0:0:1 is a different REAL time for client B and the game synchronization could not work anymore! Hmmmm... reading what I wrote it''s a little bit confusing, but the thing is difficult to explain... hope someone could understand and give me some answer! Thx! Bye Bye F104/NA
KISS - Keep It Simple Stupid
Advertisement
You can''t synchronize the clients exactly, it''s just not possible.

In a typical FPS networking scheme, the server is the absolute authority (which both simplifies things and prevents rule cheating). It just sends updates to the client which look like: "My current time is 158.3 secs, you are at 52/345/23, Player B has just fired a missile so draw some effects, the brown dog over there is at coordinates 100/352/-5" and so on.

The client will simply take this info to render the view.

It will then collect data from all input devices (i.e. keyboard and mouse) and assemble a movement packet saying "I want to move 100 units forward and I''m currently facing into direction 45°/-1°"

The server collects these movement commands and updates its internal state of the world. Then it sends out updates to all clients again.

You don''t really have to worry about synchronizing during the first stage of implementation. Of course you will have to worry about client-side predicition and lag compensation later on, but you should keep it simple in the beginning.

cu,
Prefect
Widelands - laid back, free software strategy
Ok, simply the server does all the work and all the world is referred to it... ok, that''s fine.

KISS: Keep It Simple Stupid... right? :-)

Thank you very much for your reply!

Bye Bye
F104/NA
KISS - Keep It Simple Stupid

This topic is closed to new replies.

Advertisement