Time Scale Correction [2006.10.14]

Problem
Solution

Problem

This is a small report that addresses the difference between game time and real time. Jijun has discovered that game time runs faster than real time, exactly:

(Game Time) = (Real Time) * 1.11

It means that when the real clock shows 1 second, the game clock shows 1.11 seconds. The entire game runs a little faster then real world. Sensory data are delivered with an higher frequency and timestamps use the game time. This is not necessarily a problem, but you have to take it into account if you want to match simulated world with real world.

The biggest problem, however, is that physics and game time are not in sync. Game physics uses the real clock. So, the overall effect is:

• Game Time runs at (Real Time) * 1.11
• Physics Time runs at (Real Time)

Example:

If you let an object fall from 1000 unreal units (20m) under the gravity of 950uu/s^2 (19m/s^2), the falling time will be 1.45 seconds. Using a real stopwatch you will confirm that time. However, using the game time, you'll find in your log file a different value: 1.61 seconds.

Solution

There's a console command that can change the game speed:

slomo T

where T is a floating value indicating time scale. For example if T = 0.7 the game will run slower, if T = 2 the game will run twice faster. This command alone, however, is not enough to correct the time scale problem. In fact, if you try to slow down the game issuing a "slomo 0.9", you will correct game time, but physics time will be slower now. You will have:

• Game Time runs at (Real Time)
• Physics Time runs at (Real Time) * 0.9

that does not solve the skew between game and physics time.

Luckily we have another degree of freedom, thanks to the following variable:

KarmaTimeScale, a property of LevelInfo

Its default value is 0.9. As the name already states, it controls the karma time scale (KTS from now on). The idea is to raise KTS and then lower slomo. Before doing that it's a good idea to trace a graph that shows how slomo influences game and physics time. Graph data are obtained from the following experiment:

• Take a bullet, put it at 8192uu and let it fall to 0 (same test as in gravity test).
• Measure the falling time both with a stopwatch (physics time = real time) and using game logs (game time).
• Make this test with slomo ranging from 0.25 to 2.0 (a step of 0.25 should be enough)
• Make this test with KarmaTimeScale = 0.9 (default value) and KarmaTimeScale = 1.0

Ok, this is the result:

This graph shows us what we were searching for, an intersection point. This point is always located at slomo = 0.9. Moreover, the effect of KTS is, roughly, to translate the graph up and down. We know that the right falling time for the bullet of the above test is:

so we want an intersection point located at (0.9, 4.15). As the game time has a strange behavior for slomo < 1.0, we have to do some test before guessing the right KTS value. On my PC I found:

KarmaTimeScale = 0.99

So, the correction can be done changing USARDeathMatch script in this way:

function PostNetBeginPlay()
{
	Super.PostNetBeginPlay();
	
	Level.KarmaTimeScale = 0.99;	// <-- Added this line
	Level.Game.SetGameSpeed(0.9);	// <-- Added this line
	...
}

Now physics time, game time and real time are all in sync.