Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display enemy FOV on the map #259

Open
Mikolaj opened this issue Jul 27, 2021 · 5 comments
Open

Display enemy FOV on the map #259

Mikolaj opened this issue Jul 27, 2021 · 5 comments

Comments

@Mikolaj
Copy link
Member

Mikolaj commented Jul 27, 2021

Probably whenever enemy actor is pointed at? This should make sneaking and ranged attacks against short-sighted/blinded/sleeping foes more fun.

Also, display own FOV more easily (currently only toggled via Setting menu option and visible in targeting mode only). Also, make the display better; it's quite intrusive right now despite using bright black for the highlight colour and it looks inconsistently in the web frontend.

@Mikolaj
Copy link
Member Author

Mikolaj commented Aug 11, 2021

Bright black background may be not a bad idea, but then I'd need to forbid using bright black as foreground, which limits the already modest choice of colours. However, it wasn't particularly visible on black, especially in case of small glyphs, anyway.

@Mikolaj
Copy link
Member Author

Mikolaj commented Aug 11, 2021

It would be great to also display FOV of an enemy faction whenever all our actors are outside the FOV (either really or as far as our faciton can determine). This doesn't happen too often and is a tense moment, so the extra visual noise is a good thing, even regardless of usefulness of the information. However, this is tricky from architectural perspective, because FOV is right now available only on the server, particularly enemy faction FOV. Also FOVs are large beasts and their updates even more so (edit: and intersections of enemy and our FOVs, which is what would end up being stored on the client, most probably).

@Mikolaj
Copy link
Member Author

Mikolaj commented Aug 11, 2021

The BrBlack colour is too bright to be a background, but it can't be much darker, because it needs to be readable in greyed-out menu entries, etc. In fact it's so bright, that even tiny single dot items or terrain in this colour is visible on the map, albeit not very comfortably. Still, it should not be forbidden, though some games may choose not to use it for map nor terrain.

So we need plan B. Perhaps a cheat, where BrBlack as background is much darker than BrBlack as foreground or highlight? We are already cheating past the 16 colours limit by having two shades of white to make adjacent rows of text distinct and so minimize the risk of the eye jumping. Visually, the brightness should be similar due to the difference is area, especially when comparing background with small glyphs.

Edit: yes, plan B works fine, the bonus being that even BrBlack items or terrain or highlight on the grey background is (barely) visible, so no immediate need to change them.

@Mikolaj
Copy link
Member Author

Mikolaj commented Aug 11, 2021

However, the player may have limited knowledge of enemy FOV not only due to limited own FOV, but also due to not knowing identify of sight radius affecting (and other, e.g., noctovision) items. Also, not knowing terrain obstacles precludes accurate assessment of enemy FOV. So server sending intersection of FOVs is not enough to represent the asymmetric knowledge. Even worse if we restrict factions from knowing equipment of visible enemies (currently not restricted in any way, but not displayed in UI, so undecided).

A more accurate solution, where client (conservatively) reconstructs FOV of another faction using own limited knowledge of items and of terrain has the extra advantage that the huger FOV data structures don't have to be sent from server to client. However, it's not clear what 'conservative' means. What if an unknown item makes an enemy blind? Should we assume each enemy with equipped unknown item (or even unknown temporary condition) is blind? Should we assume each unknown terrain is translucent to be on the safe side? What if games, such as LamdaHack, have dark walls and so they are unknown from afar and so any heuristic misses the mark most of the time?

It seems, intersection of FOVs should be public knowledge after all, as unrealistic as it is. Even though that lets players deduce properties of unknown items and translucency of unknown terrain with some accuracy. I guess AI should never take advantage of that, even if there were no more pressing features to add. Anyway, gameplay (stealth fun, in this case) trumps realism every time, It's just they were rarely at odds so far.

@Mikolaj
Copy link
Member Author

Mikolaj commented Aug 11, 2021

Not sure how exploitable it is, but I think enemy FOV may even serve to deduce location of enemies that are not seen. To fix that, we'd need to store FOV of each individual actor and only reveal FOV of seen actors. But storing such FOVs is very costly and FOV is already a bottleneck (to be precise we store per-actor raw FOV, but not FOV adjusted by dynamic and static lighting; that adjustment is done on total FOV, not per-actor). I'm not quite sure how fun the mini-game of deducing hidden actors would be. I hope it'd be fun or rare enough,

However, it's much worse if it actually reduces stealth play suspense. E.g., if potential enemy of the other side of the wall is not a threat, because I would see that enemy's FOV (due to seeing one of his teammates elsewhere). Even worse, to hide from me, the enemy would be better off wearing blindness-inducing items!

So perhaps per-actor light-adjusted FOV is a must, but that's a big performance cost.

Edit: However, displaying enemy FOV from seen actors helps with realism, as well --- if I see an actor, I'm able notice to which debris movements on distant tile it reacts, etc., so I can get a feel what its FOV is. FOV from unseen actors is complete magic OTOH. There is one more option: UI can display only FOV of the pointed-at actor, not all all seen actors from this faction. This means more clicks to decide if a tile is safe to traverse, but more deductive power about how FOV is going to change when a particular actor moves next turn in the same direction as before. At this point, I think I prefer qualify of life and so cumulative FOV. An option that toggles this is possible, too, or a different behaviour in aiming mode and outside.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant