Sean Howard totally stole my idea!

When I first saw the Three Hundred Mechanics project by Sean Howard my thoughts were, I have to admit, less than charitable. Early on in my life I developed a knee-jerk frustration with “idea men,” folks who thought a few scribbles on a paper napkin or, even worse, an hour on a word processor gave them a claim in someone else’s hard work. Even before I could write a program worth looking at I ran into folks who said, “Oh, you can program? I’ve got this great idea for a game that you should do,” and then they’d proceed to show me a file folder of a game they designed, making sure, before I could politely tell them I wasn’t interested, that they’d get the credit for it. It wasn’t just that they’re pitch was unsolicited but that they seemed to have no respect for the amount of time and energy that goes into making a game, fully convinced that their “idea” was the biggest and most important part. When they’d say things like, “I want it to be just like…” followed by some game that took a team of 150 Japanese four years to produce I had to just walk away.

But when the 300 Mechanics project came around I decided to make a conscious effort to give it a chance. Generally it hasn’t been too bad. I still say it needs a little less talk and a little more prototyping to help with his programmer cred; he does make concentrated efforts to think his ideas through. So every once in a while I’ll pop back in to see if he’s done another write up.

Recently I stopped by and saw that he had updated with an idea that I wrote about over 10 years ago. I’m talking of course about the “Legend of Zelda done with procedural generation.” Of course 10 years ago I called it “randomly generated maps” but it’s the same thing. I’m going to forgive Mr. Howard for now so that I can delve deeper into a discussion about Procedural generation now. But mark my words, there will be a reckoning.

What is Procedural Generation? Procedural Generation is a buzzword for any time something is done by the computer that could otherwise be done by hand. It’s a broad definition that has been applied to everything from the character animations in Spore to the maps in Dwarf Fortress and other roguelikes. Theoretically any time a program uses rand() you’ve got procedural content, tho for the most part choosing where the robots start in robot escape is not considered a good example.

Why Procedural Generation? In the space exploration game Frontier – Elite II the entire universe was, like in the Total Perspective Vortex, extrapolated from a single piece of fairy cake (a cupcake). In this way the game could fit on a single floppy. In Spore a multitude of multi-limbed, and sometimes no limbed, creatures move and interact with the world without needing a human to figure out a walk cycle. Roguelikes can promise you will never play the same level twice, unless you want to. Even Cymon’s Games own Numbrix Generator is an example of procedural generation, letting you have a book of puzzles now, instead of waiting for the slow arduous process of hand generation to catch up with demand. From a developer perspective everything you can generate procedurally is one more thing you don’t need and artist or designer to do for you.

Well, then, why not procedurally generate everything? I’m glad I asked:

I should mention that I’m more interested in procedural level generation than procedural animation. Procedural animation, if it looks good, is a good idea because it allows more fluidity with less work, tho it does suffer from some of the same pitfalls as other procedural generation exercises.

Procedural generation requires a deep understanding of what you’re trying to generate. It took me literally months to figure out how to generate space filling unicursal paths. That may just be me, but when you’re writing a procedure to generate something “make it look good” doesn’t translate to code well.

To this end I like Sean’s notes about generating a platforming game’s levels as he really thinks about what is “fun” in a game, which is one of those things that just happen when they’re done by hand. There was an attempt at making a procedurally generated Mario game a while back, but if you play it you’ll quickly discover that while it is random it’s not really fun. While Sean’s notes were on the right track if they were implemented as-is there are a lot of things they don’t mention, like multiple paths through an area, unnecessary areas that could lead to power ups, and being able to survive some pitfalls in order to try again. How do you implement these without falling back on something that’s more like “draw from a library of elements and stick them together” is the challenge. Not that there’s anything wrong with a library of elements. Diabalo used that method and it worked great to give a sense of variety. But if your library isn’t big enough or your random generation doesn’t do it’s job you could run into scenarios where the same element gets regurgitated too often. When you start to see the same element in every game the selling point of procedural generation begins to lose its effect.

Another challenge for procedural generation is “challenge” as in difficulty levels. With my puzzle generator there is no way of knowing if the result will be easy, medium, or difficult. While it may be possible to analyze it after the fact, I don’t even want to imagine what it would take to generate on the front end to a difficulty spec. Making a game the challenges the player without over stressing them is an important part of game design. Making a game that gradually increases that challenge is also important. Try to make a good procedure to do this and suddenly hand generation starts looking a lot more appealing.

Then there’s testing. A million possible outcomes is a million places for things to go wrong. If you’re producing a commercial product there’s no way you’re going to get that past QA.

Finally there is the user’s attention span. Again, maybe it’s just me, but if the box of a game promises 100 unique dungeons to explore in one of a million worlds you could play, I’ll probably pass on that game in favor of a game I can feel like I’ve accomplished something in a more reasonable time period. If I wanted infinite complexity in a world I’ll never be able to explore a fraction of then I’d take up globe trotting and get some fresh air at the same time, which I hear is good for you.

How can Procedural Generation work, then? I think the development world has pretty much come to accept that procedural generation is not a silver bullet that will put hundreds of artist, animators, and designers out of work. (Although it doesn’t look good for actors and mocap at the moment.) It does, however, have the potential to be a very powerful tool in the right hands.

The first thing to making procedural generation is to read all the counter points above as pitfalls to avoid. The next step is to realize, if you haven’t already, that developing a procedural generation solution takes time, and developing a good solution takes more time. Which is why most commercial products stick to the old formula.

But procedural generation can extending a gaming experience and with it the life of a game. As previously mentioned, Frontier – Elite II used algorithmic universe creation to fit their game within the confines of the media. Star Control 2 did something similar, tho only with the minerals on the planets. However, if you’ve played SC2 (as much as I have) you’ll notice that the minerals area always in the same place. This is because while they used a psuedo-random generator to place the minerals the kept the key a constant. (I don’t know about Elite II, never played it… yet.) What if that idea were implemented on a larger scale? The first time you play a game it defaults to a fixed key so that your game, your friend’s game, and they guy writing the strategy guide all are the same game, but then at the flip of a variable you let the wheel of random keys spin and suddenly you don’t know what you’re going to get. Suddenly you’ve got a unified gaming experience for those of us who just want to “get to the end” and darn near infinite re-playability for everyone else.

And the final reason for working out how to do something procedurally is just for the challenge of the thing. Sometimes procedural generation is it’s own reward.

Conclusion. I’ve said my peace, so I’ll just wrap this up here with a bulleted summary:

• Procedural Generation is cool.
• Procedural Generation can make infiniate replayablility a reality.
• Procedural Generation is difficult to do right.
• Procedural Generation is time consuming to do right.
• I totally had the idea of a randomly generated Zelda game first.