Why are dungeons so often created subtractively rather than additively?

Question

I'm having difficult deciding on how to procedurally generate a dungeon floor. The way I've been doing it so far is like so:

• Populate list of Rooms with random height and width.
• Place first room in list at (0, 0).
• Add room to a temporary list of rooms that have been successfully placed.
• Place next room adjacent to a room randomly chosen from the aforementioned temporary list
• Keep repeating previous step until room is successfully placed then move onto the next room.
• Repeat the two previous steps until all rooms have been placed.

After that the doorways between the rooms are created and various steps are taken to assure collision is working properly but my question is this: Why does it appear to be common practice to first create a large area of cells that all are 'filled in' and to then 'carve out' rooms and corridors rather than to generate dungeons my way? I'm not saying my way is better, I would be happy for someone to tell me what I'm doing wrong and why I should be doing it differently. I just find my way easier for managing the various rooms and cells within my dungeon. It also means I don't have a bunch of 'useless' cells on the other side of the dungeon walls doing nothing but hogging processing power - that's something I never understood.

I just want to a way of generating a dungeon which balances efficiency and design.

Answer 1

If it's easy for you, keep to it. No one says you have to do it a certain way, or that yours is wrong.

The reason it's typically done this way - subtractively or as you aptly put it, "carved" - is most likely due to the influence of roguelikes, which were arguably some of the first games to generate dungeons. In roguelikes the player can tunnel anywhere within the level's rectangular space, so every cell, even if not initially walkable, is recorded as a tile in the map, in case it becomes walkable later. Thus, tiles may as well all start out as closed spaces with the potential to be opened.

Another genre very often associated with tilemaps is the RTS, where most ground is open by default, and in which it thus makes sense to simply generate the map as all open tiles. Overland RPGs are similar in this regard. So this is certainly another influence on the typical approach.

Your approach better suits a game in an indoor space where no dynamic tunnelling will occur, i.e. once the level's rooms have been created, they will always remain the same. Obviously then we can have various very small 2D arrays each representing a room's tiles, and these can be connected in graph-fashion. This is far more memory-efficient, but again, tunnelling in the large spaces between room bounds is, if not impossible, then harder to achieve (at least, you would need to create new nodes in your graph of rooms, and allocation may not be intuitive since you don't know how wide/high the room in question will ultimately be). Memory is hardly an issue for most game levels, given the low cost per tile and the memory we have available these days (gigabytes).

This is informative in terms of the sheer number of different approaches to maze generation.