in-scenario panel layout mockups
Moderator: Forum Moderators
Forum rules
Before posting critique in this forum, you must read the following thread:
Before posting critique in this forum, you must read the following thread:
-
Blarumyrran
- Art Contributor
- Posts: 1700
- Joined: December 7th, 2006, 8:08 pm
in-scenario panel layout mockups
in-scenario panel layout mockups & thoughts. Click on images for zoom.
~500 kB
~300 kB
I removed:
"race", because it has no gameplay relevance and is mostly obvious from unit image, unittype name and unitinstance random name.
I added/changed:
a lot of things. Among others:
* turn order could very well be on the right panel - I've often heard "who goes next" from people who don't know about Status Table, and there is no reason why something as simple & important as this shouldn't be visible without entering any menus.
* Location of Mouseover-selected hex on the minimap should be hilighted
* Location of Info-selected unit on the minimap should be hilighted
* The time-of-day and terrain type of the mouseover-selected hex, and of the hex under the info-selected unit, could be shown immersively, as an image where the ground is determined by the terrain type (semitransparent image overlayed on the ToD image), and the sky is shown as a ToD image behind it. They could be animated; making eg an animation of semitransparent clouds slowly rolling would be trivial.
* the top bar currently has icons and values intermittently. This is bad; there should be blocks of the same type of information. So I arranged them in rows below each other instead. Arranging them like that also has the benefit that it looks like subtraction-done-in-rows - immediately explaining what the relation between the numbers is!
~500 kB
Spoiler:
Spoiler:
"race", because it has no gameplay relevance and is mostly obvious from unit image, unittype name and unitinstance random name.
I added/changed:
a lot of things. Among others:
* turn order could very well be on the right panel - I've often heard "who goes next" from people who don't know about Status Table, and there is no reason why something as simple & important as this shouldn't be visible without entering any menus.
* Location of Mouseover-selected hex on the minimap should be hilighted
* Location of Info-selected unit on the minimap should be hilighted
* The time-of-day and terrain type of the mouseover-selected hex, and of the hex under the info-selected unit, could be shown immersively, as an image where the ground is determined by the terrain type (semitransparent image overlayed on the ToD image), and the sky is shown as a ToD image behind it. They could be animated; making eg an animation of semitransparent clouds slowly rolling would be trivial.
* the top bar currently has icons and values intermittently. This is bad; there should be blocks of the same type of information. So I arranged them in rows below each other instead. Arranging them like that also has the benefit that it looks like subtraction-done-in-rows - immediately explaining what the relation between the numbers is!
Re: in-scenario panel layout mockups
Am I allowed to say this is awesome and more intuitive than GUI used now?
Highlights:
>ToD with terrain type is neat idea, since some maps feature different schedules for different areas (partial caves and so on), and abilities like Illuminate can create such situations on all maps - and looking at ToD display as bit counter-intutive. Showing movecost seems good idea too, not too sure about need for terrain defence (it is already shown when you have unit selected and hover mouse over any hex which is not enemy unit... Although in this rare situation it might have use.)
>New economy display - certainly works way better than old one, and is easier for newbie to understand.
Basically, this looks like display for turn-based strategy with fantasy theme, and reduces copious amounts of text seen in the current one.
Highlights:
>ToD with terrain type is neat idea, since some maps feature different schedules for different areas (partial caves and so on), and abilities like Illuminate can create such situations on all maps - and looking at ToD display as bit counter-intutive. Showing movecost seems good idea too, not too sure about need for terrain defence (it is already shown when you have unit selected and hover mouse over any hex which is not enemy unit... Although in this rare situation it might have use.)
>New economy display - certainly works way better than old one, and is easier for newbie to understand.
Basically, this looks like display for turn-based strategy with fantasy theme, and reduces copious amounts of text seen in the current one.
Artist, writer, game designer for hire.
Art portfolio: https://shino1.artstation.com
Writing dump: https://shino1portfolio.wordpress.com/
My itchio for video games and TTRPG stuff: https://shino1.itch.io/
Art portfolio: https://shino1.artstation.com
Writing dump: https://shino1portfolio.wordpress.com/
My itchio for video games and TTRPG stuff: https://shino1.itch.io/
-
Blarumyrran
- Art Contributor
- Posts: 1700
- Joined: December 7th, 2006, 8:08 pm
Re: in-scenario panel layout mockups
(quick recap: the colored dots on the mock-ups represent icons, such as those made by Melon, with small & standardized size)
This entire idea relies heavily on changing short ability identifiers (in the right panel) from strings to icons, because a layout with lots of unpredictable strings is always dangerous and unorganizable: taking a very safe line on preventing border-cases of renderings of various strings would prohibit many great ways of organization of layout. Perhaps even more importantly, string renderings almost always take up a lot more space than icons. I've been told that some do not wish this, but - I'd think it is the most obvious thing that needs to be done! So here goes a reasoning.
* * *
Short identifiers do not properly describe what the ability (or other value) actually does gameplay-wise, neither as strings nor icons. The description can be accessed mainly through tool-tips, by moving the mouse over the identifier. Changing short ability identifiers from strings to icons wouldn't be making abilities "non-verbal" and wouldn't hamper people from referring to abilities (players can't easily refer to abilities by icons when they have to use language, so this is important); this would be changing the "ability-name-short-string -> long-tool-tip-explanation" model with "icon -> (ability-name-short-string, long-tool-tip-explanation)"; the verbal identifier of the ability would be put into the tool-tip, next to the description.
Changing short identifiers from strings to icons is good in many ways:
* Icons take up many times less space than renderings of strings! Every pixel on the screen should offer the player as much prettiness and as much useful information as possible. The default thing a pixel of the in-scenario ui should do is to be transparent so as to display as much of the terrain as possible; terrain itself offers both useful information & prettiness.
* To properly parse a rendering of a string, the player must read through a number of symbols (letters). But if the player is familiar with an icon, he must only parse a single symbol.
* The (non-number) string that is an ability's name may have very different shapes in different translations. The string "leadership" of en_US is "vada" in lv_LV; a rendering of the former is both taller and wider than a rendering of the latter. Between languages with different alphabets, the differences of total shapes of renderings of strings can be even greater. It is not feasible to design a UI layout in such a way as to accommodate all the possible renderings of an ability's name in different translations; there are way too many translations of BfW to have a good overlook of them, and they are in constant flux, and their number is in constant flux. A rendering of the same x*y image in both en_US and lv_LV obviously has the same dimensions in both, allowing for greater organization of layout.
* The (non-number) strings of different possible values that are placed in the same position in the layout (such as "leadership" and "cures"), may have very different shapes. "leadership" is both taller and wider than "cures", while a leadership icon has the same dimensions as a cures icon. Again, hence greater organization of layout. Standardized dimensions for identifiers allows them to be placed easily in rows and columns, for much greater legibility.
* Icons are prettier.
* If a translation is partial, it leaves a very bad, inconsistent feel if it has translated & untranslated strings within the same panel/dialog/etc. With icons, the awfulness of partial translation is hidden one level away, into the tool-tips.
* * *
Some people think changing short identifiers from strings to icons is bad because:
for a player new to the game, an association between the gameplay-wise meaning of an ability(or income, level, xp, etc) and its identifier becomes clear faster if that identifier is a string rather than an icon - because for about all common concepts, there are some commonly known ways of phrasing it verbally, but there are not always simple images that would be commonly known to represent it. Eg for the leadership ability, there is the word "leadership" and the image of a flag, and both are somewhat easily memorizable as representing the concept of leadership because they are associated with such in many contexts in the real world; but for the teleport ability, there is the word "teleport" but no immediately recognizable image - you could draw some arrows or magical stars or humans with shiny outlines or whatnot, but learning the association between a particular kind of magical stars and the concept of teleportation will take effort from a new player. <- I think this reasoning is not nearly enough to justify not iconifying strings; the reasons brought above have more weight in total. How quickly & effortlessly a newbie learns a new icon depends a lot on all kinds of other context around the icon. Here's a look at the kinds of icons that there are in my mockup:
* Icons that represent the meaning of a single numerical value:
Gold, bruto income, upkeep, net income, level, amla count, hp, xp, movement points, defense %, 6*resistance types, village count, unit count, defense % of info-selected unit on the terrain of mouse-over hex, movecost of info-selected unit on the terrain of mouse-over hex.
Some of these are already represented by icons (eg income); also they are always in the same location on the panels, and the location adds a lot of context (eg hp & xp are very often coupled); similar kinds of statistics can be grouped together. Also they often represent very simple concepts (eg how many villages you control; not how, if you do something with your unit in a certain way then something that is not emergent from general gameplay rules will happen, as would be the case with abilities). So these won't demand real effort from newbies to learn to recognize them. So making all of them into icons should be uncontroversial.
* Other icons.
* ToD alignments: lawful, neutral, chaotic; in utbs I think there were more of them, but such are very rare, even in umc. As there are only 3 such alignments, and they are always on the same spot on the panels, and they have very easily reocgnizable images to them (sun, moon). So making them into icons should be uncontroversial.
* Traits. A newbie doesn't really need to know about traits (most of the effects of a trait, except "healthy" & "loyal", modify stats, so the trait icon of a unit should usually have little value to someone who doesn't know what the "default" stats of the unit are). Because they are relatively unimportant, iconizing them won't demand newbies to remember their icons, so making all of them into icons should be uncontroversial. However perhaps the UI should emphasize that they are sort of unimportant compared to eg abilities and statuses and alignment; maybe trait icons should be smaller.
* Statuses (poisoned/stoned/etc). They are already icons!
* Weapon ranges. In all of mainline content, and in the overwhelming majority of umc, there are only 2 ranges: melee & ranged. Also the weapon name usually suggests whether it is melee or ranged, so it should be very easy to associate. So making them into icons should be uncontroversial.
* Weapon damage types. These could be represented by the same icons as resistances in the resistances table.
This leaves us with:
* Unit abilities,
* Weapon abilities.
Of these 2, there are very many different kinds, and campaigns and umc often create new ones, and if a newbie has a unit with abilities, unlike traits it is important for him to recognize it by its icon. Also abilities are often much more complex by concept than eg how much gold you have. So there might be some trouble with a newbie associating them correctly with their icons.
However it is largely the matter of introducing new abilities slowly in general! If the tutorial & newbie campaigns introduce new abilities very slowly, which they should do in any case, this shouldn't be a real problem.
* * *
With that I think it is clear that we should iconize almost all keywords in the right panel.
This entire idea relies heavily on changing short ability identifiers (in the right panel) from strings to icons, because a layout with lots of unpredictable strings is always dangerous and unorganizable: taking a very safe line on preventing border-cases of renderings of various strings would prohibit many great ways of organization of layout. Perhaps even more importantly, string renderings almost always take up a lot more space than icons. I've been told that some do not wish this, but - I'd think it is the most obvious thing that needs to be done! So here goes a reasoning.
* * *
Short identifiers do not properly describe what the ability (or other value) actually does gameplay-wise, neither as strings nor icons. The description can be accessed mainly through tool-tips, by moving the mouse over the identifier. Changing short ability identifiers from strings to icons wouldn't be making abilities "non-verbal" and wouldn't hamper people from referring to abilities (players can't easily refer to abilities by icons when they have to use language, so this is important); this would be changing the "ability-name-short-string -> long-tool-tip-explanation" model with "icon -> (ability-name-short-string, long-tool-tip-explanation)"; the verbal identifier of the ability would be put into the tool-tip, next to the description.
Changing short identifiers from strings to icons is good in many ways:
* Icons take up many times less space than renderings of strings! Every pixel on the screen should offer the player as much prettiness and as much useful information as possible. The default thing a pixel of the in-scenario ui should do is to be transparent so as to display as much of the terrain as possible; terrain itself offers both useful information & prettiness.
* To properly parse a rendering of a string, the player must read through a number of symbols (letters). But if the player is familiar with an icon, he must only parse a single symbol.
* The (non-number) string that is an ability's name may have very different shapes in different translations. The string "leadership" of en_US is "vada" in lv_LV; a rendering of the former is both taller and wider than a rendering of the latter. Between languages with different alphabets, the differences of total shapes of renderings of strings can be even greater. It is not feasible to design a UI layout in such a way as to accommodate all the possible renderings of an ability's name in different translations; there are way too many translations of BfW to have a good overlook of them, and they are in constant flux, and their number is in constant flux. A rendering of the same x*y image in both en_US and lv_LV obviously has the same dimensions in both, allowing for greater organization of layout.
* The (non-number) strings of different possible values that are placed in the same position in the layout (such as "leadership" and "cures"), may have very different shapes. "leadership" is both taller and wider than "cures", while a leadership icon has the same dimensions as a cures icon. Again, hence greater organization of layout. Standardized dimensions for identifiers allows them to be placed easily in rows and columns, for much greater legibility.
* Icons are prettier.
* If a translation is partial, it leaves a very bad, inconsistent feel if it has translated & untranslated strings within the same panel/dialog/etc. With icons, the awfulness of partial translation is hidden one level away, into the tool-tips.
* * *
Some people think changing short identifiers from strings to icons is bad because:
for a player new to the game, an association between the gameplay-wise meaning of an ability(or income, level, xp, etc) and its identifier becomes clear faster if that identifier is a string rather than an icon - because for about all common concepts, there are some commonly known ways of phrasing it verbally, but there are not always simple images that would be commonly known to represent it. Eg for the leadership ability, there is the word "leadership" and the image of a flag, and both are somewhat easily memorizable as representing the concept of leadership because they are associated with such in many contexts in the real world; but for the teleport ability, there is the word "teleport" but no immediately recognizable image - you could draw some arrows or magical stars or humans with shiny outlines or whatnot, but learning the association between a particular kind of magical stars and the concept of teleportation will take effort from a new player. <- I think this reasoning is not nearly enough to justify not iconifying strings; the reasons brought above have more weight in total. How quickly & effortlessly a newbie learns a new icon depends a lot on all kinds of other context around the icon. Here's a look at the kinds of icons that there are in my mockup:
* Icons that represent the meaning of a single numerical value:
Gold, bruto income, upkeep, net income, level, amla count, hp, xp, movement points, defense %, 6*resistance types, village count, unit count, defense % of info-selected unit on the terrain of mouse-over hex, movecost of info-selected unit on the terrain of mouse-over hex.
Some of these are already represented by icons (eg income); also they are always in the same location on the panels, and the location adds a lot of context (eg hp & xp are very often coupled); similar kinds of statistics can be grouped together. Also they often represent very simple concepts (eg how many villages you control; not how, if you do something with your unit in a certain way then something that is not emergent from general gameplay rules will happen, as would be the case with abilities). So these won't demand real effort from newbies to learn to recognize them. So making all of them into icons should be uncontroversial.
* Other icons.
* ToD alignments: lawful, neutral, chaotic; in utbs I think there were more of them, but such are very rare, even in umc. As there are only 3 such alignments, and they are always on the same spot on the panels, and they have very easily reocgnizable images to them (sun, moon). So making them into icons should be uncontroversial.
* Traits. A newbie doesn't really need to know about traits (most of the effects of a trait, except "healthy" & "loyal", modify stats, so the trait icon of a unit should usually have little value to someone who doesn't know what the "default" stats of the unit are). Because they are relatively unimportant, iconizing them won't demand newbies to remember their icons, so making all of them into icons should be uncontroversial. However perhaps the UI should emphasize that they are sort of unimportant compared to eg abilities and statuses and alignment; maybe trait icons should be smaller.
* Statuses (poisoned/stoned/etc). They are already icons!
* Weapon ranges. In all of mainline content, and in the overwhelming majority of umc, there are only 2 ranges: melee & ranged. Also the weapon name usually suggests whether it is melee or ranged, so it should be very easy to associate. So making them into icons should be uncontroversial.
* Weapon damage types. These could be represented by the same icons as resistances in the resistances table.
This leaves us with:
* Unit abilities,
* Weapon abilities.
Of these 2, there are very many different kinds, and campaigns and umc often create new ones, and if a newbie has a unit with abilities, unlike traits it is important for him to recognize it by its icon. Also abilities are often much more complex by concept than eg how much gold you have. So there might be some trouble with a newbie associating them correctly with their icons.
However it is largely the matter of introducing new abilities slowly in general! If the tutorial & newbie campaigns introduce new abilities very slowly, which they should do in any case, this shouldn't be a real problem.
* * *
With that I think it is clear that we should iconize almost all keywords in the right panel.
-
Blarumyrran
- Art Contributor
- Posts: 1700
- Joined: December 7th, 2006, 8:08 pm
Re: in-scenario panel layout mockups
Shinobody, thank you for the response,
I agree; I think I'll remove both of them actually; I mislooked something (I thought that currently the top bar states the movecost and defense% of the info-selected unit for the mouse-over hex, but instead it states (just like inside the mouse-over hex on the map) the movecost & defense% of the move-selected unit for the mouse-over hex, and if there is no move-selected unit, it only displays the coordinates, terrain visual type & terrain gameplay type. People generally get angry when something they've grown used to is removed, so I thought I'd retain those 2 numbers, but there's no reason now. It ruined the beautiful separation of info-selected unit info in the upper half of the panel and mouse-over hex info in the lower half of the panel, because it depended on both).Shinobody wrote:not too sure about need for terrain defence
Re: in-scenario panel layout mockups
I've got feeling that feedback would be bigger in Ideas section, and this also seems to belong more in there.
I mean, it is not about creating art for icons and interface elements, it's about changing way interface works...
I mean, it is not about creating art for icons and interface elements, it's about changing way interface works...
Artist, writer, game designer for hire.
Art portfolio: https://shino1.artstation.com
Writing dump: https://shino1portfolio.wordpress.com/
My itchio for video games and TTRPG stuff: https://shino1.itch.io/
Art portfolio: https://shino1.artstation.com
Writing dump: https://shino1portfolio.wordpress.com/
My itchio for video games and TTRPG stuff: https://shino1.itch.io/
Re: in-scenario panel layout mockups
For what it's worth, I support this project, looks nice and more efficient 
Jazz is not dead, it just smells funny - Frank Zappa
Current projects: Internet meme Era, The Settlers of Wesnoth
Current projects: Internet meme Era, The Settlers of Wesnoth
Re: in-scenario panel layout mockups
Just to check, users will have to create a new, unique icon for every new trait invented for user-made factions or campaigns?
Re: in-scenario panel layout mockups
Creating sprites, which are bigger and more visually important, is never a problem, despite half of add-ons having at least single new unit, and some containing multiple sprites with animations, while custom traits and abilities are much more sparse.
And of course it wouldn't happen before at least 1.12, realistically 1.14 or 1.16 (or it would be one of "milestones" for 2.0), giving people plenty of time to switch.
And of course it wouldn't happen before at least 1.12, realistically 1.14 or 1.16 (or it would be one of "milestones" for 2.0), giving people plenty of time to switch.
Artist, writer, game designer for hire.
Art portfolio: https://shino1.artstation.com
Writing dump: https://shino1portfolio.wordpress.com/
My itchio for video games and TTRPG stuff: https://shino1.itch.io/
Art portfolio: https://shino1.artstation.com
Writing dump: https://shino1portfolio.wordpress.com/
My itchio for video games and TTRPG stuff: https://shino1.itch.io/
-
beetlenaut
- Developer
- Posts: 2825
- Joined: December 8th, 2007, 3:21 am
- Location: Washington State
- Contact:
Re: in-scenario panel layout mockups
I like it a lot. I hope it is for 1.12. I wouldn't worry too much about the trait icons. We're talking about very small symbols here, so something usable could be created pretty quickly.
Campaigns: Dead Water,
The Founding of Borstep,
Secrets of the Ancients,
and WML Guide
The Founding of Borstep,
Secrets of the Ancients,
and WML Guide
Re: in-scenario panel layout mockups
Nice images, looks good.Blarumyrran wrote:in-scenario panel layout mockups & thoughts. Click on images for zoom.
~500 kB~300 kBSpoiler:Spoiler:
Please note, that the explanation text in images is hard to quote.
I would reduce the information provided as pixel art text to a minimum.
Indeed, race is one of the informations that can be beneath the top-level of the gui.I removed:
"race", because it has no gameplay relevance and is mostly obvious from unit image, unittype name and unitinstance random name.
I am not pleased with the removal of the topbar.I added/changed:
a lot of things. Among others:
* turn order could very well be on the right panel - I've often heard "who goes next" from people who don't know about Status Table, and there is no reason why something as simple & important as this shouldn't be visible without entering any menus.
* Location of Mouseover-selected hex on the minimap should be hilighted
* Location of Info-selected unit on the minimap should be hilighted
* The time-of-day and terrain type of the mouseover-selected hex, and of the hex under the info-selected unit, could be shown immersively, as an image where the ground is determined by the terrain type (semitransparent image overlayed on the ToD image), and the sky is shown as a ToD image behind it. They could be animated; making eg an animation of semitransparent clouds slowly rolling would be trivial.
* the top bar currently has icons and values intermittently. This is bad; there should be blocks of the same type of information. So I arranged them in rows below each other instead. Arranging them like that also has the benefit that it looks like subtraction-done-in-rows - immediately explaining what the relation between the numbers is!
First, I like how it sorts side specific informations away from the rest.
Second, there is not that much room to waste in the sidebar.
The general problem with your design (or my understanding of it) is that it does not scale nor is it modular.
On small resolutions you will have problems to get all your stuff displayed, especially if you get rid of the topbar.
On large resolutions there will be a huge gape between the two boxes you defined.
That leads to the question what resolutions you want to support with your design.
Wesnoth needs to run on 800x480.
The default resolution is 1024x768. Our policy is to show the full blown gui from that resolution on.
edit:
So if we go the way to introduce several different gui for each device class and take your proposal for the PC one,
we could say that it does not need to support resolutions below 1024x768.
The 768 pixels are not much.
On the other hand, please don't let me dis-encourage you. I am all for a gui that uses more space on modern hardware.
Please consider to add the icons from images/icons/icons-resistances.png
- icons-resistances.png (1.02 KiB) Viewed 5604 times
Making everything transparent is not an idea that does have much friends in our community.Every pixel on the screen should offer the player as much prettiness and as much useful information as possible. The default thing a pixel of the in-scenario ui should do is to be transparent so as to display as much of the terrain as possible; terrain itself offers both useful information & prettiness.
While I agree that the message dialogs with the transparent portraits make a nice eye candy, I wouldn't say in general that every part of the gui should be transparent. At least not without a switch for the people who can't stand it.
Re: in-scenario panel layout mockups
I love this idea as a player I am and I think there won't be problems if when you put the mouse over the icon it appears its name. I don't know if what I say is understandble but I think it's an important point coz sometimes an image can be ambigous.
¡Salud!
¡Salud!
"I was pulling a barrow, when I saw a stalking horse
what a beautiful day!- he said- for visiting a red herring
and getting hoarse."
Working on this campaign: The septentrional tower
what a beautiful day!- he said- for visiting a red herring
and getting hoarse."
Working on this campaign: The septentrional tower
-
Drakefriend
- Posts: 436
- Joined: September 27th, 2009, 12:57 pm
- Location: Wandering from one world to another
- Contact:
Re: in-scenario panel layout mockups
I support this layout!
After far too long an absence, I have returned.
According to the quiz 100% Silver Mage (85% Archmage, 75% Shyde, 67% Flameheart and Ancient Wose,58% Assassin, Troll Warrior and Berserker). And my top score is exactly how I see myself.
According to the quiz 100% Silver Mage (85% Archmage, 75% Shyde, 67% Flameheart and Ancient Wose,58% Assassin, Troll Warrior and Berserker). And my top score is exactly how I see myself.