Procedural Content Generation
The next big thing I’m working on is the procedural generative nature of my game. Procedural Content Generation, or PCG, is a superset of algorithms that focus on creating content of some sort based on a specific number of parameters, as opposed to manually curating and implementing all the content in a game.
Spelunky, as I’ve mentioned earlier, uses PCG to generate the levels, and I too will be creating procedurally generated dungeons. To do this I’m going to be using something called grammar-based generation (GBG). GBG creates a gameplay graph of successive player actions, and then I’ll use that graph and convert it into a series of rooms and corridors that recreate what the graph describes.
Doing this effectively will make my game more modular for future expansions, as if one day I decide to add a new “verb”, such as a boss room or a trap, all I have to do is add it to the GBG, rather than refitting the dungeon generator to now account for the new room types I want to use.
I didn’t realize it until writing this, but Spelunky actually performs GBG as well. The great thing about GBG is that it makes it easy to add dungeon-wide constraints, as opposed to individualized room constraints: you can easily state to only have two rooms with item pickups, or maybe only 20 rooms maximum on a floor, so on and so forth. Spelunky’s GBG algorithm always and only generates 16 “chunks” across four “depth” levels, and it always ensures that there is an open path between the start and end chunk, AND it uses other constraints, such as making sure certain items are only placed on the open path, etc.
My game’s GBG will likely observe constraints such as only one item pickup per floor, a reasonably diverse range of difficulty levels, and limiting the number of times a room has multiple exits so as to reduce the number of dead ends.
