Conclusion and final thoughts

This concludes our random walker level generator tutorial. At this point you should have a clear understanding of the algorithm which is divided into two conceptual parts:

• constructing a conceptual representation of the level with the help of state.
• using state to build the TileMap level.

We explained a number of techniques used in procedural content generation:

• The effective use of RandomNumberGenerator to advance a walker in a random direction based on the values stored in the STEP array.
• We saw how to control the movement of this random walker based on the frequency of values stored in STEP.
• We covered how to use TileMap to store pre-defined assets and use them to populate the level.
• And one of the more important concepts: we saw how to divide a somewhat complex problem into manageable functions.

Some useful notes

1. We used the dictionary type in a less common way through state.unused_rooms. We simulated a set type in GDScript, by storing the values of interest as keys rather than values in the dictionary. And we did that because it’s fast to insert and delete keys, compared to deleting values in an array. In this case, the values associated with the keys don’t matter.
2. We relied on RandomNumberGenerator in this tutorial. It’s worth knowing that these aren’t real random number generators. They’re actually mathematical formulas that, given a seed, start producing a sequence of seemingly random numbers based on some distribution. This is actually useful because it helps us rerun our algorithms in predictable ways for debugging purposes. If the numbers were truly random there wouldn’t be any way to control them.
3. In order to minimize potential bug sources, we used Dictionary.duplicate() in functions that receive dictionary parameters. This way we get to modify a copy instead of the passed in variable. There’s also a similar method Array.duplicate() for the array type. The duplication does create a performance and data overhead because, but used wisely, this pattern significantly reduces bug sources.
4. It’s worth wile talking about the enum types. These types have an interface similar to that of dictionary. That’s because, they’re actually syntactic sugar for dictionaries. The enum values are guaranteed to be of type int and the keys are of type String. For example, if we have enum Color { RED, BLUE = 3 }, we can call functions like Color.size(), Color.values() and many more. We can also use them in loops: for c in Color where c will cycle through the keys: RED, BLUE in our case. We can also access values with brackets: Color["RED"] and even change the values of the enum at run time: Color.RED = 1. But this isn’t smart because enum types are supposed to be in essence used as constant values. Further more Godot doesn’t even complain if we assign a value of other types: Color.RED = "red". This is illegal in an enum declarations: enum Color { RED = "red", BLUE = 3} throws an error. Better to stay clear of reassigning values when dealing with enum types.