next »

[Lukas]

Hello!

I'm currently working on a game which will rely on procedural level generation when it is done.

The gameplay mechanics are quite unique and not really comparable to games like Rogue for example (you know... treasure, monsters, combat, leveling).

This means that the game would require a really different approach to developing the algorithms that shape the levels in order to enable enjoyable gameplay everytime a new game is generated.

Problem is: I know very little about the game myself so far. Or more specifically: I don't really know how to design good levels for it so far.

So my question is:
How should I approach this? Should I begin building all the levels by hand for as long as possible and develop the procedural generation at the very last moment?
Or should I try to implement some form of p.g. as soon as possible and in parallel to the rest of the development process?

Has anyone of you already made experiences with implement procedural generation into games and can give me some hints or do you happen to know how it might have been done (I don't mean how the p.g. was done but how its implementation was integrated into the development of the game itself) in games like... Spelunky or Binding of Isaac for example.

[rek]

You need to know what a level, from start to finish, looks like. Then identify the elements that can vary (and by how much/how), otherwise it will literally be a random mess. You will need to know all the mechanics available to the player so platform s or doors or whatever are within reach, and challenges (monsters or puzzles or whatever ) can be overcome.

[st33d]

Any mechanic you plan on having in a game you should try out as soon as possible. P.G. or anything else.

Otherwise, it's what most people will refer to as a "shoehorn". You will have made one game and then you will be trying to force P.G. shoes on to it.

[C.A. Silbereisen]

the question you should ask yourself is: would procedural generation benefit the game in any way? does it NEED procedural generation?

[antybaner]

Or procedural sellection for that matter.

[Derek]

Spelunky was designed with randomized levels from the start, and I would start thinking about it ASAP if it's a central idea to your game.

I would not use randomized levels as a way to get around designing your own levels, hoping that the variety will make up for it. It will a little bit, but you'll likely have to do some serious planning/experimenting before you figure out how to strike a good balance.

[Core Xii]

What is procedural content? It's that instead of designing something manually, you tell the computer how to design it.

Before you can tell the computer how to design something, you have to know what it is that you're designing in the first place, and be able to design it yourself. Otherwise... How's the computer gonna be able to?

[Fallsburg]

You need to know what a level, from start to finish, looks like. Then identify the elements that can vary (and by how much/how), otherwise it will literally be a random mess. You will need to know all the mechanics available to the player so platform s or doors or whatever are within reach, and challenges (monsters or puzzles or whatever ) can be overcome.

This.

Design some hand done levels that you like. 
Figure out what makes them work and try to create a system that can recreate that. 

[baconman]

Well, I started my PGC projects-in-progress by devising my level chunker so that I know the ways I can structure my levels, and by planning gameplay mechanics, widgets, enemies, and other wild cards like that which determine the structure/intent of said chunks. You also want to know how the player begins, whether it's open-world or level-based, how they win a level/world, and a (simple?) set of steps necessary to accomplish that.

Having a sense of directional flow will help you a LOT in your chunking, too. If the game is primarily left-to-right or top-to-bottom for example, you can create chunks that flow more naturally that direction without having to worry about whether you can backtrack; and if your game is multi-directional, flow is still something to consider because the way you traverse your terrain will change in many different ways as well.

Also, consider the different types of challenges you want your player to experience. Sure, they all have to tie into the core game, but having the player do a small variety of things can help keep your experience fresh and exciting. For instance, I'm focusing my level chunk designs around 3 core elements: one area set will usually be more combat/enemy driven, one set is more about navigation challenges and widgets, and another is about creating secret passageways, either with rewards/treasures or shortcuts (or sometimes both!).

PGC isn't a way to supercede level design, it's just a way to shuffle it up.

[zoombapup]

Just wanted to add that in worms we took a number of core concepts (is the level enclosed or not, is the level full or empty, are landmasses columns or islands etc) and assigned them to bits in a bitfield. We then generated different variations on the bitfields such that you got similar levels but with some random variations.

The idea of designers choosing from variations around a central set of procedurally generated content really stuck with me as useful. So you have individual bits of a number representing different concepts, you ascribe those bits in different orders based on how you want to cluster features. You then allow designers (or players) to generate content based on the bitfield settings. Allowing quick inspection of different bitfields really helps here. It's essentially like you'd get in a procedural texture generator (it looks a lot like the texture synthesis of kai's power tools from that era).

I'm using that same system today. Using proc gen alongside hand editing and placement to "amplify" content. Its not replacing a designer, just making life a bit easier.

[Carrie Nation]

My dream is a procedurally generated game based on Battle Royale.

It would probably be a roguelike or psuedo-roguelike due to the fact that the behind the game mechanics would be pretty complicated and I wouldn't want to have to focus on art.

Every round, the island and each individual class member would be randomly generated.

The AI would be fucking hell to code, because I'd want you to be able to team up with other people you ran into through conversation, and you'd have to have 41 or so other people roaming the island in a realistic manner, and fighting each other off camera.

But beyond that I think it would be fucking incredible, everybody has a random weapon, you could start a round with a spoon or something completely useless, and have to mold your strategy around talking to people, manipulating them, which would itself only really be useful if your character was generated to be charismatic.

I dunno, that's my procedurally generated fantasy, which will probably look like complete gibberish if you haven't read/watched Battle Royale.


But hey to contribute to your actual topic, I think procedural generation shines most when it's used to create a game with near infinite replay value, due to the sandboxy feel it offers.

[Azure Lazuline]

What everyone else said: you need to know what goes into a good level before you can tell the computer how to do it. Procedural generation is something that's really hard to do right, but it leads to a lot more replay value. I actually use procedural generation for one mode of Copy Kitty, but even though I thought the generator was "finished" as soon as I made it, 9 months later and I'm still changing and improving it.

Basically, over time I've made it vary more. At the beginning, it was completely random, much more random than it is today. It could create lots of things that it can't now. But I found out, a lot of those things aren't fun. So I played more, and found out which things were fun and which things weren't. Cramped areas weren't fun, because even though you can destroy land, that's slower than normal movement and enemies could trap you. Having tons of enemy types at the same time wasn't fun, because then it was pretty much just chaos.

Now, each randomly-generated "level" has more constraints. It picks a tileset and background (which are randomized too, but the point of this is the levels and not the graphics, so I'll ignore it). The level graphics it picks also determine some things about the generation, like percentage of open space to closed space, how much ground is generated as slopes instead of flat, how thin the walls are, and things like that. Then it picks 3 or 4 different enemy types to spawn, and the enemies are created so that each one fills a specific niche, and they compliment each other. Then there are a few "global" settings that it can change, like if it's a water level or sky level, or just a normal one.

The end result is that because of the varied enemy selection and placement, enemies will interact in different ways and create new challenges that you've never seen before. It might create a short-range enemy that you've dealt with before just from simple shooting at a distance, but now there's an enemy with a shield following it so you can't use the same tactic! Or that really weak enemy might be difficult now that it's freaking everywhere and they're all swarming you. Anyone who has played Mega Man 9 know that the mets (yellow hard hats) aren't exactly difficult enemies, but you'd be lying if you said that the one in Plug Man's stage after the disappearing platforms didn't kill you at least once. It's all about placement.

This is much longer than I thought it would be... oh well. Basically, my point is to make the generator vary over time, not just have all the random elements available from the beginning.

[senorbarborito]

Just wanted to add that in worms we took a number of core concepts (is the level enclosed or not, is the level full or empty, are landmasses columns or islands etc) and assigned them to bits in a bitfield. We then generated different variations on the bitfields such that you got similar levels but with some random variations.

The idea of designers choosing from variations around a central set of procedurally generated content really stuck with me as useful. So you have individual bits of a number representing different concepts, you ascribe those bits in different orders based on how you want to cluster features. You then allow designers (or players) to generate content based on the bitfield settings. Allowing quick inspection of different bitfields really helps here. It's essentially like you'd get in a procedural texture generator (it looks a lot like the texture synthesis of kai's power tools from that era).

I'm using that same system today. Using proc gen alongside hand editing and placement to "amplify" content. Its not replacing a designer, just making life a bit easier.

just to let you know I fully intend to use this for automatic level generation by setting each parameter with a value chosen at random within a "good" range known to give reasonable results.

should also work well, thanks!

[EdgeOfProphecy]

I've been grappling with procedural level generation for a game I'm currently working on. My answer to this is to use a lot of math.

The game's something of a runner game (Canabalt, Jetpack Joyride and those sorts), so I need to generate levels that are challenging for the player and follow a good progression of difficulty. 

What I've done is examined the elements that make up my game and attempt to describe mathematically how "difficult" each element is.  There are collectable widgets that you can get to increase your score, but you're trying to get through the level as quickly as possible, so the "difficulty" inherent in a pattern of collectables is how many times you need to traverse the area of that pattern to completely collect it.  If I know the size of a pattern, then I can figure out that pattern's "effective distance", which is how many meters you need to travel to completely collect the pattern.

Hazards in the level likewise require you to dodge, and will have an "effective distance" needed to dodge past them safely.  However, there are other things that make patterns more difficult, such as ones that sort of surprise the player and demand them to reflexively dodge versus ones that require precision movement but aren't surprises.  I'm still working on exactly how to turn those attributes into numbers.

Regardless, for the collectables at least, I take my base distance for a level (its size), ratchet that up to increase its difficulty, and point-buy collectable patterns until I've filled my level up.  I use an exponential curve to ramp up the difficulty between levels, so the later levels have more demanding patterns of collectables that require more maneuvering on the player's part to complete them successfully.

The important thing to take away from this is that I'm using a highly mathematical approach to game balance.  I'm picking one value (effective distance) to act as my "hinge value", and calculating the other variables of the system in terms of the hinge value.  I can then use the values of individual elements, expressed in terms of my hinge value, to generate levels that are mathematically balanced from a difficulty curve.

This doesn't get you all the way there, of course.  For one, your assumptions have to be right as to how difficult something actually is.  Secondly, a mathematically balanced game is not always a fun game.  The advantage is that you have at least some basis to work from, and you're not just blindly making changes to your system.  It makes for a decent starting point.

[baconman]

^ I would say to plan not how difficult each element is individually, but how complexity factors into the mix with different element combos. Spike ceilings and springboards would both rate relatively low on such a scale, but if you put the two together... 9.9

To me, a lot of it is in layering the elements and generation together. There's many factors you can generate, that can change a lot of things:

The level/map. The gameplay elements thereof. The player/role. The game's objective (speed? completion? kills? score?). Powerups and effects. Heck, if you're really sold on the idea, you can change the game on a whim between hop'n'bop, dash'n'slash, and run'n'gun. That changes a lot of factors, including how to approach enemies.

[EdgeOfProphecy]

^ I would say to plan not how difficult each element is individually, but how complexity factors into the mix with different element combos. Spike ceilings and springboards would both rate relatively low on such a scale, but if you put the two together... 9.9

To me, a lot of it is in layering the elements and generation together. There's many factors you can generate, that can change a lot of things:

The level/map. The gameplay elements thereof. The player/role. The game's objective (speed? completion? kills? score?). Powerups and effects. Heck, if you're really sold on the idea, you can change the game on a whim between hop'n'bop, dash'n'slash, and run'n'gun. That changes a lot of factors, including how to approach enemies.

I agree that when you have elements that interact in a complex or special way, it's a good idea to form groups and balance their difficulty as a unit rather than their individual parts.  I'm pretty sure Spelunky does this, because if you play it several times you notice repeating patterns of trap combinations and platform shapes.

To expand upon that, I think of my game as existing of "execution challenges", and that the play experience consists of the player being introduced to an execution challenge, devising a plan to overcome it, then attempting to overcome it.  An execution challenge doesn't have to be a single element, but can be a group.

Think of Super Meat Boy, for instance (which definitely wasn't procedurally generated).  Many levels are a series of execution challenges with little breaks in between.  You'll have a set of hazards in the level, and a platform at the end of it that's safe.  It could consist of three moving sawblades on a wall that you have to wall-jump through, then a platform at the top that's safe.  There are 6 independent elements at work here (2 walls, 3 sawblades, one platform), but they combine together into a single challenge.  You can't stop between sawblades 2 and 3 and wait to catch your breath, you'll die.  Your immediate goal as the player is to get past those sawblades and get to the next platform, the rest of the level is totally inconsequential.  After you clear the immediate execution challenge, the player repeats the process with the next one, and so on, until the level's complete.

In my specific game, the execution challenges are mostly atomic, meaning they're not composed of sub-parts (for now, this is subject to change as I gather testing feedback).  For the most part, there's one enemy per section of the level, and you encounter groups of collectables in serial.  The challenge stems from playing with perfect execution.  The most important thing is that I am actually working with execution challenges that have a group size of 1, while many games (Spelunky and most platformers) work with an execution challenge group size > 1.  I should have been more clear, but the real point I was trying to make is that you can string together mathematically represented execution challenges to do procedural levels.

[baconman]

I'd give a little ebb and flow about it, maybe conclude each level with an embarassingly easy part that's still capable of killing a player due to tension for that "YASD" effect it gives. So something along the lines of:

end-1-2-3-4-3-4-5-2-end

It (and the second "3") subvert the pacing of directly incremental difficulty, and are aimed at fooling the player into thinking it's an easy section, just because it's easier than the preceding sections. Player carelessness (and baiting thereof) is something you certainly must factor into it. It also allows the sections 1 and 5 to remain distinctly uncommon, thus drawing player's attention towards the 2/3/4 sections.

And personally, I think you'll get better gameplay out of combining sets of two things in creative ways - maybe even do two level-1 segments to simply illustrate how the elements work alone, before arranging them in dastardly combinations together.

You could also plan uber-precise shortcutting intentionally, and put the collectibles as rewards for executing them properly; but I'd place speed scoring as more vital than that; so that if a player whiffs one, they aren't necessarily always motivated to pursue it... in which case they practice it less, and it remains a challenging target for longer.

[EdgeOfProphecy]

I'd give a little ebb and flow about it, maybe conclude each level with an embarassingly easy part that's still capable of killing a player due to tension for that "YASD" effect it gives. So something along the lines of:

end-1-2-3-4-3-4-5-2-end

It (and the second "3") subvert the pacing of directly incremental difficulty, and are aimed at fooling the player into thinking it's an easy section, just because it's easier than the preceding sections. Player carelessness (and baiting thereof) is something you certainly must factor into it. It also allows the sections 1 and 5 to remain distinctly uncommon, thus drawing player's attention towards the 2/3/4 sections.

Yup, that's a good idea.  The beauty of generating off of a difficulty curve is that you can just change the curve and BAM!  Different difficulty progression.

My very starting base is a straight exponential curve, but I've been planning on trying some others around.  I do like the idea of having the hard part be more in the middle, or the ending being slightly harder than the hardest segment.  I can just pick the type of curve I want for the level and generate based on that using the same level gen algorithm.

And personally, I think you'll get better gameplay out of combining sets of two things in creative ways - maybe even do two level-1 segments to simply illustrate how the elements work alone, before arranging them in dastardly combinations together.

You could also plan uber-precise shortcutting intentionally, and put the collectibles as rewards for executing them properly; but I'd place speed scoring as more vital than that; so that if a player whiffs one, they aren't necessarily always motivated to pursue it... in which case they practice it less, and it remains a challenging target for longer.

We'll see.  I'm thinking about that sort of stuff, but honestly combining mechanics versus not combining mechanics is going to depend a lot on how those mechanics work in the first place.  I do already have provisions for generating sets of level obstacles, so it would be as simple as making new sets that are mixed.  Presently they're homogeneous, so you can get 3 laser turrets in a row or something, or 2 pistons, but not a laser turret and a piston.

And...actually those are the only two level obstacles in the game that are statically placed.  There's a third that can fly at you from off-screen, but they can spawn at any time.  So yeah, spawning groups is not off the table, but I'm not yet ready to make a decision on that.

The interaction of collectable patterns and level obstacles, however, is harder for me to figure out.  I'm kind of content to leave their generation decoupled (they're generated off the same difficulty curve, but the patterns selected for one doesn't influence the other).  I'm not precisely sure if there is a strong coupling between the two types or not (that collectable pattern A + obstacle pattern A is 3x harder than collectable pattern B + obstacle pattern A, assuming that the difficulty of Ca + Oa = Cb + Oa without any special modifiers).  It would also be a lot more work for my level generator to have to deal with that sort of stuff, so I'm not going to deal with it unless it ends up really detracting from the game.

Now, if I were making a platformer, yes it would matter immensely.  I'm not though, and the constraints of your game heavily drive what levels you can generate.

[Azure Lazuline]

The idea of making the end part slightly easier is a really good one. That also avoids the problem that every gamer has faced before: you get within 5 seconds of the end of the level, and die. It's so immensely frustrating, and makes you want to stop playing. How will your level progression work? Will you give the player a single stage and let them try it again multiple times until they beat it, or is it one shot each?