Field of view

[leftiness]

TLDR

• If a player is standing at a: Point, and b: HashSet<Point> says which points block his vision, and he has a visible range of c: i32, which d: HashSet<Point> can he see?
• A guard seeks an intruder
• A wizard shoots a fireball

  Notes

While I would first and foremost need a function to find which points are visible, it may also be useful to have a function for determining which pixels are visible. As the resources show, what you choose to show and hide can make for a neat graphical effect.

Resources

• http://www.redblobgames.com/grids/hexagons/#field-of-view
• http://www.redblobgames.com/articles/visibility/
• http://ncase.me/sight-and-light/
• http://www.roguebasin.com/index.php?title=Pre-Computed_Visibility_Tries
• https://www.reddit.com/r/roguelikedev/comments/358mt5/faq_friday_12_field_of_vision/
• http://www.adammil.net/blog/v125_Roguelike_Vision_Algorithms.html
• http://www.roguebasin.com/index.php?title=Comparative_study_of_field_of_view_algorithms_for_2D_grid_based_worlds

[leftiness]

Pixel visibility is something which should be done aside from the hex_math library. I guess hex_render (or whatever I end up calling it) would handle that. It's one task to determine if a point is visible so that you know whether to show the player what's there. It's another task to draw shadows with pixels.

[leftiness]

If I use the precomputed visibility tries (or something similar) then I should ofc precompute. Provide a function which provides the visiblity chains, and then require those as an argument in the fov function. Still not sure which lines I need to send a ray through in order to ensure that a ray touches every point in range...

[leftiness]

Directional FOV is interesting. You wouldn't be able to see what's behind you, so you'd have to check. Checking would probably be free while it's your turn. Or almost free. I'd have to include something so you could hear bad guys behind you. There could be a visual cue to identify that a character heard a sound from some direction.

It would also drastically simplify these calculations...

[leftiness]

Some devs apparently like FOV algorithms that are more permissive. For example, they want to see around corners slightly, as if you were "peaking."

I don't think I want that. Go stand on the point next to the corner. Then select the "peak" option, and select the point which is just around the corner. Now your FOV is drawn from that point. You use a minor action point (or something) for that. It also gives overwatched enemies a (reduced, affected by your agility, etc) chance to shoot you.

[leftiness]

After all this research, I think I'll probably go with a shadow casting algorithm.

A big weakness of standard shadow casting is that it's asymmetric, so sometimes A can see B while B can't see A. At least, that's the case with square tiles. I should check to see how it works out on hex tiles.

The adammill.net resource has an altered algorithm that's symmetric at the cost of some extra comparisons and multiplications per loop. Probably still just fine since shadow casting is the more performant FOV algorithm in the first place. However, again, he's working with square tiles, so his algorithm might need tweaking.