Doppleganger mimicking player's every move

0 favourites
  • 11 posts
From the Asset Store
This is a code so you can see the same skin on all screens (peers). Each peer gets a skin, in addition to 4 directions t
  • Recall one of the final stages in Rayman, where there is this doppleganger following you and mimicking your every move?

    Subscribe to Construct videos now

    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,

  • 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 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


    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 )


    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 )


    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 )


    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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)