Changes between Version 4 and Version 5 of PlanningWiki/DungeonGeneration


Ignore:
Timestamp:
03/01/14 22:34:48 (3 years ago)
Author:
nckmccnnll
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PlanningWiki/DungeonGeneration

    v4 v5  
    1818 * Second big question is whether to use a more flexible corridor system, like A* (fizzix). 
    1919 
     20OK, 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): 
     21 * 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" 
     22 * 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 
     23 * 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  
     24    * build_huge, which builds a massive open room, perhaps broken up by rubble; 
     25    * 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 
     26    * to make natural-looking areas containing a particular terrain feature (so far only rubble). 
     27 * 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. 
     28 * a couple more room types are available (taken from O/FA again) 
     29    * rooms of chambers, which are big areas of small adjoining rooms, filled with (usually) monsters chosen thematically using pit profiles 
     30    * 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 
     31 * 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!) 
     32 * 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 
     33 * 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 
     34 * 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 
     35 
     36Note 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.  
     37 
    2038=== Post-restructure === 
    2139 * Different areas of level where special properties apply (Nick)