For how long can a Unity game run before failure?

[Niter88]

I’m making an android app, it’s a tool to help some workers with an 3D representation of what he is doing. With that said.

Companies will probably use it like: operator 1 uses it for 8 hours straight, operator 2 assumes it and does the same, then, operator 3. They may use the app for anything between 20 mins or many days and the app must work correctly.

I use Unix timestamps to manage things. So Time.time is not a problem cause I won’t use it, but, I will need to use WaitForSecondsRealtime() on my Coroutines and the most crucial thing, I need the app to work for many hours with no artifacts in graphics, no noticeable performance impact and no crashes.

After research I couldn’t find a specific topic on this, I did found some others addressing that Unity keeps time internally as a double and it could run for many years, but others are saying that a unity game can’t run for 35 hours straight without exploding*.

Some cool discussions I found:

Time class floating point accuracy

I was just wondering if someone could clarify how the Unity timer class addresses floating point accuracy deterioration - and hopefully confirm that I don’t need to worry about it The docs suggest that critical fields such as Time.time and Time.realtimeSinceStartup are simply floats, but if so, that means that their accuracy will degrade over time (as explained here). Hopefully these value are internally maintained as doubles that get converted to single precision upon access?

https://gamedev.stackexchange.com/questions/141807/what-happens-when-time-time-gets-very-large-in-unity

Hypothetical: What happens if Time.time overflows?

*The last discussion has a comment from FIFTYTWO saying he had problems above 35 hours. I imagine that is because of the way he did things and not a Unity feature.

One last thing. Have been using Unity for a long time and I am aware of float precision in Vector3 space and Time.time (thanks Unity for the Time.timeAsDouble <3).

The final question(s).
1- For how long can a Unity game actually run? (not game A or game B, how long the engine itself runs before failure)
2- What causes the time limit?
3- How would I prevent it from crashing or going nuts?
4- Will WaitForSecondsRealtime() lose precision as a float like Time.time or is it internally a double?

Will appreciate if someone provides documentation on that.

[PraetorBlue]

@Niter88

For how long a Unity game can actually run? (not game A or game B, how long the engine itself runs before failure)

Indefinitely as long as you don’t have any memory leaks or issues with floating point precision.

@Niter88

2- What causes the time limit?

Floating point precision issues, as you mentioned

@Niter88

3- How would I prevent it from crashing or going nuts?

I don’t think you’ll get a crash, just wonky behavior if you depend on floating point time.

@Niter88

4- Will WaitForSecondsRealtime() lose precision as a float like Time.time or is it internally a double?

Even doubles lose precision, same as floats, though it won’t become noticeable for a LOT longer.

If you really want it to be floating-point-precision-proof you could implement your own time system based on System.DateTime ticks:
https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-6.0

These use long which is a fixed-point datatype not subject to the perils of floating point precision degradation.

[Niter88]

@PraetorBlue

Indefinitely as long as you don’t have any memory leaks or issues with floating point precision.

Floating point precision issues, as you mentioned

I don’t think you’ll get a crash, just wonky behavior if you depend on floating point time.

Even doubles lose precision, same as floats, though it won’t become noticeable for a LOT longer.

If you really want it to be floating-point-precision-proof you could implement your own time system based on System.DateTime ticks:
https://docs.microsoft.com/en-us/dotnet/api/system.datetime.ticks?view=net-6.0

These use long which is a fixed-point datatype not subject to the perils of floating point precision degradation.

Cool. Yeah, I already use my own Unix timestamps to keep/compare things.
Just wanted to assure the engine itself wouldn’t torn apart graphics or crash.
For the WaitForSecondsRealtime, if it’s internally a double, its precision will entirely suffice my needs, if it’s a float I will have to make my own class to handle that.

[Niter88]

Leaving some info here for future searchers.
An complex Android app with no garbage collector problem, no “Time” dependent scripts, floating precision solved, etc as described later was capable of running for 60 hours straight with no problems. There where no FPS loss, no visual artifacts, no strange behaviors, no math instability, no nothing, it just works as intended.

By complex I mean it is an AR app with mesh building realtime and saving lots of data.

(on Android:) Disable “Optimized Frame Pacing” or it will crash in some android devices after longer periods. Android has a bad habit of turning some things off, things it shouldn’t mess up.