Experimenting with Controversial GUI

[Acumen]

The resource tray should go back to the top, though

Well, that's the beauty of having the GUI on the top of the screen. Seriously, it's just a matter of personal opinion, but I'm really trying to find ways to keep the game's controls in one place as much as possible, to give things a much cleaner look. Having bits of it all over the screen makes it look like Jason's desktop. See how much better the screen looks when you toggle off the FPS counter and exit button, for example?

Minor thing, but it annoys me - the menu buttons are placed directly near the minimap and therefore loose their prominent place and their "importance" gets downgraded to a little more importance than the minimap buttons have.

Well, true, the decision was largely aesthetic ... But are they really that important? They tend to get tucked away in the corner of the screen on most RTSes I've seen, because what the player is doing most of the time is interacting with the world and controlling his empire. Selecting stuff and giving orders. Though it's important, he spends a lot less time percentage-wise making alliances, reading up on his objectives, chatting, firing signal flares, etc.

They still get used fairly often, though. Anybody that hasn't mastered the hotkeys yet still needs to find idle villagers or centre on last notification quite a bit.

Having said that, though, this interface itself went through many revisions while being coded. An earlier version started with the convention of keeping the menu buttons in the top right AoK-like and hinging the Mini-Map to it (but the Mini-Map orb wound up taking up a much bigger section of the screen, plus it didn't seem like we'd need that many buttons; see attached).

A counter-thought, though ... If we could stand extending the Mini-Map further down the page (by bumping the menu buttons to beneath it), we'd also have to increase the size of the Status Orb to retain symmetry. Which means more room for stat icons (see below).

I highly doubt that a new player will find them intuitively, without being told where they are.

Again, it depends on where that new player is coming from. I mean, are we assuming that our target audience has played nothing but Age of Empires for the last few years? Someone coming from Empires/Empire Earth, for example, would feel right at home. Take a look at this: See how those buttons are mixed in together next to the Mini-Map?

http://www.strategyplanet.com/empires/game/interface/

I guess what we need to establish is whom we are trying to appeal to (what's their background? what's familiar?), and what's universally necessary, because other than some major recognisable building blocks of functionality, each major RTS title tends to follow its own path. Each person will prefer the exact interface style of whichever game they've played the most (or are playing at the time, for that matter).

The lack of information

Please keep in mind that the interface is only 50% implemented at the moment; the Status Orb in particular still needs a lot of work.

As has been mentioned, there's a lot of wasted space in that orb, and we could easily shift down the icons, add some progress bars, and dedicate the top half of it to unit text of civ&class&personal names (font sizes and maximum lengths of text permitting). We could maybe also shrink down the unit portrait if we need more space?

I dunno if we'd be able to fit all the other stats too (which made me wonder whether the player references them so often that he really needs to see them all the time), and I quite liked the symmetry of Status and Map taking up roughly the same amount of space on either side of the screen.

Unit commands are also open to speculation. I was thinking that a dynamic set of buttons would appear around the unit, depending on his number of abilities. Some could be tab buttons (eg for building structures) and be clicked to drop up/down a list of structure icons which could be clicked to place the footprint, but none of that's attempted yet.

Anyway, this section even moreso than most is definitely ripe for experimentation. The guys gave some other ideas above, and Jason said he'd throw us a few concepts.

The overuse of circles vs. the overuse of rectangles

Well, I prefer to think of it as having a theme or style. Also since this is mainly using placeholders, that meant a lot of basic geometric shapes. Some actual textures, little widgets, etc would break it up considerably.

But yes, other than thematic conventions there's no reason we couldn't eg make the smaller portraits square (and it has the added bonus of them being either (depending on implementation) easier to click because they take up a full square, or realistically clicked because you can't click on edges that are smoothed off).

This is what happens when you send a programmer to do an artist's job.

Also, I personally believe that the unit portraits are too small

It looks okay on 1024x768, but yeah, we can easily increase the size. Again, smoothing off the edges to make them circular also makes them take up less area, so squaring them could have the desired effect.

But I personally think it should only be used for possibly redundant info like tooltips - because it always still has the irritating "background" behind it and the viewer doesn't focus on what's actually on the semi-transparent area.

*shrug* Difference of opinion, I guess. I thought it helped to group those portraits together while still not blocking the player's view with an opaque panel, plus making it easy to dynamically adjust it depending on the number of portrait rows. In fact, if I had my way (which I don't) I'd use even more transparency to create better awareness of what's going on behind the GUI.

Hmm, maybe I just need to get used to playing at a higher rez. But we also need to make the game pleasant to use at the default 1024 rez. *shrug*

great work on the group selection display, Stuart. I haven't yet looked at the code

Please do; it's kinda broken right now. There should be up to 3 or 4 rows of portraits, but the function's stopping after the first one.

If we have the GUI at the top, the console will be over it once opened.

Very true, although we could perhaps wangle it for the console to switch position depending on whether you're using the top or bottom GUI. Having said that, though, I think the consensus has been clear that the key WTF?! response comes from putting it on top, so the default at the very least should be for the GUI to be on the bottom for reasons of familarity (if the top GUI even survives). Trouble is that means losing the "Resource Pool and menu buttons on top of screen, but GUI is altogether" compromise.

Anyway, thanks for your initial thoughts, Malte. As long as we don't kill each other in the process, attacking it from these two different directions will hopefully wittle it down to a GUI that's familiar, easy-to-use and effective to most.

We needn't be in much of a hurry to finalise the GUI or design the "perfect" one either, of course ... We'll have plenty of time for it to evolve through sheer use and experimentation.

[Fire Giant]

Thanks for the indeed very long (yes, there's actually someone reading the task updates out here ) and well-written reply, Stuart. I admit that you are quite right in some points, but I'd really like to further discuss some others.

However, I do not have the time to type up a long reply today (and won't have it tomorrow, probably), but I also do not want to finish this with a hastened reply, so I won't write anything right now.

Only one thing - I noticed the problem with selections using more than one row, and also noticed the cause of the error: Somehow, the GUI doesn't accept your current values as valid for GUI size (it didn't work with making them strings as well, though, I think). I'll look into this - but the GUI code has gotten a lot longer and I need to get into it and know what's where again in order to know what to change and what not to change in order not to break even more stuff.

[Acumen]

Thanks, Malte. Perhaps we should bash out the details on MSN some time when you're more available? Would probably be faster and less horrific than throwing theses at each other.

Thanks for looking into the groups. That makes a lot of sense, as I lost the extra portraits when I switched to using the two size sets and tried to bring my code in line with Gustav's compliances. There must be a size in there that's of an invalid format, which then crashes the rest of the function call. I'll try to have another look at it.

[Gee]

I can add a warning if the GUI comes across sizing that isn't topleft

Oh btw, "crashes the functions call". Invalid sizing shouldn't be able to do that. Nothing in the GUI defines any size 'invalid' (except syntactical, and that will be reported in log).

[Ykkrosh]

The JS/GUI interface code uses something that looks like an exception(*) when the GUI detects invalid inputs (as well as logging "Invalid value for setting ...", and whatever the GUI itself might log), so the rest of the function won't be executed. (The 'exception' propagates upwards until it reaches some C++ code which ignores the failure). So it's not a crash, it's just a controlled response to an unexpected error condition . (Though there's always a good chance of my code being broken and causing real crashes, so please complain if you ever find any )

You can (I think) write

try { object.size="orangutan"; } catch (E) { /* it failed */ }

(in JS) if you want to carry on after failures. Or would it be more straightforward just to log the error and then carry on as normal? (which would avoid the confusion of functions suddenly aborting; except it'd add the confusion of things being subtly wrong (and unnoticed until you look at the log(**)) and would remove any way of letting JS code detect the error when it wants to. Eventually it'd be nice to just launch a debugger, but I have no idea when we're planning to start thinking about beginning to do that).

*: It just does a "return JS_FALSE" into SpiderMonkey; I have no idea whether they really are exceptions, or how to store more data in them if they are (or how to throw real exceptions if they aren't), but they do respond to try/catch like exceptions do.

**: Maybe the last few lines of recent console activity should always be displayed at the top of the screen? That would make the errors/warnings more obvious while we're developing things. A 'developer mode' (independent of debug/release mode) would be nice, to enable those kinds of things for us and for modders but not for general players.

[Acumen]

I can add a warning if the GUI comes across sizing that isn't topleft < bottomright.

Yes, please. It'd make it a lot easier to track them down and wipe them out (although hopefully we've eliminated the invalid objects in the current batch).

[Fire Giant]

**: Maybe the last few lines of recent console activity should always be displayed at the top of the screen? That would make the errors/warnings more obvious while we're developing things. A 'developer mode' (independent of debug/release mode) would be nice, to enable those kinds of things for us and for modders but not for general players.

Probably we could have a config entry for that? Like, if developer mode is toggled on, the last five lines of the console would be displayed on top of the screen on a nearly transparent panel. I think that would be helpful, but it's not urgently necessary, since we can always look at the log wheter something broke.

Also, how does the GUISize-Type work? I know that setting it to something like "10 10 20% 20%" works, but if I take these variables out of other variables (an array in case of the current GUI code, I think), it doesn't seem to work and complains about the value not being a "GUISize type" (but probably there's only a type somewhere in there, though, will try to check again).

[Ykkrosh]

var object = getGUIObjectByName("etc");
var size = object.size;
size.left += 100;
size.rleft = 0; // percent
object.size = size;

and

object.size = new GUISize(1, 2, 3, 4, 5, 6, 7, 8); // last four are optional

work for me. (Unfortunately "object.size.left += 100" doesn't; I'm not sure if that's even possible in JS (at least without making "s=object.size; s.left += 100" also affect 'object' directly))

[Acumen]

Also, how does the GUISize-Type work?

Malte: The GUISize object is covered in this document: http://forums.wildfiregames.com/0ad/?showtopic=1330 Does that help?

Or do you mean that you're trying to make sense of the crazy two-size array thing I'm doing to keep track of coordinates for GUI objects either on the top or bottom of the screen?

If so, basically I call a function each time an object is declared, which adds the object's name, and two sizes to three separate arrays (don't think multi-dimensional arrays are possible, and was too much of a wimp to try structures). This gradually builds up an index of the size values for each object in the session GUI. Then when you flip the GUI, it works out which set it should be using, and overwrites the objects' size with the appropriate one from the array.

EDIT: Philip: Ah, that's handy. I didn't realise you could reference the subcomponents of the size string. Definitely much greater potential for less redundant script using that method (reuse variables when multiple objects share the same x position, and so forth).

[Fire Giant]

Thanks, Philip. I think I might have located the problem then - the script is trying to assign the size in a string-like format.

I'll probably look into this in the afternoon today.