wiki:PlanningWiki/DungeonGeneration

Dungeon Generation

Current default method is roughly:

  1. Decide to build 36-50 rooms
  2. Divide the dungeon into 108 (6x18) blocks of 11x11 grids each
  3. Until we have built as many rooms as we want or run out of space:
    1. Pick a random block we haven't tried yet (out of the 6x18 total)
    2. Choose a rarity
    3. Choose a (weighted) random room type of that rarity
    4. Check the profile allows that room
    5. Check there is space for the blocks allocated for that room type, with the chosen block at the top left
    6. Build the room in that space
  4. Connect the rooms

Restructure

  • Big question is whether to ditch the old block allocation system (fizzix).
  • Second big question is whether to use a more flexible corridor system, like A* (fizzix).

OK, I have a partial answer to the first question, and have done some stuff which may shed light on other issues. I have done a big rework of the whole dungeon generation code, with the following things now true (Nick):

  • the four different types of permanent and granite walls are now gone. The labelling of granite as inner, outer etc has been moved to flags to cave->info, which are wiped at the end of generation. Also, I've changed permanent walls to TERM_BLUE_SLATE - I always found the brown ones made me thing "dirt, therefore diggable"
  • a lot of dungeon generation parameters have been moved to the dun_data struct, some things have been given clearer names, arrays have been allocated dynamically instead of statically (allowing removal of some constants) and the dependence on blocks has become optional, with the block size being a parameter to the cave_profile
  • the function generate_starburst_room (stolen from Oangband - I don't actually fully understand the whole arc thing) will generate an arbitrarily sized room with edges made up of internally facing arcs. This is used for
    • build_huge, which builds a massive open room, perhaps broken up by rubble;
    • build_moria, which builds ragged-edged, caverny rooms used in moria levels (which are levels consisting mostly of these rooms, and populated mainly by orcs, trolls. giants and ogres) and
    • to make natural-looking areas containing a particular terrain feature (so far only rubble).
  • the function find_space (also pinched from O) can be called from within a room_builder function to find an area of free blocks to place the room. The advantage of this as opposed to the generation function allocating the space is that the room knows its own size more precisely.
  • a couple more room types are available (taken from O/FA again)
    • rooms of chambers, which are big areas of small adjoining rooms, filled with (usually) monsters chosen thematically using pit profiles
    • interesting rooms, which are like less-than-lesser vaults - they're really occupying a similar niche to template rooms, but I thought throwing them in was worthwhile anyway
  • related to this, I've included a lot of different vaults from FA as well, and could easily from elsewhere too - PosChengband? for example has some awesome ones (many designed by Derakon!)
  • along with this, there is the facility to include specific objects and monsters (chosen by monster base) into vault and interesting room templates; this could easily be extended to template rooms. The monster part of this is done using the function mon_select, which can be chosen as the get_mon_num_hook argument to get_mon_num_prep
  • the function mon_restrict allows temporary restriction of monster generation to a particular kind of monster - usually chosen from a pit_profile. This enables the restrictions mentioned above for moria levels and rooms of chambers, but would also allow a similar thing anywhere in the dungeon
  • there is a sample cave_profile, called sample1, in generate.c which can be easily swapped in using an ifdef and which demonstrates a lot of the things mentioned above

Note that (apart from the wall colour change) there is no gameplay change; I am hoping, though, that the code is flexible enough that making gameplay changes is a lot more straightforward.

Post-restructure

  • Different areas of level where special properties apply (Nick)
    • unmappable
    • no teleport
    • no summoning
    • "themed"

Possibly Related Tickets

Last modified 3 years ago Last modified on 03/01/14 22:34:48