Implementing a fixed tick system

Hi,

Thanks to fholm and others over at gamedev and here I understand how to use, and maintain, a fixed tick system for controlling my simulation over the network. I was just wondering how people go about implementing a fixed tick system on their client in unity.

I understand how to tick at a fixed rate using the canonical fixed time loop. However, given that each element in unity has its own update method, and each might have been instantiated at a different time, maintaining this loop in each gameobject’s update call seems less than ideal.

The way i am currently thinking of doing it is to have a script on the client that maintains the tick, and then calls a Tick method in a given script on each of the relevant objects in the client when a tick occurs. When the object is instantiated I will register them with this script and therefore I can call Tick on each of the objects in the client during the same game loop?

Does this sound sensible to people, or am I overly complicating it!

Thanks

Matt

Unity already has a fixed game loop internally, which you can subscribe to by implementing the FixedUpdate function in a MonoBehaviour: Unity - Scripting API: MonoBehaviour.FixedUpdate()

It felt a bit wrong to use that one because I may want to run my physics at a different rate to my simulation. I cant think why, at the moment, but wanted to keep that option open.

The physics is your simulation.

To be honest, you really shouldn’t be using physics in a fixed time step system. Determinism being the most important part, is not guaranteed with the unity physics system. If it isn’t simulation specific, you can still use the fixed time step to match your needs, just do your lerping

I think you have the concepts deterministic, lock-step and fixed-step simulations confused.

Maybe I shouldn’t respond when i am tired, lol.

From what I am reading, he is trying to implement a lockstep system. Which needs to be deterministic. Objects still need to be updated between each lockstep “tick”, which is “fixed” using the “fixedupdate”.

He is wanting to use physics, which is NOT deterministic in the sense of a client simulation. If he plans to use physics on non-critial elements, he can do it just fine using fixedupdate.

There is no mention of lock-step anywhere in the original post, “ticks” in this context I assume refers to the numbered simulation ticks on a client and/or server, and has nothing to do with lock-step or a deterministic simulation.

and shows my lack of reading comprehension :wink:

Yep, no lock-step just ticking!

Thanks for all the replies. If I did use the fixed update I guess I need to ensure that I use a consistent tick number for the fixed updates, so that will require some jigery pokery considering you can’t determine the order that objects are processed in a game loop…

Infact, thinking about this further, I don’t really need a centralized tick at any point on the client as the only object that will be sending messages, rather than just receiving them, is the player. So each of the proxies can just maintain their own, local tick, and as long as each of them keep their tick in “sync” with the server from the messages they receive their tick number is arbitrary as it will only ever be used by them so only needs to be relative to them. The only time I need to know anything about them on the server is when I rewind them, and at this pont I will be using the server tick anyway. I think. Hopefully.