Endless runner game: Dynamic world vs Static world [duplicate]

I've seen a lot of tutorials on how to build infinite runners and came up with a question about game optimization.

This types of games are built on two ways, according to my research; these are:

1. Set the player and camera static. Usually on the origin of the world space, and have all the environment assets created on the distance and move them towards the user.

2. The environment assets are created on a straight line to infinity and the player and the camera both move forward until the player loses. This means the environment's position will not be changed once they are created.

My question arises from here. Which of the two involves less calculations? Which one gives the player a better feel of movement? Is the difference actually significant (in terms of performance) or is it just a trivial question?

• Question title does not match question body. Please check and fix that Aug 12 '16 at 4:47
• The computation cost should be equivalent in either case when comparing to other more computationally intensive parts of the game, i.e. physics and graphics. This is not an issue for you at this time: it is premature optimization and you should focus on releasing your game :) Keep profiling. Aug 12 '16 at 12:02

Although it may seem more intuitive to move the player object forward, it can lead to problems of numerical instability. If the runner is truly 'endless', then you can, at least in theory, end up with a player at a position with very large values. I'm basing this on experience with Unity specifically, and you can see this answer for more details:

So finally, I would suggest that you either have the player and camera static and move the obstacles toward them like a conveyor belt, or that you move the player forward up to a certain limit before resetting. In both cases, you would generate your obstacles ahead of the player by either a fixed or random offset, before either moving them or the player closer, which allows you to limit your worries to just the player's position in the world.

I'd say to move the player/camera. It will probably be easier, and at the very least it's generally more intuitive to move the player rather than the world.

In terms of number of calculations, I'd say the effect would be minimal, but if not ( your scene has many, many objects) it would tend towards moving the player: Moving the player means moving one thing, moving the scene means moving everything that's part of the environment.

In terms of "feel of movement," the two should produce the exact same visuals if done correctly.

(Interesting piece of info: OpenGL's "camera" is locked in one position, so if using it you do at some point have to move the world around the camera. However, in my experience at least, it's pretty simple to have my own user-defined Camera object even so, as the OpenGl camera is only 1 matrix multiplication away.)

• IIRC in old OpenGL camera was adjoined with Model into glMatrixMode(GL_MODELVIEW), but in modern GL it's up to you to choose how to structure it. Common approach is MVP. Aug 12 '16 at 8:25

Think of flappy birds, the pipes move towards you. I know this is not exactly what you are making but just bear with me.

When you allow your player to be static, you can cheat a little (Nice right?) and have the player only use animations for running, sliding can be done using a "pixel perfect" collision, so again... a sprite just changes, and the sprite image is smaller (Neeto). Now jumping is just done like a platform jump, with an animation to make it look like you are keeping momentum.

Now i built a similar game in GameMaker, and at first the player moved. But think to yourself, why? why move the player etc. Just have the world around you move. Flappy bird did a good job of this by having the pipes spawn slightly off screen and delete themselves slightly off screen.

To sum it up

Have the player and camera stay still. I believe youl find it easier, have a nicer finish and less "mess" to worry about.

• This answer does not provide any arguments Aug 12 '16 at 8:21