I am making a racing game and am looking to record and playback previous races.
I’ve looked at this forum question and it seems the best way to go about this is to save position and rotation each frame.
I was wondering what the best way to go about this would be, I’ve seen implementations of more complex data being saved through JSON but was unsure if this was too much for my application as it seems a lot of unnecessary data is stored along with the variable, especially with potentially 360 floats per second. This also required the Vector3 values be stored separately.
I would like this data to be stored in a file as it is important that it remains after closing the game.
I’d say this… at 360 floats per second. We’re talking about 850KB per 10 minutes of recording. That’s not a lot of data in today’s terms.
So I’d say don’t record it to json in real time. Store it away into a collection of something (List, whatever), then save it at controlled points. Like when the race is over, or when they quit, or whatever. Then do the heavy lifting of converting to json and writing it to disk.
My point is that the KB KiB thing is a very contemporary thing and is to this day (not just by MS) a thing that varies from user to user/brand to brand/etc to etc.
::emoji of questionable sarcasm?::
But yes, at OP… KiB is the more appropriate abbreviation if you want to get technical (or maybe KKB, or kB, or just k, or bK, or the many other contested abbreviations). My original point to you is that 864000 / 1024 works out to sub 843.75 KB (ahem… KiB), making it under 850.
I would suggest saving out as a csv instead of a JSON. JSON is useful for complex data structures, but all you are recording here is a series of floats.
I do half the job in trend.me if you want something to start with. It will let you hook up to an arbitrary float, then record its value each frame, then saves it as a .csv. It only takes a few minor adjustments to get it to read and save multiple floats.
This would be how I would approach it, not sure if it’s the best approach.
Have a buffer list to store every 10 seconds (or some other sweet spot) before appending it to a csv file. As @Kiwasi has said, JSON is troublesome as you need to take care of the formatting and therefore can’t do a simple append.
At the end of the race (when recording stops) do a compression of the csv file to make the file smaller. Find a compression library that is compatible with the platforms you are after.
I realize that you can’t just record position and orientation, you probably have many more variables to save in order to replay realistically.
In which case you should serialize it to json or xml.
Create a class with all the data you want to store, perhaps call it ReplayClip. Make it serializable.
Identify the biggest number of seconds you can comfortably store in memory. Every this amount of time, save the class as a json file through serialization and clear it from memory.
At the end of the race, deserialize all the json chunks into multiple instance of the ReplayClip class.
Create a class to hold all these ReplayClips and play them in sequence, perhaps call it ReplayMovie. Make this class serializable. ReplayMovie will have methods such as play(float time), pause, stop() etc.
Serialize it into compressed binary json and delete the ReplayClip JSONs.
If ReplayClips are too large for the device memory, you could make ReplayMovie stream the ReplayClip by deserializing the ReplayClip json one at a time during play(), each time unloading the previous from memory. Therefore the ReplayMovie contains only one (or a few) active instances of ReplayClip and only stores the paths of all the ReplayClip json files.
