Need zones time progress
Opened this issue · 2 comments
For some odd reason, in-game time sometimes progresses faster or slower than the time in the "Need zones" feature. This may be because of the phone's hardware or because of how the game is programmed. I can really do nothing about it. You will have to adjust the time now and then.
So I have done some testing regarding this issue. From what I have found, the problem is not in the app, but unfortunately in the game. When I first programmed the Need zones feature I roughly estimated that 1 in-game minute should be 15 real seconds. It is not actually.
I was trying to adjust the in-app second for a long time. I did some really minor testing so the results were not correct. The last change was done in the version 1.6.1 to final int _inGameSecond = 993333. This is in microseconds so it is 15 * 0,993 seconds for 1 in-game minute. Like written, it is not correct unfortunately.
So I have done bigger testing instead. I was testing how long is 1 in-game minute in real seconds. I used Windows' stopwatch. As this was done manually by me, I believe that I kept somewhat same reaction time to mark the seconds. I was recording the seconds for each in-game half hour. The time span was 10 in-game minutes. E.g. 11:00 - 11:10, 11:30 - 11:40, 12:00 - 12:10, etc. I tested some hours twice or thrice as I was not sure about the results after the first iteration. Especially from 0:00 to 5:00. What I have found out just surprised me a lot. Everything can be found in the graph below.
- X axis - in-game hour
- Y axis - number of real seconds per one in-game minute
The GREEN line shows exact 15 seconds.
The RED line shows what I have collected from the testing. You can see that for each half hour, 1 in-game minute is not exact real 15 seconds. I honestly do not know why the game works like this. It is a rollercoaster, not gonna lie.
- Between 0:00 and 3:30, in-game minute lasts in average for about 15,011 real seconds. In this case, one real second equals to 1,0007 in-game.
- Between 4:00 and 15:30, in-game minute lasts in average for about 14,933 real seconds. In this case, one real second equals to 0,9956 in-game.
- Between 16:00 and 23:30, in-game minute lasts in average for about 15,327 real seconds. In this case, one real second equals to 1,0218 in-game.
The BLUE line shows overall average of collected data. Based on that, in-game minute lasts in average for about real 15,0778 seconds. This means that my app should have 1 second as 1,0052 instead. Even though it does not seem like a big difference, for some, this is actually a problem. To show this, the in-app time would be around 4,5 seconds behind per 1 in-game hour. That could add up to around 7,5 minutes per 1 in-game day.
Interesting discovery. From what we know and can see in the graph the day lasts from 5:00 - 19:00, and night from 19:00 - 5:00. In my case, the day lasts for about real 3h 30m, and the night lasts for about 2h 32m. That makes the day longer for about 58m. Whole cycle lasts for about 6h 2m obviously.
Now, to fix the issue I have 2 options.
- First I can use the overall average value - 15,0778s. In this case at some time the app will fall behind but later on it will catch up again and will be ahead eventually.
- Second option would be to divide the time into three sections and use the three average times mentioned above - 15,011s, 14,933s, and 15,327s. I think this would be the better solution as it will reflect the in-game time more accurately. Upon that it will probably not fall behind or be ahead.
I will probably go with the second option as many users would probably complain a lot more, than now, if the time would fall behind, or would be ahead, that much. Keep in mind that there are still hardware limitations, even though they should not affect this too much.
The problem above was partially solved by adjusting the time progress. It is better but still not great. I will work on it further.