Question How would I keep inputs in lockstep?

Assuming I had a deterministic game, can I rely on the server tick/snapshot updates of player inputs to be consistent enough to simulate on?

For example, I have a server system that simply publishes each client's right clicks to one another.

Code (CSharp):

1. protected override void OnUpdate()
2. {
3.     var group = World.GetExistingSystem<GhostPredictionSystemGroup>();
4.     var tick = group.PredictingTick;
5.     var deltaTime = Time.DeltaTime;
6.  
7.     Entities
8.         .ForEach((
9.             DynamicBuffer<LocalInputCommand> inputBuffer,
10.             ref Translation trans,
11.             ref PredictedGhostComponent prediction,
12.             ref PlayerInputComponent playerInput
13.         ) =>
14.         {
15.             if (!GhostPredictionSystemGroup.ShouldPredict(tick, prediction)) return;
16.        
17.             inputBuffer.GetDataAtTick(tick, out var input);
18.  
19.             playerInput.Position = input.Position;
20.         });
21. }

Would something like this system update consistently across the clients?

Code (CSharp):

1. [UpdateInGroup(typeof(ClientSimulationSystemGroup))]
2. public class ReactToPlayerInputComponentSystem : SystemBase
3. {
4.     protected override void OnUpdate()
5.     {
6.         var serverTick = World.GetExistingSystem<ClientSimulationSystemGroup>().ServerTick;
7.      
8.         Entities
9.             .WithChangeFilter<SnapshotData>()
10.             .ForEach((Entity entity, in PlayerInputComponent inputSnapshot) =>
11.             {
12.                 if (!inputSnapshot.Position.Equals(default(float2)))
13.                 {
14.                     Debug.Log($"{entity} input snapshot updated.");
15.                     Debug.Log($"{entity} input value is now {inputSnapshot.Position}.");
16.                     Debug.LogError($"{entity} reacted at tick #{serverTick}.");
17.                 }
18.             })
19.             .Schedule();
20.     }
21. }

 

Doing some more research, they definitely do not react at the same time.

 

Thanks for the reply, so then should I really be using RPCs to guarantee that a client receives a message?

 

Thanks! I was struggling to get it working using the built-in server tick, it's helpful to know about the guarantees

 

In lock step inputs are not synchronized per say.

So first off equating determinism to fixed time step is a common misconception, and also very very wrong.

Deterministic means given the same inputs you get the same output. Time is just an input.

And fixed timesteps are precise but not accurate. OS ticks drift over time, and by quite a lot even over short time periods in terms of amounts that matter in games.

StopWatch might say it took 10k ticks but it was really 9900k ticks. It's precise but not accurate. Your computer's clock can keep accurate time over months and years, but only down to a precision of 100+ms or so.

So a multiplayer RTS game needs a single source for ticks and timestamps, it can't use local time. You can't just offset local time by a server time either, because your local time is drifting.

Now back to inputs. The simulation or simulations are running off of a single source of inputs. So player inputs are just merged in, placed at a specific tick. And then that is sent to the simulation(s) to simulate.

You probably don't really need determinism.


If you just want to control inputs, go back to how OS ticks work above. Clients and server are all running on their own time, there is no such thing as client and server ticks in sync. You apply inputs as they arrive, or some time later. It's really that simple. Trying to reason about this through client/server ticks will just make this difficult to reason about, and won't provide a good solution either.

 

Sorry I'm not 100% I digested what you're describing.

"Now back to inputs. The simulation or simulations are running off of a single source of inputs. So player inputs are just merged in, placed at a specific tick. And then that is sent to the simulation(s) to simulate."

"Clients and server are all running on their own time, there is no such thing as client and server ticks in sync. You apply inputs as they arrive, or some time later. It's really that simple."

So I think what you're saying is that trying to ensure that both simulations execute things on the same "ticks" at the same time is problematic. If I just keep a buffer of inputs on the server, let the server authoritatively decide when the inputs should be executed (maybe scheduling them a bit in the future), and then broadcast those inputs to the clients. That might be sufficient enough?

The clients all run on their own ticks? I'm worried that the client simulations will desynchronize.

"So a multiplayer RTS game needs a single source for ticks and timestamps"

Would that just be the server's job (or the master peer's job) in this case?

Thank you for your feedback, this stuff has been really difficult to understand and get working.

 

How do I address a situation where a client receives a input that should have been executed a few ticks ago? I've been keeping a history buffer of the translations and applying movement through lerping like this:

lerp(historyBuffer[commandStartTick], command.targetPosition, currentTick - commandStartTick / totalTicksToGetToTarget); 

But this has also been causing problems. I can't get the clients to produce the same historyBuffer exactly so the timings for when they arrive have been off.

 

Sorry to necro, but just in case anyone is also working on this type of thing and stumbles across this thread - this book and source code helped ALOT

https://github.com/MultiplayerBook/.../RoboCatRTS/RoboCatRTS/Src/NetworkManager.cpp

 

Btw do u mean when go with lockstep model, we should expect the response speed will not as fast as the current server authoritative with client-prediction model Netcode anymore?

 

Yeah sorry I should clarify that I ended up implementing lockstep using the MLAPI over the Facepunch transport