UI discussion
Moderator: Moderators
Re: What is the status on bar? what is left and what can the community do to help?
replace with red ui please
See https://springrts.com/wiki/Forum_Etiquette for information on how to become part of the discussions on these forums.
See https://springrts.com/wiki/Forum_Etiquette for information on how to become part of the discussions on these forums.
Re: bad ui
In all honesty, most Spring things have not-so-great UIs. I don't want to come across as overly critical here, but I think it's safe to say the majority of content creators' backgrounds in this community is more on the development/code side than the UI and design side. In fairness to OP, I do think Regret's Red UI is one of the better UIs, along with IceUI, primarily because of their simplicity and lack of clutter.
I'd love to see a Spring project hire an actual GUI designer/creator and come up with something really fancy like SC2 or DOTA 2. From the recent Spring games I've had a quick 5 minute look at, the GUIs do have a lot of clutter and an insane amount of Lua stuff going on. I kind of think that some people would like to see some games completely reduce the widgets to a minimum and increase the game's micro-management complexity and difficulty, but it's got to a point where players are so used to having widgets do things for them, that removing them would cause a lot of uproar.
I always thought about starting my own Spring game project, and I had it in mind that if it were to happen, I'd only ever include widgets that significantly add to the game's quality, instead of adding gimicky components or increasing the easiness of the game.
I'd love to see a Spring project hire an actual GUI designer/creator and come up with something really fancy like SC2 or DOTA 2. From the recent Spring games I've had a quick 5 minute look at, the GUIs do have a lot of clutter and an insane amount of Lua stuff going on. I kind of think that some people would like to see some games completely reduce the widgets to a minimum and increase the game's micro-management complexity and difficulty, but it's got to a point where players are so used to having widgets do things for them, that removing them would cause a lot of uproar.
I always thought about starting my own Spring game project, and I had it in mind that if it were to happen, I'd only ever include widgets that significantly add to the game's quality, instead of adding gimicky components or increasing the easiness of the game.
Re: bad ui
Honestly Jaz, that's just a longer version of "bad ui, replace with red ui". Equally useless to the developer.
You should be able to point out the exact things you think are wrong.
"Insane amount of Lua stuff" -> Games are written in Lua, they're expected to be Lua heavy. We're actively pushing to remove TA-isms from the engine so that's only going to increase.
You should be able to point out the exact things you think are wrong.
"Insane amount of Lua stuff" -> Games are written in Lua, they're expected to be Lua heavy. We're actively pushing to remove TA-isms from the engine so that's only going to increase.
Re: bad ui
Try to have 2 game versions: 1) with user widgets allowed and 2) without user widgets. Like fedora linux and red hat linux :-)
1) for players like me who like freedom and hates microing too much. This version of the game will give ability to improve widgets and some changes can be back-ported to the game itself
2) for serious players like you and tournaments
P.S. I don't think that UI sucks. As for me - it rocks! (esp with Floris changes)
1) for players like me who like freedom and hates microing too much. This version of the game will give ability to improve widgets and some changes can be back-ported to the game itself
2) for serious players like you and tournaments
P.S. I don't think that UI sucks. As for me - it rocks! (esp with Floris changes)
Re: bad ui
Heh, I kind of have the opposite idea in regards to micromanagement than you Jaz! I'd imagine that majority of BA players happily welcome reduction of microing when done in a non-obstructing way. Majority of the micro-reduction widgets are exactly that; Completely invisible.
What goes to the actual BAR GUI, well, I think it's actually a step in the right direction and its aesthetical value is good. After not having launched Spring for two years and comparing RedUI and BAR's GUI (what's the name of that, anyway?), I have to say that while the aforementioned is more understandable in its simplisticness, the latter does have a more charming and warm feel to it. I like it.
There are indeed a few problems with it, though:
EDIT: Oh lol, the "other numbers" in the resource box that I thought were for the whole team, are net incomes..! @_@
What goes to the actual BAR GUI, well, I think it's actually a step in the right direction and its aesthetical value is good. After not having launched Spring for two years and comparing RedUI and BAR's GUI (what's the name of that, anyway?), I have to say that while the aforementioned is more understandable in its simplisticness, the latter does have a more charming and warm feel to it. I like it.
There are indeed a few problems with it, though:
- The construction icons take a lot of space. I'm not 100% sure if splitting buildables to Economy/Battle/Factory is a particularly good idea, but I guess it's more newbie friendly that way.
- The resource box is a little confusing. Metal incomes and energy incomes are shown twice -- I guess that the other is for the whole team and the other for yourself, but there's no indication about which is which. Adding things that you "just need to remember" may not feel like much at first, but when they pile up, they do become a bit taxing to our conginition.
- The music menu, I think, could as well be under ESC menu. It's not something you would ever use in the heat of the battle.
- I think the map coordinate box could be spread a bit along its width and be lower in height.
- The orders menu's orders could maybe be grouped a bit more tightly by being presented in two or three lines of height, with closely related commands (like add/remove priority target) on the same X-axis, with such groups separated by thin lines.
- The "M/E" incomes on the big unit icons need a background. The red number in it is barely visible if your team color happens to be red.
EDIT: Oh lol, the "other numbers" in the resource box that I thought were for the whole team, are net incomes..! @_@
Last edited by tzaeru on 17 May 2015, 12:17, edited 2 times in total.
Re: bad ui
Sorry if it came across that way, I was trying to stress the clutter added by a huge amount of unnecessary client-side widgets that add nothing of great value to the game. In particular, I feel like a lot of the UIs are trying to show too much information at once, instead of having pop-up displays or sub-menus. When I get round to it, I'm gonna make a list of small changes that could be made to BAR that be big improvements to the game. Having some trouble with SpringLobby spamming errors at me and Alt-tabbing out of Spring causing the game to become windowed though.gajop wrote:Honestly Jaz, that's just a longer version of "bad ui, replace with red ui". Equally useless to the developer.
You should be able to point out the exact things you think are wrong.
"Insane amount of Lua stuff" -> Games are written in Lua, they're expected to be Lua heavy. We're actively pushing to remove TA-isms from the engine so that's only going to increase.
However, from trying BAR out just now, it's come a long way since I last tried it, especially Chili. I'm gonna try and post suggestions as tickets on the trac site instead of on here.
Re: bad ui
Exactly, and I completely understand. But by that logic, at what point do you stop automation? StarCraft could automate a lot of things for example, but it doesn't, because that would take away from competitive element that it has, not to mention the fact that it is a game that people are playing by actively pressing buttons and issuing commands. It started with innocent widgets like automating the patrolling of Nanos, but now it's come to the point where even mex placement is being automated.tzaeru wrote:Heh, I kind of have the opposite idea in regards to micromanagement than you Jaz! I'd imagine that majority of BA players happily welcome reduction of microing when done in a non-obstructing way. Majority of the micro-reduction widgets are exactly that; Completely invisible.
I think a clearer line has to be established between what is good automation and what is bad automation. I must stress that I don't object the idea of widgets automating things, just specific objections to the exact tasks that some widgets are automating.
Re: bad ui
I don't think so, it will only shift the competitive element further to macro, and unit compositions as opposed to micro and APM.that would take away from competitive element that it has
Whether that's desirable or not, is a matter of taste.
Re: bad ui
Yes, actually, this is more accurate. I suppose with such a small community, higher skill ceilings brought along by large mechanical skill requirements aren't that desirable. Looking at it from that angle, and designing the game to be more thought and decision oriented might be the more favourable option. Like you said, a matter of taste, all about what the game developers are trying to achieve.hokomoko wrote:I don't think so, it will only shift the competitive element further to macro, and unit compositions as opposed to micro and APM.that would take away from competitive element that it has
Whether that's desirable or not, is a matter of taste.
So I take back some of my points about automation brought about by widgets
Re: bad ui
I honestly don't think the level of automation is important for the discussion at this point.
This is something that can be decided upon hopefully with the feedback from the community.
Do you want to allow higher degree of automation depending on the widgets the player has, or would you rather give a default and disable user widgets? Alternatively only disable it for compos? Anyway, doesn't matter atm, imo.
What's more important is how the basic UI (build/command menus, orders, etc.) looks and works like. Are there any concerns regarding that?
This is something that can be decided upon hopefully with the feedback from the community.
Do you want to allow higher degree of automation depending on the widgets the player has, or would you rather give a default and disable user widgets? Alternatively only disable it for compos? Anyway, doesn't matter atm, imo.
What's more important is how the basic UI (build/command menus, orders, etc.) looks and works like. Are there any concerns regarding that?
Re: bad ui
Agreed. Another problem with removing automation is really that players can just manually download and enable those widgets. So it doesn't really matter that much. For the average player, I believe that the level of automation is great. Of course we can change it later on.
Mayhaps the build menu entries are still a little big, too. What does everyone think about the Factory/Economy/Battle split?..
It's in good direction. Of my points above, I think the most important change would be to move the music player to ESC menu or just disable it by default. It'll make the UI a lot cleaner already. A lot of texts seem misaligned, too, like as if they had no padding. That's something to look into as well and quite crucial, as it contributes to how "clean" the UI looks.gajop wrote:What's more important is how the basic UI (build/command menus, orders, etc.) looks and works like. Are there any concerns regarding that?
Mayhaps the build menu entries are still a little big, too. What does everyone think about the Factory/Economy/Battle split?..
Re: UI discussion
Spring has a default UI that is "good enough" so most game devs focus on gameplay and art. Projects do work on the gui parts we NEED but then get back to gameplay. The gui is kinda a "final" step. One which many projects have not reached the point of replacing already functional gui with something that is their own.
ZK was replacing all the spring stuff(They may have already). Grts was moving towards that, Evo is, BAR is, there are some other projects but you get the deal.
There is a small faction here that hates chili either because they are playing spring on machines that have or actually are the equivalent of 8-10 year old crap hardware. Or They hate on chili because they hate and I give them zero pause beyond groaning at their constant baseless and NEVER BACKED UP hatred. Why is chili bad? Overhead... anytime you have exta code running overhead happens... why is chili bad, I hate how much space the elements take up.... you can skin it you turd.
and so on..
This thread was a split off from the BAR what can the community do thread. The user created an account and posted these 2 worthless posts which could very well be little more than trolling. I don't find that these people actually give any real feedback. IT could even just be regret coming back as a smurf and baiting. Either way, it is your time if you give this stain your time.
ZK was replacing all the spring stuff(They may have already). Grts was moving towards that, Evo is, BAR is, there are some other projects but you get the deal.
There is a small faction here that hates chili either because they are playing spring on machines that have or actually are the equivalent of 8-10 year old crap hardware. Or They hate on chili because they hate and I give them zero pause beyond groaning at their constant baseless and NEVER BACKED UP hatred. Why is chili bad? Overhead... anytime you have exta code running overhead happens... why is chili bad, I hate how much space the elements take up.... you can skin it you turd.
and so on..
This thread was a split off from the BAR what can the community do thread. The user created an account and posted these 2 worthless posts which could very well be little more than trolling. I don't find that these people actually give any real feedback. IT could even just be regret coming back as a smurf and baiting. Either way, it is your time if you give this stain your time.
Re: UI discussion
Bad in-game UI is one of the problems in spring.
I was using XTA UI on my game and changed recently to red UI (same as BA)....and made a few changes (check attached image):
. added filter of build options by category : "energy/metal", "plant", "other"
. added buttons to toggle build facing and spacing
. changed many variable names from lowercase to camelCase (*)
. changed next and previous page buttons to use images instead of ascii arrows
. commented out saving and loading config due to bug
(*) couldn't resist doing this. This means if someone wants to use it they'll need the red ui framework with renamed vars, which could break compatibility with other red_ui widgets
I was using XTA UI on my game and changed recently to red UI (same as BA)....and made a few changes (check attached image):
. added filter of build options by category : "energy/metal", "plant", "other"
. added buttons to toggle build facing and spacing
. changed many variable names from lowercase to camelCase (*)
. changed next and previous page buttons to use images instead of ascii arrows
. commented out saving and loading config due to bug
(*) couldn't resist doing this. This means if someone wants to use it they'll need the red ui framework with renamed vars, which could break compatibility with other red_ui widgets
- Attachments
-
- red_ui_improved.jpg
- (292.44 KiB) Not downloaded yet
Re: UI discussion
Congrats to raaar for being the first, and only person to post a screenshot of UI, in a UI thread.
For the most part, all the talk of APM etc is not so big a deal, or widths of things. Instead nobodies mentioned alignment, padding, grouping, etc The only consistent thing in the screenshot is the panel background and the typeface, otherwise everything else is inconsistent, be it font size, icon alignment, spaces between UI elements, etc
Look at the tooltip for example, there's no design, and someone needs to sit down and figure out how things sit next to each other and what information is grouped, and it's visual separation. Argh did this a long time ago ( albeit with questionable ideas about how to do it ), and I've seen Smoth gave some thought to it too, and Zwzsg I think it was asked me about it in a tool once, but otherwise usability and UX design is something that gets mentioned by someone, who's then sniped or attacked because the developer in question fails to recognise it's a problem and see it as nitpicking or being pedantic. So people shut up and say nothing and it's forgotten about.
One advantage of UI frameworks that auto-layout is that a lot of the spacing and positioning problems go away, but they still have to be kept in mind.
I'd suggest people do mock ups, and importantly, explain why things are the way they are in their mock ups, how things are grouped, why X was placed where it was, and why a Y was used instead of a Z
For the most part, all the talk of APM etc is not so big a deal, or widths of things. Instead nobodies mentioned alignment, padding, grouping, etc The only consistent thing in the screenshot is the panel background and the typeface, otherwise everything else is inconsistent, be it font size, icon alignment, spaces between UI elements, etc
Look at the tooltip for example, there's no design, and someone needs to sit down and figure out how things sit next to each other and what information is grouped, and it's visual separation. Argh did this a long time ago ( albeit with questionable ideas about how to do it ), and I've seen Smoth gave some thought to it too, and Zwzsg I think it was asked me about it in a tool once, but otherwise usability and UX design is something that gets mentioned by someone, who's then sniped or attacked because the developer in question fails to recognise it's a problem and see it as nitpicking or being pedantic. So people shut up and say nothing and it's forgotten about.
One advantage of UI frameworks that auto-layout is that a lot of the spacing and positioning problems go away, but they still have to be kept in mind.
I'd suggest people do mock ups, and importantly, explain why things are the way they are in their mock ups, how things are grouped, why X was placed where it was, and why a Y was used instead of a Z
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: UI discussion
Either I am an arrogant guy who thinks the sun shines over his ass or I don't show off enough.AF wrote:Congrats to raaar for being the first, and only person to post a screenshot of UI, in a UI thread.\
I have been posting improvements to UI for years, different things here and there, I did some solid work for MW:Spring I also had a bunch of really cool stuff for GRTS(a project no one cared about anyway) and I have my own gui for my buckets stuff... just saying.. I am not digging that shit up for what I think was a smurf troll.
but JUST because you are AF.. here is what I was doing for Feature placer before it was forked and that feature pack was released.. oh I dunno YEARS AGO
Whatever, I could flood this abomination of a thread but what is the point.
I mean REALLY NO ONE EVER DOES GUI WORK AROUND HERE...
We should all just hire someone because NNNNNNNNNOOOOOOOOOOOOOOOOOOOOOOO ONE ever works on gui.
Christ, will no one ever leave springs default ui?!?!?!
I mean, it isn't like SCENEED or LUALOBBY is a thing..
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: UI discussion
Leaving it is exceptionally difficult.smoth wrote: Christ, will no one ever leave springs default ui?!?!?!
Re: UI discussion
I did actually mention the space take of the build menu icons and the grouping of the order menu..AF wrote:Instead nobodies mentioned alignment, padding, grouping, etc
You're right though that there are some inconsistencies in padding and alignment and text sizes and so. However, I consider these very minor and quick for anybody to toy around with. Also, I don't think they are really something that can benefit much from discussion.. They're just things that need to be done. We all know that text should be aligned consistently and we all know that tight boxes need their content aligned to the middle.
Things I brought up are more things that need discussion before implementation.
And c'mon smoth.. In past 48 hours I've learned to like you a bit and do have a lot appreciation for your work towards Spring.. But perhaps we can rather discuss the actual points about GUI and less the lack of community appreciation?
EDIT: Wait, now I'm super-confused. Wasn't this BAR related in the first place? Now it's just a general UI topic?