Ticket #156: notes.txt

File notes.txt, 5.7 KB (added by takkaria, 12 years ago)

Notes on the changes made

1This folder contains a patch of the majority of the Oangband dungeon generation
2code, suitable for installation over a clean copy of Angband 2.9.3.  There will some
3issues when installing on anything higher.
5Installation is very easy:
6 - replace "generate.c" with the enclosed copy, recompile.
7 - open up "/lib/edit/vault.txt", and do the following _in order_:
8   - change all occurances of "X:7" to "X:6".
9   - change all occurances of "X:8" to "X:7".
11What parts of the Oangband dungeon generation code got included:
13I. Room placement
15Rooms are now built in descending order of difficulty.  Because the code builds
16greater vaults first, they usually appear when requested.  For each type of room,
17the code finds out how many it is allowed to build; you may specify this number by
18editing a table.  You want three greater vaults on average per level at level 30?
19Barring a few caveats, like limited monsters, objects, and space, you'll actually
20/get/ three greater vaults on average per level at level 30.  For each room of that
21type allowed, the code dynamically allocates 11x11 dungeon blocks.  All rooms are
22now aligned in 11x33 rectangles, because there is no longer a need to ever have
23rooms out of alignment.  Small rooms are placed very flexibly, using up as little
24as one dungeon block.  This makes for more natural-looking dungeons.  Large rooms
25are aligned towards the edges of the dungeon - again, this improves their appearance
26on the standard screen.  A handy side-effect of all this is that any room can be any
27size; Chris Weisiger can make his vaults as big as he wants.
29There have been various changes to room allocation chances; they are /not/ intended
30as a final draft.  If you choose to adopt this code, I will supply a reference table
31that duplicates the current Angband room generation probabilities (the actual
32probabilities, not the theoretical - the two differ greatly!).
34II. More powerful monster-selection code
36Monster nests have been combined with monster pits*.  A room of this type may have an almost
37infinite variety of monsters in it, from the familiar orc pits and jelly nests, to the unfamiliar
38sonic dragon pits, to the totally unheard-of Ogre pits, schools of sorcery, and fire elementals'
39playgrounds.  Creating new types of pits involves choosing selection criteria, which may take the
40form of restrictions on symbol, monster race, breaths, or color.  For example, one creates a pit
41of fire elementals by requiring 'v's and 'E's, than requiring the colors TERM_RED and TERM_L_RED.
42The monsters in a pit may be ordered or randomly placed; some monster-selection categories choose
43one kind, some the other.
45This code is not only used for pits.  Special varieties of ordinary rooms include
46checkerboard rooms with undead and rooms with collapsed ceilings harboring creatures
47of earth.  The only limits here are those of imagination.
49As with the room generation probabilities, the choices for monster selection in pits
50are just for show.  You can easily duplicate the traditional Angband pits, have the
51pleasure of designing your own, or encourage people to get creative.
53The combination of pits and nests means that there are seven kinds of rooms now, not
54eight.  This means that lesser vaults are type 6 and greater vaults are type 7.
57III. New tunneling code
59The tunnelling code has been greatly revised, and many of the annoying little problems
60that it has suffered from are now gone.  It now heads for vault entrances (see file
61"vault_entrance.gif", is less liable to turn the dungeon into Swiss Cheese, is
62guaranteed not to go in a straight line for longer than line of sight, does not
63place doors two grids beyond where it should as it leaves the initial room, has new
64checks to confirm that it's actually connected all the rooms, can cope with
65non-rectangular "natural-looking" and circular rooms (this is the most important
66advance from the standpoint of variants such as Zangband), and is better able to
67handle varied terrain.
69Note, however, that I still consider this code to be in beta; it has known areas of weakness.
72IV.  Other changes
73- The streamer code is much, much more efficient.  Streamers now vary in width and can twist and
74  turn as they travel through the level.
75- The structure "dun_data" is considerably smaller.
76- Characters now usually start off in hallway alcoves, which really cuts down on the insta-deaths.
77  The searching routine for stair placement is a great deal faster.
78- Ragged edges and pillars are never generated in rooms with dimensions divisible by two, for
79  neatness' sake.
80- Various efforts have been made to speed things up, increase robustness, and reduce the number
81  of internal failures; two examples are the depth-variant criteria used by auto-scum, and new
82  checks against the limits on monsters and objects.
87what didn't get included:
89- My name in the copyright listing at the top of the file.  If you choose to adopt all or part
90  of the code, and decide those portions adopted change the nature of dungeon generation
91  sufficiently to warrant that kind of recognition, fine.  If you don't, also fine.
93  The other stuff that didn't get included is more O-specific (e.g. themed levels),
94  or requires code in other files to function properly (specified types of monster
95  or objects in vaults).
97- chambered or starburst rooms
98- huge rooms
99- "interesting" rooms (minor vaults)
100- themed or "Moria" levels
101- varieties of ordinary rooms requiring special terrain
102- code related to bigscreen
103- the ability to place objects of a specific type (like amulets)
104- The ability to generate monsters quickly
105- The ability to place monsters of a specific race or of a defined category (like "magic-user")
106  in vaults
107- code to prevent monsters from being randomly generated in areas where monsters of
108  specific types were placed