The following article contains my Extended Thoughts on Procedural Generation systems discussed in the Gameology podcast with my co-host Mathew Falvai. You can listen to the Podcast via RSS, on iTunes, Google Play Music, or watch the episode in video format:

Procedural Generation

Having discussed Environmental reuse last week, I wanted to touch upon another game design tool; procedural generation. Advances in both hardware and software have improved the nature and quality of experiences generated by procedural generation. As the prospect of using procedural generation becomes more accessible, it is important to consider its use cases.

When talking about procedural generation it will be useful to break it up into two distinct categories; procedurally generated experiences and procedurally generated environments. A procedurally generated experience is one that takes place within a fixed environment (an "endless" mode in a game where enemies keep spawning according to a set of rules) while a procedurally generated environment is the physical space that an experience takes place in (a randomly generated dungeon). A procedurally generated experience can take place in either a hand-crafted environment or one that was created with procedural generation, whereas a procedurally generated environment can only play host to a procedurally generated experience as the level will never be seen by a designer.

Procedural generation may seem like a great tool for small teams to quickly build out the physical terrain of large game worlds, but there is a significant time cost associated with creating that system in the first place. To break down this time cost, lets go over the basics of how a procedural generation system is built.

At its heart, a procedural generation system is a constrained means of creating random outputs. Those outputs can be (but aren't necessarily limited to) the experiences or environments you are seeking to create. The constraints are made up of the very same rules you would use as a designer when creating your game (certain enemies must be placed on the ground, power ups should not be placed on spots players cannot reach). Certain "rules" will no-doubt be easier to recreate in code than others. The more elements there are in your game, the more the constraints grow exponentially as all possible inter-relations of those elements must be taken into account. Consider this example from a platforming game like Super Mario World; while it might be easy to create a system that does a position check to ensure that Goombas are always placed on the ground, it might be more difficult to ensure that those Goombas are not placed in such a space which it will make it impossible for Mario to jump up through a one-way floor. Of course, you could create a simplified set of rules for such a game by only generating terrain which can be traversed through a series of easy-to-perform jumps; making "safe-guesses" as this will guarantee that you'll end up with something playable. Of course, "playable" can be a long way from "fun". Ultimately, you need to decide if the scope of the project you are working on merits the time investment necessary to create a procedural generation system, or if that time would be better spent hand-crafting your levels.

Whether or not you use procedural generation to create your game environments, it can be an excellent tool for decorating them. For instance, if you are creating a large open-world where the emphasis is on filling a large area with decoration, you can use procedural generation to fill a space with a set of randomized elements. For example, it would be incredibly tedious to decorate all the roads of a city with lane markings, cracks in the pavement, weather damage, etc. but you could easily feed these details into a procedural generation system and have it do a large amount of the work for you, so long as you take the time to look over what the computer came up with and verify that it didn't make something outlandish.

On the experiential side of things, procedural generation is excellent at creating certain types of puzzles, specifically ones with simple rule sets like that of a Rubix cube. The possible movements the cube can make can be encoded and then applied as a shuffling algorithm to scramble the puzzle.

The same sort of logic can be applied to creating a Sudoku. A completed board can be generated which adheres to the rules of a Sudoku, then numbers can be deleted from the board at random to create the puzzle itself. That being said, any puzzle which is created by an algorithm can be solved by an algorithm. Relying too heavily on procedurally generated puzzles can get boring or frustrating because the computer can actually spit out puzzles faster than it takes a player to solve them. At that point, the challenge being presented is as arbitrary as playing 52 pick-up. That being said, lots of people enjoy Sudoku puzzles and solving scrambled Rubix cubes, and I don't mean this as a slight against that sort of entertainment. However, as I see it, with the power and flexibility afforded by modern game devices I personally believe we can create puzzles that are more varied, interactive, and satisfying to solve. 

As with all tools available to a game designer, if you decide to use procedural generation in the creation of your game, or as part of the game experience, you must consider all the implications of the randomly generated experiences that the system can produce. Investing a lot of time into a well built procedural generation system can create a near-limitless number of possible experiences, but volume does not substitute for the quality of an experience. It is highly important to start with a fundamentally strong game-play experience, only then should you consider which elements of the experience can be handed over to a procedural generation system.

For more Gameology Episodes, Extended Thoughts articles, and to check out the games I've made, consider visiting BluishGreenProductions.com. You can find me on Twitter @BluishGreenPro