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

Separate Terrain VBL into Hill VBL and Pit VBL #3148

Merged
merged 1 commit into from
Nov 9, 2021

Conversation

kwvanderlinde
Copy link
Collaborator

@kwvanderlinde kwvanderlinde commented Nov 8, 2021

Identify the Bug or Feature request

Improves #2755

Description of the Change

Terrain VBL has been split into Hill VBL and Pit VBL, and regular VBL has been renamed to Wall VBL. The new toolbar icons should be considered stand-ins - I'll be asking around for help to get some graphical icons made up. The colour scheme also could use some work

In addition to changing to Hill VBL and Pit VBL, regular VBL was renamed to Wall VBL. New icons and translation keys
have been added for each kind of VBL. Due to changes in field names, MapTool will not be able to load campaigns created
in 1.11.0 Alpha 3.

Some refactoring has been done to support this change:

  1. Islands are no longer marked according to a VBL type. Instead, the entire tree is treated as one type or another, and
    the tree has no knowledge of its own type.
  2. The TopologyMode enum has been replaced with a TopologyType enum that does not include combined types. I.e., it
    only includes Wall, Pit, Hill and MBL types. A new TopologyMode class has been introduced to combined various
    TopologyTypes where that is still useful.
  3. The algorithm for calculating vision blocking segments in FogUtil.calculateVisibility() has been refactored into a
    VisionBlockingAccumulator class that can track the necessary state. This cleans up the algorithms for the various
    cases while keeping them separated from the many other FogUtil methods.

Possible Drawbacks

  • Anyone who made a map in the 1.11 alpha won't be able to load it without trouble.
  • More topology types means more colours that become hard to distinguish.

Here is a what each topology mode looks like, overlaid in pairs. Note how similar some colours are, and this doesn't even include all the possibilities (e.g., Hill+Pit+MBL).
image

Documentation Notes

There are three types of Vision Blocking Layers (VBL) that exist in MapTool:

  1. Wall VBL: Previously just called "VBL", this type always blocks vision. I.e., a token can never see into or beyond it, and a token inside an area of Wall VBL can't see anything.
  2. Hill VBL: Tokens outside an area of Hill VBL can see into the Hill VBL but not beyond it, while tokens inside the area can within the area and also see out of it.
  3. Pit VBL: Tokens outside an area of Pit VBL can see into the Pit VBL and beyond it, while tokens inside the area can see within the area but not out of it.

Release Notes

  • Added Hill VBL and Pit Wall in addition to Wall VBL (previously just called VBL).

This change is Reviewable

In addition to changing to Hill VBL and Pit VBL, regular VBL was renamed to Wall VBL. New icons and translation keys
have been added for each kind of VBL. Due to changes in field names, MapTool will not be able to load campaigns created
in 1.11.0 Alpha 3.

Some refactoring has been done to support this change:
1. Islands are no longer marked according to a VBL type. Instead, the entire tree is treated as one type or another, and
   the tree has no knowledge of its own type.
2. The `TopologyMode` enum has been replaced with a `TopologyType` enum that does not include combined types. I.e., it
   only includes Wall, Pit, Hill and MBL types. A new `TopologyMode` class has been introduced to combined various
   `TopologyType`s where that is still useful.
3. The algorithm for calculating vision blocking segments in `FogUtil.calculateVisibility()` has been refactored into a
   `VisionBlockingAccumulator` class that can track the necessary state. This cleans up the algorithms for the various
   cases while keeping them separated from the many other `FogUtil` methods.
@FullBleed
Copy link

Here is a what each topology mode looks like, overlaid in pairs. Note how similar some colours are, and this doesn't even include all the possibilities (e.g., Hill+Pit+MBL).

Since we're talking about 4 types here, I think you could use a Theme complementary color calculator to come up with colors that are easier to distinguish. We should actually put in at least two options as color blindness can make these things very difficult for some. The base option should probably stay away from red/green.

https://www.w3schools.com/colors/colors_complementary.asp

I think the theme that uses #E4F132 (bottom-right) as the central/selection color is pretty divergent.

@melek
Copy link
Collaborator

melek commented Nov 9, 2021

This is amazing. You are amazing!

Seeing this grid of colors does concern me with regards to accessibility. I have trouble differentiating these, and color blind people will almost definitely be unable to use them without a lot of frustration.

If it is possible, I think pattern fills, at least opposing diagonal lines, would immediately improve things without having to develop more new UI to selectively disable the layers, customize fills, etc.

Full bleeds ideas are good, but I do think colors alone aren't gonna cut it.

@FullBleed
Copy link

FullBleed commented Nov 9, 2021

Seeing this grid of colors does concern me with regards to accessibility. I have trouble differentiating these, and color blind people will almost definitely be unable to use them without a lot of frustration.

If it is possible, I think pattern fills, at least opposing diagonal lines, would immediately improve things without having to develop more new UI to selectively disable the layers, customize fills, etc.

Full bleeds ideas are good, but I do think colors alone aren't gonna cut it.

I agree. Some experimenting with more neutral pattern fills should be looked at. Getting even one or two static colors off the table helps a lot. I suggest a diagonal fill for Hill and vertical fill for pit. Though, too many possible patterns will also create issues. ;)

PS: Using the link above, you can see options for Triadic and Compound color schemes. Depending on how/if pattern fills can be done, these options may be good ones.

Copy link
Contributor

@Phergus Phergus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 28 of 28 files at r1, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @kwvanderlinde)

@Phergus Phergus merged commit 91de400 into RPTools:develop Nov 9, 2021
@Azhrei
Copy link
Member

Azhrei commented Nov 9, 2021

I agree. Some experimenting with more neutral pattern fills should be looked at. Getting even one or two static colors off the table helps a lot. I suggest a diagonal fill for Hill and vertical fill for pit. Though, too many possible patterns will also create issues. ;)

Just spitballing here, but I can see two other options. One is to use a portion of the window status bar to display information about what type of VBL/MBL is currently under the cursor. (I chose that instead of a tooltip because I think the tooltips will get in the way, but that’s also an option. Another would be a special purpose pop up window like the drawing palette panel.) I’m not a huge fan of this approach, as I think people don’t really look at the status bar much, plus it can be difficult for some to position the mouse accurately while keeping an eye on the status bar, and if there are many overlapping types of VBL/MBL, the text will get long winded.

Another option is striped colors. We already use this approach for selected tokens (red for owner, green for unowned; at one time we had purple for Individual FOW). However, those stripes are built from canned images and not generally applicable to this need. And it doesn’t eliminate the color choice issue. And maybe it will look too much like selected tokens? And if the VBL/MBL lines are very thin, they may look like dash-dotted lines rather than stripes. And… As you can see, I’m not sold on this one either.

These are more ideas for others to improve on. Now, get to work! ;)

kwvanderlinde added a commit to kwvanderlinde/maptool that referenced this pull request Nov 9, 2021
Campaigns that predate terrain VBL could not be loaded without error due to the refactoring in RPTools#3148. This was because
the old `Zone.topologyMode` field has the same name and type name as before the refactoring, but was structurally
distinct and so could not be correctly deserialized.

To avoid this, and to avoid potential other confusions with the previous enum `TopologyMode`, the new class has been
renamed to `TopologyTypeSet` and methods and variable names have been updated accordingly.
@kwvanderlinde kwvanderlinde deleted the issue-2755-hill-and-pit-vbl branch November 10, 2021 00:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants