[Feature]: Overlappable chunks of topology

[kwvanderlinde]

Feature Request

At the moment, map topology is "flat", i.e., any point on a map either has a given type of topology or it doesn't. This is fine for Wall VBL and MBL which strictly block vision and pathfinding respectively, but it limits the effects that can be achieved for Hill VBL and Pit VBL.

The Solution you'd like

Make topology more like drawings in that there can be independent pieces of topology on the map. These would be able to be layered on top of one another without being merged into a single area.

Alternatives that you've considered.

Token topology could be modified to behave in this way. Any given token's topology is already separate from map topology and any other token topologies in the sense that it can be moved and manipulated and technically layered on top of each other. At the moment token topology is always merged with map topology on-the-fly when running the vision and pathfinding algorithms, but it seems natural to consider making them truly layered.

Another alternative is to Introduce a different/new system for line-of-sight and pathfinding. This system could focuses on higher-level concepts of like walls, doors, windows, etc. If such a system were based on drawing line segments rather than covering areas, it wouldn't have to worry about explicitly allowing layering as that could happen naturally.

Additional Context

A use case for layered topology is a multi-level tower, as seen from the exterior. This could be represented by a few circles of Hill VBL layered on top of one another.

Similarly, a layered pit could be achieved by layering some nested circles of Pit VBL on top of one another.

[kwvanderlinde]

The more time goes on, the more I believe an implementation based on thin, editable, and configurable walls would be far better than the area-based approach suggested in this FR. Wall VBL might still be useful as a mask, but everything else would be more intuitive if it was wall-based. And these walls would also be easier to hook into for other concepts that have floated around, like doors, windows, elevation, etc.

[cwisniew]

The more time goes on, the more I believe an implementation based on thin, editable, and configurable walls would be far better than the area-based approach suggested in this FR. Wall VBL might still be useful as a mask, but everything else would be more intuitive if it was wall-based. And these walls would also be easier to hook into for other concepts that have floated around, like doors, windows, elevation, etc.

You won't get any arguments from me on this point.
Drawing and editing VBL would be a markedly better experience. It would be closer to how a vector drawing program works than a paint program. The ability to edit, move, and assign attributes to a line segment or connected line segments would open up so much more flexibility, both in editing and how vision and light can interact with it.

I wonder if the current libraries we already use, support turning an image into a series of vectors for edges as a stopgap for conversion. However, it's bound to be a non-perfect conversion in some cases.

[kwvanderlinde]

I wonder if the current libraries we already use, support turning an image into a series of vectors for edges as a stopgap for conversion. However, it's bound to be a non-perfect conversion in some cases.

I'm probably missing the point you were trying to make, but I expect any conversion to be easy (or maybe I should say "straghtforward"). We already have access to all the edge information that would be required to convert existing topology.

---

I've been hacking away on a POC for this which is showing some promise. But it's also highlighted a number of technical challenges:

1. Backwards compatibility. We already noted that Wall VBL can't be replaced with thin walls do to its masking behaviour, but Hill VBL is also difficult to express. The others are fairly straightforward.
2. Performance. Today we can cull lots of geometry based solely on the structure of the topology. E.g., if standing outside of any Cover VBL, we don't have to consider any of the holes during the vision sweep. Or if standing inside a hole within Cover VBL, we don't have to consider any Cover VBL that lies outside. If we switch to a system with a bunch of unrelated walls, this adds a lot of geometry to the sweep with a noticeable performance impact.
3. Performance again. Today we implement our different VBL effects based on the structure of the VBL so that only important segments are processed during the vision sweep. If we don't have this structure, then the sweep itself would become responsible for checking wall conditions and disregarding them in the moment.
4. Performance or correctness (you choose). The vision sweep doesn't work when segments intersect except at endpoints. If topology can overlap, we will get these bad intersections and the results won't be predictable. This is fixable by noding the geometry, but this has a significant cost if vision is calculated at each step during pathfinding.

I don't think any of this is a deal breaker for walls themselves, but it does show they are lacking on their own. So what I'm thinking to solve (1) - (3) is that we support both polygons and walls:

• Polygons:
  • can have holes punched in them;
  • can have topology types associated with them;
  • would be editable and movable;
  • can have automatic conversion from today's topology.
• Walls:
  • just a line segments
  • would be editable and movable;
  • not a target for conversion
  • basic behaviour only: yes/no for blocking vision, yes/no for blocking movement.

Should also have a way to merge or group pieces together so they can be easily copied, moved, etc.

In the future, we can add fancy stuff to walls, like directionality, etc. We can even make them the preferred tool due to their ease-of-use despite their shortcomings. But for the cases where structure matters more, then polygons would be the thing to reach for.

For point (4), this should be solvable with some creative caching. As long the token being dragged doesn't itself have topology... We also might be able to find a more advanced algorithm that deals with intersections, but last time I looked I didn't find anything practical for us.

[kwvanderlinde]

To avoid creep, I'll use this issue (#3485) to just track the addition of basic walls as line segments. These will always block vision and movement, and would offer a "good enough" alternative to Wall VBL and MBL despite not being 100% able to replicate the masking behaviour.

Existing Area-based topology will have to stick around because there's a lot of tooling around that relies on its existing behaviour. I'll create follow-up feature requests to provide as many wall-based equivalents for existing topology uses, and even provide a tool that can convert existing masks to walls upon request.