I use the two terms interchangeably.

For every wall cell, try to apply this: If the wall has 0 neighbors to the left or right, destroy it. If the wall has 0 neighbors to up or down, destroy it as well.

Thanks for the feedback! Since the demos are not scripted like the rest of the video, my error-ridden brain takes over and thus we see some explanation quirks.

No problem, they were fun to make.

Yes, you are correct, I made some arithmetic mistakes while doing the calculations manually. I'll post a standalone comment about this. Thank you.

@@WhiteBoxDev OK thanks, I'm glad I wasn't off the beam - I was worried I'd messed up. I'll stay tuned for your comment so I can complete the exercise.

Good luck with your projects! I suppose the best hint I can give to beginners is that procedural generation is never about just one perfect algorithm or method. A generated world is built with all kinds of algorithms layered on top of each other. The result of each layer can be interpreted by the programmer however they like. It’s all about creative thinking and breaking down the end vision into a series of steps.

@@WhiteBoxDev Thanks. Indeed, multiple layers are necessary, even just for creating biomes. What I have in mind for continents was the Voronoi noise and opensimplex on top of that. I'd love to find an article containing the good practices for worldmap generation, though. Advanced math isn't exactly my strong point.

The cool thing about procgen is that you can create your own quirky algorithms just by thinking of little tweaks that might align better with whatever you're making. There are many established algorithms, but what makes them really come to life are the little changes you make.

The name Cx6 is a play on VVVVVV (a popular indie title), where "C" is short for "carrot" or "^", which is an upside-down "V".

The implementation I explained in the video is exactly what I wrote in the demo project.

@@WhiteBoxDev Thank you for the quick response! I am certain that I implemented it correctly; I suspect it might be due to a difference in math.random implementation in the engine i'm using. Looks like i'll need to find a different generation method

Hi from six months in the future. Sorry for not replying back then, must have missed your comment. Yes, you are correct, I made some arithmetic mistakes while doing the calculations manually. I'll post a standalone comment about this. Thank you.

@@WhiteBoxDev No worries! It was an enlightening video nonetheless, and I enjoyed implementing and playing with the algorithm you presented.

Unlikely, however thinking on my feet, I might do the following: 1. Use flood fill algorithm to scan all areas on the map and keep track of their volumes. 2. Average the position of each tile in each volume to get the "center tile" of each volume (or somewhat close to it). 3. If any volume is less than some threshold, then it should be either filled (eliminate it) or connected to the nearest volume. Hope this gives you an idea of how to go about doing this. I'm sure there are plenty of alternative ways, but this would be my first approach.

@@WhiteBoxDev ​Thanks for the advice! I assume after performing a flood fill (but before actually filling in the cells), the volume would simply be how many elements were to be filled? That's a lot simpler than I thought it would be

@@spectrecular9721 Based on your term "volume", yes I figured you meant "group of similar cells". The actual connecting of distinct volumes would be up to your creativity. Glad to help. :)