Kruptein / PlanarAlly

A companion tool for when you travel into the planes.
https://www.planarally.io/
MIT License
400 stars 73 forks source link

feat(Vision): Exempt vision-blocking shapes from themselves #1338

Closed Kruptein closed 9 months ago

Kruptein commented 9 months ago

This PR is an attempt to tackle #1324.

Goal

With this implementation all vision blocking shapes that are closed will be visible themselves, but still block everything behind them.

This fixes a longstanding issue where you can't see the pillar/tree/whatever that is blocking the vision, instead your vision is just cutoff. As a DM you could try to give some glimpse by making the vision blocking shape slightly smaller, but this is an annoying balancing act.

What are closed shapes

It's important to focus on the closed aspect. What I mean with this is shapes that actually fill their content.

Most basic shapes fit this criterion (i.e. rectangles, circles, assets).

Some shapes do not fit this criterion (e.g. Text, Brush tool, and some shapes you can't manually draw (e.g. ruler lines etc), these shapes tend to not be interesting for vision blocking anyway.

That leaves us with the polygon tool. This has always had an explicit "closed polygon" toggle that dictates whether the content should be filled and also automatically closes the polygon if you didn't do so yourself. The polygon tool's behaviour thus will depend on its closed status.

Why only closed shapes

This is simply because I need the fill for how I ended up implementing it. Open shapes can be too wild and unpredicting to make a guess that it's better to leave them out entirely.

As said earlier, most open shapes are not interesting to begin with. Only the open polygon tool is one I use a lot myself to draw walls.

The result is that open polygons will still behave as they did before, they form a hard-block of vision and the nice thing is, this gives us an alternative for when we explicitly don't want the self-excluding behaviour.

What about the issues mentioned in #1324

I posed 2 problems in the linked issue I had a year ago when I last attempted to solve the same problem.

(1) Although excluding vision-blocking shapes from themselves is nice for small objects like pillars etc, it can potentially have drawbacks when used for more complext things. E.g. if all walls are drawn with rectangles that now can be looked into up to the other end of the wall, potential secret rooms can be spoiled by the notion that the wall suddenly becomes smaller

This still to a certain degree is an 'issue'. However:

(2) I had some version working in the past, but it had the downside that if a part of a vision-blocking shape was in vision, the entire shape would become visible even if your light aura didn't reach all the way.

This implementation no longer has this issue :D

Todo

Main todos are:

Example

Example player vision: image

FOW behind the scenes, notice the pillar is a full circle, the door is a full rectangle, but the walls are open polygons. image

Kruptein commented 9 months ago

The choice was made to make the behaviour configurable per shape. Vision blocking now essentially is either: "no blocking", "complete blocking" (old behaviour), "behind blocking" (new behaviour).

This just gives more power to the end-user and doesn't suddenly surprise a bunch of users that update and suddenly have all their light/vision behaving differently.

There are 2 locations in the entire codebase were a decision is currently made for the user: