Endless runner: Could there be an overflow?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By mydoghasworms
:warning: Old Version Published before Godot 3 was released.

If you make an endless runner, in which the player keeps moving in one direction, is there a chance that there might be an overflow in one of the position values, causing the game to crash eventually?

Endless runners are, to my knowledge, usually made with the runner being in a fixed space and the environment moves around them. The environment objects can be wrapped around or destroyed when they leave the viewport.

indicainkwell | 2016-11-02 22:39

And if not in a fixed space, they have phases, or levels, or ways to rotate so the player stays in the same big area.

Zylann | 2016-11-03 00:09

@indicainkwell This is what I have been doing, but I have found that trying to move everything else relative to a fixed point is such a headache, and then it seems that parallax scrolling does not work, because the camera also stays in one place. (I’m new to this, so maybe I’m missing something?)

mydoghasworms | 2016-11-03 04:28

You could also move all stuff backwards at some point, so from a global point of view your character advances, but warps back to the origin. But from the point of view of the player, nothing changes.

Zylann | 2016-11-03 20:09

You could structure this with a top level node called like ‘environment’ that will handle your base scrolling behavior and also communicating with your parallax layers. The node could be scrolled by pages (a whole screen) with some padding on the sides. At the beginning or ending of a page, give off a signal, arrange your next page, and then reset your positional values to avoid overflow.

Take this with a grain of salt because I’ve never actually created an endless runner before.

indicainkwell | 2016-11-03 23:34

:bust_in_silhouette: Reply From: volzhs

int range is –2,147,483,648 to 2,147,483,647.
so… even moving 10,000 pixels for 1 second speed,
it will take over 59 hours (214748÷60÷60) to be a problem.
is it enough to be an endless runner?

I would say float range precision loss since positions in Godot are floats, not ints :stuck_out_tongue:

Zylann | 2016-11-03 00:08

Thanks. I guess the right thing to do for me would be to keep what I have now (everything moving around the character) and handle all the scrolling of backgrounds etc., myself. But that is interesting, thanks.

mydoghasworms | 2016-11-03 05:01

:bust_in_silhouette: Reply From: eons

Everything not in sight, does not “exists” in an endless runner, just stuff a bit close and about to be in the camera zone.

Can be optimized to use just a small pool of instances that enter and exit the tree all the time… can’t help but to remember the “army” running in circles in Top Secret! xD

Thanks. As per my comment to indicainkwell, I have been putting the player in a fixed position and moving everything around it, but calculating the relative positions has been a headache, and then I found that parallax scrolling does not work because the camera is standing still.

mydoghasworms | 2016-11-03 04:31

The “Splash Screen” demo use a simple parallax simulation with sprites and an animationplayer on a fixed camera.
That can be done with just moving the texture regions at different speeds too.


There is this crazy approach using paths for endless runners (maybe too much for beginners) https://twitter.com/fischspiele/status/780886581469179904
This technique can work fine if you make blocks of “screens” and change the contents when restarting the path.

eons | 2016-11-03 11:53