OK, you said the side command button thing was slightly smaller width, yet ti actually looks bigger!
For those of you who thinks the players and stats things are cluttering, look closer, you'll see that there're 2 buttons, 1 to close the windwws and 1 to hide it so it's just a small tab like thing that can be later expanded.
Add a maximise button to the minimap.
Seperate the build items from the commands and switches into a second window that strecthes across the bottom, and use that extra vertical space to make the command/switches panel thinner.
Also perhaps panels can be attatched to the edge and then a 3rd button would apepar allowing them to collapse onto the edge so that you can see a small bar with a label and an uncollapse button
I like the command icons and the divisions. The divisions, if managed right, help separate "state" buttons (Fire, Movement Mode, On/Off, Cloaked, Repeat, etc) from "command" buttons (Guard, Move, Attack, etc). I don't think D-Gun and Capture should be off on their own. I'm not quite sure what the right thing to do with these is. Having them appear/disappear depending on what unit's selected and moving all the other buttons around, the way the current GUI works, is obviously a Bad Idea.
It might be worth moving Reclaim/Restore/Repair/Resurrect to their own "builder panel", and using the freed-up space in the orders panel for D-Gun, Capture, Load, and Unload.
aye, it would be good to have commands divided into "Commands" and "Standing Orders." Subdividing Commands further into "Construction Commands" and "Combat Commands" would also be good. Or maybe Construction Commands should be bound with the build menu.
Either way... Usually, division and categorization like this is a Bad Idea. But in this case, with builder commands in particular, they're only going to be active some of the time, and are going to be used in very different situations from the normal commands. So being able to position them separately, even if they're linked to the buildpics, sounds like a very sensible idea.
I really like what I see so far. My only questions/concerns are:
1) how hard would it be to change the layout of the buildmenu, ie, to have it be 2x8 or 2x4 or 3x10 or whatever, on the mod end? Would that even be possible? As good as any design might be, it needs to be readily modifiable or else there's not a lot of point.
2) How hard would it be to change Metal/Energy to, for instance, Water/Food, or something? Can you change the colors of the bars as appropriate, like be blue and red or something?
3) How is the fullness of those bars next to buildpics (a great idea btw) determined? For instance, wouldn't something that costs 100 metal and 100 energy have no fullness at all? What about something that costs 100,000 metal and energy? Would it overflow or something crazy?
4) For the love of all that is holy, make the buildpics square, not rectangular.
5) The bars next to unit pics won't be of much help to veterans, but it would certainly help newbies. But don't forget a buildtime bar. Try making all three of the bars 2 pixels wide each with 1 pixel seperating them or something... Dunno.
6) To fix the scaling problem I mention in 3, try doing something like this with bars drawn across at increasing intervals, indicating that it's nonlinear:
One thing i always hated about the current GUI is the fact that the «windows» always start a little separated from the edge, wasting extra space in the middle of the screen.
I know i can move some of them but not all. Also, it is annoying to always be moving them.
zwzsg wrote:I don't like the interspace between buttons, it feels like wasted space to me.
...
To me, all interspaces feel like wasted space.
I think that all windows should be touching the edges instead of near the edge to open the more possible room in the middle.
Caydr wrote:I really like what I see so far. My only questions/concerns are:
6) To fix the scaling problem I mention in 3, try doing something like this with bars drawn across at increasing intervals, indicating that it's nonlinear:
Logarithmic bars? Imho, ditch the bars altogether - with the nature of TA play, bars are just confusing. I get 200 energy per second - can I afford somthing that costs -------- energy? Use numbers - the metal and energy are already in numbers. Just get them out of the hideous 03189419847123 type display. Cap at 2 or 3 digits, using k, M, and G to represent kilo, mega, and giga. So you get 1, 10, 100, 1.0k, 10k, 100k, 1.0M, 10M and so on. G should never be used (anything cost a billion energy?). Clear to anybody who knows metric, and short enough to be legible. Align the costs to the right, and make the "k" and "M" different colours so that they pop out to the reader.
Edit: Correction. Ditch the bars altogether. If modders want markup on the buildpics, they can add them to the buildpics. A better idea would be to include tools to make buildpics easier (pick a point on the map, list a set of units, and autogenerate buildpics for those units), including letting people build an XML file full of markup information that will be blitted onto the buildpics (really, with the first program available, something could be whipped up in Python seperately).
It's annoying that the current interface is always the same size regardless of the resolution, increase the resolution, the buttons and side menu gets larger to compensate, ahk, I'd prefer it got bigger as you got smaller not the other way round......
6) To fix the scaling problem I mention in 3, try doing something like this with bars drawn across at increasing intervals, indicating that it's nonlinear:
[/quote]
you also could check the highest metal and energy costs of the actual mod. For example if the krogoth kosts 1000 metal and 10000 energy, the GUI checks (or the modder must set these values) these values and than if a solar collector costs 100 ad 2000, the bars are filled 10% metal and 20% energy. Shouldnt be so hard to implement.
Btw very nice interface - how long do you need to release it?
Well, I'm starting with hard coding the look of the gui, but leaving it open to skinning. Also, I'll give it a memory of the last position you moved each window to, so that you can customize where each window is and keep it that way for each spring game. Eventually (hopefully!) when its lua-ed, there can be several implementations of the "build window" letting people use the one they prefer most.
jouninkomiko wrote:Well, I'm starting with hard coding the look of the gui, but leaving it open to skinning. Also, I'll give it a memory of the last position you moved each window to, so that you can customize where each window is and keep it that way for each spring game. Eventually (hopefully!) when its lua-ed, there can be several implementations of the "build window" letting people use the one they prefer most.
What are you using atm for integration with Spring?
CEGUI in there svn?
As they like to have a license change to MIT before they release 0.5
Okay, a lot of reactions i'll try to remember them all and try to respond to them:
First of all, it just photoshop, and all coding stuff is not meant for me, i was hoping someone else would like to do this, because i need to learn all of that, and by the looks of all the posts, the design alone needs a lot of work.
The buildpics:
as i know they are square (and maybe should stay that way) in a interface that already is 4:3, you can cram more pics in a menu this way. But as most of you like them to be square, i'll design them that way.
The resource bars:
First of all, they should be a toggle option. Veterans that don't like them should be able to hide them. The idea of putting these bars in the buildpic themselves is good. I thought of that aswell, and this will decrease cpu power to calculate them. This does need every mod to re-make their buildpics, and i dunno if thats a good idea. Also the res you're playing on could make these bars to small, or ugly, and veterans aren't able to shut them off. Ill make them smaller maybe, and a buildtime bar next to them aswell. Indeed the log scale should be used. I could also make the most upper 1/3 of the bar in log-scale (more red-ish colour for example), that is in log scale.
As i do like the idea of 10k or 35m for the resources, i still don't like to hover my mouse over buildpic, and have to look closely in the bottom and check some number, and them have to go to next pic, and check again... i like to visualize as much info as possible, because this is much more intuitive and faster to recognize. what percentage is 28346 to 76325? you need to think about it, and that is time lost.
Buttons and layout:
It's hard to find the right location for a button. Personally i hardly ever use one of the commands buttons (only stand- & fire orders, cloak/on and off.. land AT also indeed) Fixing this problem, could be by adding more sub groups, and letting you choose to show or hide them. On the other hand this needs more space, with max. min. buttons, and i also agree that you should waste minimal space of your screen to this. My question to you is, how imporant specific buttons are, and which aren't.
The basic commands, do you want me to delete the text? or the icons? is it enough to only have icons? esspecially for newer players? I think it's quite okay this way.
The minimap 3% is the actual size in the minimap of that of the total size. Not really a must-have, but could give players a better idea of how large the map (and corresponding distances) are. (maximize button needed indeed)
Lower right menu should hold the tooltips. In these should be experience, hp, metal nrg costs/output, team color (probably name of team also?)
Lower right menu (stats) should hold kills and losses, but they can be added to the player list as well.
How much of you want a seperate menu for the groups. As i did like the concepts one of send of a mod. Info on the unit count and health could prove quite useful. Maybe even a visual animation if group is being attacked or reached their movement destination. Any really like group info, or only showed in tooltip?
How many of you want all builpics in some menu (bottom, maybe with spacebar toggle?)
That as much as i can remember.. I'll start on editing the concept now.
thx for all info and discussion. (though this makes hard to decide what is best thing to do)