next »

[tylerthedesigner]

Hey guys/gals! I recently posted an article on AltDevBlog regarding
procedural generation, and would love to get some feedback from fellow
designers. The topic is "When should something be procedural?", and it
delves in to the various things to consider before committing to the
procedural generation of a system or content. Please let me know what
you think!

http://altdevblogaday.com/2011/12/02/procedural-generation-cost-analysis/

[gimymblert]

I like to define PG as "Content as function" opposed to "content as data"
Blending is an edge case: data as a function of data (see normal map), similar: tagging, template.

Ultimately PG is design and is gameplay, gameplay is a "PG experience" after all (experience result from rules and player input).

[baconman]

PG used in context of design is good.
PG used in PLACE of design is bad.

That said, considering the memorization factor of Touhou games, a PGC danmaku is probably not the best idea, unless it creates a procedurally generated lineup of characters, and then allows you multiple attempts to clear the set. A PGC danmaku with permadeath/no continues would ultimately fail, unless there's some type of giveaway, and that would kill the memorization routine as well.

What could work is to take an array of mini-patterns, start opponents off with a combination of 2 of them, and then climax at a combination of 5 or so that you have to dodge all at the same time. And you may have to live with the fact that one game out of a dozen or so is just unwinnable - but given typical shot spacing and your four-pixel hitbox in those games, it's hard to imagine any of them being virtually impossible. You just may have to graze a bit.

PG'ing a sword that's "effective against wood enemies" is fine.

PG'ing a sword that's "+70% critical against enemies of Wood Type, +3 to defense, and -3 to strength" (IMHO) is just babbling. Sorry Borderlands! But I still love you.

[DavidCaruso]

Randomly generated levels (if that's what you mean by "procedural generation" here, it seems to be what you're talking about in your blog post) are pretty much always a compromise, but sometimes they're a decent one. When they should be used: games which take place over an extended period of time, and where the actual layouts matter less. When they shouldn't be used: pretty much any game that takes place in realtime. Also, don't try to randomly generate a level if you know you'd not be able to make a good one by hand, you're not going to be able to write an algorithm which can generate a half-decent danmaku level if you can't make one yourself.

[tylerthedesigner]

PG used in context of design is good.
PG used in PLACE of design is bad.

I agree, to an extent. The question that I am posing within the article is when to procedural generate, and what parts of a game? So, in Minecraft's case, they generate the maps. Borderlands, the weapons. And the list goes on. I would like to some some structure and decision process as to what is going to be generated, and why.

As for the Touhou/bullet hell games...
The system I had mapped out was rather simple- I would generate the player path, then generate the enemy spawns and firing styles based on that. In other words, there would always be at least one right path in the level, and it would be up to the player to find it. I am not versed in bullet-hells(as stated in the article), but it seems to me like that formula would allow for one to at least be playable, maybe not fun? I don't know.

Randomly generated levels (if that's what you mean by "procedural generation" here, it seems to be what you're talking about in your blog post)

While the article was focusing on levels for the sake of convenience, I was attempting to look at PG in a broader sense. The idea behind the post is to have basic guidelines as to when/why you would PG content in a game.

Also, don't try to randomly generate a level if you know you'd not be able to make a good one by hand, you're not going to be able to write an algorithm which can generate a half-decent danmaku level if you can't make one yourself.

How else is one going to learn, but to fail early/often? I understand your point, but it should be stated this concept was only just a concept. I have no intentions on making bullet-hells commercially, it was just a exercise in design/code. As for the point made about hand crafted skill -vs- PG... I don't believe there is a direct correlation between being a level designer, and someone who can PG content. Its in my opinion that those are different skills with a different mindset. Both roles require an in-depth knowledge of the game mechanics and play style, but level design mastery is not needed to be an expert at PG'ing levels.

[s0]

When they should be used: games which take place over an extended period of time, and where the actual layouts matter less.

or games where the inability to memorize level layouts is important for the design to work (ex: roguelikes).

[Zaphos]

In a cost analysis procedural content generation really starts to shine for things like tree generation, where the effort is orders of magnitude lower and the end product is highly structured.

If the design calls for infinite content, that's not so much a cost analysis issue as it is a design which implicitly asks for procedural generation; I mean, it's trivial to see that hand generating 'infinite' content is infeasible, so the actual question is 'do you really want/need infinite content,' which should have more to do with creative direction than cost.

As for the point made about hand crafted skill -vs- PG... I don't believe there is a direct correlation between being a level designer, and someone who can PG content. Its in my opinion that those are different skills with a different mindset. Both roles require an in-depth knowledge of the game mechanics and play style, but level design mastery is not needed to be an expert at PG'ing levels.

I disagree; if you can tell a computer how to make good levels, you can make good levels by hand.

You can use PG-style tools to assist manual content generation too, you know.

The only way being good at PG but not hand-crafting makes sense is if the PG levels are fundamentally different from the non-PG levels, like in the infinite generation case.  And then it's really more a design direction question.

[tylerthedesigner]

I disagree; if you can tell a computer how to make good levels, you can make good levels by hand.

I concede that if someone has a better understanding of developing levels by hand, then they will do a far better job at procedurally generating levels. However, there are skills required for both of these tasks that are not dependent of each other. For instance, an amazing programmer may not understand the softer skills of level design, or a great level designer may not be a programmer. The point is that there are skills of implementation for either of these. (Personally, I find that I am terrible at level design)

You can use PG-style tools to assist manual content generation too, you know.

Of course! The point I was bringing up with the CrazyBump paragraph in my article was trying to point that out. Other examples would include CityEngine, SpeedTree, and Natural Motion.

[antybaner]

Or you can let the computer assemble a mix of randomly selected pre made stuff ins no particular order.

[baconman]

Or you can let the computer assemble a mix of randomly selected pre made stuff ins no particular order.

The problem with this approach (and most Roguelikes for that matter), is that this doesn't allow for infinite potential - it's just the sum of what pieced-together potential is already there; and generally when broken into these pieces, there's far LESS content than there is in an actual instance of the game, without considering factors that can truly mix it up.

SMB wouldn't change much if all the worlds did was randomize what order parts 1 through 3 of each world were played in, for instance.

[s0]

The problem with this approach (and most Roguelikes for that matter), is that this doesn't allow for infinite potential - it's just the sum of what pieced-together potential is already there;

Idk where you're getting this from but "most roguelikes" don't piece their levels together from premade segments. Also the point of "PG" in roguelikes isn't to provide "infinite content" it's to make memorizing level layouts impossible, because if you could it'd literally change the genre of the game (from strategy to puzzle).

[gimymblert]

Developing a PG is developing a language with grammar and syntax to express the target domain. If you don't understand the target domain no way the PG produce good things, only gibberish.

[antybaner]

Personally, I really like the PG of the binding of isaac. You just have rooms. And the way it selects random foes and random items etc. Just genius. The story on the other hand....

[baconman]

Personally, I really like the PG of the binding of isaac. You just have rooms. And the way it selects random foes and random items etc. Just genius. The story on the other hand....

Stuff like this, Spelunky, and Terraria are PGC done right. And yes, I get why Rogue makes memorization impractical, but it doesn't stop it from being very samey-feeling, or oftentimes kind of empty-feeling for awhile.

[s0]

what roguelikes have you played?

i usually agree with you but your arguments here are kinda off base. first you criticize games that piece their levels together from premade building blocks then you praise spelunky and the binding of isaac which do pretty much exactly that and feel more "samey" than every good roguelike i know.

[st33d]

Actually making a connected level without resorting to bombs (Spelunky, Binding of Isaac), digging (Minecraft, Terraria) or some other Deus Ex Machina (Nethack) is a lot harder than people think.

I've only just managed to solve the problem myself - and before then I thought I'd solved it but it was horribly broken %5 of the time (usually for playtesters, never for me). So it's probably still broken even though I've implemented yet another fool-proof connectivity test on top of it all.

[eclectocrat]

I've only just managed to solve the problem myself - and before then I thought I'd solved it but it was horribly broken %5 of the time (usually for playtesters, never for me). So it's probably still broken even though I've implemented yet another fool-proof connectivity test on top of it all.

And computationally expensive. Floodfill > Tunnel > Floodfill > Tunnel ad nauseum.

[st33d]

I save the floodfill for the end now.

Now it just doesn't give a fuck, then tests whether it's all connected at the end. And if it doesn't (which isn't that common) it just rolls again.

The results are actually better than trying to get it right as you go along.

[Fallsburg]

The places where a PCG system make sense:
1) Where content can be samey but shouldn't be the same.  e.g. trees
2) Where having the same content repeated makes the game uninteresting (or less interesting or just goes against the design principles of the game). e.g. Roguelikes (turning from strategy game to puzzle game)

To make a good PCG level design system you must:
1) Be able to differentiate between a good level and a bad level.
2) Be able to design a good level
3) Be able to create a system of rules that can do either 1 or 2, and hopefully both (the easiest is typically creating a system of rules that can do 1 well and 2 decently, so that you can just reroll if you determine it isn't good)

Personally, I don't think a danmaku is a horrible choice for PCG.  The Geometry Wars games sort of get to that type of play (i.e. find the negative space [or create it yourself]) and are PCG.
That being said, you should understand what makes a danmaku good and/or bad, beyond the level of "know it when I see it". And if you can do that, then you should probably be able to make a good level by hand.

[antybaner]

The places where a PCG system make sense:
1) Where content can be samey but shouldn't be the same.  e.g. trees
2) Where having the same content repeated makes the game uninteresting (or less interesting or just goes against the design principles of the game). e.g. Roguelikes (turning from strategy game to puzzle game)

To make a good PCG level design system you must:
1) Be able to differentiate between a good level and a bad level.
2) Be able to design a good level
3) Be able to create a system of rules that can do either 1 or 2, and hopefully both (the easiest is typically creating a system of rules that can do 1 well and 2 decently, so that you can just reroll if you determine it isn't good)

Personally, I don't think a danmaku is a horrible choice for PCG.  The Geometry Wars games sort of get to that type of play (i.e. find the negative space [or create it yourself]) and are PCG.
That being said, you should understand what makes a danmaku good and/or bad, beyond the level of "know it when I see it". And if you can do that, then you should probably be able to make a good level by hand.

I would agree for the most part besides the idea that spellunky and TBOI are not ask good as, for instance, diablo or fate. I rather think that games like that have the problem of making you go through 50x levels that have no varriance what so ever. If you play these games for long enough, you begin to already predict the level build. ITs also true for spellunky but its not as bad. I did once get to the point where I could predict if a pot in spellunky had a spider in it or not but...