Doppleganger mimicking player's every move

Recall one of the final stages in Rayman, where there is this doppleganger following you and mimicking your every move?

I used to make something like that in other game engine that has fixed framerate, so I simply record all of player's moves, and then "inject" all these movements to the doppleganger x seconds later.

But in C2, with event running every tick and variable framerate, the method above is not possible. So in variable framerate game, ...how?

If all your actions use delta time using seconds won't be a problem.

LittleStain It would be a problem.

Imagine you are running around with 60 fps for now, then suddenly, the game drops to 20 fps for whatever reason. So here, your inputs are logged from 60 times a second and 20 times a second respectively.

If you feed your doppleganger's input that is 60 times a second in a 20 fps situation. The position of the doppleganger will be off.

See the problem?

I always thought that frame rate independant meant that things happened at the same time regardless of framerate, but I could be wrong..

LittleStain check out koonsolo.com/news/dewitters-gameloop and you will know what I meant.

C2 decided to go with the "Game Speed dependent on Variable FPS". So to tackle this problem, we need some ways that make the values identical in every run.

Like I tried to explain before, using delta time construct2 uses the "Constant Game Speed independent of Variable FPS"

LittleStain Read this part from the link carefully:

low Hardware

Slow hardware can sometimes cause certain delays at some points, where the game gets ?heavy?. This can definitely occur with a 3D game, where at a certain time too many polygons get shown. This drop in frame rate will affect the input response time, and therefore also the player?s reaction time. The updating of the game will also feel the delay and the game state will be updated in big time-chunks. As a result the reaction time of the player, and also that of the AI, will slow down and can make a simple maneuver fail, or even impossible. For example, an obstacle that could be avoided with a normal FPS, can become impossible to avoid with a slow FPS. A more serious problem with slow hardware is that when using physics, your simulation can even explode

!

Fast Hardware

You are probably wondering how the above game loop can go wrong on fast hardware. Unfortunately, it can, and to show you, let me first explain something about math on a computer. The memory space of a float or double value is limited, so some values cannot be represented. For example, 0.1 cannot be represented binary, and therefore is rounded when stored in a double. Let me show you using python:

>>> 0.1

0.10000000000000001

This itself is not dramatic, but the consequences are. Let?s say you have a race-car that has a speed of 0.001 units per millisecond. After 10 seconds your race-car will have traveled a distance of 10.0. If you split this calculation up like a game would do, you have the following function using frames per second as input:

>>> def get_distance( fps ):

...     skip_ticks = 1000 / fps

...     total_ticks = 0

...     distance = 0.0

...     speed_per_tick = 0.001

...     while total_ticks < 10000:

...             distance += speed_per_tick * skip_ticks

...             total_ticks += skip_ticks

...     return distance

Now we can calculate the distance at 40 frames per second:

>>> get_distance( 40 )

10.000000000000075

Wait a minute? this is not 10.0??? What happened? Well, because we split up the calculation in 400 additions, a rounding error got big. I wonder what will happen at 100 frames per second?

>>> get_distance( 100 )

9.9999999999998312

What??? The error is even bigger!! Well, because we have more additions at 100 fps, the rounding error has more chance to get big. So the game will differ when running at 40 or 100 frames per second:

>>> get_distance( 40 ) - get_distance( 100 )

2.4336088699783431e-13

You might think that this difference is too small to be seen in the game itself. But the real problem will start when you use this incorrect value to do some more calculations. This way a small error can become big, and <img src="smileys/smiley35.gif" border="0"> up your game at high frame rates. Chances of that happening? Big enough to consider it! I have seen a game that used this kind of game loop, and which indeed gave trouble at high frame rates. After the programmer found out that the problem was hiding in the core of the game, only a lot of code rewriting could fix it.

Anyone else?

I'm sorry, I thought you wanted a frame rate independant game, so you could call actions in seconds (or parts of it) instead of per tick.

I must have misunderstood.

Although This is not exactly what you are looking for it might give you some ideas, especially the capx Rojohound posted.

Lerp function! OK, rojohound's solution is what I am looking for. I can extend from it. Thanks LittleStain !

You can take dt into account when recording player movements and replaying them with another object. Take a look at this example. The example is for a braid-like rewind effect that takes dt into account when recording/rewinding. It could easily be modified to create a doppelganger effect. Instead of "rewinding" the recorded movement data, you can just replay the recording on a delay.

If the game's frame rate differs greatly when recording vs. rewinding, the replay can look choppy, but you could probably smooth it out by tweening the recorded data.