Have in editor options to simulate common forms of color vision deficiency (color blindness)

[Two-Tone]

Ported from https://github.com/godotengine/godot/issues/21304

Describe the project you are working on:

Unrelated.

Describe the problem or limitation you are having in your project:

A decent number of people suffer from being colorblind and as a result a lot of games are considerably harder or even impossible to play unless the devs specifically go out of their way to include colorblind modes.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

My suggestion is to have toggles in the editor that lets the developer see what their game looks like if they had deuteranopia, protanoapia, or tritanopia. It'll help the devs who want to create color blind modes by letting them see what those users would see and it'll help raise awareness that it is an issue in the first place.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

For UI I was thinking putting the options inside an icon menu on the toolbar.

When clicked it'd show a dropdown menu of the various forms for color vision with radio buttons.

If this enhancement will not be used often, can it be worked around with a few lines of script?:

I expect it'll be used fairly often, especially as awareness of the issue grows.

Is there a reason why this should be core and not an add-on in the asset library?:

Having this as a plugin greatly diminishes the usefulness of it simply because it's something most people don't consider. Having it in editor and easily discoverable will make it much, much more likely that devs will use the tool and develop for the colorblind.

[eon-s]

This may be more useful as viewport/camera option, so in split view you can see differences and make corrections.

[Two-Tone]

That is a good point about split view, but having it hidden within the camera node would greatly reduced discoverability. Not sure where to put it that is as discoverable as the toolbar but still gives the dev the ability to only affect specific viewports.

On Fri, Feb 14, 2020, 6:28 AM eon-s notifications@github.com wrote:

This may be more useful as viewport/camera option, so in split view you can see differences and make corrections.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot-proposals/issues/473?email_source=notifications&email_token=ABBEIS2HTOAKQ2OSNRVEJE3RC2E5TA5CNFSM4KVCQ342YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELY3ZLQ#issuecomment-586267822, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBEISYVJLIGTVHDCZTKIFTRC2E5TANCNFSM4KVCQ34Q .

[eon-s]

It can be under the perspective menu, which also need a revision because the name and contents are confusing or not too related (maybe it could be called "view options" or something like that)

[paulloz]

Colour spaces conversions can be found here if need be.

[henriquelalves]

Does it make sense to add this natively in the editor seeing this is already implemented as an Addon (kudos to the author btw)? I understand how raising awareness for this issue is important, but this can be done in many different and better ways than implementing a redundant feature in the Editor itself. Improving this kind of Addon visibility to the community is one of them.

[willnationsdev]

@henriquelalves

I think that when it comes to accessibility features, if there is a way to sufficiently address any needs from a single built-in solution, then we should do it, so as to make the feature more readily accessible to developers who might otherwise not have considered it.

With that said, if there really are a large number of ways to implement a solution to the problem, where there are distinct benefits to using one way over another, then I would agree that it should be left as an addon. A big part of the addon system refactoring being done is to improve visibility and resolve workflow issues, so even an addon like godot-colorblindness would become easier to find no matter what we do (theoretically).

However, thus far, no one has shared any alternative implementations. You seem to have some ideas, so could you share how having a single "official" solution would be problematic to certain use cases? And if so, are we able to conceive of any way to satisfy those use cases with some level of extensibility or customization with a built-in solution?

[henriquelalves]

@willnationsdev (sorry about taking so long to answer) What I think might become a problem by addressing every accessibility feature (for the games, not the editor) as a built-in engine mechanism is the final user experience. Godot success is, in parts, thanks to making it easier and clear for the user the purpose of its features, and being a lot less bloated than other engines. But even a simple "eye" icon in the upper bar of the engine can create some confusion; is it something that only affects the engine? When testing a specific colour-blind combination, will it be exported along with the game? Does the user have to turn it off before compiling the game? How can you describe the type of the colourblindness being tested? If every feature we add in the engine create those kinds of question, sooner than later Godot will be bloated with a lot of features that surely will alienate a lot of users.

I'm not saying this feature is not important and it shouldn't be added by any means, but I think this kind of feature (not core, and something that can be created as an addon) is better as something the user "turns on" himself, because that way he made the conscious choice of using and understanding the feature. Creating a better "store-front" for the addons is what I think the best approach, as it should be accessed in-engine and other addons might be created with a similar purpose. Another approach would be to add those kind of engine features as toggle options in the Editor Settings menu, but this would have a worse discoverability than a nice looking Addons web-page.

EDIT: I just read my previous comment and I think I should take back what I said. I don't think there are "many different and better ways" to implement this kind of feature in the editor without affecting UX since the whole point is that I think this kind of feature should only be added in the editor by a conscious user choice, not by default. Sorry if I sounded a little pedantic there.