I'm working on generating an endless level game on Android. I've got the framework up and running and some physics, and now I'm getting to the point to where I need to think about how I'm going to generate and track the world around the player. I've been thinking about this for a while and I'm just not sure what to do from here. I was thinking I could just randomly generate objects and the background of the level as the player progresses. But the player needs to be able to move backward as well. If that is the case then I need to keep track of all of my objects, and in an endless game, doesn't that mean I'm going to have a metric ton of objects in memory? How do I store the data for the ground, trees, mountains and whatnot? What is the best practice for this sort of thing? My initial thought is, the grass, trees and mountains are inconsequential to the game, they're just background objects. I'm thinking I can set up a pattern that repeats for these (tree1,tree2,tree3 in an array that uses a formula to figure out where each object needs to be loaded based on where the player x,y coord is), and save myself some grief with keeping track of those. Is that pretty standard? What do I do about keeping track of enemies/objstacles/powerups? Also right now I'm using a camera class that uses OpenGL orthographic projection to change the Frustrum to follow the player around the map. I've seen some articles say keep the player in one spot and move everything around the player, and some say the camera is good as well. What is the best practice for this?

And lastly, if anyone knows of any good resources that are worth a read for a budding game developer, I'd love to hear about them. I've found a lot of material on frameworks, languages and whatnot, but nothing that tackles specific problems that developers run into and best practices for those sorts of things. Sort of a standard practices for various game types book? Nothing code specific, just ideas on how to tackle various problems.

Thanks!

Instead of using pseudo-random numbers, use a hash function that takes the position in the level as input. If the hash function is any good the results will look just as random, but you can go back and regenerate whatever you need to regenerate.

So, there's a few ways to do this. It partially depends on if you're storing the background as tiles or as separate object, but the theory is the same either way.

1. Repeating loops. So your background is stored in an array or a list with positional indexes, and you pick what to display with the modulus of the current position in the level. If you have several loops at different frequencies of repetition (one for trees, one for background mountains, etc.) then you'll get more variety.

2. Random generation with a fixed seed pseudorandom generator / hash function (technically, those are the same thing). You have a hash function that takes the current position in the level and returns a random number. Be careful to pick a random number generator that gives good results on its first roll with a seed; some have flaws that make the first few rolls really streaky.

3. Sections: each section of the level has a prebuilt chunk of content. As you load each new section, pick what it is at random. You can use the fixed-seed hash for this, or store the index of the generated chunk in an array to reload when you return to that area. You'll need to have a bunch of chunks to pick from for it to look really random. Bonus points if the chunks can be modularly combined in different ways.

All these techniques can be mixed and matched.

Note that with all of these you'll still need to store the changes the player has made (enemies killed, powerups collected, etc.)

I would go with a combination of choices 2 and 3 from ikarth's answer.

Generate your level with a random generation from a fixed seed, which you store somewhere so you can always re-generate the level in the same layout.

As part of the random positioning, position pre-designed sections at random, which will give the appearance more of a designed, rather than completely random level.

Be careful though that the sections do not repeat as players cotton on to this very quickly and label it as simply repetitive gameplay.

A side note on repetition of graphical assets:

Lets say you have a repeating background with 3 layers.
If each of those layers is of the same width , you will have a strong pattern effect, like this:

012345670123456701234567
012345670123456701234567
012345670123456701234567

If you would change the width of some layers to reduce the effect but the widths have a large common divisor, the effect is lessened but still visible, like this:

012345670123456701234567
012301230123012301230123
010101010101010101010101

To minimize the pattern-effect try to use primes as width, like this:

012345601234560123456012
012340123401234012340123
012012012012012012012012

Now add an offset for the final touch like this:

012345601234560123456012
123401234012340123401234
201201201201201201201201

As you can see, in the first case every combination of backgrounds appears 3 times within the range (24).
In the last two cases, there is no combination that is repeated within that range.
In fact, using the primes 3,5,7 you could go on for 105 without a repeating combination, in contrast to
8 in the first example. The range would be the least common multiple of all used numbers.

If have recently heard design folks call it the cicada principle, but well, it's just math.