2D Infinite Runner : how to manage background layers?

Question

First of all, sorry for this post, I guess this already has been discussed. I browsed stackexchange and the web but I couldn't seem to find a clear information for my case, with always mixed results.

So I'm making a mobile game with Unity, and am re-starting the development from the beginning in order to have smooth performances. The game is a 2D runner (Canabalt style). Though there will be two modes :

• One story mode with about 12 levels precisely designed which will be always the same
• One arcade mode with randomly generated level (platforms).

Main features :

• Back and Foreground Parallax (5-6 layers totally, with different movement speed)
• Automatically running, manually jumping over holes and attacking ennemies

So I have a few interrogations :

• The classic question : should I make it like a theadmill, having a fixed player position, and making the level move forward. Or should I be moving the character as the camera follows him ? Given the fact that I want multiple parallax background. Are there differences performance-wise ?

• A linked question : should I use the perspective camera and play with the Z axis ? or keep the orth camera ? I'm not sure how it affects the performances.

Then, having read many topics, I guess I should try to move back the objects and backgrounds, instead of instantiating and destroying them all the time when doing a random level, right ? And for my pre-designed levels (not random) should I split the background to display it step by step, in terms of performance ?

I already know how to scroll my backgrounds, make a parrallax effect with my 5-6 layers, here I'm looking for tips to start clean with the smartest development style, especially in terms of performances and would like to have some hints on which are the best practices to follow

Maybe you have other good practices to share with me... I'm hoping I'm not asking too much, thanks for any insights !

Have a good day

Answer 1

Many infinite runners scroll the world instead of the player to prevent the problem of float overflow. Also, this makes several things easier to manage like player movement and the camera.

For scrolling backgrounds, you can use parallax scrolling. Basically, farther objects appear to move less relative to closer objects across the same distance.

For example, when you scroll the endless terrain by a value of 5f to simulate movement, you can scroll the background by half that value which makes it look farther away. By scrolling, I just mean position.x -= 5f.

Answer 2

If it's a 2D game you'd be better off using ortho camera. If you want to "zoom in" / "zoom out", you can change the orthographic size, which would give an effect similar to moving the camera closer and farther in perpsective mode.

About your first question, I'd recommend moving the player rather than moving the world. You can check the limits of unity in terms of position (which are very large) and if you decide you might reach those limits, then you can have a code that as soon as the player reaches a certain position, move it and the entire world back. But don't move all the objects and background every frame.

About your parallax, since I recommended using orthographic camera, you can't just put them in different Zs. What you can do is either have the backgrounds that are farther away move a bit in the direction that the camera moves (but less than the camera), making it so the camera moves slower compared to those backgrounds than to the level objects.

Another method which might be easier, is to have a separate camera that only shows the background, and it moves slower than the main camera. This will cause the background to move slower. (the main camera will not display the background)

Answer 3

Re: #2 - There is no "performance difference" between ortho projection and perspective. In both cases, vertices are transformed by a similarly sized matrix (4x4). One may produce larger on-screen geometry than the other and, therefore, more pixels to shade, but neither is preferred-by or optimized-for the GPU. Perspective will probably just look wrong.

Re: #1 - Yes, do treadmill:
Consider:

-A stationary ortho camera
-1 full-screen quad for each parallax level
-A number of recyclable sprites for powerups (instanced quads)
-A number of recyclable sprites for the terrain (also instanced quads)
-A number of recyclable sprites for the enemies (also instanced quads)
-A sprite for the character (yep, a quad instance)

The character is animated in place at (0,0).
The camera is always at (0,0).
The position of on-screen objects are in view/camera space.
The camera's position delta, per frame, is added to each of the parallax quads' UV coordinates. The delta is scaled by a different factor for each quad producing the parallax effect.
The camera's position delta, per frame, is subtracted from each of the on-screen objects' positions.
The camera's position delta, per frame, is used to determine whether new objects have come on screen and/or old objects need to be recycled.

The framerate for drawing everything except the power-ups is approximately fixed. With fewer than 100 textured power-up quads on screen, you should expect no significant framerate decrease.

Since everything I've described being on screen is a textured quad, each frame could be rendered with a single, instanced, draw call. I would expect a game organized as such to produce upwards of 1200 fps on my couple-year-old GTX (not counting update logic).