I have this game I’m working on, I have a script that plays the game in order to test it, so you could say the game plays itself. Since the game plays itself with the same inputs every time, I should be getting the same result over and over again until I made a change in the game’s logic, however every time I play it I get a different result. To make things even more puzzling, only one script on my game has a FixedUpdate function and all the physics related calls are made there, there are no Update functions either, so the possibility of execution order related issues is practically nil.
Determinism is in a critical issue when you are making a movie and the guys that developed the Unity Recorded know that, so they obvious put some effort to ensure Unity behaves in a deterministic way when you are recording. I know that because when I use the recorder to record my game play I always get exactly the same results, so there is in fact a way to force Unity to behave fully deterministic and it would be great if someone cloud just share the secret.
When you update objects via unity’s update loop in FixedUpdate, you are letting unity take control of the reins in terms of when to update your objects and how. Even though it’s in fixedupdate, the circumstances in which fixedupdate is called may change. The way to overcome this is to take complete control of how your objects are updated. You can turn Physics.autoSimulation off and update it manually using Physics.Simulate. If you make sure that the way in which you update the physics is totally deterministic, with deterministic values, it should play back deterministically.
I have a main controller object to which all other physics objects suscribe, the main controller uses FixedUpdate to decide which objects to update, when and in which order. This way, no matter how many objects are in the scene, Unity makes one and only one call to FixedUpdate per physics frame to this unique object. Also theoretically FixedUpdate is called at regular intervals and is frame rate independent, so I have good reasons to think and believe I’m having full control of the process, and thus to expect a fully deterministic behavior. In theory, under this circumstances and in this particular case Physics.Simulate should not have any effect, and in the practice it doesn’t.
I followed your advice and disabled Auto Simulation and called Phyics.Simulate manually, first inside FixedUpdate, and then copy/pasted the example that comes in the Unity’s documentation, but in neither case I’m getting even close to a deterministic simulation. So obviously, the guys that developed the recorder are doing something else to achieve determinism.