Movement blocking gives confusing user experience

[Azhrei]

Describe the bug When a token is dragged into a cell containing MBL, the token path is removed and the distance is displayed as "0". The user is left wondering why the path disappeared since there's no visual indication of MBL being involved.

To Reproduce The screen shot below shows a map configuration. There is MBL on the left and some VBL elsewhere.

Here's what it looks like when a token on the right is dragged into a cell that is covered by MBL. Notice that there is no token path and the distance is "0".

And here's the reverse, the token being dragged out of MBL. Again, the path is gone and distance is "0".

Expected behavior I would like the path to continue to appear, but cells that involve MBL should be highlighted differently. Here's how the path is currently displayed (the first two steps are water tokens that have their terrain modifier set to MULTIPLY x2):

I propose that:

1. Movement through MBL cells use the MBL color for the path instead of the light gray that is normally used.

2. Cells that cross MBL and any further cells the token might try to move into should display a distance as if the MBL weren't there, but with the MBL color used to highlight the text (as background color, or in some other prominent way).

   This allows the GM to mark lava flows or chasms as "impassable", but tokens that are flying or otherwise unhindered could still see how much of their movement they've used up.

3. If a given cell has both MBL and MBT (movement blocking tokens), the distance calculation should use the terrain modifier on the MBT.

4. Moving over MBTs should be displayed similarly, but instead of changing the shading of the entire cell, the MBL color could be used to draw a highlight around the outside of the cell, leaving the fill as light gray.

   That gives the user some feedback that movement blocking is involved.

   Optionally, the terrain modifier could be shown as x2 or x½ in the bottom right corner of the cell.

MapTool Info

• Version: 1.6.1

Desktop (please complete the following information):

• OS: macOS
• Version 10.15.6

Additional context You need more? Seriously?

[JamzTheMan]

Can you show me what "Path" you would like me to display for this MBL configuration where the Creature on the left is moving to the target spot on the right?

Also, I need a set of rules/algorithm to determine that path. Am I removing chunks of "MBL" until A pathfinding can find a valid path? If there is no path am I just turning A off and showing a direct a->b path? And if so why show the path at all then (as it would move directly through 3 blocks/lines of MBL when it could have moved around them)

Throw in a few more permutations, variable cell costs via terrain tokens, and I think you will be increasing the calculation times greatly (it already only has 500ms to find a path before it 'gives up' otherwise it would calculate to infinity since we have boundless maps)

For #2 I would grant tokens that can "fly" the "Ignore terrain multiplier" and they would then ignore the x2 cost.

MBT that are marked as "block" would also suffer the same issue, like if you had 6x6 MBT tokens and you move into the middle, am I walking a token up to the edge? which edge? How do I get there? The A* has no cost to figure this out unless I give it a cost of say 1000 vs infinite but it's still going to "walk" around the map until it reaches 5000ft because up to that it still may still find a 'cheaper' path.

I think the best we can offer is a visual cue that the cell is not a valid cell. For non-gm's maybe we just don't allow it, replace the "grey token image" with a "red x" and if the mouse button is released, revert the move.

For GM, maybe just put a red X over the grey image but let the GM drop the token with knowledge that no "valid" path could be found.

[cwisniew]

@JamzTheMan since the 0 movement is a result of an unreachable location, I think it's best if it just displayed "unreachable" (i18n of course). With a possible improvement of a server setting that stopped non GMs from moving tokens to in reachable areas.

As you mentioned in your comment the other suggestions presented ignore the realities of how path finding works.

[Phergus]

Yup. Indicate in a more obvious fashion that the location is unreachable and a setting to revert the move if not valid (before any FoW reveal obviously).

[Azhrei]

I appreciate that the A* algorithm has the MBL areas set to such a high terrain factor that they can't penetrate it. But I'm not concerned about that. I'm concerned about what the user sees. So stop thinking about what the algorithm can or cannot do and think about how the results should be presented to the user.

Here's what the user sees as they're dragging their token across the screen...

And then it suddenly changes to this:

(Actually, the distance displayed stays at "10" for some time before changing to "0".)

So, I'll say it again: this is a terrible UX. Craig admitted as much by saying that the "0" should become "unreachable". (And I'd like to see color used. For the distance text or for the entire path.) But he still missed the jarring disconnect between what the user sees for one cell and what they see for the next one.

Adding the word "unreachable" is a fine stop-gap, but that's still suboptimal. From the user's standpoint, they see that MT has drawn a path and suddenly the entire path disappears. (Keep in mind that the user doesn't give a flip about what algorithm is being used.)

The user who pointed this out to me suggested what I put in the OP: leave the path to the last known point on the screen and highlight anything beyond that.

Could the A* approach be modified to account for this desired UX? Perhaps. For example, what happens if the user tries to drag the token onto a cell covered by MBL? Obviously, there can't be a route to that cell. So what can we do? What happens if we treat the cell that the token is currently on top of as though it had no MBL? Then the algorithm could route to that cell. That means the path could be displayed (as in the first image in this post) but with the following cell displaying "unreachable". That takes care of the situation where the user has positioned the token on top of a cell covered by MBL that is adjacent to a reachable cell.

Could this be generalized to any larger block of MBL? Say the MBL doesn't cover a single cell, but it covers a filled 3x3 or 10x6 area. If a token were being dragged into the area, could that "block" of MBL be treated as normal cost so that a route could be planned, then when the path is displayed, the parts that ran over MBL cells be displayed in red or say "unreachable" or use some other user-friendly display? (This clearly doesn't work with how MBL is currently implemented. But pretend like you're doing some TDD. Write the documentation first about how it should work, then create the code. I'm trying to say that the "documentation" we currently have doesn't work for the users.)

It's pretty obvious that Jamz' picture in his post shows a nonsensical layout. If a GM were to design such a map, we'd have to assume that if tokens were meant to get into the enclosed area, the GM had plans for that (teleport, underground tunnel, whatever). But the problem I'm trying to address is perception.

[melek]

I like the idea of improving user experience for pathing. Without getting into the bowels of pathfinding math, it seems to me at least there is an easy solution. I have an inkling I'm missing something, but here's my take to improve user experience (well, unless performance gets worse doing this):

• Always show the token's movement path to the user, even if AI is enabled but no path is found (showing the distance number with any terrain mods, but not treating MBL or BLOCK squares differently)
• Always show yellow tinged pathing blocks over ADD or MULTIPLY tokens.
• Always show slight red effect on edges touching MBL & BLOCK Tokens.
• Always show red-tinged pathing block over MBL & BLOCK Tokens.
• Don't change actual behavior at all.

This has several benefits:

1. If a path isn't found, it reverts to a 'non-AI' path display, which can still be useful to determine grid distance, etc. - say, the GM 'teleporting' a token 60 ft over Lava.
2. Using waypoints to force a path will display to the user/GM exactly which cells they are crossing that have MBL.
3. MBL & Terrain modifiers suddenly become useful as a visual indicator even in non-AI enabled game sessions.

[JamzTheMan]

I still didn't get an answer other than my use case was nonsense? It was meant to spark conversation on what a human perceives as an obvious route vs what we can calculate based on rules.

And for what its worth, the example is not non sense and even came up last night in our game after a creature cast a Force Wall blocking a player in. An appropriate MapTool response would have been to prevent the movement altogether and give a visual clue. Instead MT let the PC cross with 0 movement and confusion.

We should not let tokens move through or onto MBL. We dont allow it today with VBL and should probably code it the same way rather than come up with very complicated code to show possible paths "up to a point" which i still argue make no sense.

[Azhrei]

It was meant to spark conversation on what a human perceives as an obvious route vs what we can calculate based on rules.

Then you succeeded. 👍

We should not let tokens move through or onto MBL. We dont allow it today with VBL and should probably code it the same way rather than come up with very complicated code to show possible paths "up to a point" which i still argue make no sense.

You said above, "An appropriate MapTool response would have been to prevent the movement altogether and give a visual clue". I'm just trying to make the "visual clue" as obvious as possible for the user. Believe me, when this came up during the game, our group talked about it for a few minutes and then I cut it short and said we should continue the game and talk about this after the session was over. (All of the other members of the group are new to MT.) When the game was over for the evening, the GM and two players stayed on and we talked about this for 20+ minutes. I explained how the algorithm searches for a path (these are not software folks, so it was conceptual), but understanding the algorithm didn't change what they felt was dissonance between how they expected it to look and how it actually looked.

I understand the desire to make MBL an absolute — "it works like this and it cannot work any other way". But we all know that it's the GM's job to break the rules. If the tool can't accommodate that, then GMs (or users) will become frustrated and simply won't use the feature. I think that would be a shame.

If I understand you correctly, you believe that MBL should never allow token movement. But I'm concerned that what the user sees on the screen doesn't foster any knowledge of that rule.

So...

Let's pretend that there is no MBL yet — it hasn't been written. Now take a fresh look at the UX and ask yourself, "What visual clue(s) should MapTool provide when the GM (or a user) tries to cross an area that has been defined as 'impenetrable'?" The primary use case for me is the first cell inside an MBL (or MBT) area; I think removing the path and displaying "unreachable" is insufficient (and apparently the users in this gaming group thought so as well).

The second use case would be dragging the token much further into an MBL (or MBT) area. How should that look to the user? I described how I thought it should look, now we can have others describe how they think it should look, including yourself (@melek has made some comments already).

One new thing that occurred to me when I read melek's post was that it might be good to highlight the cells around the token that are MBL cells when the token is moved into an MBL area. That would provide visual feedback that some cells were 'impenetrable' as well as show which ones were not. But this might give away in-game information and that would be a Bad Thing™.

[cwisniew]

It was meant to spark conversation on what a human perceives as an obvious route vs what we can calculate based on rules.

Then you succeeded. 👍

We should not let tokens move through or onto MBL. We dont allow it today with VBL and should probably code it the same way rather than come up with very complicated code to show possible paths "up to a point" which i still argue make no sense.

You said above, "An appropriate MapTool response would have been to prevent the movement altogether and give a visual clue". I'm just trying to make the "visual clue" as obvious as possible for the user. Believe me, when this came up during the game, our group talked about it for a few minutes and then I cut it short and said we should continue the game and talk about this after the session was over.

If changing this from 0 to "not allowed"/"blocked"/some other indicator and not allowing the player to drop the token would not be enough of an indicator then there is a very strong argument that the map is the problem. If your players can't see a reason on the map for movement being blocked and wonder why it has been blocked then something is missing from the map. If on the other hand there is a wall/chasm/etc on the map and players are still wondering why they are being blocked from moving through then the problem lies elsewhere and I am not sure if we could solve that.

I understand the desire to make MBL an absolute — "it works like this and it cannot work any other way". But we all know that it's the GM's job to break the rules. If the tool can't accommodate that, then GMs (or users) will become frustrated and simply won't use the feature. I think that would be a shame.

If the GM wants to break the rules then the suggestion that the GM can move the token works. But if you turn pathfinding on and want to limit players to path finding then they can't move to where there is no path. When you have pathfinding you either have a path, or you don't there is no 3rd option. If you say "well just make it more expensive to move through MBL and if it hits a certain limit then it just displays unpassable" comes with its own host of problems, but if you had actually read Jamz reply instead of dismissing his map as non sensical you would understand this and possibly be able to discuss the concerns he raised instead of flat out ignoring them in your reply. Never mind you ask the GM to consider what would happen if a player could move through the movement blocking when they are creating it as players are now able to move through it.

If I understand you correctly, you believe that MBL should never allow token movement. But I'm concerned that what the user sees on the screen doesn't foster any knowledge of that rule.

To the above point then its a fault with the map. Unless outside of players vision in which case that is visual indication in of itself of why they can not move there directly.

So...

Let's pretend that there is no MBL yet — it hasn't been written. Now take a fresh look at the UX and ask yourself, "What visual clue(s) should MapTool provide when the GM (or a user) tries to cross an area that has been defined as 'impenetrable'?" The primary use case for me is the first cell inside an MBL (or MBT) area; I think removing the path and displaying "unreachable" is insufficient (and apparently the users in this gaming group thought so as well).

The second use case would be dragging the token much further into an MBL (or MBT) area. How should that look to the user? I described how I thought it should look, now we can have others describe how they think it should look, including yourself (@melek has made some comments already).

You could have a path to the last reachable point the token moved over (notice I don't say last reachable point before where the token is currently at). But once its in/beyond the MBL by definition the location is unreachable, the A* returns no path because there is none. Even having the last reachable place will look funky in many situations as the player tries to get back to where they can go. So there are still trade offs (and extra work), which I am not sure cant be solved better than having a decent map.

One new thing that occurred to me when I read melek's post was that it might be good to highlight the cells around the token that are MBL cells when the token is moved into an MBL area. That would provide visual feedback that some cells were 'impenetrable' as well as show which ones were not. But this might give away in-game information and that would be a Bad Thing™.

Its the map that should be providing the visual cues any feedback of glowing walls that MT provides is without context and would either confuse more or reveal too much.

[cwisniew]

1. If a path isn't found, it reverts to a 'non-AI' path display, which can still be useful to determine grid distance, etc. - say, the GM 'teleporting' a token 60 ft over Lava.

This is not great unless Non-AI path ignores all costs, otherwise people might be able to determine things they shouldn't. At this point a better measuring tool would really be a better option than trying to get the path finding movement to be the answer to everything

[JamzTheMan]

I'm chalking this up to a learning curve as well. Clearly the GM thought when he created the map "ok, this pool is to big for players to walk into/over, let me put MBL there" but when it came time to play, they forgot they put MBL (checking the VBL/MBL layer would have confirmed this).

Also the player didn't think there was any issue walking into a pool on the map.

Now, this can also happen with terrain mod tokens, but even worse, because the GM could use any sort of tokens, even invisible ones, and place them on any layer. I place mine on the Hidden layer over things on the map that make sense to "me" like statues, rocks, etc. Maybe some rubble is x2 move and a large rock is block (would use MBL now days)

Given this just came out in the last version or so, it'll take some time for GM's to remember and TELL the player, "you can't seem to move there because xyz..."

I'm not discounting what we can do which is block movement and change the drag icon and add text. We can not do anything with paths without a major rewrite and development. If someone want to tackle that, have at it and good luck! We could display some partial paths but I'm 90% sure if I showed you what that may look like it would still look very confusing to the end users and nonsensical. A path may be blocked because of VBL or terrain tokens and may be blocked in several locations and not just the "end point".

Also please remember that MapTool has some limitations on "path finding" that most video games do not and that is it's insistence on using boundless maps. Give be a map with exact dimensions and some things become easier and more performant.

[melek]

1. If a path isn't found, it reverts to a 'non-AI' path display, which can still be useful to determine grid distance, etc. - say, the GM 'teleporting' a token 60 ft over Lava.

This is not great unless Non-AI path ignores all costs, otherwise people might be able to determine things they shouldn't. At this point a better measuring tool would really be a better option than trying to get the path finding movement to be the answer to everything

Ah, good point. I was thinking only the GM can drag tokens to impossible places, but that is probably not always the case!

[kwvanderlinde]

I'd like to revive this discussion as I've recently been dealing with confused players even when I think the map image reinforces what is happening.

My concept for how to do that is essentially to keeping showing the user the last valid path they could have seen, then indicate to them that they are still dragging the token into some inaccessible area. Here's as sequence of events to describe it more:

1. As a player drags their token to accessible locations, they are continually updated with optimal paths as they come in from the pathfinding algorithm. This is current behaviour.
2. At some point, the player drags the token somewhere inaccessible. Let's remember the point just before that (the last accessible position), and the associated path (the last valid path).
3. For as long as the token is being dragged somewhere inaccessible, continue showing the last valid path while also allowing the player to drag the token around.

And then I imagine dressing (3) up a little, maybe something like these options:

• Render two versions of the token - possibly stylized differently - one at the end of the last valid path, and one where the cursor is currently at.
• Draw a straight red line or a line of red cells from the end of the last valid path to the current cell.

So it would look roughly like this, if I start by dragging my token from left to right, then enter an inaccessible room, then drag the token down and to the right:

If I ever drag back out the inaccessible room, paths can be calculated again. And if I try go in somewhere else, I'll see a different path:

---

The above description assumes a couple things that we can't always rely on, but I think we can smooth over:

• It assumes we capture mouse inputs frequently and reliably enough to know what the last accessible position should be. But if for some reason we "skip" cells with the dragging, we can interpolate to fill that in and still pick a good last accessible position.
• It assumes pathfinding is performant enough to give users constant feedback as they drag. If there are large delays, it won't be obvious to the user why the path only goes up to a certain point. But I find delays to be very small in practice, and it might be possible to get some more updates shown to the user even in the presence of larger delays (e.g., by not always cancelling pathfinding for the previous position).

What I think the concept does well is fitting in with the current implementation. We wouldn't fundamentally change how we deal with pathfinding or how pathfinding works, we would just hold onto some prior state and draw stuff to keep users informed.

[Azhrei]

I'd like to revive this discussion as I've recently been dealing with confused players even when I think the map image reinforces what is happening.

I guess your map(s) just don't reinforce the idea enough either. 😉

I like your idea of coloring the paths. Maybe a light shade of green (for "go") and red (for "stop")? Those are culturally appropriate for much of the world, but not everywhere. There's also the issue of color blindness to take into account. It would be best to make this user-configurable, but I can't see any reason to make it theme-able...?

Right now, setting a waypoint causes the FOW to be cleared at that waypoint. Maybe that would be a good idea in this case? I'm wondering if MBL were placed in such a way that movement were slowed down, it would be good to expose FOW from that point so the player can choose where to continue movement. Without doing that, a casual player will drop the token (to get the expose event), then pick up the token and move it again. That makes the Undo Last Move option on the context menu useless for undoing the entire movement on their turn.

However, many games/GMs will not want the FOW to be cleared unless/until the movement has been approved. I'm not sure how to handle that conflict.

The above description assumes a couple things that we can't always rely on, but I think we can smooth over:

• It assumes we capture mouse inputs frequently and reliably enough to know what the last accessible position should be. But if for some reason we "skip" cells with the dragging, we can interpolate to fill that in and still pick a good last accessible position.

This is reasonable and what happens now if a large mouse movement triggers a mouseEvent that has a jump in (x,y) coordinates that crosses multiple map cells at once. (I believe it works this way, at least.)

What I think the concept does well is fitting in with the current implementation. We wouldn't fundamentally change how we deal with pathfinding or how pathfinding works, we would just hold onto some prior state and draw stuff to keep users informed.

LGTM. 😉

[Pmofmalasia]

I think this is a great idea, and in my opinion a natural extension of the idea would be having the last valid path be available programatically. This way, onTokenMove() functions designed to block invalid moves could stop tokens at the last valid point, which might be a nicer user experience.

[cwisniew]

I think this is a great idea, and in my opinion a natural extension of the idea would be having the last valid path be available programatically. This way, onTokenMove() functions designed to block invalid moves could stop tokens at the last valid point, which might be a nicer user experience.

Two problems with this, 1) user can't drop the token so there is no move that occurs 2) onTokenMove() shouldn't be relied on for nothing it's completely broken :) I do not support adding anything to it. If we need new functionality, a new event should be created that the way that the initiative change events happen (an event where many handlers get to reject the update but should make no changes, and an event called only after the move has occurred). And a strong suggestion to stop using onTokenMove().