Difference between revisions of "Permissive Field of View"
m (added libtcod) |
m (added new implementation link) |
||
(6 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
Permissive field of view defines visibility more loosely than other [[Field of Vision]] methods. A destination square is visible from a source square if there is any unobstructed line from some point in the source square to some point in the destination square. This means that players and monsters will automatically 'peek' around corners, for example. It also means that field of view is symmetric. That is to say that if a destination square is visible from a source square, then that source square is also visible from the destination square. Some approximation algorithms might lose the property of guaranteed symmetry. | Permissive field of view defines visibility more loosely than other [[Field of Vision]] methods. A destination square is visible from a source square if there is any unobstructed line from some point in the source square to some point in the destination square. This means that players and monsters will automatically 'peek' around corners, for example. It also means that field of view is symmetric. That is to say that if a destination square is visible from a source square, then that source square is also visible from the destination square. Some approximation algorithms might lose the property of guaranteed symmetry. | ||
Line 18: | Line 16: | ||
* The player cannot sneak up on monsters more easily. | * The player cannot sneak up on monsters more easily. | ||
* May ruin play balance of current games. | * May ruin play balance of current games. | ||
* It is more difficult for the player to withdraw from ranged combat. | * It is more difficult for the player to withdraw from ranged combat (but easier to stay out of range, see [[Discussion:Field_of_Vision#Extra_visibility_properties | Retreating is safe]]). | ||
== | ==Algorithms== | ||
There are a number of articles describing different methods: | There are a number of articles describing different methods: | ||
Line 28: | Line 26: | ||
* [[Precise Permissive Field of View]] -- A fast and, in theory, artifact free variation. | * [[Precise Permissive Field of View]] -- A fast and, in theory, artifact free variation. | ||
== | ==Games using Permissive Field of View== | ||
* [[Dungeon Crawl Stone Soup]] | * [[Dungeon Crawl Stone Soup]] | ||
* [[Cataclysm]] | |||
== | ==Implementations== | ||
{| class="wikitable" cellpadding="10" cellspacing="0" border="1" | {| class="wikitable" cellpadding="10" cellspacing="0" border="1" | ||
Line 42: | Line 41: | ||
| [[Permissive Field of View in Python]] | | [[Permissive Field of View in Python]] | ||
| Python | | Python | ||
|rowspan= | |rowspan=8| [[Precise Permissive Field of View]] | ||
|- | |- | ||
| [[permissive-fov]] | | [[permissive-fov]] | ||
Line 55: | Line 54: | ||
| [[libtcod]] | | [[libtcod]] | ||
| C/C++/python | | C/C++/python | ||
|- | |||
| [[Permissive Field of View in Javascript]] | |||
| rowspan=2 | Javascript | |||
|- | |||
| [https://www.npmjs.com/package/permissive-fov permissive-fov] | |||
|- | |||
| [https://github.com/LambdaHack/LambdaHack/wiki/Fov-and-los Recursive shadow casting PFOV (and DFOV)] | |||
| Haskell | |||
|} | |} | ||
[[category:FOV]] | [[category:FOV]] |
Latest revision as of 20:43, 25 February 2017
Permissive field of view defines visibility more loosely than other Field of Vision methods. A destination square is visible from a source square if there is any unobstructed line from some point in the source square to some point in the destination square. This means that players and monsters will automatically 'peek' around corners, for example. It also means that field of view is symmetric. That is to say that if a destination square is visible from a source square, then that source square is also visible from the destination square. Some approximation algorithms might lose the property of guaranteed symmetry.
One tricky corner case are literally the corners. There are two questions that must be answered. Are corners of squares valid points in the source and destination squares for determining visibility? And do corners of walls obstruct line of sight? Different algorithms may answer these questions in different ways.
Advantages
- Symmetry of field of view may make ranged combat more sensible.
- Monsters cannot sneak up on the player as easily.
- Reduced player exploitation of line of sight artifacts.
- There is an existing library implementing it.
- May make certain aspects of the game easier (realistic lighting).
Disadvantages
- The most complicated method to understand and implement (and therefore debug).
- The player cannot sneak up on monsters more easily.
- May ruin play balance of current games.
- It is more difficult for the player to withdraw from ranged combat (but easier to stay out of range, see Retreating is safe).
Algorithms
There are a number of articles describing different methods:
- Isaac_s_fast_beamcasting_LOS -- An approximate algorithm using 'wide beams' sent out at fixed slopes. The larger the radius, the more beams must be sent out to avoid artifacts.
- Mutual_Visibility_Field_Of_View -- Uses the corners of squares to determine visibility. In some cases, it does not precisely capture Permissive Field of View. However, the algorithm guarantees symmetry in the field of view.
- A fast algorithm using pre-cached dependencies is described in the source code for Dungeon Crawl Stone Soup
- Precise Permissive Field of View -- A fast and, in theory, artifact free variation.
Games using Permissive Field of View
Implementations
Library | Language(s) | Algorithm(s) |
---|---|---|
Permissive Field of View in Python | Python | Precise Permissive Field of View |
permissive-fov | C/C++ | |
Roguelike Library For Java | Java | |
Ruby implementation | Ruby | |
libtcod | C/C++/python | |
Permissive Field of View in Javascript | Javascript | |
permissive-fov | ||
Recursive shadow casting PFOV (and DFOV) | Haskell |