Resource icons in tooltips

[desyfer]

I found the tooltips to be quite confusing as a new player, they're also pretty huge; so much blank space!

The information which is of most use is definitely the cost, followed by counters/is countered by.

Stats are only of use to more experienced players, and we can possibly assume that a)they're not going to factor in in-game decision making, and b)experienced players won't need things spelt out for them.

I'd suggest something the following:

Qeset (Mauritanian Archer)

[F]50. . . [W]40. . . [P]1

Health: 90 . . . Armour: 3/2/3

Attack: 20r . . . Speed: 8.5/22.25

+ Swordsmen(2x), Cav. Spearmen(1.5x)

- Cav. Swordsmen, Cav. Skirmishers

Grouping unit costs with the name allows new players to instantly see unit cost without spending precious seconds searching around the tooltip. 'Cost' marker is not needed as it's quite obvious when we have the icons, and stops the tooltip looking like a long list of stats

Huge bit of blank space follows health. Armour is also a defensive stat so no reason they can't be shared. Hack pierce and crush will mean nothing to new players; who are better off looking at the counter/countered by section, so might aswell save the space and group them together.

"Ranged attack" is too long. I think everybody knows that archers have ranged attacks. Unless there are plans for 2 types of attack by archers in the future?

As a new player, I'm not sure of diff. in-game between walk and run, and even if I did, it wouldn't factor in my in-game decision making.

Finally, counters and countered by is very wordy. A plus and minus, accompanied with red and green font does the same job much clearer.

"vs." takes up too much space, and seperates the information too much; making it unclear.

Where can I find the code relating to this stuff? I'd love to give it a look over and play around with it a bit.

Edited December 17, 2012 by desyfer

[FeXoR]

I found the tooltips to be quite confusing as a new player, they're also pretty huge; so much blank space!

The information which is of most use is definitely the cost, followed by counters/is countered by.

Stats are only of use to more experienced players, and we can possibly assume that a)they're not going to factor in in-game decision making, and b)experienced players won't need things spelt out for them.

[...]

Grouping unit costs with the name allows new players to instantly see unit cost without spending precious seconds searching around the tooltip. 'Cost' marker is not needed as it's quite obvious when we have the icons, and stops the tooltip looking like a long list of stats

Huge bit of blank space follows health. Armour is also a defensive stat so no reason they can't be shared. Hack pierce and crush will mean nothing to new players; who are better off looking at the counter/countered by section, so might aswell save the space and group them together.

"Ranged attack" is too long. I think everybody knows that archers have ranged attacks. Unless there are plans for 2 types of attack by archers in the future?

As a new player, I'm not sure of diff. in-game between walk and run, and even if I did, it wouldn't factor in my in-game decision making.

Finally, counters and countered by is very wordy. A plus and minus, accompanied with red and green font does the same job much clearer.

"vs." takes up too much space, and seperates the information too much; making it unclear.

ONLY the stats effect my in-game decision. I hate not being able to see unit stats. That doesn't mean they have have to be seen in the tooltip of the build icon or the unit itself but they have to be available during play for that version of the game you actually play. So a tech tree including all stats (or even a list of units/buildings sorted by civ, but I don't really like that) would do as long as the stat values are linked to the values in the templates and the information are available in-game. A web page for example would not do because it would not be linked to the values of the templates the player is playing right now. Making an unlinked (to the template stat values) ""help article" would be bad too, because it would have to be updated every time any stat changes (e.g. for balancing reasons).

So the accurate values of all useful stats (maybe not e.g. how long an attack animation lasts before the hit actually takes place for example) should be available during the game and if any value changes (e.g. by triggers/updates etc.) they should be automatically updated wherever they are shown (separated in base value and upgrades at least).

To use colors for bonuses is a good idea IMO.

[Cerridan]

To use colors for bonuses is a good idea IMO.

I've implemented the colored unit counters, like so:

This was basically done by modifying the .xml files with the tooltip descriptions with color tags. I just edited the general templates, so the more specific tooltips, like the Macedonians' Companion Cavalry, were not affected.

ColoredCounters.patch

I would probably put the icons before the numbers, for consistency with the resource icons.

I've switched the damage icons to the left of the number.

AttackIconsLeft.patch

AttackIconsLeft.zip

Where can I find the code relating to this stuff? I'd love to give it a look over and play around with it a bit.

The 'Getting Started' guide for programmers can be found here: http://trac.wildfire...rtedProgrammers

It's written in C++ for the core, and JavaScript for the game files (what you will be editing). Most of the code is found under the

binaries\mods\public directory. Good luck!

Edited December 18, 2012 by Cerridan

[Lion.Kanzen]

the color of each text must be most soft for the legibility, that samples are hard to read.

Edited December 18, 2012 by Lion.Kanzen

[Josh]

I've implemented the colored unit counters, like so:

This was basically done by modifying the .xml files with the tooltip descriptions with color tags. I just edited the general templates, so the more specific tooltips, like the Macedonians' Companion Cavalry, were not affected.

ColoredCounters.patch

I've switched the damage icons to the left of the number.

AttackIconsLeft.patch

AttackIconsLeft.zip

The 'Getting Started' guide for programmers can be found here: http://trac.wildfire...rtedProgrammers

It's written in C++ for the core, and JavaScript for the game files (what you will be editing). Most of the code is found under the

binaries\mods\public directory. Good luck!

I really like how that looks!

[alpha123]

I've switched the damage icons to the left of the number.

Cool! Thanks.

I really like the colored counters, but they're kind of aggressively bright right now IMO.

[historic_bruno]

the color of each text must be most soft for the legibility, that samples are hard to read.

Yeah pure "red" and "green" are probably not suitable, it would need some tweaking to find a good color.

However, I think we should be careful about how we use color to distinguish things in the UI, and especially careful about using color as the only difference to make e.g. text stand out. There's almost always a better way to do it. Someone has already proposed using color for failed tech and resource training/building requirements, so there would potentially be a lot of color used in the tooltips. It also makes it more difficult to find useful information, because the player's eye will be attracted to the red text, when all they really care about is costs, or health, or something.

[Lion.Kanzen]

Yeah pure "red" and "green" are probably not suitable, it would need some tweaking to find a good color.

However, I think we should be careful about how we use color to distinguish things in the UI, and especially careful about using color as the only difference to make e.g. text stand out. There's almost always a better way to do it. Someone has already proposed using color for failed tech and resource training/building requirements, so there would potentially be a lot of color used in the tooltips. It also makes it more difficult to find useful information, because the player's eye will be attracted to the red text, when all they really care about is costs, or health, or something.

yeah because must be a contrast with Background. im not Graphic Desing for use the Computer Tools.

You can read Yourselft Search this:

However, most studies have shown that dark characters on a light background are superior to light characters on a dark background (when the refresh rate is fairly high). For example, Bauer and Cavonius (1980) found that participants were 26% more accurate in reading text when they read it with dark characters on a light background.

and

People with astigmatism (aproximately 50% of the population) find it harder to read white text on black than black text on white. Part of this has to do with light levels: with a bright display (white background) the iris closes a bit more, decreasing the effect of the "deformed" lens; with a dark display (black background) the iris opens to receive more light and the deformation of the lens creates a much fuzzier focus at the eye.

Edited December 21, 2012 by Lion.Kanzen

[Lion.Kanzen]

yeah because must be a contrast with Background. im not Graphic Desing for use the Computer Tools.

You can read Yourselft Search this:

and i found this in same page.

Timothy Samara in Design Elements: A Graphic Style Manual provides interpretation of the colors black and white. Samara tells us that the color black is "extreme [...] the strongest color in the visible spectrum." He further calls it dominant and also typical of the feeling of nothingness. The color white, on the other hand, is described as being both the presence of all color (in subtractive color models) and also the absence of all color (in additive models).

A dominant darker-value color region (the black field) will cause our brain to expand lighter-value colors placed within it. The effect is that lighter-value objects will tend to bleed into the void of the very dark-value region. Practically, white characters will look heavier in a dark background.

Letters require a certain amount of space between each other to be readable—they need to be close enough to look like a grouped collection (and look like a word) but not so close that the boundary between letters becomes indistinct (and makes the group look like a blob). As the letters look thicker, the apparent space between them decreases and words tend toward bright white blobs. Unless the font presentation is modified, this makes white-on-black less readable and therefore undesirable.

White-on-black can be achieved, however, with a little extra effort in the interface's style sheets (or whatever is used to define how/what text is presented).

First, a "thin" or "light" (not "narrow") font or font-weight will reduce the effect of the letter body bleed. Alternatively, a larger type size will provide the letter glyphs with enough surface area to successfully battle the black background for visual dominance.

Secondly, an increase in letter spacing (more-so for the smaller font sizes) will give the glyphs the bit of extra room they need to look like letters. These two effects can mitigate the usability losses of standard fonts in white on a black background, allowing you to use said alternative color combination.

[Mythos_Ruler]

My original UI mockups called for white boxes and black text. Not sure why we went the opposite direction.

[Pedro Falcão]

I think colored tooltips are overwhelming. I have nothing against the icons, in fact i like the icons, but please, don't add colors!