Hi,

I'm developing a 2d platformer with Procedurally generated levels.
What i have been doing is,

- create walkable/jumpable 16*16/8*8 small rooms (lots of em)
- combine many of them in a linear route
- add branches and subbranches

that's not really a real random generated level, after some hours users start to see the patterns and the magic disappears.

I would choose a method like Terraria or Minecraft with perlin noise however, game does not have tile destruction/creation. Player doesn't have grapnel gun (cheat!) neither.
This is not a of technical limitation, but a design decision.

Almost all the random level generation articles/game around the web are isometric top-down.

Do you know any links / games / articles about this type of level generation ?

Your constraints on no tile destruction and no grapnel or other means of getting out of tight spots is going to place some tricky restrictions on your generator. You are going to have to require that the generator not create levels where it is possible to get stuck, or else the player will, uh... get stuck. Minecraft and Terraria create interesting worlds because these constraints are not in place; ie, the player can usually find some way out of a canyon or a hole. Without any options for escape, you need to resort to rather bland and uninteresting levels, in order to meet the constraint of not getting stuck.

There are a few techniques you can use to guarantee non-stuckedness (yay, made-up words) in a level.

1) Generate it with non-stuckedness in mind. Every technique you use has to ensure that it generates patterns that are "sane" from the player's standpoint. As well, the combination of techniques needs to ensure the same. Best bet here is to go with something similar to what you already do, ie create small pieces that are guaranteed to be walkable/jumpable and combine them into sequences that themselves are guaranteed to be walkable/jumpable. The more crazy and chaotic you get with your pieces and layouts, the harder it becomes to make these guarantees.

2) Generate it however you want, then meta-analyze the level and make modifications as needed to fix the trouble spots. Smooth out steep slopes, lower cliffs, widen tunnels, etc...

Neither of these options is exactly trivial. I mean, it's easy enough to go with (1), but without the ability to exhaustively test every possible level permutation, you are either stuck with extremely flat and boring levels or with the possibility that there is going to be an edge-case somewhere that will trap and annoy your player. (2) can really be trouble, since that sort of meta-analysis can be computationally expensive, may have lots of edge or degenerate cases, and can result in rather schizophrenic levels where the player can actually see the level correction taking place. The generator needs to be able to analyze sections of blocks to determine their fitness for walking/jumping and attempt to correct them, but it needs to do this analysis in the context of the greater level so that if there is an alternate way around a trap, the trap isn't smoothed. It's a tricky job, and although I've attempted such meta-analysis before, I've never stumbled on any solution I would call "good".

I have found that rather than try to squeeze/force the generator into such tight constraints, it is best to let the generator be natural, and instead give the player tools to overcome whatever obstacles the generator may throw at him/her. Forcing walkable/jumpable constraints onto a procedurally generated level simply forces the world to be relatively flat and uninteresting. Every place is reachable, there are few opportunities for creating cool little locations that take some thinking to get to, everything starts to look pretty much the same. It gets uninteresting fast.

Procedurally generated levels naturally tend toward bland and uninteresting anyway, without lots of effort; constraining them only exacerbates the problem.

i dont think procedurally generated levels are bland. Look at all those Rogue-likes, most of em present infinite enjoyment which you cant get from any handmade game. Some people are playing Nethack for 10 years.

Maybe if i add limited number of "stuck-fix item"s (limited fuel jetpack, flimsy breakable jump stick?).
Since i have story to tell i just cant allow user to destroy the level.

Idea of an infinite platformer really interest me.
Noise generated levels aren't sufficient for this case, but i wont stop trying

I would agree with FLeBlanc's assessment.

I'm currently working on a platformer (dev notes and download available on my website) that uses noise to generate the levels. Although, unlike your situation my character fits well with the idea of picking up and moving a block over. Even with this ability it didn't take much to get stuck or otherwise destroy the level sufficiently to make the randomness completely pointless. I did my best to play around with the character's abilities to come up with what I think works with the level. I'm still not 100% sure it's not possible to get stuck.

Even then, I think what FLeBlanc said is generally correct. (At lest in my case) there isn't really a connection with your location within the level. I don't know if it's because it all looks the same or if there's some sort of psychology vs architecture thing involving points of reference but that disconnect (or whatever it is) is there.

I'm not trying to be discouraging I'm just saying that what FLeBlanc said fits with what I've recently experienced.

First post. Hello everyone.

Random generation of course comes with some problems, as has already been pointed out [players getting stuck, 'blandness']. Assembling levels out of coarse grain chunks is an attractive middle-ground, but in order to not end up with introducing a number of problems [two blocks with pits on opposite sides being selected to construct a pit that is too wide to jump across, for example], you really need an extra something. A likely easy solution to solving this would be to have a compute controlled player test-navigate each area, and make selections based on areas the bot is capable of navigating. At each 'decision point', which would be a point where the bot is not falling or dead or whatever, you generate a bunch of scout bots that jump off or run off in random directions. You place features in places where you can assure at least some subset of the bots survive to some next 'decision point'.

If you have this bot in place, and thus solve the getting-stuck problem [since your bot wouldn't select options that result in the bot getting stuck, as it would be unable to reach the next 'decision point'], then you could probably even relax the coarse grain room thing, and let your bot navigation test fill in some gaps, thus affording you additional flexability, and the ability to use finer grain [thus reducing the level of redundancy]. A player would likely recognize whole rooms, but if your generator can make placement decisions on the level of ledges and blocks, rather than whole rooms, redundancy won't be perceptable. You could even guide it by demanding that the general flow of the level proceed in a certain direction. Or, as another middle ground, add whole rooms and let a random generator add more stuff to the room [you have a template, but programatically add enemies or a few extra bricks or things] to break up the monotony.

First post. Hello everyone.

Random generation of course comes with some problems, as has already been pointed out [players getting stuck, 'blandness']. Assembling levels out of coarse grain chunks is an attractive middle-ground, but in order to not end up with introducing a number of problems [two blocks with pits on opposite sides being selected to construct a pit that is too wide to jump across, for example], you really need an extra something. A likely easy solution to solving this would be to have a compute controlled player test-navigate each area, and make selections based on areas the bot is capable of navigating. At each 'decision point', which would be a point where the bot is not falling or dead or whatever, you generate a bunch of scout bots that jump off or run off in random directions. You place features in places where you can assure at least some subset of the bots survive to some next 'decision point'.

If you have this bot in place, and thus solve the getting-stuck problem [since your bot wouldn't select options that result in the bot getting stuck, as it would be unable to reach the next 'decision point'], then you could probably even relax the coarse grain room thing, and let your bot navigation test fill in some gaps, thus affording you additional flexability, and the ability to use finer grain [thus reducing the level of redundancy]. A player would likely recognize whole rooms, but if your generator can make placement decisions on the level of ledges and blocks, rather than whole rooms, redundancy won't be perceptable. You could even guide it by demanding that the general flow of the level proceed in a certain direction. Or, as another middle ground, add whole rooms and let a random generator add more stuff to the room [you have a template, but programatically add enemies or a few extra bricks or things] to break up the monotony.

nice. i like your solution.
i already have a fully functional pathfinder. i would run it start to finish, then finish to end. Also do the same for branching paths.
Modify the level as it runs.

"Loading Time" might be a problem. since i would need to run pathfinder multiple times for huge paths. However with multithreading and caching it may even take just a second.
I cant really be sure about it till i implement it.

Thank you for the idea.

"Loading Time" might be a problem. since i would need to run pathfinder multiple times for huge paths. However with multithreading and caching it may even take just a second.
I cant really be sure about it till i implement it.

The only guarantee you really need is to assert your pathfinder can stay ahead of the player. You don't even need to generate the entire level is one go. If you know your player takes X seconds to make it to the current end of the world, that means you have X seconds to build more world for it to be as if the world was complete from the beginning, from the players point of view. Realistically, you could even just not build the parts of the map that are off the path the player chose, and leave parts of your game world forever uninstantiated.