Ideas for a UI facelift

[LordBob]

Long lists call for a long answers, so please bear with me.

Gold: the new display unifies not only gold and income, but also upkeep (see detail on the left side of the first mockup). The aggregated status would show Gold amount +/-( Income - Upkeep), with a tooltip that gives the detail of each value.

Clock display: this one's an omission on my part. The clock display will remain unchanged.

Toggle grid button: concepts are constantly evolving and in our latest discussion, we came to the same conclusion. It would be replaced with a button that handles color coding (show individual team colors or show sides - ally/enemy/...) separately from the "switch unit display mode" button, making the later a simple on/off toggle

Zoom slider: I'm not myself a user of the zoom function, but I assumed it exists for a reason - in which case hiding it in a preference menu may cause players who need it to overlook its existence. Or we decide that there's little point to zooming and completely remove the functionnality from the game.

Turn sequence display: the idea is to let players know which team will play next, especially in MP games. We are aware that there isn't a *limit* to the number of sides, and that *exceptions* exist, and I am bothered that there would not be a more convenient way of handling those (more accurately, I find myself short of words to describe how stupid the whole situation feels). So, we resorted to a sequence that would display the next 10 player/team turns, and be updated at the end of each turn . If there are only 4 teams in a game, then the widget shows two and a half cycles. If there are 12, then it cannot show a full cycle. I would aso hope that we can find a way of detecting hidden sides and, well, hide them, but if it seems that coding the whole business will give birth to a white elephant, then I say we shove the feature in the incinerator...

Alignment display: the mock-up doesn't make it clear enough, but the alignment of a unit is displayed only once in the profile box, where the alignment icon (there will be a different one for each alignment) is completed by the bonus/malus factor currently affecting the unit.
As for the alignment icon featured above the ToD display, it does not depend on the unit and shows the alignment -if any- favored by the ToD or local lighting condition currently displayed. This might create confusion, though , so maybe there is room for simplification - in which case I would indeed relocate alignment icon + bonus factor above the ToD.

Terrain defense: the value depends on the unit as much as it depends on the terrain, so displaying it in the profile box still makes sense. Besides, it will be easier to read on a black background than on the ever-changing ToD+terrain artwork.

Attack icons: I was planning to give their borders a facelift, so maybe it's the right time to do as you suggest.

Icon color coding: we do have some plans about color - including sets of differently-shaped ellipses, but indeed I have not considered how profile icons would be optimized for color-blind players. Color is meant as a helpful hint here, but it doesn't carry the entire meaning. The best I can do for now is ensure that a clear contrast will always make the icon easy to read, and maybe play on the shape of the icon background in order to differentiate categories.

Level display: I'll make sure the icon has room for two digits. It should be more than enough to content everyone.

Icons & artwork: This is a subject that would deserve its own thread. I will make the icon design effort public and provide extras when required, but beyond this maybe we do need to implement some sort of a 'if no icon is found, then default to text or to a placeholder icon' feature. There is still a lot of trial and error to be made on this profile display.

[fabi]

I won’t comment on the art aspects of the new layout because I don’t feel I could provide any useful comments besides “Good job!”, but it seems like the emphasis on the End Turn button is a little too much on the flashy side with the unique decoration around it. That might be just me, though.

We also plan to have some decoration in the currently gray area around the tod/terrain/unit box, taking away some of the focus from the end turn button's decoration.

I like how the income and gold display are unified in the proposal to save space. There is currently an additional display in the production game theme for unit upkeep, but I don’t know how widely used it is or whether anyone understands what it’s supposed to mean.

What do I need to do for seeing this additional display?

I see the clock display is gone in the proposal. I assume it’ll be made so it only appears in games with turn timers? (This is an EasyCoding idea at the moment.)

No, we were not aware of this EadyCoding task. The turn timer was simply forgotten.

I have to say that I find the rest of the proposed layout to be more than a bit cluttered with the large amount of permanently visible icons and buttons on the sidebar.

If you do not like icons and buttons, stay with the classic theme (which we will polish as well).
We can't address everyone's needs and taste in a single one.
Having different themes for different tastes of our users is one of the points for having a theming system at all.

I don’t need to be able to toggle the hex grid in-game and I doubt many other people do, so I don’t see the point in exposing that option when there is already a way to toggle in Preferences → Display or using keyboard shortcuts.

LordBob and myself came to the same conclusion, the grid button is not really needed there and won't be included in the next iteration.

I will never use the zoom slider either since the function is both slow and not very pleasant-looking due to the scaling algorithm in use and terrains being always designed for the default 1:1 scale.

The slowness of the zoom function is one of the issues being addressed by the slider.
Zooming is slow because the game calculates every step when zooming until you reach the wanted level.
The slider allows to zoom into the target level with a single recalculation, making the zoom functionality much more useful.

I feel the need to use the zoom feature often, to get a better overview of the situation (zooming out),
being it less pleasant to the eye doesn't matter there much.
I know visual impaired persons which frequently need to zoom in and out again, for obvious reasons.

Maybe you own a display with a huge resolution that gives you enough information in all situations and your eyes are good enough to avoid the need
for zooming in, good for you.

Implementing a better scaling algorithm might be a nice task (or part of a bigger project) for gsoc,
their is indeed room for improvement.

Still the slider is only a very small additional widget, it won't hurt much the user not wanting or needing the feature.

Displaying the current playing side’s team color above End Turn seems redundant with the flag provided in the top bar’s turn counter.

This is true, we could reduce the displayed turn sequence by one small icon.
But that saves only a small amount of space and the current side makes sense in the context of the sequence.

Displaying all other side’s team colors in the same place seems to be proposed under the assumption that the maximum amount of sides a scenario can have is 9—it’s not—and that there won’t be multiple sides in the scenario with identical team colors, which is an assumption I actually break from time to time in one of my campaigns.

No, we are aware of the fact that the number of sides isn't limited to 9.

Please fill a feature request for defining additional colors (if that isn't already possible) by addons and fix your campaigns after it got implemented.

How would hidden sides (either for story reasons or in order to create the illusion of a single side with different AI behaviors without coding a more complicated AI) be handled by this feature?

That will still need to be discussed.

Displaying the unit’s alignment status in a manner that is always relative to the current ToD doesn’t strike me as the most intuitive thing to do for players who may need to think ahead (turn-wise) about how they’ll use newly acquired non-standard units.

Good point, I we will discuss it.

Also, why is the alignment displayed both in the lower area and the ToD/terrain display area?
It wastes a full line that could be used for more information in the former (especially for units that have four or more attacks).

As LordBob already pointed out, the upper icon displays if lawfull_bonus= is a positive, negative or null value.
It will also be visible when no unit is selected to allow for scanning the terrain for local time of days and other modifications to the global tod.

The southern icon + value displays the actual value of bonus/malus the unit receives.

It also seems like the terrain defense would belong in the ToD/terrain display area instead.

Like LordBob said, the defense value is as much unit depended as it depends on the terrain.
Thus both positions seem to be valid.

The attacks list display uses shrunk weapon icons in your mock-up, which reminds me that it’d be a great idea to make the icon frame separate from the individual attack icons (bug #20387 [Gna.org], not mine though) since otherwise it might not look very good automatically downscaled by the game.

Good point.

There have been some complaints in the past about how much Wesnoth relies on colors to display unit allegiances on the game map and how this isn’t optimal for people afflicted by different forms of color blindness. I’m not sure the proposed color-coding takes this into account since that isn’t mentioned in your post.

We are working with a color blind user to improve the display for impaired persons.
This is a difficult issue, red-green blindness is not the only color related phenomenon, although the most common.

Making the unit’s current level into the XP icon needs to take into account that some add-ons (including one of my own) might have very rare units which go up to level 10 or even more.

Yes.

It also seems you removed the unit’s race display. Yes, it’s arguably redundant in mainline, but I’m not all that sure about UMC since I don’t play any other people’s add-ons.

Maybe.
Does anybody know more about the issue?

I assume the second bar below the menu bar will only be visible in replay mode.

Yes.

Finally, I have to agree with the concern about artwork for user-made content. Not all add-ons replace mainline units and abilities or weapon specials in their entirety, so it seems more than a bit odd to be forced to switch to a “text-mode theme” in order to allow custom content to coexist with mainline during scenarios. I know the community is generally good about making new unit art, but designing unique semantic icons requires different additional skills than drawing some person on wizard robes for displaying on the map. There is also the matter of similar abilities with different strength, such as heals+4 vs. heals+8, or cures vs. heals+4+unpoison, or weapon specials with variable attributes such as plague(attacking unit) vs. plague(walking corpse) vs. plague(custom unit).

What LordBob said.

[fabi]

... I would also hope that we can find a way of detecting hidden sides and, well, hide them, but if it seems that coding the whole business will give birth to a white elephant, then I say we shove the feature in the incinerator...

Detecting if a side is hidden or not is trivial. I don't see any coding problems at all.
The only question is if we display them in the sequence or not (or maybe display them but mark as hidden).

[Iris]

Gold: the new display unifies not only gold and income, but also upkeep (see detail on the left side of the first mockup). The aggregated status would show Gold amount +/-( Income - Upkeep), with a tooltip that gives the detail of each value.

My bad, I didn’t pay much attention to the tooltips. Good then.

Turn sequence display: the idea is to let players know which team will play next, especially in MP games. We are aware that there isn't a *limit* to the number of sides, and that *exceptions* exist, and I am bothered that there would not be a more convenient way of handling those (more accurately, I find myself short of words to describe how stupid the whole situation feels). So, we resorted to a sequence that would display the next 10 player/team turns, and be updated at the end of each turn . If there are only 4 teams in a game, then the widget shows two and a half cycles. If there are 12, then it cannot show a full cycle. I would aso hope that we can find a way of detecting hidden sides and, well, hide them, but if it seems that coding the whole business will give birth to a white elephant, then I say we shove the feature in the incinerator...

Well, of course we will find a way to detect hidden sides — mostly because there already is a way, or otherwise hidden sides would not exist in the first place. :p I decided to point out their existence anyway to ensure the specifics are part of the plan instead of a border case that will be patched months or even years later when somebody finally decides to file a bug report about it.

You didn’t address the part about the possibility of there being multiple sides with the same colors, though. (See my response to fabi further down.)

Terrain defense: the value depends on the unit as much as it depends on the terrain, so displaying it in the profile box still makes sense. Besides, it will be easier to read on a black background than on the ever-changing ToD+terrain artwork.

As an aside: in general (and this is probably mostly relevant for story screens with bright backgrounds) we should look into implementing (or finding, if there is such a thing readily available outside of the map labels display code) a way to render shadowed text anywhere.

***

I like how the income and gold display are unified in the proposal to save space. There is currently an additional display in the production game theme for unit upkeep, but I don’t know how widely used it is or whether anyone understands what it’s supposed to mean.

What do I need to do for seeing this additional display?

On the current production theme this would be the field with the red minus sign overlay on top of the gold icon, between the units count and income display.

If you do not like icons and buttons, stay with the classic theme (which we will polish as well).
We can't address everyone's needs and taste in a single one.
Having different themes for different tastes of our users is one of the points for having a theming system at all.

That is my concern, actually. Ideally, a non-conforming add-on shouldn’t need to force a choice that might be entirely opposed to the user’s theme choice and be considered inferior by them — potentially resulting in the user giving up on playing the add-on.

Maybe you own a display with a huge resolution that gives you enough information in all situations and your eyes are good enough to avoid the need
for zooming in, good for you.

Well, yes, I guess I prefer scrolling the map around and taking note of its structure, and using the minimap and the Show Enemy Moves command as a gameplay aid than staring at haphazardly downscaled graphics.

(Since I am not completely sure about your tone, I’ll just point out that I am only providing my own opinions on things. I am not a UI designer and I generally have no idea what I’m talking about aside from experience as a user myself. In particular, I tend to be put off by applications that flaunt all their commands and options by default regardless of their relevance. If the zoom slider is deemed relevant by other people, I can’t possibly oppose it gaining permanent visibility.)

Displaying the current playing side’s team color above End Turn seems redundant with the flag provided in the top bar’s turn counter.

This is true, we could reduce the displayed turn sequence by one small icon.
But that saves only a small amount of space and the current side makes sense in the context of the sequence.

When I said it’s redundant I didn’t mean “it’s wasting valuable display space” — I just meant it’s information that is already readily available on the same screen within an area that the player will be watching in most cases anyway.

If you’d prefer making it fit in the player colors sequence you could add some kind of decoration to the square displaying the playing side’s color, like a thicker and/or lighter border as if it were the selection or focus in a listbox.

Displaying all other side’s team colors in the same place seems to be proposed under the assumption that the maximum amount of sides a scenario can have is 9—it’s not—and that there won’t be multiple sides in the scenario with identical team colors, which is an assumption I actually break from time to time in one of my campaigns.

No, we are aware of the fact that the number of sides isn't limited to 9.

Please fill a feature request for defining additional colors (if that isn't already possible) by addons and fix your campaigns after it got implemented.

I have very good reasons to reuse team colors in my campaign most of the time (when it happens, anyway, which is a rare thing by itself), mostly going in hand with my point about hidden sides:

How would hidden sides (either for story reasons or in order to create the illusion of a single side with different AI behaviors without coding a more complicated AI) be handled by this feature?

The rest of the time the reason is that I just can’t come up with color ranges that aren’t too similar to others that are already in use in the same scenario (the mainline nine, plus yellow and pink).

(Defining additional color ranges has been possible since before 1.3.x (presumably since the introduction of the feature in 1.1.x) and I actually worked on making it a bit easier much later on, so I don’t need to file any feature requests in that regard.)

There have been some complaints in the past about how much Wesnoth relies on colors to display unit allegiances on the game map and how this isn’t optimal for people afflicted by different forms of color blindness. I’m not sure the proposed color-coding takes this into account since that isn’t mentioned in your post.

We are working with a color blind user to improve the display for impaired persons.

This is a difficult issue, red-green blindness is not the only color related phenomenon, although the most common.[/quote]
Yeah, hence I said “different forms”, plural. :p

It also seems you removed the unit’s race display. Yes, it’s arguably redundant in mainline, but I’m not all that sure about UMC since I don’t play any other people’s add-ons.

Maybe.
Does anybody know more about the issue?

I’ll just add that I shortened some unit type names that originally included race adjectives in one of my campaigns after this feature was first introduced in 1.3.x, so that they could display on the sidebar (in English, anyway) without being truncated/ellipsis’d. I for one am not against making the adjectives part of the type names again if necessary.

[LordBob]

Turn sequence display: considering comments we have received, we are considering the possibility to relocate this in a tooltip attached to the flag of the "number of turns" status. The tooltip would display the name and color of sides (or their flags if we can add image support in tooltips) in the order they are played. Hidden sides would remained hidden, with some extra code magic to make sure several sides sharing the same color can be displayed as a single side when there is meaning to it - if, for example, side 7 is a previously hidden reinforcement to side 2 that is revealed on turn 10, and both share the blue side color because you want the player to think they are one and the same, then we would try to show only one blue flag in the sequence.

Race names: in addition to the aforementionned redundancy that makes type names eat up a lot of space, race doesn't have much impact on game mechanics AFAIK. Based on what fabi tells me, it only serves to determine how a unit's name is generated and the pool of possible traits upon creation of said unit. Furthermore, implementing a mechanism that would determine if and how race is displayed or not, and how to properly use it as an adjective or full name, feels like white elephant potential.
So, whenever informing the player about the race of a given unit has importance, I propose to include the information in the type name as it's already done for half the mainline types. It might be a step back in some regards, but it really looks like the easiest solution here.

Icons vs text: this one is likely going to be a problem. We're still discussing it and haven't found a satisfying answer so far. I do agree that forcing addons to provide complimentary artwork is an unwelcome constraint, and that neither the full-icon nor the full-text solutions are satisfying, each one for different reasons. And any hybrid of the two is probably going to be a nightmare as well...

As an aside: in general (and this is probably mostly relevant for story screens with bright backgrounds) we should look into implementing (or finding, if there is such a thing readily available outside of the map labels display code) a way to render shadowed text anywhere.

Agreed. Shadowed or outlined, being able to overlay readabe text on bright areas of the screen would do us a world of good (how do map labels manage it, by the way ?).

[Telchin]

Some random comments from someone who isn't a developer:
@LordBob

The clock display will remain unchanged.

Good to know. It's not only important for timed turns in multiplayer, but also for those "Have I been playing Wesnoth for last four hours?!" revelations

Alignment display: the mock-up doesn't make it clear enough, but the alignment of a unit is displayed only once in the profile box, where the alignment icon (there will be a different one for each alignment) is completed by the bonus/malus factor currently affecting the unit.
As for the alignment icon featured above the ToD display, it does not depend on the unit and shows the alignment -if any- favored by the ToD or local lighting condition currently displayed. This might create confusion, though , so maybe there is room for simplification - in which case I would indeed relocate alignment icon + bonus factor above the ToD.

At first I thought that the smiley in the terrain window and in the unit's description means that it gains bonus at the current ToD. But from this answer I gather you intend to use a happy face for lawful units and a sad face for chaotic ones. I don't think that's intuitive (as there is no reason for chaotic units to be sadder than lawful ones and vice versa). I'm not sure what a better shorthand would be (my first idea would be sun and moon, but that leaves out neutral and liminal units).

Race names: in addition to the aforementionned redundancy that makes type names eat up a lot of space, race doesn't have much impact on game mechanics AFAIK. Based on what fabi tells me, it only serves to determine how a unit's name is generated and the pool of possible traits upon creation of said unit. Furthermore, implementing a mechanism that would determine if and how race is displayed or not, and how to properly use it as an adjective or full name, feels like white elephant potential.
So, whenever informing the player about the race of a given unit has importance, I propose to include the information in the type name as it's already done for half the mainline types. It might be a step back in some regards, but it really looks like the easiest solution here.

It sort of pains me to have this feature removed (as I got used to it), but these reasons are convicing. It's irrelevant once the unit is recruited, it's either redundant (Drake Burner is a Drake ) or inconsistent (Wolfriders are Wolves rather than Goblins, because foot Goblins get different traits) and it is displayed in the game's help (so it wouldn't be removed completely).

@fabi

We will have some extra icons for user made custom abilities/traits/weapon specials/unit statuses...
Those can be used by UMC designers if they lack of proper artwork.

Still, if an addon makes heavy use of custom features, the designer can enforce the usage of the classic, mostly text based theme.

Thanks. Given that the ability icons seem to be small and using only two (?) colors (white and "designated ability type" color) I guess it would be possible even for artistically challenged people (like myself) to make decent icons for custom abilitie, but it's reasuring that the developers intend to make it easier for UMC creators.

@shadowmaster

There have been some complaints in the past about how much Wesnoth relies on colors to display unit allegiances on the game map and how this isn’t optimal for people afflicted by different forms of color blindness. I’m not sure the proposed color-coding takes this into account since that isn’t mentioned in your post.

I'm not colorblind, so I may be wrong, but I think that as long as the ability icons are recognizable and have tooltips it doesn't matter whether they are color-coded depending on their effect or not (unless some abilities have a otherwise same icon, only recolored). There may be some initial confusion between ranges/damage types/weapon specials (e.g. both melee range and blade damage use some sort of swords), but AFAIK each attack has exactly one range and damage type, so it shouldn't be hard to remember that icon #1=range, icon #2=damage type, icons #3, #4,...=weapon specials (if people can remember that N-M means M strikes, N damage each, they can probably remember the succession of the new icons as well). The bigger issue could be distinguishing traits and abilities stricto sensu - LordBob's mock-up shows undead (trait) and stalwart (ability) next to each other (and given that one is teal and the other blue I can see the color-blindness problem here). I think that the abilities should start on a separate line.

I know the community is generally good about making new unit art, but designing unique semantic icons requires different additional skills than drawing some person on wizard robes for displaying on the map. There is also the matter of similar abilities with different strength, such as heals+4 vs. heals+8, or cures vs. heals+4+unpoison, or weapon specials with variable attributes such as plague(attacking unit) vs. plague(walking corpse) vs. plague(custom unit).

Yes, I'm worried about that as well. The obvious solution for the scaling abilities (e.g. heal+N) would be using the same icon with an added number, though that might have issues with both the icon's size and perhaps also some translations that don't use the latin alphabet. However, there might be problem with making recognizable icons for abilities that are either too complex, are used for different concepts on different units (e.g swarm's name suggest it's meant for insect swarms, where each attack would be a separate animal in the swarm, but on the cuttlefish it depicts separate tentacles of a single animal) or use similiar concept (but different mechanics) to other abilities (e.g a leadership-like ability affecting different stat than attack).

[LordBob]

I know the community is generally good about making new unit art, but designing unique semantic icons requires different additional skills than drawing some person on wizard robes for displaying on the map. There is also the matter of similar abilities with different strength, such as heals+4 vs. heals+8, or cures vs. heals+4+unpoison, or weapon specials with variable attributes such as plague(attacking unit) vs. plague(walking corpse) vs. plague(custom unit).

Because this will be a recurring concern, I'm sharing below my working sheet for icons. I hope it is pretty obvious that some of them are still WIP placeholders, but it should still give a better idea of where I'm headed than just the UI mockups.

The (hopefully recognizable) heal icons show how I intend to handle scaling abilities. Note that this working sheet is partly based on previous efforts that can be found on these forums, in which case I focused on making the icons more recognizable, i.e greater contrast and simpler shapes.

On a side note, I don't inted to keep smiley faces as alignment icons. They're placeholders and the final icons will indeed be in the manner of sun, moon, etc.
And yes, defining clear icons for every single trait and ability is going to be a challenge, but each icon will have a tooltip that gives its full name in game, so do not despair.

[Telchin]

@LordBob
Thanks for your answer. I think that using numbers on scalable abilities are OK, but I would advice against using words (or letters) as that would be problem for translations. Yes, I understand that the traits with words are placeholders and will be replaced with actual pictures in the final version, but I'm not sure about the "1st" on first strike (I think you can represent going first by say adding some lines/arrows/wings to the sword to denote speed). I also think that arcane damage should use different icon than lightning (as those tend to do fire damage).
I apologize that I berate you for placeholders that you intend to change anyway. I don't have 1% of your artistic talent, so I trust in your skills and the developer team's judgement.

[GunChleoc]

I won’t comment on the art aspects of the new layout because I don’t feel I could provide any useful comments besides “Good job!”, but it seems like the emphasis on the End Turn button is a little too much on the flashy side with the unique decoration around it. That might be just me, though.

First of all, I'd like to concur with the "good job!" sentiment.

I also see a problem with the "End turn" button - I already had to use an abbreviation for "End scenario" in my translation. The new button gives me even less space. The text I would fit in a perfect world would be "Cnàmh-sgeul deiseil". That's a wee bit longer than the English string

So, we will have to lose the decoration - no space available.


Regarding color blindness, maybe this site will come in handy: http://colorfilter.wickline.org/
It lets you view a webpage as if you were suffering from color blindness and it has settings for a while range of impairments.

For example, this is what the current state of the icons looks like with the greyscale filter http://colorfilter.wickline.org/?a=1;r= ... D62167;t=m

[doofus-01]

... I'm bit worried about the issue with those ability icons creating a rift between "mainline" and "UMC" abilities (as I understand it I'll have to make icons for my custom abilities myself, right?)...

We will have some extra icons for user made custom abilities/traits/weapon specials/unit statuses...
Those can be used by UMC designers if they lack of proper artwork.

Still, if an addon makes heavy use of custom features, the designer can enforce the usage of the classic, mostly text based theme.

This has sort of been addressed, but a question I still have is: What effect will this have on ThemeWML? Would it still be possible for a campaign author to specify a right-hand side status panel that does what the current one does (shows "race", "image_icon", text)? I get that there will be a text/classic theme available, but depending upon how hard-coded(? - not WML accessible) this new one is, that could mean different things.

[fabi]

This has sort of been addressed, but a question I still have is: What effect will this have on ThemeWML?

I have extended the features of ThemeWML by a few new ones.
The [menu] tag which was used for both, menus and buttons, got split in two introducing a new [action] one.
Both tags now support an overlay attribute for putting icons on the buttons.

A new [slider] tag can be used to put sliders into the themes, currently it supports only zooming,
a more generic usable implementation will follow.

The wml reference wiki is not yet updated, I will do so when the implementation is final and the syntax won't change anymore.

Would it still be possible for a campaign author to specify a right-hand side status panel that does what the current one does (shows "race", "image_icon", text)?

UMC designers will still be able to define their own themes.

I get that there will be a text/classic theme available, but depending upon how hard-coded(? - not WML accessible) this new one is, that could mean different things.

The new theme and the classic one are using ThemeWML like ever, thus there won't change much in this regard.

[beetlenaut]

I regards to the zoom slider, can we get a snap point at exactly 400%? When the pixels in the .png images correspond to 4 screen pixels, the images should be sharp once again. This is nice for large, hi-res monitors. (In fact, it would be nice if the interface could be doubled as well.)

[fabi]

I regards to the zoom slider, can we get a snap point at exactly 400%? When the pixels in the .png images correspond to 4 screen pixels, the images should be sharp once again. This is nice for large, hi-res monitors.

Shouldn't that be 200%?
Anyway, I got your point. The slider does not support snap points. But I will see if I can do something...

(In fact, it would be nice if the interface could be doubled as well.)

LordBob already drew most of the gui widgets in double size for implementing high resolution support later.

[Urs]

Hey guys,

It's been a while since I've posted here last. I played a bit recently (really impressed with how far the game has come!) and decided to check the forums - this seemed interesting.

I don't know how much progress has happened on this behind the scenes, but the mockup posted a few pages back seemed pretty interesting, and since this thread seems to have become pretty quiet since June, I decided to take a swing at what I could make this look like. It's pretty rough, and steals heavily from the mockup. There are a couple of things that I know don't look too great right now - this was kind of a hack job. If there's interest, I could continue working on it.

I took a less "realistic" textured approach and a simplistic one - using some subtle noise rather than wood/rocks/paper. My reasoning was that those kinds of effects tend to always look a bit off; the representation clashes with what it actually is, i.e. pixels on a glowing screen. As such, I tried to strike a balance between the mood of the game (fantasy setting, pixel art graphics) and the medium (modern, Hi-Res computers).

[LordBob]

Unfortunately we've all had other priorities and less available time, so the in-depth UI renovation is currently on hold (I'm not giving up, though). Instead, we will begin with a facelift to the classic theme in 1.12, so that the UI of the game is at least consistent with that of the editor.

In that purpose, I've attached a project of a renovated end turn button. It's considerably larger than the existing one and in a different style so that it stands out more.