Really interesting! I didn't know about this concept of "rubber ducking". My tendency is to try and organise my thoughts by writing down notes about all the steps I'll need to go through (which I then never look at again). I guess it's quite similar, just without a real person and/or duck.
it is similar. I feel another person works best, because you have to drill down to the point where it's understandable by someone else. Whereas "notes to self" (and / or rubber ducks :) ) don't place a hard restriction on how understandable you have to be.
Another thing that works well is simply commenting the code as if someone else was going to work on your game, with the added bonus that you end up with commented code, of course. Which is as much help for your future self as it would be for an actual different person.
In this case, I have a relatively clear idea of how to achieve the functionality I want... it just involves a lot of steps. Today I got through this one:
Wow, nice, that was very quick! I'm assuming you use something similar to good ol' flood fill, but with tiles instead of pixels? (i.e. something like a breadth-first search).
That wasn't even a task particularly unique to procedural generation, it's just that it takes time to set it all up. Also I was really not in the flow this evening coding-wise... You know that feeling where somehow every single change you make has unintended consequences that mean changing something else?
I wish I could say I don't, but I'd be lying through my teeth. :D
(Also that feeling where a bug you're struggling to fix turns out to be because you put a curly bracket in the wrong place...)
Yeah, it's similar to the feeling I had about a week ago when I found out the cause behind an utterly mysterious and unexplainable bug that evaded debugging and logging. This one caused things to appear and disappear from the game when you activate your character's Ultimate Attack. This is triggered by pressing Melee and Ranged at the same time... respectively bound to Ctrl and Z :D . If I had realized the bug only happened when playing the game in the editor, I guess I'd have figured it out earlier!
Anyway, now that this is sorted, the rest boils down to: Make a node graph of the floor regions, find all potential ports between regions, and fill in ports until the regions are all accessible. For the ports, I'll start off with stairs as these will be relatively easy, but ultimately I want to add extra paths to link more distant regions.
So for now you're doing the above separately for each "screen", that is, the idea is to have all floor regions in a single "screen" accessible from within the screen, without going through a different screen? The alternative would be to construct a dungeon-wide graph of all the regions in all the screens, and make a fully connected graph out of all of them combining same-screen stairs and adjacent-screen doors, right?
I have an intuition the latter would not be significantly harder in the long run (you have to compute adjacent-connecting doors sooner or later anyway) and would result in richer dungeons, while doing the former first could mean coding a significant amount of work you'd later throw away, but obviously you have given this much more thought and are able to calibrate it better.
There's also the extra wrinkle of doors which aren't meant to be accessible from other doors (which the dungeon layout routine does allow for), but I'm hoping that won't cause too much extra work.
Doors accessible from other doors? You mean one-way doors? I'm somewhat lost here with this bit.
Another interesting link! I agree with everything you say, while also not knowing exactly how I'll feel by the time my game is in shape to actually get more feedback =)
Try showing the game to friends and then carefully considering what feedback they give you as if they were your bosses, that's good training. I pretty much treat my friends as bosses for the purposes of this game, making an effort to regularly send them new version with meaningful new content, etc; it keeps me revved up and motivated.