Procedurally generated content

Hi guys ! I'm new to Unity and C#, but not necessarily to programming, and I was wondering about levels in general. I hope I posted in the right place. Do you reckon that automatically generated levels are a common practice nowadays in games such as Tap Tap Dash ?
I have two reasons why I'm asking this: first, because I doubt that someone created 1000 levels manually and second, because I would like to implement some sort of free play mode in my game. Thanks !

 

Procedurally generated content is pretty much everywhere.

 

How does one approach this programming technique ? Do you happen to know where I could find a way of/more information on implementing this? Because my idea of doing this is pretty rudimentary...

 

Catlike coding is a good place to start. Some of the best procedural generation tutorials for Unity on the net.

 

Procedural Generation is basically defining a set of rules for the way a piece of content is constructed at runtime.

If I was to procedurally generate a snowman, some of the rules might include that the bottom sphere must be larger than all spheres on top of it. Otherwise the snowman would be lopsided! Other rules would be based on some kind of input- like if I told the snowman generator to make me a british snowman, the generator would put a top hat and an English flag on the snowman. Maybe add a sign that says "god save the queen!" somewhere in there. Anyway, that's the basic idea.

The problem with procedural generation is that by itself, it isn't about anything. If I had my snowman generator make a hundred snowmen, you would notice that none seem to really stand out. That's because they are all made from the same set of rules. This is true for all types of content made procedurally. This is fine for content that won't be in spotlight- window dressing stuff. But for things like level design that are front and center, I would think long and hard about what you want from your levels, and if procedural gen can actually deliver that.

Roguelike games generally use procedural generation as a matter of course, since the basic idea of a roguelike involves starting over many times. The levels have to be different every time, or else the mechanics fall apart. Also, they don't really expect too much from the levels except that they be about x minutes long and contain x amount of loot, and x number of baddies scattered across the dungeon. So Procedural Generation is a great fit for that type of game.

To contrast that, Bejeweled is a matching, puzzle game. Lots of structure there and only so much space on the screen, So naturally it's got to be a perfect contender for procedural gen right? WRONG! Hand-designed, every stage. The reason ties in with their monetization design- the level design makes it easy to see just how many moves away from victory the player is. After being stuck on one level for days, it's a lot easier for a player to justify spending a small amount of money when they are sooooo close. That kind of clever design is a lot easier for a dev to get by hand, than it is to code a procedural gen system that will nail that reliably every time. Honestly if there are a limited number of levels available and a steady introduction of new features to keep the player engaged, I would not be surprised at all if someone manually created 1000+ levels by hand.

 

Thank you so much sir for your extremely detailed answer!

 

The irony of this is that it's not really the fault of procedural generation. It's more to do with your own notion of how something should be made (assuming you spent enough time with it). If you made a hundred snowmen yourself, there probably wouldn't be many that stand out unless you modify what defines a snowman to you. The best a PCG algorithm can be is your own rule set for creation.

...Unless it's level generation. Level generation is such a huge can of worms that it's next to impossible to capture how you create a level.

 

I am really looking into procedurally generated levels. So that my player can never get bored of playing my game. I'll call it Free Play mode. Sir, do you mean that it's very hard to explain how a level is procedurally created because it highly depends on the game? And that every game has its own way of procedurally generating content?

 

That's not really possible. One of the major functions of level proc gen is that it takes away the mystery of exploring the levels, and it ends up becoming rote. Instead, the player's real drive to explore comes from exploring the mechanics, i.e. system mastery. This means your game's life expectancy is largely tied to mechanical depth.

I was thinking more about how a person will almost always make a better level. Part of this seems insurmountable. Crafting a level is a largely iterative process that goes from making the level playable to making the level "feature rich," balanced, and ostensibly unique in character. It's not that difficult to make a proc gen level playable once you come to realize it's 90% graph theory, but making it feature rich requires an imperial S*** ton of work, balancing it without some L4D style AI director is almost unheard of, while giving the level a unique character usually requires building it off of a completely different algorithm.

 

When I was looking for answers for exactly your question I came across DunGen (asset store). I did take a look at the documentation and was surprised in a quite positive way (tbh, I didn't expect too much from procedural generated dungeons). What did impress me was the amount of features regarding procedural dungeon generation I didn't think of, e.g. advanced spawning along a main path. Might be a good read for you. https://www.assetstore.unity3d.com/en/#!/content/15682 The documentation can be found as link in the description.
I know this is not the asset store forum, but I think the documentation is able to answer some of your questions.
ThomasR

 

You're totally right. Should've thought about this.

I have never specifically heard of L4D AI director's notoriety before, but after checking it out here it seems to me that the algorithm is more than smart to say the least. The A* algorithm got my attention at first, after which I was quite impressed by the "reactive path following". And then there's the climbing algorithm and the others of course.

Yes that is exactly what I've come to realize. My game is tremendously less complex than the usual game you might think of, so I'm only going to use Dijsktra's for some distance calculus ( if even necessary, I'll think about it). The rest is a simple quest of information gathering while searching the vertices ( either deep first or breadth first depending on what I'll need). But even so, could you possibly tell me more about the connection between graph theory and proc gen (or where I can more info on it) ? Just to broaden my narrow horizons you know.

Will do!

 

Imagine you generate dungeon that consists of rooms and corridors. Now each graph point is a room, and each graph line is a corridor. Simple as that. Now to make it look good you can use graph algorithms to create graph, traverse it, simplify it, find shortest path, etc... And then make sure graph doesn't have self-intersecttion and 'project' in onto tiles/mesh to get actual level.

There are other applications. For example, you have N rooms without types. You have their types: storage, security, office, etc. Now you need to make layout (room-type links) that's most optimal in terms of security/cost/employee performance. So you make graph of rooms and then attempt to place each type of room in each space and calculate what happens from it (how much times one passes through security, how long it is till you reach storage from shop, etc) - thus after a lot of combinations you find the most optimal one that suits your need. To optimize that algorithm you would need graph theory.

There are other more advanced uses like cause-consequence chains, story generation (never seen that one in games yet), A.I. behaviours... Basically, in anything you can represent as graph you can try to use graphs instead of plain array.

 

Procedural generation can also get very, very hard, really quickly.

It can very quickly turn into a never ending rabbit hole. I read a story about a game build around proc gen content that was scrapped after 8 years or so, never having gotten to much of the actual game play.

Tile based systems where you just mix up a set of pre built tiles are probably the easiest and most reliable. Once you start stepping into the wild waters beyond that the currents get real rough unless you essentially copy another implementation, and even then.

 

And self-intersections are usually resolved with spatial partitioning (more graphs), BSP/k-d trees and Voronoi diagrams/Delaunay triangulation being the big methods. Then there are uses of cellular automata to create totally different structures. Rogue Basin as a bunch of good articles on these.

 

I don't think procedural generation as such is particularly useful. Much more useful is procedural prediction of what the artist/developer wants to create, based on minimal input. Imagine if you hooked up to your computer via electrodes and imagined what you wanted, and some 'procedural' algorithm caught that information, cleaned out the noise, filled in all the nooks and crannies that your mind didn't dwell on and generally created a detailed scene from abstract thought impulses. Now that would be useful.

 

Hey hey hey...remember your unit conversions for the non-US audience!

2.5 Imperial S*** Ton = 1 Metric S*** Ton.

...Therefore it takes 0.4 Metric S*** Tons of work to make a feature-rich procedurally-generated level.

 

Let's be honest though, the only place the metric S*** ton is used is in rocketing S*** into space. So unless you work at JPL, it's the Imperial March all day, every day.