Improving Angband's appearance, esp. colors

[tilkau]

Ah, I fear I've been misunderstood. I just meant that in the display code, individual grids should be able to have any colour as a background that can be used as a foreground (instead of the current possibilities of 'same', 'black' and 'shade'). It was a technical point about the code, not anything about user-facing display options, which I agree, should be as close to zero in number as possible.

Thanks; I didn't realize it wasn't already like that. I would have thought that the Curses code could also be made to support at least several different BG colors, based on what I've seen in console DCSS (blue BG for sleeping enemies, brown BG for wandering enemies, 4 different colors in the sidebar to indicate their level of health; red BG for an item stack containing >1 item)

And I get what you're saying, just didn't know if you knew some of the applicable features. Too bad the only native build is windows only, oh well. Back to your regularly scheduled thread, keep the pretty pictures coming

Yeah, it gave me a good idea for instant preview for font touchups (grafx2's tile autocompletion), anyway, so thanks. Sorry if I'm a bit abrupt or grumpy (not sure but I've been getting that impression of myself recently).

To be more explicit:
* I have researched REXPaint previously; wasn't specifically aware of the color-swap support.. (not completely sure whether you meant A: 'replace one color already in the picture with a new one', or B: 'swap two colors already in the picture')
* I tend to collect tools, and already have a sizable collection that I'm familiar with and I've customized (GIMP (with GMIC), GrafX2, MyPaint, Inkscape, Fontforge, Krita, Blender) plus all my shell scripts, plus my own plugins (mainly for GIMP, some for GrafX2). Particularly, typical shortcuts are not suited to Colemak layout; some important ones like Ctrl+Z/Ctrl+Y are not ergonomic.
* I also tend to focus heavily on speed
* So I typically have several ways to do a given task, that are fairly fast. With GIMP I noted 3 ways of doing case A above in a few seconds. At least one of them should be directly portable to Photoshop (By Color select with threshold 0, then use any of the color tools to adjust the color interactively). For case B, GrafX2 as noted (palette editor handles all of those cases.. but I should probably also write a simple plugin for GIMP that does that, since that would allow restricting the change to a subsection of the image.)

More ontopicly..

1. Anyone know offhand what colors are used in the alternate status display (ie. what you get when you press h on the C screen)? I've seen green, white, and grey so far. Hoping that there is some opportunity to safely do the 'alternating colors' thing for more readability. Aside from that, I don't see any other improvement that could be made to the alt status screen.

2. Looking at the inventory interface. IMO the prompt (eg 'Inscribe which item?') should get a special color (the revised color B might suit, and would match the 'selected' marker.), help messages like 'Inven: a-d, / for Equip, ESC' should be made darker (W or z), as should the weights column (W). Same for related actions like viewing equipment list.

3. 'Look'/target interface: Monster name should be separated color-wise (eg W for 'You see a' and w for 'large white snake'). Possibly color code 'wounded'/'somewhat wounded' etc.. status similar to the way @ is drawn in different colors according to amount of HP. Statuses that the player can get, like Afraid, should probably be drawn in the same color they are for the player (to get the same assessment-at-a-glance benefit)

4. Distinguish colorwise between primary and secondary prompts -- eg. for digging, 'Direction or <click>' in w, '(Escape to cancel)' in W

[Kyzrati]

Yeah, it gave me a good idea for instant preview for font touchups (grafx2's tile autocompletion), anyway, so thanks. Sorry if I'm a bit abrupt or grumpy (not sure but I've been getting that impression of myself recently).

I know you're cool so I didn't get that impression

I meant A, since that's what's most applicable here.

I'm all about editing efficiency, too, which is why I made REXPaint . I've been using Photoshop for 20 years, but when it comes to roguelike work raster programs just can't compare to dedicated software for me. Certainly some of the pixel art editors these days are better at it, but not for the complete task of grid-based editing. (Of course, in this use case you're mostly looking at just color rather than layout.)

In the latest version I added HSV color shifting directly on an image, which makes tweaking and exploring options even easier.

I've been very tempted to throw together some Angband mockups, but I'd be afraid I'm not familiar enough with it to do a good enough job.


Back on topic...
I think the row-wise alternating brightness makes the UI unnecessarily more difficult to read. The only good reason to do that is when you have very long rows of data in which the viewer might need to visually track back to the beginning to see what the header is, e.g. with a spreadsheet. The only part of the character screen where this might be desirable is the attributes box.

[tilkau]

I know you're cool so I didn't get that impression

Hahaha thanks

I meant A, since that's what's most applicable here.

I'm all about editing efficiency, too, which is why I made REXPaint . I've been using Photoshop for 20 years, but when it comes to roguelike work raster programs just can't compare to dedicated software for me. Certainly some of the pixel art editors these days are better at it, but not for the complete task of grid-based editing.

Yeah, I agree... I guess one way to put it is that I wouldn't class this stuff as 'roguelike' work yet, it's hardly different from web design so far.

(Of course, in this use case you're mostly looking at just color rather than layout.)

Yeh, basically what I was getting at. Intentionally trying to keep things really loose and resist the temptation to fiddle. A certain amount of it is psychological (painting a swathe over things to recolor them doesn't tempt me to fiddle like tile / text work does.)

In the latest version I added HSV color shifting directly on an image, which makes tweaking and exploring options even easier.

Hm. I'm struggling for what to say here. I like the idea but hate HSV (because it routinely mangles the apparent brightness of colors when you change H or S). Have you considered HSL or HCY?.

I've been very tempted to throw together some Angband mockups, but I'd be afraid I'm not familiar enough with it to do a good enough job.

I have to confess I'm pretty rusty. I used to play it a lot, don't really anymore to speak of*,

* That is, I don't play any games to speak of anymore.. so I promise I'm not discriminating against Angband

Anyway if you want to throw your hat in the ring, I would like that. I respect the aesthetic choices you made with CogMind, and more ideas/alternatives at this design/thumbnailing stage can only be of the good IMO.

Back on topic...
I think the row-wise alternating brightness makes the UI unnecessarily more difficult to read. The only good reason to do that is when you have very long rows of data in which the viewer might need to visually track back to the beginning to see what the header is, e.g. with a spreadsheet. The only part of the character screen where this might be desirable is the attributes box.

Interesting. So do you mean that it would be more suitable for columns, or you don't like it in any role?
Many GTK themes use that type of alternating for list/treeview backgrounds, though the difference is significantly less than what I have done here.. basically just enough to tell that there -is- a difference.

Attributes box? Do you mean the STR / DEX / FOO block, or the big spreadsheet-thing that is the alternate stats screen?



(No, I don't know why Light is blue. My torch has 4800+ turns left, so it's not running out of fuel...)

Well, hopefully we can agree that they both need attention. The existing grid alternation is a good readability measure here IMO, and I've started by implementing some of the feedback you and Nick gave:



* I think it's cleaner without the alternation.
* But I'll also make a version with the ..altered.. alternation that Nick suggested.
* I left Light's color as is since I didn't know what it meant.
* Brown might be a little too dark? I tried s and D colors, but IMO they make the row titles visually clump onto the table contents; z is a bit better (differing saturation) but is too bright, giving basically the original problem -- the ENTIRE thing visually sticks together like a huge brick. U is similar. b is a little better, here's an alternate with b instead:



* Tried a variation in the statusline which I think is a success (display keys you can press in a lighter shade)

Was I gonna darken the middle columns of the STR/DEX/FOO block? I don't remember, anyway, here's a variation with that:

(uses 't' color, which feels like about the right level of visual priority)


..
and finally, an inventory mockup:



Not super happy with this. I think it has some improvements though. If we could drop back the species/title/class color to b or D when an inventory prompt comes up, that would help make things clearer. Bumping the action ('Select item') color up to white also seems to help readability -- the white of the action and the grey of the item letter visually group together. Here are those revisions:

[Kyzrati]

I first encountered and started using HSV when I was getting into pixel art, since a lot of pixel artists use it, and it's easy to wrap your head around. So I wrote REXPaint with support for RGB and HSV (and hex). Never even heard of HCY before! I'm not great with desaturated colors, anyway, so I like to find a static saturation and set of hues, then tweak for brightness. It's limiting, but I mostly work with emulated terminals now, anyway :P. (If I'm not doing terminal stuff, I'll just stick to RGB in PS.)

Hahaha thanks
Interesting. So do you mean that it would be more suitable for columns, or you don't like it in any role?

Ah, I think in general it works better to have row-wise coloring, not columns, but only when there are many columns (i.e. long rows). (I was referring to the STR / DEX / FOO block in your first mockup.)

However, as used in the full "stat spreadsheet" page, with a non-square font giving more vertical space between glyphs, column-wise coloring works better. Foreground-based coloring isn't as effective for chart readability as a faint background color, though (which is one reason other programs do it that way). I don't know how feasible it is to change something like that in Angband.

Your Light is blue to indicate there is a value present in that row.

[tilkau]

I first encountered and started using HSV when I was getting into pixel art, since a lot of pixel artists use it, and it's easy to wrap your head around.

Yes, I tend to advocate against that on Pixelation every now and again. It's certainly approachable, but IMO the values are not actually intuitive -- comparing a hue of 240 with a hue of 60, same S and V values, illustrates:

So I wrote REXPaint with support for RGB and HSV (and hex). Never even heard of HCY before!

IMO in terms of predictability with perceived lightness, HSV < HSL < HCY < LCH(ab).. You can see HCY in MyPaint's color selector, and in MyPaint and Photoshop's Colorize layer modes.
I didn't mention LCH(ab) before because implementing it correctly is nontrivial.

There are other variations (ProMotion uses HWB, IIRC, which is like HSL), but my impression is they don't differ very much from their close relatives. Also, some of them are just synonyms.

Ah, I think in general it works better to have row-wise coloring, not columns, but only when there are many columns (i.e. long rows). (I was referring to the STR / DEX / FOO block in your first mockup.)

However, as used in the full "stat spreadsheet" page, with a non-square font giving more vertical space between glyphs, column-wise coloring works better. Foreground-based coloring isn't as effective for chart readability as a faint background color, though (which is one reason other programs do it that way). I don't know how feasible it is to change something like that in Angband.

Yeah, that particular idea might be more trouble than it's worth.

Your Light is blue to indicate there is a value present in that row.

Oh, thanks.. Hmm. I guess 't' might be a suitable color to replace that, then.

[Nick]

1. Anyone know offhand what colors are used in the alternate status display (ie. what you get when you press h on the C screen)? I've seen green, white, and grey so far. Hoping that there is some opportunity to safely do the 'alternating colors' thing for more readability. Aside from that, I don't see any other improvement that could be made to the alt status screen.

Aside from the w/W alternation between columns, there's B (an item with that property, as mentioned), G (only in the last column, representing a temporary property) and g (representing an immunity, and only relevant in the top 4 rows on the left panel).

Here's a more filled out example:


My feeling is that the column alternation is more important than row here, because which column is harder to pick.

For the inventory (and menus in general) - would a slightly different background shade (to both the regular black and the shaded sidebar) work?

[fph]

For resistances, there is some red-yellow-green color-coding in the monster list ("breathes X" is in red if you don't resist X, or something similar -- I never knew the exact criterion). Would it make sense to use the same color scheme here?

Maybe we can differentiate based on the resistances: no rCold (after a certain level) or no FA could be in big flashy red, but lack of nether resistance is less important and can be another color.

[bio_hazard]

Aside from the w/W alternation between columns, there's B (an item with that property, as mentioned), G (only in the last column, representing a temporary property) and g (representing an immunity, and only relevant in the top 4 rows on the left panel).

Here's a more filled out example:


My feeling is that the column alternation is more important than row here, because which column is harder to pick.

For the inventory (and menus in general) - would a slightly different background shade (to both the regular black and the shaded sidebar) work?

Not really what you're asking about in this thread, but I'd love to be on this screen and able to scroll through each equipped item, and have it either highlight the relevant columns and/ or highlight the resistance/bonus provided by that gear. Also have it display the name of the item.

alternating column brightness/color are just making the best of a bad job.

e: eventually, possibly an option to scroll left/right to get to rings, then scroll up/down to substitute other rings in your inventory, and, with a confirm, switch equipment from this screen.

[Bowman]

For resistances, there is some red-yellow-green color-coding in the monster list ("breathes X" is in red if you don't resist X, or something similar -- I never knew the exact criterion). Would it make sense to use the same color scheme here?

Maybe we can differentiate based on the resistances: no rCold (after a certain level) or no FA could be in big flashy red, but lack of nether resistance is less important and can be another color.

I'm okay with the current color scheme of white if you don't have it and blue if you do (and green for special cases). Matching the resist colors with the monster memory would be okay, too, as long as it doesn't lead to the screen screaming at me in red because I don't care about slow digestion or feather falling.

Imposing values for various resists/properties sounds like a bad idea, though.

[fizzix]

Just want to chime in that I think a lot of the changes suggested here are fantastic. I absolutely approve of changing the background of the non-playing regions, and that's probably the change I like the best.

[tilkau]

Aside from the w/W alternation between columns, there's B (an item with that property, as mentioned), G (only in the last column, representing a temporary property) and g (representing an immunity, and only relevant in the top 4 rows on the left panel).

Here's a more filled out example:


My feeling is that the column alternation is more important than row here, because which column is harder to pick.

For the inventory (and menus in general) - would a slightly different background shade (to both the regular black and the shaded sidebar) work?

.. Yes? I have to say I'm not a great fan of that particular solution though. Smaller palettes are better IMO, and it does raise the question of whether it would be doable in curses interface.

One sort of .. miscellaneous thought I've been kicking around (and the reason I linked Solarized palette in the OP) was to overall rebalance the entire palette along the lines of the idea from Solarized : make each color have a unique level of perceptual brightness. This would maximize the amount of usable 'X on Y' combos, as well as improving distinctness for, at least, people with colorblindness. That's more of a 'polishing' step though.. I wouldn't want to do it until the primary adjustments to the palette are finalized.

Anyway, let me make this counterproposal, using D:



Note that this still uses the 'drop the species+title+class display back in brightness during inventory actions' idea, as you have not specifically commented on whether that's doable. Also would require Takkaria's idea of (to some extent) supporting a wider range of BG colors.

Whatever coloring scheme we arrive at for the alt stats page, I strongly agree with Bowman : it should be completely consistent, not dependent on an internal 'importance rating'.

[fph]

I'm okay with the current color scheme of white if you don't have it and blue if you do (and green for special cases). Matching the resist colors with the monster memory would be okay, too, as long as it doesn't lead to the screen screaming at me in red because I don't care about slow digestion or feather falling.

Imposing values for various resists/properties sounds like a bad idea, though.

I understand, this makes sense.

In part, my proposal started from the fact that some of the important attributes are a bit hidden in the columns now. For instance, free action and speed are in unremarkable positions in the middle of their columns. I know that importance is relative, but this seems like a clear-cut case.
So, a different proposal to fix this issue: let us change the order of the attributes in the columns:

* first column: ok as it is.
* second column: move pBlnd/pConf/pFear/pStun to the top.
* third column: move FA to the top
* fourth column: move speed to the top, and infravision/tunnelling close to the bottom (light as the very last place is fine for me).

[mixer]

Colours per dungeon level

Personally I would like this screen to have the current green for immunity, and blue for single cover. Then you can have yellow for double cover and red for no cover AND being on a level where this is dangerous. That leave white for not covered and not dangerous. Most people who have played the game for a while learn the levels where particular resistances should be covered but even then miss it, so what chance do beginners have!

[takkaria]

Anyway, let me make this counterproposal, using D:

Personally I find this pretty difficult to read and visually distracting. The list item labels are already pretty well marked without needing an extra background colour change, and the grays of 'for Quiver' etc are too close to the background colour for comfort.

[Bowman]

Personally I would like this screen to have the current green for immunity, and blue for single cover. Then you can have yellow for double cover and red for no cover AND being on a level where this is dangerous. That leave white for not covered and not dangerous. Most people who have played the game for a while learn the levels where particular resistances should be covered but even then miss it, so what chance do beginners have!

The problem that I have with this is what is the criteria for what is important enough to be "dangerous" to miss? As it is now, everything is shown equally and left up to the player to prioritize. If I die because I lacked rPois and a AMHD breathed on me, then okay, I learn that I should have that resist to face that enemy. If instead, rPois is white until dl40 (for example) and I die because of an out-of-depth drolem in a vault on dl37, it'd be a lot more frustrating because the game was explicitly telling me not to care about a resist that actually was important. Similarly for dying on dl1 from a floating eye paralyzing in a room with other enemies before free action was "important", or getting knocked out by vibration hounds before rSound/pStun was "important", etc.

Also, just because something isn't generally considered very important (e.g. rShards) doesn't mean that it isn't still useful in certain situations (e.g. gelugons).

Not to mention that having importance ratings will encourage inexperienced players to grind until they have those modifiers.

Reorganizing the lists to have the more "survival critical" attributes at the top like fph suggested sounds good.