Nailing down the Build Menu

[keith.lamothe]

In terms of changing the button color, telling Unity "use button X instead of button Y" is fine.

Good news, we can easily change the colors of both text and images during runtime.

Wish list: I'd overall like to be able to have more direct control of the UI from within the C# only (for example, I'd like to have the Game Start screen able to dynamically add some drop downs/buttons depending on the currently selected map type. So if someone wanted a "clusters-mini" map then they could say "I want fewer, larger clusters" or "I want lots of small clusters". But if they selected a different map type then they get a different set of buttons/drop downs. The ButtonSet is almost good enough, but it would be nice to have a button/drop down/text box set too. ).

I'm not sure how doable that will be, but I can bear it in mind.

0.508 isn't out yet, but here's the current state of the build and tech menus.

[x4000]

Okay, that's out now.

[Cyborg]

Are there no words to represent what you are buying?

[BadgerBadger]

In theory hovering the cursor over the item you are interested in will show you hovertext. In practice it doesn't seem to work right now though.

Otherwise, this is a really nice improvement. I'll try to get a chance to use it more tomorrow/over the weekend so I can give better feedback.

[keith.lamothe]

Build Queue in AI War classic was exceptionally ugly (imo) but I think doing it like that doesn't exactly hurt the GUI, as long as everything has a nice look. And white icons are not a nice look (imo)

What would you suggest instead of white icons?

I know, we'll use plaid icons!

(That UI work affected me more than I realized)

[eRe4s3r]

Build Queue in AI War classic was exceptionally ugly (imo) but I think doing it like that doesn't exactly hurt the GUI, as long as everything has a nice look. And white icons are not a nice look (imo)

What would you suggest instead of white icons?

I know, we'll use plaid icons!

(That UI work affected me more than I realized)

Never ask an artist what he thinks about GUI art Especially not if YOU are the one who's gotta actually create it, hehe.

White icons look really out of place imo, they need... some kind of texture and color adaption, here I just up-blended the original AI war fighter sprite and in the process made the build icon a bit smaller, I know you can't use terminal font, so that's probably not possible anyway (the size that is) but it also takes into account something Cyborg said.

That said, I don't think putting the name in the button is gonna work for everything so well ;P

Ps.: Just to re-iterate, that size and font isn't what I am suggestion you use, it's just.. a style example, not a literal graphics asset.

PPs.: In true redneck artist fashion, I was too lazy to copy out your original white sprite so I lifted the AI War classic one (which was way faster, btw..) anyhows.. if turning them on the side ain't an option, removing the text and making them fit into a very defined area of the button would still work. But they'd need to become smaller and gain somehow at least SOME texture on their surface? Maybe...

[Cyborg]

I'm only thinking that I'm not going to remember the silhouettes of how many ships for a good long while. Wherever you put the overlay is fine. I understand if it's not going to fit on the sprite.

[keith.lamothe]

Never ask an artist what he thinks about GUI art Especially not if YOU are the one who's gotta actually create it, hehe.

If I were the one doing it I wouldn't mind, but that's Chris and Blue, and I don't think Chris is going to go in for a new icon art style, because if the build menu shows icons like that then the icons on the sidebar and (most importantly) in the game view itself have to be at least recognizably the same thing.

Anyway, your point is that no color shift is going to make those icons look good to you, there would also need to be changes to the image to have more texture?

Is it possible to add texture to the existing icons?

They're accessible in each steam install (with default path that's "C:\Program Files (x86)\Steam\steamapps\common\AI War 2\AIW2ModdingAndGUI\Assets\Icons\OfficialGUI\GUIShipsWhite\*.png") , to apply the changes you have to run the unity editor and load the AIW2ModdingAndGUI\ folder, then do Arcen -> Save All Assets and then Arcen -> Build Windows Asset Bundle (or whichever one applies on your platform).

Iirc you're staying out of the testing until it's more mature so you might not have an install. So I've attached the Fighter.png from my steam install.

I'm quite willing to make changes, but it has to work within the framework of what we have to some extent.

On the placement of the name, I think that's going to be tooltip-only to avoid excessive busy-ness, but I'll consider alternatives. Possibly each column has a button at the bottom with the name of that type (so Fighter, once, for the column of buttons, instead of MkI Fighter, MkII Fighter, etc on each button).

[eRe4s3r]

To be speaking plainly, I just think the icons are 25% too large for build menu and  50% to 60% too large for the sidebar to be pretty ( These 2 things should have ever so slightly different icons..) That's just from doing a bit of dirty icon shuffling to see how many of those would fit on the sidebar if you didn't stack them infinitely but only at 5:1 or 10:1 so as to still allow a hover-over function to display HP of each ship (and allow us to click on a specific one) the result is.. well, not good for readability.

You could do all of this of course, but texture.. well, I guess my suggestion was more along the lines of the button style itself, a white sprite is by definition not exactly pleasant to the eyes when you got a dark background.

But really, a 25% downscale of the icon would make the build menu a ton more readable. For sidebar I totally agree that icons should be flat, but never white. (The icons in sidebar should probably be player-color?)

*Ignore the AI War 1 sprite merging, I kinda forgot how I did that in the previous button.... probably shouldn't play Factorio while I do graphics lazily aside

And 3 more things
1) A color shift WOULD make the icons look better to me, but the primary problem is that they don't fit the button (which is kinda pretty) I dunno how you do the icon scaling when resolutions go higher or lower, but if that scaling doesn't contain the icons within a very specific ratio then the buttons gonna look super wonky.

2) Yeah, I will not play until the game is mature. First impressions are only first impression when they are the first impression...

3) Is it absolutely 100% necessary to have the (ship) sprites facing north? Is it just me or does facing east look automatically better? Well, it must be me.... probably.

Either way, hope that Wall of Text made any sense.

When it comes down to it, I just don't find the current GUI visually pleasing. But that is easy to say and really hard to quantify in detail.

Ps.: I went overboard with all those features to exemplify them, a real icon would be ever so slightly affected by this, anyhow, I just wanted to point out 1 big thing, icons become smoother to look at if you scale them down slightly. And visually, a right facing fighter looks better than an upwards facing fighter. Don't put too much stock otherwise into this mockup..

PPs.: I'd really like for way more feedback regarding this from more people too. Maybe it's just me and you should really ignore my ramblings.

[BadgerBadger]

Here's another wall of text to go with eRe4s3r's.

I think the gui elements overscale, if that's the word. When I full screen on my 2560x1440 monitor I feel like I'm spending a huge amount of space on gui elements. The ratios make sense when my screen is smaller, but not at full screen on a large screen.

I agree with eRe4s3r that the icon colour is imperfect; right now the Bright White on blue buttons doesn't look great. Some sort of different color/gradient/texture might be nice.

I don't have an opinion on the direction that the icons are facing.

A few additional points thanks to Wombat Wombat. What's going to happen when I have 4 flagships and my ark and 2 starship constructors on various planets, and I'm trying to keep track of what is building where. I feel like we're going to need some sort of consolidated way to examine all my build Qs to keep track of what's going on (Imagine I'm defending a CPA and need to start turning off some of my build Qs so I can rebuild turrets quickly. I now need to remember where my flagships are, which planets I've left my various constructors on, and it's potentially quite tedious in a panicked moment).

When I'm in a higher level menu, do we  really need all those blank buttons at the bottom that are generally for control groups? Can we just make them vanish?

Is there a way we could give additional feedback to the user that some menu buttons (Pursue) are toggles and some open new menus? Maybe make that button look different somehow, or a different kind of button (think the difference between a radio button and a checkbox). Also I think for the Ark especially, Pursue is a fundamentally different sort of "Thing" than "Build/Hacking/Warhead", so it would be nice to have it be differentiated somehow (and the missing scrap button looks weird; there's this random space between "Pursue" and "Build" that looks weird).

Should "Warhead" actually be placed under the "Build" menu? You are building them after all. Or maybe we should have distinct "Build Ships" and "Build Structures" menus to go with "Warheads".

The "I-IV" looks like "H V". Also some menus replace their names entirely with a "^" and some change their names to  from "NAME" to "^NAME". Some consistency might be nice (it would probably be better to include the name of the item along with the ^). Also the "^NAME" doesn't really stand out. You could perhaps turn ^NAME into "^ NAME ^" (note the space next to the ^), or perhaps also change the text colour, or something.

In the "Game Start Screen" the toggles are labelled "[On/Off] Thing". The other toggle in the game (Pursue) is labelled "Pursue: On/Off". Can we make this more consistent?

Also, the blue outline around the TextBox for the Seed (in the game select screen) might make another really useful way to call out selection. Some people (Wombat) don't like the orange highlighting currently used for hovering a button (it is kinda competing with the information on the button itself, though it does look nifty), and suggest using that outline instead. At the very least, I feel like that's a useful graphical element that's currently only used once and it might be handy.

I'm not sure how many of these ideas will no longer be relevant once some beautifying is done to the GUI, but I give it in the hopes that it is useful.

[keith.lamothe]

I think the gui elements overscale, if that's the word. When I full screen on my 2560x1440 monitor I feel like I'm spending a huge amount of space on gui elements. The ratios make sense when my screen is smaller, but not at full screen on a large screen.

To be clear, are you saying that the elements literally overscale in the sense of taking up a larger % of screen space on larger resolutions? Or simply that maintaining the % as resolution increases is excessive?

The goal I understood from Chris regarding resolutions is that it should be possible to:
- take a screenshot at resolution AxB
- take a screenshot of the same exact situation at resolution CxD, where C=A*2 and D=B*2
- use gimp or whatever to re-scale the second image to AxB
- the first image and the second image are now visually identical

What I think I'm hearing is that this is not necessarily desirable.

Sometimes it is, though, I'm guessing. Is the key factor the dpi of the screen?

Perhaps I just need to add some debug functions for increasing/decreasing the UI scale, so we can experiment. It may be a bit tricky to get looking correct.

I agree with eRe4s3r that the icon colour is imperfect; right now the Bright White on blue buttons doesn't look great. Some sort of different color/gradient/texture might be nice.

I'm happy to change it, I just want to make sure we're doing a reasonable change, in terms of work-required vs benefit.

What's going to happen when I have 4 flagships and my ark and 2 starship constructors on various planets, and I'm trying to keep track of what is building where. I feel like we're going to need some sort of consolidated way to examine all my build Qs to keep track of what's going on (Imagine I'm defending a CPA and need to start turning off some of my build Qs so I can rebuild turrets quickly. I now need to remember where my flagships are, which planets I've left my various constructors on, and it's potentially quite tedious in a panicked moment).

I'd like to extend the sidebar to have an econ tab with an expandable outline of all your metal flows, or at least all your construction metal flows, with each flow and group being toggleable in the outliner itself.

So:
Metal (-120/sec) (-)
> Extractors (4) (+414/second) (+)
> Construction (7) (-534/second) (toggle) (+)

And if you click the Construction + that part becomes :
Construction (23) (toggle) (-)
> Ark Queue (1) (toggle) (+)
> Space Dock Queues (2) (toggle) (+)
> Starship Constructor Queues (1) (toggle) (+)
> Turrets (19) (toggle) (+)

And if you click the Turret + that part becomes:
Turrets (19) (toggle) (-)
> Planet A (9) (toggle) (+)
> Planet B (6) (toggle) (+)
> Planet C (4) (toggle) (+)

And maybe even have the planet's + expand a list of specific turret types. Obviously there's a limit to how many different sub-trees you could have expanded before the vertical space got silly, but I've seen this sort of interface element in other games and (while it can take a while to learn to use properly) it can be a wonderful power-tool. I've just got to figure out how to do very fine-grain multi-part UI mousehandling, in addition the fine-grain UI display I've been working on for the new ship-detail-display (i.e. unit tooltip) for the next version.

When I'm in a higher level menu, do we  really need all those blank buttons at the bottom that are generally for control groups? Can we just make them vanish?

We could.

Is there a way we could give additional feedback to the user that some menu buttons (Pursue) are toggles and some open new menus? Maybe make that button look different somehow, or a different kind of button (think the difference between a radio button and a checkbox).

That would be good, yes.

(and the missing scrap button looks weird; there's this random space between "Pursue" and "Build" that looks weird).

Yea, it's a matter of wanting the number for build to be the same for a scrap-able and a non-scrap-able constructor. I could have the buttons "collapse" the hole and keep their numbering as if all the buttons were there, but will that work right? Probably a job for a settings toggle.

Should "Warhead" actually be placed under the "Build" menu? You are building them after all.

You're not actually building them, your Ark starts with a fixed number of each type and clicking the button for a warhead type simply "launches" the warhead out of the ark so you can give it direct orders. So you don't build more; if you want more you have to get them from AI silos.

The "I-IV" looks like "H V".

Renamed to Fleet for next version, since it includes Mark V if you have it anyway.

Also some menus replace their names entirely with a "^" and some change their names to  from "NAME" to "^NAME". Some consistency might be nice (it would probably be better to include the name of the item along with the ^). Also the "^NAME" doesn't really stand out. You could perhaps turn ^NAME into "^ NAME ^" (note the space next to the ^), or perhaps also change the text colour, or something.

Yea, the ^ bit is very placeholdery so I don't know what to do with it. Presumably it should be a different button background that has a shape which makes the "up"-ness obvious. Or it could be shaped like a literal tab, with the stuff above it fitting in a panel that looks like it's an extension of that tab (with the other tabs being "under"), though that's more involved.

In the "Game Start Screen" the toggles are labelled "[On/Off] Thing". The other toggle in the game (Pursue) is labelled "Pursue: On/Off". Can we make this more consistent?

Sure, which way do we go? "[Off] Pursue" and "[On] Start with first planet", etc? Would icons be better? If so, what should the icons picture? CheckedBox/EmptyBox-style toggle, etc?

Also, the blue outline around the TextBox for the Seed (in the game select screen) might make another really useful way to call out selection. Some people (Wombat) don't like the orange highlighting currently used for hovering a button (it is kinda competing with the information on the button itself, though it does look nifty), and suggest using that outline instead. At the very least, I feel like that's a useful graphical element that's currently only used once and it might be handy.

I'm not sure how that one works and how baked into unity (or the text-mesh-pro library or whatever it is, which Unity decided at some point to bake in) it is, but I'll bear that in mind.

I'm not sure how many of these ideas will no longer be relevant once some beautifying is done to the GUI, but I give it in the hopes that it is useful.

Sure, no problem. I don't know what will apply and what won't, but I'd much rather hear stuff than not hear stuff

[x4000]

I think the gui elements overscale, if that's the word. When I full screen on my 2560x1440 monitor I feel like I'm spending a huge amount of space on gui elements. The ratios make sense when my screen is smaller, but not at full screen on a large screen.

To be clear, are you saying that the elements literally overscale in the sense of taking up a larger % of screen space on larger resolutions? Or simply that maintaining the % as resolution increases is excessive?

The goal I understood from Chris regarding resolutions is that it should be possible to:
- take a screenshot at resolution AxB
- take a screenshot of the same exact situation at resolution CxD, where C=A*2 and D=B*2
- use gimp or whatever to re-scale the second image to AxB
- the first image and the second image are now visually identical

What I think I'm hearing is that this is not necessarily desirable.

Sometimes it is, though, I'm guessing. Is the key factor the dpi of the screen?

Perhaps I just need to add some debug functions for increasing/decreasing the UI scale, so we can experiment. It may be a bit tricky to get looking correct.

This is what I requested, yes -- or at least part of it.  As a baseline, this is 100% the desired functionality, because people CONSTANTLY complain that they can't use their native screen resolution on an LCD display and actually read the text.  That's the issue that takes precedence in the modern world, given the plethora of differing DPIs that are increasingly flooding the market.

---

The secondary issue is "what if I have a giant monitor, and therefore my DPI is lower relative to the visual surface area I'm looking at?"  Aka you have a bigger screen to go WITH your bigger resolution.  There's literally no way for a program to know if that's the case, because monitor sizes are not reported by the OS in any meaningful way.  There are things that say if it's a high DPI display, but then you have people who are able to artificially zoom their screens using OS settings, etc.  So there's no way to basically get an actual deterministic "this number of pixels equals this number of inches."

...and even if there WERE, there's the problem that eyesight differs between people, as does the clarity and contrast of monitors, as does the distance they sit from their monitor.  So even if we could work out how many inches it takes up, there would be absolutely no way for us to know what "feels right" to anyone.

And that's where the concept of "resolution scaling" comes in for the GUI.  Basically in those situations the GUI should be treated as if the screen is smaller, and thus it winds up scaling down and taking up less of the available real estate.  But the main game view isn't altered.  For someone with a mega-sized screen at a non-dense DPI, this is what they'd be looking for.

We added that sort of functionality in a couple of our games, I think SBR mainly.  I can't remember for sure. 

---

At any rate, once the resolution-independence issue is solved (which I think it is?), then the issue of letting players have a slider that says "pretend you're shooting for 75% of the usual size for the GUI compared to whatever it would normally be at this resolution."  That should be a single number that we can plug into our math somewhere deep down in the GUI scaling code, and it would "just work."  In theory.   We HAVE done it before, but I haven't seen this code.

My assumption previously was that if we got the resolution-independence going, then this second part would come pretty easily.  We talked about this waaaaaay back in the day, and it was in the original specs, but then in the revised specs that started talking about window arrangements I didn't re-include these in the notes there.

At any rate, hopefully this is just a multiplier that can go in gamesettings and that then gets applied to two numbers centrally and everything just magically does what it is supposed to.  Fingers crossed?

[Wanderer]

You three gents will be able to figure the answer faster than I, but I want to interject with a side issue to the UI, and for it's example, I want to use Factorio.

So, Factorio, in full screen native, has NO problems with the UI.  However, I record my YT vids in 1080x720 for post-production simplicity because my full screen is non-standard.  This creates really weird overlap issues in the UI, particularly with the sidebar helptext that is presented when highlighting.  No, I have no idea if this is even a concern in AIW2, but I'll drop an img below to present the problem.  I'm really looking forward to YT'ing your stuff (no, I haven't read your license yet but I figure we can talk if I'm concerned) but I'd like to avoid this for AIW2.  Obviously I haven't played yet but if you can keep this in mind when adjusting UI components, this would help those like myself tremendously.  I don't know if it's a problem, but if it can be avoided, ROCK!...

The screen in general:


The problem area, lower right corner:


The biggest problem for me, from a presenter's point of view, is the underlapping of something I'm trying to 'at the moment' present beneath something I can see 'whenever', and take a different moment to see/show.  The reason I decided to bring it up here was because it seems like it could go into a deep resizing/hardware vs. settings discussion, and this has been a particular frustration of mine.

[keith.lamothe]

This creates really weird overlap issues in the UI, particularly with the sidebar helptext that is presented when highlighting.  No, I have no idea if this is even a concern in AIW2, but I'll drop an img below to present the problem.

It's a good thing to bring up. I don't think we're likely to have that problem because the UI sizing is based primarily on percentages of window width/height rather than pixels or whatever. So in the factorio example if they had set the sidebar to take 80% height (from the top) and the doohickey in the bottom-right to take 20% height (either from the bottom, or fixed under the sidebar) then they'd never have more overlap at different resolutions.

Our approach has its own problems, of course.

1) When you increase your resolution you don't actually get more "room" in your UI. The buttons and whatnot just expand to fill the same % of screen space that they did at the lower resolution. For some players this is desirable (because they don't read Smurf), but for others they specifically want to be able to either show a lot more information without element overlap, or they just want a smaller UI that lets them see the game area better.

2) Aspect ratios. Some elements are designed to look good at one aspect ratio and look odd or downright awful at different ratios. Icons, for example, get stretched along the X or Y axis in a very unflattering way when the width or height of the screen changes without the other one changing (so 5% of width is suddenly different, but 5% of height is the same, and now the thing is stretched horizontally).

#1 thankfully has a solution that is straightforward conceptually, which is to give the player a way to scale the UI up or down. This is what Chris was talking about a moment ago, and it's basically the approach we'll be taking. It's not straightforward in practice because the straightforward implementation leaves you with a UI that's correct in the upper-left of the screen but either runs off the right and bottom edges (if the ui is scaled up) or the bottom-right "corner" of the ui is actually somewhere in the middle of the screen (if the ui is scaled down). Or if you've laid out your UI relative to screen-center then you have your UI kind of camping out in the middle of the screen.

So each element has to have it's own particular anchoring rules so that it gracefully handles a situation when "100% != 100%" (computers are never gracious when you tell them things like that). Thankfully a fairly robust set of anchoring rules was recently implemented for our "windows" (element groups), so it's just a matter of trying the scaling, seeing what breaks, and fixing it. The "seeing what breaks and fixing it" is the "It may be a bit tricky to get looking correct" I referred to earlier.

#2 is mainly solved by not solving it: instead of maintaining the specified % sizes, we just pick an axis to maintain % on and change the other axis to maintain the aspect ratio. This means that if you change your resolution without changing the aspect ratio then you'll still have the "I can take a screenshot, rescale it, and it looks exactly like the same screenshot in the previous resolution" behavior. But if you change your aspect ratio you won't have that, so that the icons don't look awful. That said, you'd probably have to be looking for it to see the difference in the screenshot-rescale test, unless you took the two shots at wildly different aspect ratios.

[Wanderer]

#1 thankfully has a solution that is straightforward conceptually, which is to give the player a way to scale the UI up or down. This is what Chris was talking about a moment ago, and it's basically the approach we'll be taking.  *Snip*...

So each element has to have it's own particular anchoring rules so that it gracefully handles a situation when "100% != 100%" (computers are never gracious when you tell them things like that). Thankfully a fairly robust set of anchoring rules was recently implemented for our "windows" (element groups), so it's just a matter of trying the scaling, seeing what breaks, and fixing it. The "seeing what breaks and fixing it" is the "It may be a bit tricky to get looking correct" I referred to earlier.

Nice work, that's great to hear!