Random level generation

Hello…
how do i generate levels randomly?
in Unity i used a method where i make a level in the prefabs… and generate prefabs randomly…

i am looking to make a infinite runner … where i would want to create a set of 25 levels and generate randomly …
any ideas ?

It does depend a bit on what you mean - 25 levels that are infinite is probably not what your really mean - or how are you ever going to get to level 2!! :smile:

For my random landscape I simply generate a number of points, starting at (0,0) and increase X by a random between, say, 10 and 30 meters, and increase Y by a random between, say 1 and 2 meters. I then take those two points, and extrapolate a curve between them in, say, 8 points.
So now I have the original two points and 8 points between - making 10 points, that I add into an array and make a Box2d chain out of them.

I keep the array of points handy, and have a method ‘GetLandscapeHeightAtX’ that I can use to find (you guessed!) what the landscape height is at any X coordinate.
I can then use this, together with some more random loops, to position various obstacles in the way of the player.

If the levels don’t need curves, it’s somewhat simpler (as you can just generate simple points for the landscape, using some logic to keep it sensible (like dy cannot be > the height the player can jump)

but I recommend calculating the whole level at the start unless you want a really infinite level!

if you do, then you can use the same logic, but start at ‘end of current terrain’ rather than (0,0)

once the Physics terrain exists, it is fairly simple to paint textures below the surface and place sprites on the surface (e.g. soil below grass)

1 Like

@Maxxx But what do you do with camera ? How can i move around my world with simple pan ?

By using a FollowAction. The camera will follow your defined target.

Another method would be using an orbit camera.

but how did you make the levels?
did you use level helper?

P.S i do not want random landscape…
i want to make a level myself…
i make like say 20 levels which are seamless…
and then i call randomly any level as i keep moving…

I don’t use levelhelper or anything else to make levels - I use the game itself.

Because the terrain is just a series of points, when I run the game in edit mode, I show each of those points as a touchable sprite, and drag them to modify the terrain.
I can insert and delete points then drag them until the terrain looks right.
Then i have a menu showing all of the ‘entities’ I have designed - I can then select them and insert them into the world.

The entities are in a vector like the terrain points, so I then have a method that saves each vector as a pList in the same format that is loaded by the game when it runs.

I still do some manual tweaking to set specific values against some of the entities - and (for example) to change the friction on a particular piece of terrain - but the editor mode gives me a pretty good idea of what it is going to look like.

best of all, I can switch back to ‘play’ mode at any time and test to make sure that gap isn’t too wide, or that hill too high!

I have no intention of leaving edit mode in the app when it is finally released - but it saves me having to type in coordinates for things, running the app then changing coordinates - and I can add functionality to the editor as I see fit (for example, I recently added a switch to allow me to view the Box2d debug while editing, so that I can see some of my invisible ‘trigger’ objects that don’t have associated sprites.

for your scenario, I personally would invest the time to add an editor in the app, edit 20 levels (you can make the editor force the first and last terrain points to be at the same height, for example)

At run time, you would need to know when the end of one level is coming as you scroll toward it (a simple calculation) and adding the next level on to it.

At the same time you could remove the last-but-one level from the collection and adjust your pointers.

Alternatively, you can make the levels overlap by at least one screen width (i.e the first and last screen width of every level is identical) then, when the (length - screen width) point is reached, simply swap which level you are looking at, adjusting the pointer to 0

@iQD But how does it work with box2d ?

The following camera has nothing to do with a physics engine. The FollowAction is a cocos2d-x feature.
E.g. you set it to your character node, an it will follow it, aka it will automatically pan the scene.

This is what you asked for, right?

You mean you want to prefab 20 levels and want to randomly seam it to the actual one, wile running to the right/left?

And this should happen indefinitely. Always seam/stitch another level out of those 20 ones?

Well, just use some “levelhelper” app to create those levels and store them in a tile map. Each level as a separate tile map.
When creating the level you pre-load 3 tilemaps: left - center - right, which are all chosen randomly. When the border maps enter the center(left gets center/right gets center), you stream in the next tile map, which is chosen randomly again.

E.g.:
left - center - right
map2 - map10 - map0

You are running to the right: map0 enters the center. Now map7 was chosen by the random number generator and you stream in the tile map/tile.

As I keep everything in world coordinates, I just have some Point’s that hold the location of the bottom left of the viewport, and the width of it, in meters.

So if my physics world is 600m long, and my viewport bottom left is at 100m, then I find a sprite whose world location is 110m, I know it’s location within the window is 10m from the left, and that each meter is (say) represented by 32 pixels - so I set the sprite’s X position to 23 x 10 = 320.

I actually have two ‘windows’ I use - one is the visible window, and the other is the ‘active’ window - so I still calculate for sprites that are within the active window, even though they aren’t visible. The allows an enemy to move off the screen a short distance, and return, rather than just becoming inactive completely as soon as it is out of shot, but it also means I don’t have to process sprites that are miles out of shot