āreal timeā and āsimulation timeā are two different things.
So if you donāt play the game for a year but a yearās worth of time must pass then use real time. If you want to know how much simulation time has passed, ie: time when the game was actually running then use SimTime.
Do note that System.nanoTime() is also not āreal timeā. It has no direct basis on system time. You have to use System.currentTimeMillis() if you want actual real time.
Iām trying to understand when this would be useful, though, unless the game continues to āplayā even when itās not running somehow.
Edit: note⦠I do see that there is no settable bias which makes it a little tough to continue a game where one leaves off. Unless Iām overlooking something, thatās going to be a problem for me also.
Googling this I noticed System.currentTimeMillis() is based on a fixed origin but can be affected if the user change the machine time. (i.e easy to cheat)
I am not sure which one I should use then. I do not need the actual real time, just want to know the time passed since the last saved time. (Could be that player left the game, stopped JVM and turned of the machine)
nanoTime() is using a CPU counter. Historically it could even be different from CPU to CPU which was really interesting when threads would hop around. I count on the fact that theyāve fixed that. But itās starting point is still arbitrary.
SimTime needs an easy way to force set the offset. (ie: back-date the base time) This can be faked with the existing API but itās not what Iād consider straight-forward.
When your game shuts down, get the time: getTime() and save it.
When the game starts up again, instead of letting the default update(System.nanoTime()) initialize SimTime, initialize it yourself with System.nanoTime() - timeYouSaved⦠which should back-date the base time.
Edit: note that I have not looked to see if the rest of the GameLoop/GameSystemManager makes that easy at all.
Do you mean single execution of the JVM? Does the arbitrary value change when I start a new instance of the JVM?
If it changes then saving the last time will not be safe.
Edit:
from javadoc I noticed
The same origin is used by all invocations of this method in an instance of a Java virtual machine; other virtual machine instances are likely to use a different origin.
So it is not safe to be used in my case. I will use currentTimeMillis() as suggested.
You canāt really prevent cheating there, unless you take the time from some āweb time APIā or something and even then I can proxy that or just patch your class.
So if that really is a concern, it needs separate consideration.
NanoTime is probably based on some QueryPerformanceCounter stuff from the Windows API (or depending on the OS), so I would look around what they do.
That will back-date to the time player left the game and will ignore the time that has passed since the player was not in the game. So I still need to add to it the time passed since the last login. (maybe I need to add a REST API to save the game session start/stop time. Similar to web API Darkchaos mentioned)