next »

[baconman]

As I go about, slowly-but-surely fleshing out my gamedev projects and discussing ideas; one thing always seems to creep out of the blue whenever I mention it: PGC level design.

Most people think it kinda sucks, and removes the art of masterful level design from a game. Fact is, most of the time, it does. In just about every instance provided, it does. So I understand the skepticism surrounding it. I do believe however, that when properly utilized, PGC *can* be intergrated with cohesive level design to make something beautiful (and VERY HIGHLY replayable!), and I'm here this morning to try and illustrate how.

PGC relies heavily on randomizing circumstances; and most games that use it tie a random number generator to the system clock, usually producing in essence, a "new game per second." This leads to two things: a very high level of randomization, and a very high dispersal rate of content. Usually within a day or two, you've already seen pretty much all (or at least most) of what the game has to offer. And there's nothing to it about "beating a level," you simply beat one screen/scenario at a time; not too unlike random encounters in RPG's.

However, not all number generators *have* to work that way; and there can be ones designed with deliberate cohesiveness and deliberate randomness about them. One that I'm planning to use, with which to solidify the concept with old-fashioned level design works mostly based on the hour-of-day, the day-of-month, and the day-of-week. This creates a system that can produce both a range of frequent changes, and a set of long-term changes, ensuring both the spirit of "randomness" that PGC games are known for, and a prolonged dispursal rate that ensures that the game you play tomorrow *will* offer you something that the game you played today did NOT.

First of all, I'm going to discuss mathmatical factors and cohesiveness. Used in proper mathmatically-related sets, games that have randomizable factors that share a common multiple can be used so that one section of the game can "assume" neighboring results. For instance: 2, 3, and 6. If "x \ 6 = 4", you can then assume that "x \ 2 = 0" and "x \ 3 = 1". Once you have the level sets for factors 2 and 3 done; you can deliberately engineer a level for factor 6 that takes them both into account.

Took a little fiddling out (very little, in fact); but I've already found an optimal order to these factors:

\ 1 = completely consistent (usually, level beginnings and/or ends)
\ 8 = cohesive loop #1 (8 > 4)
\ 4
\ 12 = cohesive loop #2 (4 > 12 > 3)
\ 3
\ 6 = cohesive loop #3 (3 > 6 > 2)
\ 2
\ 10 = cohesive loop #4 (2 > 10 > 5)
\ 5
\ 7 = at this point on, the design becomes more randomized
\ 11
\ 9

For an example of a cohesion loop in work, let's look at Lost Hills or Lost Woods in orignal Legend of Zelda. You can use the 12-factor to produce 12 different screen-scrolling solutions. Say 3 of the directions lead you out to a common area of gameplay; and the fourth is the one that the solution "requires" in order to access. The 12-factor generates both the puzzle and the answer (the solicited advice cave, and variable dialog that goes with it). You can assume from the puzzle that one of those 3 directions (IE: the 3-factor) will lead you out in one of those directions - so you can *also* use a 3-factor to place the "solicited advice cave" on that screen (since it's result with the same randomization will always coincide with the 12-factor's). You can also use a 4-factor to randomize what the following screen contains. For instance, (dungeon, big gift, sword upgrade, letter).

x \ 12 = random puzzle/solution
EQUALS
x \ 3 = semi-random place of solution shop/"safe exit"
TIMES
x \ 4 = semi-random consequence of solving puzzle

_{Did I lose anybody there?}

Depending on the result you're going for, you can snip out any part of this formula, and use only part of it. Removing the "cohesive loop" steps or the low-factor ones between them will natrually break the cohesion, if you want more randomness; and removing the randomness in the end will lead to more cohesiveness. You can also play around with the "12 factor" to create a sense of foreshadowing to the "6 factor;" as that *also* has a cohesion factor about it; which can be very good for storytelling!

The second step is about the randomization itself. As mentioned before, it's optimal to gameplay value that some things randomize more often, and some things randomize less often. This is where a lot of PGC design starts sucking; because they often stick to a single source of randomization. You can mix up sources any which way you want; but here's how I see myself mostly using this approach:

1 = consistnecy. Something you ALWAYS want in place, like a starting point. Say (again) it's a PGC Zelda; you'll probably want your homescreen to have a 100% chance of containing the wooden sword. That's what 1-factor is all about.

7 = day-of-week. Not only is this pretty obvious; but 7 makes a very "lucky number" when it comes to pro-gen. Using it as day-of-the-week is something only it can do; and that insures that it's always result that's independent of other factors, such as day-of-the-month. If you plan on doing some kind of "rare item/rare treasures," I highly suggest you make this one of your variables for it; and only hide each "rarity" in the factor once.

2, 3, 4, 5, 11 = hourly shuffle. These are areas that, while they vary, they don't have a LOT of variation about them. A factor 3 section only has 3 different outcomes, so there's not a whole lot of replay value in concealing them. So sections like these, you'll want to make shuffle pretty often, because it's the combinations of them that keep PGC interesting, especially where the lower terms are concerned. The "highly randomizable" factors you can stick pretty much anywhere, but seeing as 11 is the highest I'm planning to use, why not make the largest amount of frequently-changing areas as well?

6, 8, 9, 10, 12 = day-of-month. These higher factors are where most of your level design work is at; since they're the multiples of the lower factors, and provide the most cohesion. Even 9 has cohesion potential, sandwiched between two of the 3s; if you want to explore that. And since this is where most of your core level design work is, you're also going to want to preserve as much of that work for as much replay value as you can get out of it. So by randomizing it LESS often, you create more exploration potential upon replaying it in later dates.

If you're really savvy, you can even incorporate a "month of the year" variable with the 12-factor to create holiday-based decorations or level themes; or even to change the entire flow of gameplay by introducing something like a different starting item, or a protagonist with completely different abilities! So now, from one factor of randomization, you have a whole new game to learn and play, every month! It's consistent enough to be playable, and random enough to keep you coming back.

Bear in mind also; you have a full range of factors available on every randomization type. Just because you have a 3-factor "by hour" doesn't mean you can't ALSO have a 3-factor "by day" as well.


What I hope I've illustrated with this, is that PGC really has a METRIC ASSTON of untapped potential, and that cohesive level design does not have to die at the very mention of it. And that higher levels of randomness and lower levels of randomness don't have to be greater in value than one another, but utilizing them both can have a considerably greater effect that using one alone.

[eclectocrat]

I think I understand the details... 

I think I understand the gist of it... 

I like what I think I understand. I can only begin to fathom how to apply it to a roguelike game, cus as far as I can tell all of the stuff in most roguelikes are generated once at level startup. Given that it would be cruel to punish a player for starting his game on a Tuesday, I can't connect the dots to how this would be used unless it is implemented in a game that continuously generates randomized content.

Maybe I don't understand... 

What I hope I've illustrated with this, is that PGC really has a METRIC ASSTON of untapped potential...

Yes!

[gimymblert]

Great post

But I think you have needless complexity in that.

First, the reason PGC use random is to provide surprise, the problem is that those surprise are unplanned resulting in a distribution that is not interesting. It's not something hard to do.

The main idea here seems to use time as a source of randomness to group "surprise", hence it's a form of planning.

PGC have a lot of untapped potential and you are barely scratching it, i'm glad you try though.

My insight is that PGC is akin to Language, it's about breaking a level down to its semantic element and rebuild it using a grammar to create meaningful sentence. There noun (gameplay element) and verbs (action) eventually adverb (difficulty or monster level). So PGC has nothing to do with randomness.

A Roguelike for example is made of screen, level, room, corridor, items and monster. Screen contain room and corridor that contain monster and items, that's the syntax. But syntax is not enough, you need a way to generate thing meaningfully, for example there is constrain that made exit and start far apart, or remove monster that are close to the starting point. Also there is parameter to plan the level difficulty a bit, for example the most difficult monster only appear in the deepest level.

Randomness is a problem because it create little meaning, and PGC designer does not design with meaning in mind, they just hope to replicate superficially something that "look" good. It's like a reverse parser that produce grammatically good text that never make sense (colorless green sleep furiously). But you can replicate the process of producing meaning with planning parameter, that transform the PGC problem into a search problem (graph are a great tool to solve this, it happen language are easily turn into a graph(parse tree)).

Ask yourself, which kind of planning I do when I make a level? what motivate my decision? if you can translate that into rules, you can write a PGC that does it. Randomness is just one mean to simulate one aspect (variation), you can find other way to do that (number of partie, progression in the game, playstyles, previous pattern that have been use in generation, etc...).

[XRA]

great thread 
Once I start dealing with PG in level design I've been planning/dreaming to create various curves for specifics about a desired experience I want a level to have, that when put together can be considered pacing or even a reward loop. I'd then referring back to that when serving up the content.. a bit like what GILBERT Timmy brings up, I will already know how I want enemies and mechanics to work, so I will be able to build the procedural system around that. 
Level design in that case (as i see it) would become more about creating curves (or graphs) for various factors of a level, showing how I want to pace everything, it could even get down to controlling desired elevation changes or the average sum of turns the player is having to make X minutes..  controlling the introduction of enemies and items based on the player's performance and needs.
I guess I look at it as less of a completely random generation, and more of allowing the game to build out the experience and even scale it to the Player, while also have numerous experiences without having to do all the heavy hand crafting of each one. 

[Derakon]

Your concern about showing all the content to the player very quickly is more a matter of scale, I would say, than a problem with procedural content generation per se. For example, most roguelike games reveal content slowly to the player as they descend into the dungeon. Going deeper gets you new monsters to fight, new gear to play with, new traps to deal with, new dungeon configurations, and so on. This creates a sense of progression, and there's enough real time passing that by the time the player loses their high-level character to a horde of demons, fighting kobolds and rats with a new character is fresh again.

Now, if your procedural game only takes a couple of hours to play from start to finish, then yes there's a definite potential for the game to stagnate. In that case, though, I approach the solution from a different angle. Your concern, as I see it, is that once a player has experienced a given selection of content a few times, they'll get bored with it and that content is no longer bringing anything fresh to the game. The answer isn't to limit what content we show the player; that just delays the inevitable. The answer is to ensure that our procedurally-generated content remains interesting. This is naturally a harder problem to solve, but it is clearly doable.