Move player or move the ground beneath him?

Hi, I’m making a Crossy Road prototype. When player jumps I move the ground back and generate new piece of it in front of the player. So the player does not change his position.
But in all tutorials I found developers make player moves with camera following him. Player moves in infinity.
I was thinking that approach that I took is more appropriate for endless runners.
So the exact question is: what is more appropriate and optimized way to create endless runner: move the ground with player does not change his position or let player actually go with camera attached to him? Or maybe it doesn’t matter at all…

There’s another approach that may suit you: move the player and keep the ground constant, but periodically teleport everything “back” (whatever that means in your context) some distance, ground and player and everything.

The main concern is you should remain within a few thousand units of (0,0,0) at all times, because the further you go, you begin to run out of precision in floating point land, and you will begin to see graphical artifacts such as jitter.

To see what I mean, make a new scene, create and parent a few random visible GameObjects (Cubes, spheres, whatever) together, child a Camera to them to watch them clearly (zoom in), bolt a Rigidbody on them and let them drop. By the time they get to around -5000 you will begin to see jitter between them… the further they go, the worse it gets.

2 Likes

Another thing which might help you is to calculate how long your “runs” are (what’s the maximum run distance).

If you assume that your char runs with 10 units per second (that’s 36 km/h = pretty fast) for a duration of 5 minutes then it would end at 3.000 (5 * 60 * 10). That’s still okay I think. If your runs are sufficiently short then you can get away with just restarting every new run from 0. If your runs are long then you can look into what Kurt-Dekker suggested.

1 Like

And you can get TWICE that distance by starting your runs at negative half that distance!

It is the magnitude difference away (plus or minus) from zero where less significant bits start getting dropped.

It reminds me of going hiking until you’re half tired, then turning around.

3 Likes

Thanks a lot for clarifying

I would stick with the approach you have if it works for you you don’t have to concern yourself with float precision as your player and therefore the camera remain in one place

An “impressive” visualization of this can be seen here taken from here.

2 Likes

Thanks @exiguous
There is an interesting link in there:
https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition@7.1/manual/Camera-Relative-Rendering.html

1 Like