RPTools / maptool

Virtual Tabletop for playing roleplaying games with remote players or face to face.
http://rptools.net
GNU Affero General Public License v3.0
782 stars 259 forks source link

[Feature]: Overlappable chunks of topology #3485

Open kwvanderlinde opened 2 years ago

kwvanderlinde commented 2 years ago

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 commented 8 months ago

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 commented 2 months ago

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.