|
| static int | next_to_walls (int y, int x) |
| | 上下左右の外壁数をカウントする / Count the number of walls adjacent to the given grid. [詳細]
|
| |
| static bool | alloc_stairs_aux (int y, int x, int walls) |
| | alloc_stairs()の補助として指定の位置に階段を生成できるかの判定を行う / Helper function for alloc_stairs(). [詳細]
|
| |
| static bool | alloc_stairs (int feat, int num, int walls) |
| | 外壁に隣接させて階段を生成する / Places some staircases near walls [詳細]
|
| |
| static void | alloc_object (int set, int typ, int num) |
| | フロア上のランダム位置に各種オブジェクトを配置する / Allocates some objects (using "place" and "type") [詳細]
|
| |
| static int | next_to_corr (int y1, int x1) |
| | 隣接4マスに存在する通路の数を返す / Count the number of "corridor" grids adjacent to the given grid. [詳細]
|
| |
| static bool | possible_doorway (int y, int x) |
| | ドアを設置可能な地形かを返す / Determine if the given location is "between" two walls, and "next to" two corridor spaces. [詳細]
|
| |
| static void | try_door (int y, int x) |
| | ドアの設置を試みる / Places door at y, x position if at least 2 walls found [詳細]
|
| |
| bool | place_quest_monsters (void) |
| | クエストに関わるモンスターの配置を行う / Place quest monsters [詳細]
|
| |
| static void | set_bound_perm_wall (cave_type *c_ptr) |
| | マスにフロア端用の永久壁を配置する / Set boundary mimic and add "solid" perma-wall [詳細]
|
| |
| static void | gen_caverns_and_lakes (void) |
| | フロアに洞窟や湖を配置する / Generate various caverns and lakes [詳細]
|
| |
| static bool | cave_gen (void) |
| | ダンジョン生成のメインルーチン / Generate a new dungeon level [詳細]
|
| |
| static void | build_arena (void) |
| | 闘技場用のアリーナ地形を作成する / Builds the arena after it is entered -KMW- [詳細]
|
| |
| static void | arena_gen (void) |
| | 闘技場への入場処理 / Town logic flow for generation of arena -KMW- [詳細]
|
| |
| static void | build_battle (void) |
| | モンスター闘技場のフロア生成 / Builds the arena after it is entered -KMW- [詳細]
|
| |
| static void | battle_gen (void) |
| | モンスター闘技場への導入処理 / Town logic flow for generation of arena -KMW- [詳細]
|
| |
| static void | quest_gen (void) |
| | 固定マップクエストのフロア生成 / Generate a quest level [詳細]
|
| |
| static bool | level_gen (cptr *why) |
| | ダンジョン時のランダムフロア生成 / Make a real level [詳細]
|
| |
| void | wipe_generate_cave_flags (void) |
| | フロアに存在する全マスの記憶状態を初期化する / Wipe all unnecessary flags after cave generation [詳細]
|
| |
| void | clear_cave (void) |
| | フロアの全情報を初期化する / Clear and empty the cave [詳細]
|
| |
| void | generate_cave (void) |
| | ダンジョンのランダムフロアを生成する / Generates a random dungeon level -RAK- [詳細]
|
| |
ダンジョンの生成 / Dungeon generation
- 日付
- 2014/01/04
- 作者
- Copyright (c) 1997 Ben Harrison, James E. Wilson, Robert A. Koeneke
This software may be copied and distributed for educational, research,
and not for profit purposes provided that this copyright and statement
are included in all such copies. Other copyrights may also apply.
2014 Deskull rearranged comment for Doxygen.
Note that Level generation is not an important bottleneck,
though it can be annoyingly slow on older machines... Thus
we emphasize "simplicity" and "correctness" over "speed".
This entire file is only needed for generating levels.
This may allow smart compilers to only load it when needed.
Consider the "v_info.txt" file for vault generation.
In this file, we use the "special" granite and perma-wall sub-types,
where "basic" is normal, "inner" is inside a room, "outer" is the
outer wall of a room, and "solid" is the outer wall of the dungeon
or any walls that may not be pierced by corridors. Thus the only
wall type that may be pierced by a corridor is the "outer granite"
type. The "basic granite" type yields the "actual" corridors.
Note that we use the special "solid" granite wall type to prevent
multiple corridors from piercing a wall in two adjacent locations,
which would be messy, and we use the special "outer" granite wall
to indicate which walls "surround" rooms, and may thus be "pierced"
by corridors entering or leaving the room.
Note that a tunnel which attempts to leave a room near the "edge"
of the dungeon in a direction toward that edge will cause "silly"
wall piercings, but will have no permanently incorrect effects,
as long as the tunnel can eventually exit from another side.
And note that the wall may not come back into the room by the
hole it left through, so it must bend to the left or right and
then optionally re-enter the room (at least 2 grids away). This
is not a problem since every room that is large enough to block
the passage of tunnels is also large enough to allow the tunnel
to pierce the room itself several times.
Note that no two corridors may enter a room through adjacent grids,
they must either share an entryway or else use entryways at least
two grids apart. This prevents "large" (or "silly") doorways.
To create rooms in the dungeon, we first divide the dungeon up
into "blocks" of 11x11 grids each, and require that all rooms
occupy a rectangular group of blocks. As long as each room type
reserves a sufficient number of blocks, the room building routines
will not need to check bounds. Note that most of the normal rooms
actually only use 23x11 grids, and so reserve 33x11 grids.
Note that the use of 11x11 blocks (instead of the old 33x11 blocks)
allows more variability in the horizontal placement of rooms, and
at the same time has the disadvantage that some rooms (two thirds
of the normal rooms) may be "split" by panel boundaries. This can
induce a situation where a player is in a room and part of the room
is off the screen. It may be annoying enough to go back to 33x11
blocks to prevent this visual situation.
Note that the dungeon generation routines are much different (2.7.5)
and perhaps "DUN_ROOMS" should be less than 50.
XXX XXX XXX Note that it is possible to create a room which is only
connected to itself, because the "tunnel generation" code allows a
tunnel to leave a room, wander around, and then re-enter the room.
XXX XXX XXX Note that it is possible to create a set of rooms which
are only connected to other rooms in that set, since there is nothing
explicit in the code to prevent this from happening. But this is less
likely than the "isolated room" problem, because each room attempts to
connect to another room, in a giant cycle, thus requiring at least two
bizarre occurances to create an isolated section of the dungeon.
Note that (2.7.9) monster pits have been split into monster "nests"
and monster "pits". The "nests" have a collection of monsters of a
given type strewn randomly around the room (jelly, animal, or undead),
while the "pits" have a collection of monsters of a given type placed
around the room in an organized manner (orc, troll, giant, dragon, or
demon). Note that both "nests" and "pits" are now "level dependant",
and both make 16 "expensive" calls to the "get_mon_num()" function.
Note that the cave grid flags changed in a rather drastic manner
for Angband 2.8.0 (and 2.7.9+), in particular, dungeon terrain
features, such as doors and stairs and traps and rubble and walls,
are all handled as a set of 64 possible "terrain features", and
not as "fake" objects (440-479) as in pre-2.8.0 versions.
The 64 new "dungeon features" will also be used for "visual display"
but we must be careful not to allow, for example, the user to display
hidden traps in a different way from floors, or secret doors in a way
different from granite walls, or even permanent granite in a different
way from granite. XXX XXX XXX
1.8.5