I was wondering how to tackle that subject.
Someone has suggestions on how to tackle this? My main concern is mostly aesthetics and would be used for visual purposes like planets rotation, etc.
So let’s say that 1 hour in-game = 5 min real time, what would be the best way to do this?
1 Like
The question is what depends on that “real time”… Its probably things like your characters thirst, the day/night cycle etc. I’d suggest simply having an AppState that manages this, keeping the time and upping it with a certain factor based on tpf, then all other parts of the application that need the “real time” just ask the AppState. This way its centralized and easy to adapt. Edit: Best keep it as a long or double though, its prone to become quite a large number, or invent your own “time format”.
1 Like
@normen said:
The question is what depends on that "real time".. Its probably things like your characters thirst, the day/night cycle etc. I'd suggest simply having an AppState that manages this, keeping the time and upping it with a certain factor based on tpf, then all other parts of the application that need the "real time" just ask the AppState. This way its centralized and easy to adapt. Edit: Best keep it as a long or double though, its prone to become quite a large number, or invent your own "time format".
Thanks.
The thing is, this is way too complicated for my need. As I mentioned, it's only for graphics-related stuff. Right now my rotation values are so low that nothing moves at all (the base used is 500 years, in seconds) so as you can imagine this gives tiny values.
I guess what I would need is a "multiplicator" that would relate to the "time spent in-game" for each frame so that after 5 real mins (for example) rotation for those objects would be the equivalent of 1 hours.
Does that make sense?
Yeah, if you want to “globally” change the time thats probably the best way. I’d still go with a central app state where everybody else gets the time though 
Probably its better to use Timer.getTime(). Adding up tpf could result in rounding errors when you do it over many frames
I was thinking of doing something like:
Take the rotation time value of object, add the modifier which would be a constant value like X sec in game in 1 sec real time multiplied by tpf.
So let’s say I have a star that rotates about 1 per month.
Sun axis rotation = 6.338798E-11 [ 1 / (15_778_800_000 - rotation in secs) ]
1 sec real time = 1 080 000 secs in game time (5 mins real time = 1 hr game time)
1 080 000 multiplied by tpf should give me the time value equivalence to rotate per frame.
and finally that last value multiplied by the object’s rotation value should, technically, rotate the object properly for the frame.
Does that sound right to you?
What I do, for what it’s worth… is keep track of a start System.currentTimeMillis() and a scale. Current game time = (System.currentTimeMillis() - start) * scale. You could do it in nanoseconds, too. In my case, the game time does not need to be very granular.
And I just have a shared instance that provides this time. I didn’t use AppState because I also use this on the server side where JME classes are only minimally used.
2 Likes
You might have to watch out though… I am pretty sure currentTimeMillis() is changed by the system date/time settings, so the user could go forward or backward in time
Yeah, that’s true. nanoTime() should be insulated from that and I’ve meant to switch. Fortunately, daylight savings time didn’t cause any issues when the game jumped back 60 hours in game time. 
1 Like
@pspeed said:
Yeah, that's true. nanoTime() should be insulated from that and I've meant to switch. Fortunately, daylight savings time didn't cause any issues when the game jumped back 60 hours in game time. :)
And actually, it wouldn't in that case because currentTimeMillis() already accounts for that.
But you are right that a user could mess with their system time directly to affect game time.