How to synchronize continuous movement (windmill wheel)

Hi,

what is a good way to synchronize continuous movement over the network? In our case we have a windmill wheel that is constantly rotating at steady speed with powerups between the blades that the player can collect, so it’s important that client and server agree on the position of these powerups. We have client side prediction in place, so generally, player position will be accurate on client at any given time.

I could derive the position based on game time, but will this be 99% accurate, or does game time generally divert between client and server?

Or is there a better way?

Thanks in advance

This is in the AGameState class…
Since it is replicated, it should be the same value for the server and the clients.

    // AGameState member
    int32 ElapsedTime

	//Gives clients the chance to do something when time gets updates
	virtual void OnRep_ElapsedTime() override;

    // Called periodically, overridden by subclasses
    virtual void DefaultTimer() override;

Another option (just in case) may be to use the time to rotate the mill.
For example (GMT 0) → London time should be exactly the same for the client and the server.

It’s just an idea!!
Best regards!!

Game Time is not accurate between client and server. It varies from client to client do to each clients latency.


Time in general is only updated once per frame on the running machine. This includes Timers, Timelines and Delays. The update rate is dependent on the tick frequency(HZ/FPS).

30 Hz/FPS = 33.333ms frame interval
60 Hz/FPS = 16.667ms frame interval

Time incrementation: (Clock Time + Delta Seconds)
Time Deduction: (Time - Delta Seconds)
Delta seconds is the last frames frame rate in ms.

Say I have a timer that runs for 1 second and prints a string.
A client at 30FPS will print the string on the start of the 31st frame (30 * 33.333).
60FPS :: Print on 61st frame (60 * 16.667).
120FPS :: Print on 121st frame (120 * 8.333).


In short there is no way to accurately sync anything. Every client is bound to their frame rate and latency. Thus a client with a 30ms ping will be closer to the servers sim than a client with a 150ms ping.

Player A (30ms) 60FPS, Player B (100ms) 130FPS
When Player “A” moves it happens immediately on their screen do to client-side prediction. Next MoveDeltaSeconds Player A’s client sends the moves to the server. It takes 15ms to get there. Server waits till next tick and processes the movement. The following tick it sends the new moves to player B. This takes 50ms to get to him. The next frame for Player B the moves are processed and simulated. 2 frames later the start of the new movement is rendered to screen.

Base Inherited Delay (time)

  • Network (65ms) :: 15ms + 50ms… packet travel times
  • Processing (65.384ms) :: Server (33.333ms) + Player A (16.667ms) + Player B (2*7.692)
  • Total :: 130.384ms

We are all rendering the “Past” states of actors. How far behind oscillates on each client because our connections aren’t 100% stable with 0% loss. And our framerate is not constant. It fluctuates just as pings do.

2 Likes

That’s 100% dependent on the clients system working correctly.

1 Like

The link is great, thanks for this as well as the detailed explanation!