Novice/Spawn Counter - Ticks not Time
-
Instead of setting novice areas to be real time limited, we should use ticks instead.
In the start areas documentation it shows a novice area example at 23 days remaining. That would be 1,987,200 ticks. Instead of saying 23 days remaining, we can say 1,987,200 ticks left. Or perhaps you can keep it with 23 days remaining but only decrease it per tick so if ticks are 10.5x long at the time, tomorrow it'll still say 23 days remaining.
Adding a field to the room's area would be nice too, showing the current time dilation effect.
In this image I made, the ticks remaining is calculated based on 1 second being one tick. So if you switch the game to use ticks not time, you'll simply do this in reverse, calculating time from ticks assuming 1 second per tick, but you might even calculate time dilation as part of this too and modify the time output to time dilation's value. In this case, 8 hours 7 minutes 4 seconds, at current tick time dilation would be 3d 13h 14m 12s. Then you simply update that value every tick. If you don't decide to use time dilation in the calculation, just tick time down once per tick rather than real time.
Players who start a few days before a server malfunction for example will have 300,000 ticks advantage, and you join on the day of a server slowdown, with 3 days remaining while the other player had 3 days at no lag, but you instead only get 30,000 ticks because of this.
Sure, the novice areas aren't exactly super protected to begin with, but instead of allowing the sever to cut some people's slightly protected time down, you should leave the protection up to the ticking system instead of a real variable. Then you don't need to adjust anything in the event of an outage because instead of using real time, you'll be storing tick times.
-
Because of a debate with people who can't for some reason see how real time is unpredictable, I'm going to explain a little more here.
Shard average seconds per tick, is 3. Severe issues like right now, have it at 10.5-11.
Game.time = ticks, this is a constant. You will always get a tick from Game.time new date = fixed real time, unknown tick.
1000 ticks at 3x is 50 minutes. 1000 ticks at 10.5x is 2 hours 55 minutes.
Guy outside the novice zone has received threats from the guy inside the zone. Guy who sent the threats from inside novice zone needs to prepare an army as well.
They both know that at exactly 8AM server time the novice zone will drop.
Player1, it ends at 1AM his time so he sets his army to start producing 40 minutes before 1AM his time using "new date" while he sleeps. He assumed that, since the server is always 3 seconds per tick, his calculated approach would work and he'd be ready by then.
Player2, its a weekend and 10AM for him when the novice zone goes down. He's awake and sees that tick time is 10.6x. So he starts producing his army 2 hours 40 before novice period ends because he was able to re-calculate the real ticks remaining before novice period ends.
Unfortunately, the guy who set his to use real time, lost the war. Because time dilation screwed up his army production and only 24% of his army got produced before he was hit.
But if tick time is used. Knowing Novice Zone will end at exactly tick 1,000,000. Both players start producing their army at tick 999,000. Regardless of any server speed ups or slow downs. Both armies will produce in perfect synchronization. Regardless of who's asleep and awake, regardless of how bad the tick lag is, both armies will be produced simultaneously and attack at the exact time the novice area goes down.
Real Time, just can't be used to predict what tick to prepare your army at. Creeps live 1500 ticks, not 25 minutes. Don't use real time for things that depend on tick time.
