Brooo this is such a good tutorial holy shit. You pace it so well and come back to summarise so often that I never lost track. I'll be sure to credit you if my project goes anywhere!
Omg, this is a total goldmine. I recently picked up a networking book that has over 300 pages and then I found you. Your way of explaining is awesome. Thank you!
I'm assuming you wouldn't have to even go through each prediction at each update if the updated position is the same as your prediction for that tick. So, not only would you not do reconciliation but you wouldn't re-run simulations if you held onto updated position client-side. Is that correct? I know a lot of the resources touching on this topic haven't really mentioned that either. Your tutorial is the first one that touches on network ticks that I've come across.
@Net_ Thank you so much for these videos, they are awesome! One question that I have is how do you handle a case where a Tick() function doesnt complete in time? From what I am understanding the Tick() function should 1.accept the input change, 2. Run the process movement function, 3. Send updates. But what if all that logic doesnt finish before the next iteration of Tick() needs to be called? ( assuming that Tick() needs to be called 30 times per second). Should each Tick() function be handled by a new thread , allowing Tick() iterations to happen in parallel? thanks in advance!
If a tick overruns the timing window that it needs to complete within, then hopefully a future tick is short enough that it can catch up. If not, you're stuck in a overrun loop and need to either find a way out (shut down systems, kick players, etc), crash, or wait for someone to close the process. Ticks are necessarily sequential, so you can't really process T1, T2, and T3 in parallel. However, you may have individual systems or chains of systems that are independent enough that they can be processed in parallel with other chains. If you google around, you should be able to find some resources on forming dependency chains and parallelizing systems/jobs in game engine programming.
ty for this! I've implemented it and it works great for X left/right position on a platformer. Do you recommend sending information per tick? if 10 ticks pass im at x=speed*ticks but im not sure if its a good idea to send every tick.. but if I do not then my end location is uncertain.. where x=speed*ticks+latency right?
Glad it's working :D If you're sending input state from the client to the server, you only need to send data when an input changes. For example, if the user presses a movement key, you immediately send an input change request to the server. While the user is holding the key, you don't need to send any messages. Then when they release the key, you send another input change request.
How would you deal with fluctuating latency? For example what if package t90 arrives and then package t88 arrives? Or if the server receives them in wrong order too?
Ordering is assumed to be handled at a layer above this by using either TCP or a "reliable UDP" setup to guarantee in-order transmission. If you're trying to avoid those to get absolute minimal latency, you would have to go for a more complicated approach.
Brooo this is such a good tutorial holy shit. You pace it so well and come back to summarise so often that I never lost track. I'll be sure to credit you if my project goes anywhere!
Glad it was helpful! 🙂
Omg, this is a total goldmine. I recently picked up a networking book that has over 300 pages and then I found you. Your way of explaining is awesome. Thank you!
Networking ASMR, nice explaining nice tingles
ikr
What a nice nice nice video, I was having real difficulties to understand this! Thank you very much!
Thank you very much!!
I'm assuming you wouldn't have to even go through each prediction at each update if the updated position is the same as your prediction for that tick. So, not only would you not do reconciliation but you wouldn't re-run simulations if you held onto updated position client-side.
Is that correct? I know a lot of the resources touching on this topic haven't really mentioned that either. Your tutorial is the first one that touches on network ticks that I've come across.
Great explanation!
@Net_ Thank you so much for these videos, they are awesome! One question that I have is how do you handle a case where a Tick() function doesnt complete in time? From what I am understanding the Tick() function should 1.accept the input change, 2. Run the process movement function, 3. Send updates. But what if all that logic doesnt finish before the next iteration of Tick() needs to be called? ( assuming that Tick() needs to be called 30 times per second). Should each Tick() function be handled by a new thread , allowing Tick() iterations to happen in parallel? thanks in advance!
If a tick overruns the timing window that it needs to complete within, then hopefully a future tick is short enough that it can catch up. If not, you're stuck in a overrun loop and need to either find a way out (shut down systems, kick players, etc), crash, or wait for someone to close the process.
Ticks are necessarily sequential, so you can't really process T1, T2, and T3 in parallel. However, you may have individual systems or chains of systems that are independent enough that they can be processed in parallel with other chains. If you google around, you should be able to find some resources on forming dependency chains and parallelizing systems/jobs in game engine programming.
@@net_ makes sense, thank you!
ty for this! I've implemented it and it works great for X left/right position on a platformer. Do you recommend sending information per tick? if 10 ticks pass im at x=speed*ticks but im not sure if its a good idea to send every tick.. but if I do not then my end location is uncertain.. where x=speed*ticks+latency right?
Glad it's working :D If you're sending input state from the client to the server, you only need to send data when an input changes. For example, if the user presses a movement key, you immediately send an input change request to the server. While the user is holding the key, you don't need to send any messages. Then when they release the key, you send another input change request.
@@net_ thanks!! 😄
How would you deal with fluctuating latency? For example what if package t90 arrives and then package t88 arrives? Or if the server receives them in wrong order too?
Ordering is assumed to be handled at a layer above this by using either TCP or a "reliable UDP" setup to guarantee in-order transmission. If you're trying to avoid those to get absolute minimal latency, you would have to go for a more complicated approach.
you can pass sequence data in the udp package which allows you to know if it’s a package from ”the past” or if you should use it