Colourless colours

[IQuick143]

The mechanic of coloured boxes relies on a certain palette of colours being discernible, this is a problem for colour-vision impaired people, therefore an alternative visual scheme is required as a backup.

[IWonderWhatThisAPIDoes]

You don't even need to be colorblind, picking six different colors to be distinguishable on all screens is already an impossible task.

I lazily pasted several random shapes into the boxes. What do you think?

[IQuick143]

Seems good, although extensibility could be an issue. I can think of at least one level concept that would need 15 distinct boxes. Although I presume for such cases it might be best to simply use numbers inside the boxes.

Re: Box shapes, we can distinguish the boxes, but how do we distinguish the buttons?

[IWonderWhatThisAPIDoes]

An idea that comes to mind would be adding a similar shape into the box slot like this. This, of course would not work well in levels like Rubik, where all the buttons are obscured at all times.

If all else fails, hover hints should mention the color of objects.

[IWonderWhatThisAPIDoes]

Another concern regarding this is how to highlight a correctly placed box. A colorless box lights up green, but that is awkward at best here for obvious reasons. As it stands right now, the box and button become a brighter shade of their color, but with increasing number of different colors, it becomes difficult to tell a lighter/darker tone from a completely distinct color. The symbols/numbers should help with this. An alternative to this would be to turn only the frame or the fill of the box green, leaving the other part its original color.

Ad numbers: We could have a set of pictograms for different box colors, and switch to numbers if we run out of those. Or we could make a visual setting for this (switch between pictographic and numeric box labeling)

[IQuick143]

Proposal: Drop colours entirely and just use pictograms or numbers.

Maybe the level description could have a command to declare which pictogram is assigned which colour, and unassigned colours greedily use unassigned pictograms by default.

[IWonderWhatThisAPIDoes]

I like that last idea. Pictograms/numbers/both would be plenty enough.

We could even use a different box "color" for each one-color level (declare the "default color" in the level file) for some easy diversity

Do we want colorless/universal boxes/buttons as well?

[IQuick143]

Yep, all sounds good.

[IWonderWhatThisAPIDoes]

For the button visuals, I think putting the color mark directly into the box slot is infeasible in far too many levels. We could go with a label below/next to the button. Which design do you think works better? I'm skewing towards the one with a black framed label, but it may be nice to be able to decide that on case-by-case basis (with a parameter in the level description file, for example. Same could go for the direction in which the label is from the button).

The only level (as of now) where even this would break is Rubik, which is an outlier amongst outliers. We can use a different way to identify it there, e.g. decorative sprites (which is surprisingly something we have not even considered yet, but it could easily bring more life to some levels) used as labels.

Alternatively, we could come up with an entirely new design for the button sprites, but I do not have any that come to mind (and guess what: that would still break on Rubik).

[IQuick143]

I like the design with the arrow-y label if that won't be too difficult to implement, I suppose we just pick one of N variants for the sprite.

[IWonderWhatThisAPIDoes]

Me too. I might be in favor of making it a mesh instead of a sprite (just the arrow, the symbols should probably be sprites), especially if we opt in to allow placing it anywhere around the button like I did in that example

[IQuick143]

Agreed, a mesh is a good idea for the arrow.