- Home /
Fixed Update dobut - Gameplay Save
Hi! I'm developing a drive simulator for my degree thesis which is synchronized with an eyetracker. I have to record the "gameplay" to replay it after (like a demo) and sync with the eyetracker output. I'm using "FixedUpdate" for the motion of my model and here i take the input of the controls, if it have changed, i save it in a db. My question is if FixedUpdate can start and be "cutted" by the next "FixedUpdate", because when i play in the simulator, it behaves in one way and when it replays it is different I'm using timestamps and the variation is minimal, that's not the problem
Can you advice me about a better way to save the gameplay?
Thanks in advance!
Are you accounting for the fact that fixed update can be run multiple times per frame?
It sounds to me like you're putting input in based on real time and not simulation time. You might get better results if you count the number of fixed updates and use that as a "timestamp" ins$$anonymous$$d.
I think the method is a common way to repeat gameplay: set all starting values to the same at the start, then input the same data. Seems logically sound either way.
Thanks a lot for your comment! I'm using "Time.timeSinceLevelLoad" as the timestamp, that (i supose) will cover the fact that can run multiple times per frame. I'm right?
I think thats a likely cause of your problem. Try swapping it for a frame number or something.
Imagine in the first simulation you get your 60th frame at exactly 1s (in real time). It is very unlikely that in your second play you'll get your 60th frame at exactly the same time. Although Unity's physics simulation is 60fps*, the actual "real" time of the 60th frame is unlikely to be exactly 1s in (due to background tasks, cache misses, cosmic rays, etc).
*Note that 60fps is a default. On a side note, since it seems like you care more about accuracy of the simulation than graphics fps, you might want to consider increasing the physics fps (if you haven't already)
Tarlius You are the best! You've found my problem! I gonna try to solve it like you've said.
I've post in here if i solve the problem, thanks a lot!
Answer by Tarlius · Sep 11, 2013 at 03:33 PM
Are you accounting for the fact that fixed update can be run multiple times per frame?
It sounds like you're putting input in based on real time and not simulation time. You might get better results if you count the number of fixed updates and use that as a "timestamp" instead.
I think the method is a common way to repeat gameplay: set all starting values to the same at the start, then input the same data. Seems logically sound either way.
Try swapping it for a frame number or something.
Saving the input might be problematic if the game relies on physics; collisions etc. Unity's physics are non-deter$$anonymous$$istic (as far as I know), that is, the same collision could have slightly different consequences on different runs. For platformers, and possibly racing games, it is possibly a valid idea.
I always assumed they were deter$$anonymous$$istic. If not I think its going to have to be faked somehow (if I've interpreted the question correctly). It'll be like a networking problem I think.
Any sources on that? (googling now!)
No other sources than my memory. I remember reading an answer here that stated the same with convincing arguments...
You are correct. I hunted around and found more hearsay, but there it is from the source. Stuff like this is what makes doing all this worthwhile! The strategy I was suggesting is apparently called "lockstep" and depends on deter$$anonymous$$istic physics, which PhysX is not.
As for the question... Whether this remains viable will probably depend on how long the simulation runs. But, given this new info, a sampling strategy seems more "correct". Neither will be an absolutely perfect reproduction, but neither is digital audio but we all use it anyway! ('cept those audiophobes who claim they can hear the difference. (Spoiler: they're lying))
Tarlius, maybe I've rushed when i've said that you completely solved my problem... The problem is the one that you said but i don't know how to solve it.
How do i get the phisics frame count? That would be the best fix!
Thanks in advance!
Answer by Jamora · Sep 11, 2013 at 03:39 PM
Because this was such an interesting question, I'll post my solution too.
The problem of tracking eye motion or gameplay is the same as of recording music or any analog signal. You'll need to set a sampling rate, the key being that you have a set amount of samples per second. You can then interpolate between the samples to reproduce the movement. Using frames as the measuring stick may cause problems because the frame rates could be different during subsequent runs.
I would first attempt at storing values would be something like this:
public class SampleTaker : MonoBehaviour{
List<Sample> samples; //needs initialization
public static int frequency = 44000f;
float sampleRate = 1/frequency;
public void StartTakingSamples(){
//Start the coroutine or use Invoke
}
public void EndTakingSamples(){
//End the coroutine/invoke
}
IEnumerator TakeSample(){
//record position of car and eye
//store in samples list
yield return new WaitForSeconds(sampleRate);
}
}
public struct Sample{
public readonly Transform carPosition;
public readonly Vector2 eyePosition;
private Sample(Transform newCarPosition, Vector2 newEyePosition){
/*set values*/
}
public static Sample CreateSample(Transform carPosition, Vector2 eyePosition){
return new Sample(carPosition, eyePosition);
}
}
And to play them back I would just Lerp the transform/Vector2. Because we know the sample rate, playback can be done to accurately replay the motions.
Notice that Sample is actually a struct. They're faster to create than full-blown classes, but depending on your sample rate, may cause a stack overflow. If this happens, you will have to make them a reference type as well.
Using frames as the measuring stick may cause problems because the frame rates could be different during subsequent runs.
Its possible that I misinterpreted the question, but it sounds like he wants the simulation exactly the same from a given input. Physics frames are guaranteed to be a set fps so processing an input at (physics) frame 60 should always give the same result.
Yes, FixedUpdate could work as well. I was referring to the normal Update.
Your answer
Follow this Question
Related Questions
How do I stop the trees from rotating during gameplay? 2 Answers
How can i disable WMA playback on my PlayStation 3? 0 Answers
How to do screenshake without influencing the transform of the camera? 2 Answers
Making a game with two types of gameplay 1 Answer
Send live camera from Unity game play to youtube or vimeo 2 Answers