Author here. I love all of the deobfuscations. Usually, when I put code online, I try to make it as clear as possible. It's really interesting to see that going the other direction actually makes it a more interactive experience for the reader.

This one is great: https://gist.github.com/airstrike/66e0152e75c3a81fd1496bfbf5...

A couple of remarks:

// The door should not be created in the cave's corner or over
// another door, or in another cave's corner. It's impossible
// to make a cave without a door, because randInt(1) always
// returns 0.
if (atWallButNotAtCorner && FIELD[y][x] == TILE_WALL) {
doorCounter++;
if (randInt(doorCounter) == 0) {
doorX = x;
doorY = y;
}
}

The randInt() part here is pretty confusing. Here's the intent of the code. It picks a random boundary for the new room. Then it walks over the edges and finds every tile where the room's wall overlaps the wall of an existing room. Those are candidates where a door can be placed to connect this room to the existing one.

If no candidates are found, the room is discarded. This ensures the dungeon is always connected.

If there are multiple candidates, we only need to pick one. We want to pick one randomly because otherwise you'd get obviously biased choices where the door always appeared at the left-most edge between two rooms or something. The obvious way to do that is to build a list of the candidate coordinates and then choose a random element from the list.

But that's a lot of code. Instead, I use Algorithm R [0]. It's a streaming algorithm for selecting a random item as you walk the set of items being sampled. The idea is that you keep a running winner. Each new element, you have a random chance of replacing the winner. As the number of elements visited increases, the chances of replacing the winner decreases. So the first element has a 1/1 chance of being the winner. The second has a 1/2 chance of replacing the winner, the third 1/3, etc.

// If the cave's walls were made completely out of corners
// and doors, don't make such a cave
if (doorCounter == 0) { return; }

This case actually means the new room didn't share a wall with any existing room.

// We need to somehow record corners of all caves to check
// for intersections later, so we use a special tile for it
FIELD[y][x] = atCorner
? TILE_CORNER
: (atWallButNotAtCorner ? TILE_WALL : TILE_FLOOR);

For a room to connect to an existing one, they need to share a tile on their actual sides, like:

#####
#...#
#...#####
#...X...#
#####...#
#...#
#####

That's leaves at least one tile where we can place a door. If only the corners overlap, there may not be enough room to connect them:

#####
#...#
#...#
#...#####
#####...# ???
#...#
#...#
#####

#####
#...#
#...#
#...#
######### ???
#...#
#...#
#...#
#####

So, during room placement, the corners are not treated as part of the room:

###
#...#
#...####
#...X...#
####...#
#...#
###

###
#...#
#...#
#...####
####...# ???
#...#
#...#
###

###
#...#
#...#
#...#
### ### ???
#...#
#...#
#...#
###

But, when rendering the rooms, I want them to look rectangular. So the special "!" means "render like a wall, but don't act like a wall".

// 1d6 of entities total, 25% chance of gold, 75% of a mob.
// Mob letters range from 'A' to '~', inclusive

Technically, the "mob" case includes all of the non-"$" treasure too. Punctuation characters are in that character range as well and represent items.

Otherwise, the comments are all spot on. It's really gratifying seeing people figure this all out.

[0]: https://en.wikipedia.org/wiki/Reservoir_sampling#Algorithm_R