|
| bool | test_hit_fire (int chance, monster_type *m_ptr, int vis, char *o_name) |
| | プレイヤーからモンスターへの射撃命中判定 / Determine if the player "hits" a monster (normal combat). [詳細]
|
| |
| bool | test_hit_norm (int chance, int ac, int vis) |
| | プレイヤーからモンスターへの打撃命中判定 / Determine if the player "hits" a monster (normal combat). [詳細]
|
| |
| s16b | critical_shot (int weight, int plus_ammo, int plus_bow, int dam) |
| | プレイヤーからモンスターへの射撃クリティカル判定 / Critical hits (from objects thrown by player) Factor in item weight, total plusses, and player level. [詳細]
|
| |
| s16b | critical_norm (int weight, int plus, int dam, s16b meichuu, int mode) |
| | プレイヤーからモンスターへの打撃クリティカル判定 / Critical hits (by player) Factor in weapon weight, total plusses, player melee bonus [詳細]
|
| |
| static int | mult_slaying (int mult, const u32b *flgs, const monster_type *m_ptr) |
| | プレイヤー攻撃の種族スレイング倍率計算 [詳細]
|
| |
| static int | mult_brand (int mult, const u32b *flgs, const monster_type *m_ptr) |
| | プレイヤー攻撃の属性スレイング倍率計算 [詳細]
|
| |
| s16b | tot_dam_aux (object_type *o_ptr, int tdam, monster_type *m_ptr, int mode, bool thrown) |
| | ダメージにスレイ要素を加える総合処理ルーチン / Extract the "total damage" from a given object hitting a given monster. [詳細]
|
| |
| static void | discover_hidden_things (int y, int x) |
| | 地形やその上のアイテムの隠された要素を明かす / Search for hidden things [詳細]
|
| |
| void | search (void) |
| | プレイヤーの探索処理判定 [詳細]
|
| |
| void | py_pickup_aux (int o_idx) |
| | プレイヤーがオブジェクトを拾った際のメッセージ表示処理 / Helper routine for py_pickup() and py_pickup_floor(). [詳細]
|
| |
| void | carry (bool pickup) |
| | プレイヤーがオブジェクト上に乗った際の表示処理 [詳細]
|
| |
| static int | check_hit (int power) |
| | プレイヤーへのトラップ命中判定 / Determine if a trap affects the player. [詳細]
|
| |
| static void | hit_trap_pit (int trap_feat_type) |
| | 落とし穴系トラップの判定とプレイヤーの被害処理 [詳細]
|
| |
| static bool | hit_trap_dart (void) |
| | ダーツ系トラップ（通常ダメージ）の判定とプレイヤーの被害処理 [詳細]
|
| |
| static void | hit_trap_lose_stat (int stat) |
| | ダーツ系トラップ（通常ダメージ＋能力値減少）の判定とプレイヤーの被害処理 [詳細]
|
| |
| static void | hit_trap_slow (void) |
| | ダーツ系トラップ（通常ダメージ＋減速）の判定とプレイヤーの被害処理 [詳細]
|
| |
| static void | hit_trap_set_abnormal_status (cptr trap_message, bool resist, bool(*set_status)(int turn), int turn) |
| | ダーツ系トラップ（通常ダメージ＋状態異常）の判定とプレイヤーの被害処理 [詳細]
|
| |
| static void | hit_trap (bool break_trap) |
| | プレイヤーへのトラップ作動処理メインルーチン / Handle player hitting a real trap [詳細]
|
| |
| static void | touch_zap_player_aux (monster_type *m_ptr, bool immune, int flags_offset, int r_flags_offset, u32b aura_flag, int(*dam_func)(int dam, cptr kb_str, int monspell, bool aura), cptr message) |
| | 敵オーラによるプレイヤーのダメージ処理（補助） [詳細]
|
| |
| static void | touch_zap_player (monster_type *m_ptr) |
| | 敵オーラによるプレイヤーのダメージ処理（メイン） [詳細]
|
| |
| static void | natural_attack (s16b m_idx, int attack, bool *fear, bool *mdeath) |
| | プレイヤーの変異要素による打撃処理 [詳細]
|
| |
| static void | py_attack_aux (int y, int x, bool *fear, bool *mdeath, s16b hand, int mode) |
| | プレイヤーの打撃処理サブルーチン / Player attacks a (poor, defenseless) creature -RAK- [詳細]
|
| |
| bool | py_attack (int y, int x, int mode) |
| | プレイヤーの打撃処理メインルーチン [詳細]
|
| |
| bool | pattern_seq (int c_y, int c_x, int n_y, int n_x) |
| | パターンによる移動制限処理 [詳細]
|
| |
| bool | player_can_enter (s16b feature, u16b mode) |
| | プレイヤーが地形踏破可能かを返す [詳細]
|
| |
| bool | move_player_effect (int ny, int nx, u32b mpe_mode) |
| | 移動に伴うプレイヤーのステータス変化処理 [詳細]
|
| |
| bool | trap_can_be_ignored (int feat) |
| | 該当地形のトラップがプレイヤーにとって無効かどうかを判定して返す [詳細]
|
| |
| void | move_player (int dir, bool do_pickup, bool break_trap) |
| | 該当地形のトラップがプレイヤーにとって無効かどうかを判定して返す / Move player in the given direction, with the given "pickup" flag. [詳細]
|
| |
| static int | see_wall (int dir, int y, int x) |
| | ダッシュ移動処理中、移動先のマスが既知の壁かどうかを判定する / Hack – Check for a "known wall" (see below) [詳細]
|
| |
| static int | see_nothing (int dir, int y, int x) |
| | ダッシュ移動処理中、移動先のマスか未知の地形かどうかを判定する / Hack – Check for an "unknown corner" (see below) [詳細]
|
| |
| static void | run_init (int dir) |
| | ダッシュ処理の導入 / Initialize the running algorithm for a new direction. [詳細]
|
| |
| static bool | run_test (void) |
| | ダッシュ移動が継続できるかどうかの判定 / Update the current "run" path [詳細]
|
| |
| void | run_step (int dir) |
| | 継続的なダッシュ処理 / Take one step along the current "run" path [詳細]
|
| |
プレイヤーのコマンド処理1 / Movement commands (part 1)
- 日付
- 2014/01/02
- 作者
- 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.
- 覚え書き
The running algorithm: -CJS-
In the diagrams below, the player has just arrived in the grid marked as '@', and he has just come from a grid marked as 'o', and he is about to enter the grid marked as 'x'.
Of course, if the "requested" move was impossible, then you
will of course be blocked, and will stop.
Overview: You keep moving until something interesting happens.
If you are in an enclosed space, you follow corners. This is
the usual corridor scheme. If you are in an open space, you go
straight, but stop before entering enclosed space. This is
analogous to reaching doorways. If you have enclosed space on
one side only (that is, running along side a wall) stop if
your wall opens out, or your open space closes in. Either case
corresponds to a doorway.
What happens depends on what you can really SEE. (i.e. if you
have no light, then running along a dark corridor is JUST like
running in a dark room.) The algorithm works equally well in
corridors, rooms, mine tailings, earthquake rubble, etc, etc.
These conditions are kept in static memory:
find_openarea You are in the open on at least one
side.
find_breakleft You have a wall on the left, and will
stop if it opens
find_breakright You have a wall on the right, and will
stop if it opens
To initialize these conditions, we examine the grids adjacent
to the grid marked 'x', two on each side (marked 'L' and 'R').
If either one of the two grids on a given side is seen to be
closed, then that side is considered to be closed. If both
sides are closed, then it is an enclosed (corridor) run.
LL L
@x LxR
RR @R
Looking at more than just the immediate squares is
significant. Consider the following case. A run along the
corridor will stop just before entering the center point,
because a choice is clearly established. Running in any of
three available directions will be defined as a corridor run.
Note that a minor hack is inserted to make the angled corridor
entry (with one side blocked near and the other side blocked
further away from the runner) work correctly. The runner moves
diagonally, but then saves the previous direction as being
straight into the gap. Otherwise, the tail end of the other
entry would be perceived as an alternative on the next move.
#.#
##.##
.@x..
##.##
#.#
Likewise, a run along a wall, and then into a doorway (two
runs) will work correctly. A single run rightwards from @ will
stop at 1. Another run right and down will enter the corridor
and make the corner, stopping at the 2.
##################
o@x 1
########### ######
#2 #
#############
After any move, the function area_affect is called to
determine the new surroundings, and the direction of
subsequent moves. It examines the current player location
(at which the runner has just arrived) and the previous
direction (from which the runner is considered to have come).
Moving one square in some direction places you adjacent to
three or five new squares (for straight and diagonal moves
respectively) to which you were not previously adjacent,
marked as '!' in the diagrams below.
...! ...
.o@! (normal) .o.! (diagonal)
...! (east) ..@! (south east)
!!!You STOP if any of the new squares are interesting in any way:
for example, if they contain visible monsters or treasure.
You STOP if any of the newly adjacent squares seem to be open,
and you are also looking for a break on that side. (that is,
find_openarea AND find_break).
You STOP if any of the newly adjacent squares do NOT seem to be
open and you are in an open area, and that side was previously
entirely open.
Corners: If you are not in the open (i.e. you are in a corridor)
and there is only one way to go in the new squares, then turn in
that direction. If there are more than two new ways to go, STOP.
If there are two ways to go, and those ways are separated by a
square which does not seem to be open, then STOP.
Otherwise, we have a potential corner. There are two new open
squares, which are also adjacent. One of the new squares is
diagonally located, the other is straight on (as in the diagram).
We consider two more squares further out (marked below as ?).
We assign "option" to the straight-on grid, and "option2" to the
diagonal grid, and "check_dir" to the grid marked 's'.
##s
@x?
#.?
If they are both seen to be closed, then it is seen that no benefit
is gained from moving straight. It is a known corner. To cut the
corner, go diagonally, otherwise go straight, but pretend you
stepped diagonally into that next location for a full view next
time. Conversely, if one of the ? squares is not seen to be closed,
then there is a potential choice. We check to see whether it is a
potential corner or an intersection/room entrance. If the square
two spaces straight ahead, and the space marked with 's' are both
unknown space, then it is a potential corner and enter if
find_examine is set, otherwise must stop because it is not a
corner. (find_examine option is removed and always is TRUE.)
1.8.5