(SOLVED/NA) delta_time Acceleration In A Frame Dependent Game

[Drell]

I can't seem to find a solid resource that really clarifies how to properly and accurately calculate acceleration values relative to delta time. Due to my game being a competitive 2D fighter using rollback netcode (meaning the game play is frame dependent and hosted on each machine rather than having one machine serve as server), it absolutely must respond to all inputs exactly the same way every single time. While I'm able to think of logical solutions, I need a mathematical one to implement in the code. All help is much appreciated!!

 

[YellowAfterlife]

If movement is done via

position += velocity * dt;

(or equivalent), acceleration is done via

velocity += acceleration * dt;

when gradual (e.g. gravity) and via

velocity += acceleration;

when momentary (e.g. jumping)

However, when you have lockstep or rollback networking, your "delta time" must be a constant value, or the game will not advance identically between players.

Also, consider editing your signature - not only is it animated and 2.5x over the height limit (guidelines), but the GIF is also 9MB.

 

[Drell]

However, when you have lockstep or rollback networking, your "delta time" must be a constant value, or the game will not advance identically between players.
.

This is pretty much what I keep coming to as a conclusion, in which case, wouldn't that effectively defeat the purpose of even using delta_time?

 

[GMWolf]

However, when you have lockstep or rollback networking, your "delta time" must be a constant value, or the game will not advance identically between players.

thats not really true:
you only consider the latest packet received, and then extrapolate from that to predict where the payer currently is.
or at least, that s how most online networked games do it.

 

[Drell]

thats not really true:
you only consider the latest packet received, and then extrapolate from that to predict where the payer currently is.
or at least, that s how most online networked games do it.

That seems reasonable, but what's the point? Is delta_time going to be significantly smoother if the netcode is constantly rolling back/forward both players to compensate for the discrepancies in their processing capabilities? That is, if the game is already running at 60fps and synchronizing player inputs across the network (i.e rolling back frames to compensate for frame drops), does the purpose of delta_time outweigh the potential for bugs it presents?

 

[YellowAfterlife]

This is pretty much what I keep coming to as a conclusion, in which case, wouldn't that effectively defeat the purpose of even using delta_time?

You could still use it for local game modes, but you'll have to make the game run at target framerate online (or things would look unusual when one of the players can't run the game at target framerate, causing the rest to wait for them every now and then), so it becomes largely only beneficial if you want to allow running it at arbitrary (e.g. >60Hz) framerates.

thats not really true:
you only consider the latest packet received, and then extrapolate from that to predict where the payer currently is.
or at least, that s how most online networked games do it.

That is not the case with mentioned networking types. Rollback is lag compensation through predicting player inputs (rather than extrapolating), and rewinding-replaying with the right inputs when they are discovered to not match upon receiving.

 

[GMWolf]

That is not the case with mentioned networking types.

yep, you are right. I just realised that before you replied. derp.

 

[Drell]

Thanks all; for ease of access, I'm just gonna abandon delta_time for now and maybe re-implement it for local gameplay during the beta phase. Thanks for clearing this up for me!