Experimenting with Controversial GUI

[Acumen]

Like Aviv, I recently had a dream. Over the last week or two I've been refining that flash frame that came in the night after doing a lot interface research, and putting it into scripted form to prototype how it pans out.

It's very unusual, so I'm almost certain it will be disregarded for reasons of unfamiliarity alone. But I had to give it a shot, and to my twisted mind, it doesn't seem that inaccessible (maybe just because I've been looking at it for too long).

So, I've had a crack at mocking it up in the GUI (with the aid of Jason for some placeholder art, and Gustav with various pestering questions) so that you can take it for a test drive.

I've mainly just put some basic controls on the screen with minimal functionality; a lot of what I still plan to do depends upon accessing some entity stats, some more GUI controls, some extra events, and a couple of fixes. Where there's something in the GUI that I've noticed needs improvement, I've marked that to describe it in more detail in this topic's footnote. I hope it gives you a rough idea, though.

I also dumped a lot of the GUI script and started over, just to keep the pages clean. It's probably highly incompliant and buggy, but at least it's consistent.

If you want to check it out, make sure you have the Latest Build, Art Pack and System Pack.

EDIT EDIT EDIT

Only download this file and unzip the contents over the top to overwrite GUI art and scripts if you want to revert to a version that's a couple of weeks old (but less buggy). The one in the build is more recent.

EDIT EDIT EDIT

Hopefully it's not missing any files. It's been a long couple of weeks. If it doesn't work, try removing your official/gui/ folder and replace it with this one (it might not like additional files declaring the same objects).

OBJECTIVES

I had a few objectives while putting this into place ...

a] Centralise: Keep the GUI in one area of the screen.

b] Maximise: The player's view of the game world. The interface should support his interaction with that world, not become the focus. This includes using a lot of dynamic elements. If the player doesn't need to see part of the interface, remove it so that he can look at the world instead.

c] Smooth: I was reminded of something Malte told me earlier, which I'll paraphrase ... Rectangular controls are very space-efficient, but curves are much easier on the eyes, kind of an ergonomics thing. So, I went out to maximise the use of circles and arcs. Major inspiration here came from Battle for Middle Earth and Warrior Kings: Battles.

d] Symmetry: Try to keep a decent balance between either side of the screen.

PREVIEW

For those without the patience or desire to set up a testbed, though, here's some screenshots.

This is how the interface might look if the player doesn't have a unit selected. Note that only the mandatory stuff is shown on the screen: Resource Pool and Mini-Map, and they're tucked away in the corner of the screen. All the rest is dedicated to the game world.

This is the worse-case scenario. The player has selected a whole bunch of units and he's saved a full complement of groups to the 1-9 hotkeys.

INITIAL REACTION

Cry of Indignation #1: "Have you taken leave of your senses? Why are you putting the interface at the top of the screen?"

The interface could work just as well at the bottom, but while I was at it, I thought I'd try something ... Due to the perspective of the camera, things at the bottom of the screen are larger and more accessible than those in the distance. By putting the interface on the bottom, we're effectively stopping the player from interacting with items that are right in front of his face, and forcing him to click on stuff that's further away.

This situation is only worsened with the perspective camera that Jason has in mind (have a look at ScEd for an example of the "chess board" angle that he ultimately has in mind). Anyway, try it out, see what you think. Either could be done.

As an added bonus, it keeps the Resource Pool where Agers expect it to be.

Cry of Indignation #2: "Ha, you fool! You finally caved in and moved the Mini Map to the right. We were right all along, haha."

This is true, and the method in this madness was the result of looking at a Behind the Battle movie of BfME about its interface (I've lost the link, but Jason could provide it if you're interested).

Their GUI is even more spartan than this one (there's no Group Pane, no Team Tray, etc). What they did, though was put the core of their GUI -- the Mini-Map -- right down in the bottom left corner, and built other interface components on that as needed. Just about everything springs out of the bottom left corner, but virtually everywhere else is clear.

Even so, I couldn't help feeling that was the part of the screen I wanted to look at the most; I don't know about anyone else, but typically my focus is on the centre of the screen (particularly the mouse cursor) and to left of centre. But I'm quasi-ambidextrous, so I could just be badly wired. Anyway, see what you think.

Cry of Indignation #3 (from Aviv): "What happened to my resource icons, you fiend?"

Jason made up another batch, largely by accident: I asked him to make a circular set for a unit's Supply to match the gold-and-white statistic icons we already have; then it turns out they look better uncircular. Since we had the assets, I thought I'd throw them in here too to see how they look in-game. I shall leave it up to others to decide which combination is preferable.

GUI COMPONENTS

Let's focus on the second screenshot and go through all the components of the GUI:

RESOURCE POOL

The set of five counters and icons at the top centre of the screen, showing the player's Food, Wood, Stone, Ore, and Population. Nothing you haven't seen before.

MINIMAP ORB

* Mini-Map: In the top right is the miniaturised view of the game world. Same old, same old. The size of the minimap box pretty much defines how much of the screen the interface is occupying.

People like a big clear, mini-map that lets them distinguish details like different unit colours, so I used square and top-down for clarity. That's about the only square thing on the screen, though.

* Mini-Map Buttons: These 8 buttons wrap the Mini-Map, turning it into a circular orb. I call this construct the Mini-Map Orb.

4 buttons are for sub-windows (prob. Diplomacy, Objectives, Chat/Tech-Tree, Menu). 4 are for navigation/map controls (prob. Signal Flare, Idle Villager, Last Notification, Civ Centre Cycle). I don't have the talent to create icons, and they don't do anything anyway right now.

One handy thing about this arc construct is that we can prioritise our buttons. Buttons that get used regularly (like Idle Villager) can be on the larger central buttons. Buttons that aren't used as often (like Signal Flare) can be on a smaller edge button.

STATUS ORB

On the left-hand side of the screen we have an orb that appears when the player selects at least one unit. This is basically the statistic window, and it shows details about the selected unit (or the leader of the group).

It consists of:

* a 64x64 portrait (which can be clicked to centre on the unit);

* Red Heart: hitpoint counter (I'll probably also put a hitpoint bar there too; I couldn't get progress bars to work at the moment); doesn't appear for invulnerable objects;

* Yellow Chevron: counts the number of upgrade points until the unit's next rank (number of chevrons, 1, 2, 3, indicate the current rank; only appears for Citizen Soldiers;

* Meat: shows the resource type and quantity of supply (eg wood in a tree, food on an animal); only appears if the unit is carrying some kind of resource;

* Gate: Number of units garrisoned out of maximum; only appears if unit (eg building, ship) can be garrisoned.

Cry of Indignation #4: "What about attack, speed, accuracy, etc?"

This unsettled me too at first. Then I realised ... how often does the player really have to check a unit's attack rate? Very rarely. Maybe once in a blue moon he'll compare two units to see which has the best attack.

The only stats that player needs to monitor are those that change regularly. For the rest, we have the online manual. A page of detailed stats, descriptions and histories are just a hotkey away (a la AoM's manual). Because it's pulling data directly from the game at run-time, we can also display any dynamic stats (eg the +2, -1 modifiers gained from techs) in the manual.

Icons indicating that the unit is being locally affected in some way and his stats are changing (eg in range of an Aura) might also need to be appear here, that's another option, or it might just create unnecessary clutter. Still, there's plenty of room in the corners of the orb for extra icons if needed.

COMMAND BUTTONS

Around the Status Orb appear all portraits for all the commands available to the unit. This is dynamic, so if a unit has 3 commands (Garrison, Scout, etc), then just 3 icons will appear. Equally, if a command later becomes available (Ungarrison) then it'll pop onto the arc.

These start in the right-hand corner of the Status Orb and arc out on either side. This keeps the icons closer to the centre of the screen for easier mouse access.

This section is still under a lot of consideration, mostly because it'll need to read entity abilities to generate the commands(1).

What I'm thinking of doing though is integrating tabs into here alongside normal buttons. eg in Warcraft you click Build Basic and it fills out the Command Card with buttons for all basic buildings to construct.

In this case, you click, say, the Build Military button in this set of command buttons, and a second arc of buttons appears around the primary set, showing all the military buildings that can be constructed under that "tab". Because you're building on another circle, this means a wider radius and so up to 12 buttons could fit in that arc.

I didn't add the secondary buttons since it's totally non-interactive right now(1), but hopefully you get the idea.

Another possibility is a radial menu that appears over a building when you hover the cursor over it and you can select techs, etc, that way. This is slightly less intuitive, though (not to mention impossible to implement right now).(2)

The buttons may need to be larger than 32x32 too (for one thing, circular buttons appear smaller, since the corners are cut off). It depends on just how many buttons we have to display at once for each unit.

GROUP PANE

Below the Resource Pool is a list of any group the player currently has selected. Depending on the context, this could be the portraits (and hitpoint bars) of a bunch of units the player has selected, the research/training queue for a building, the units garrisoned in a ship, and so forth.

The semi-translucent box is dynamic, and increases in size as the number of units in the group increases and more rows are added. I stopped at 3 rows, 13 on each row = 39 in a group, but we could easily add another row without exceeding the height of the interface, maybe even add another column on either side up to a max of 15x4 = 60, twice what we could do with the existing interface plan.

Currently the group is centered for symmetry's sake, but we can make the group add up in any order we want.

Obviously one would be able to click the different portraits to do appropriate things (select a unit from the group, cancel a tech in a research queue), but I couldn't seem to get that to work at the moment.(4)

TEAM TRAY

Finally, the numbered batch of portraits on the far right is the Team Tray. This shows the portrait of the unit most common to a saved group, and provides a mouse-controlled way to select (left-click) and save (right-click) Ctrl groups.

This is the least necessary part of this interface, and could easily be scrapped if more screen visibility is preferred. It's not considered a mandatory part of an RTS interface (only a couple of games eg AoM have used it -- though it just displayed broad classes like cavalry or ranged), but it does have the advantage of helping you to remember what you've saved to each group.

Keep in mind also that any part of this interface could have a hotkey to toggle that component. The player could even play full-screen if he wanted to (though that'd be pretty crazy with no map and no resource view).

ODDS AND SODS

There are a few little details of an interface that aren't covered in this example, and I'm not entirely sure where to put them.

* Event Text: eg "Acumen has allied with you", "You have been defeated". These typically get put in the top left corner of the screen, which is currently occupied. I guess they could either go in the bottom left, or on the left below the interface, depending on which works better.

* Chat Cursor: Where to put the cursor and input string when the player is sending chat messages? Again, probably bottom left or underneath the interface panel.

* Triggered Counters: eg a counter until the territorial borders between Provinces goes down, the number of Houses the player has to build to complete an objective, etc. These usually get put on the far right.

* Scores: List of the scores of each player, in player colour. Again, usually on the left. Usually only used by ladder players or the extremely competitive (score-based games are fairly rare).

* Time Elapsed/FPS: On the left again, normally.

Cry of Indignation #5: "Well, that's just great, genius? But what about all the descriptive text? How does the player know a Hoplite from a Triari? How does he know to whom a unit belongs?"

For this sort of stuff, I'm planning to hide it away in a tooltip (with any less important text going into the manual). Unfortunately tooltips don't seem to be working at the moment(3), but fixed-position (like the main menu one) and following (appears near to the cursor) types are covered in the GUI TDD. I'd suggest going with the cursor-anchored one in this case.

Finally, there are other things we're used to seeing in text-heavy RTS games, like a progress bar at the top of the screen indicating the progress to the player's next Age (or what Age he's currently in). I'm banking on that being less necessary in this game, though, due to the lack of an Age focus (the city upgrade system is very much like that in Warcraft, for example, and they don't seem to need one).

If there's other critical RTS stuff that I've missed, please shout it out and I'll try to figure out how to make it fit.

Well, that was extremely long, and if you've managed to read through all this without skimming, I'm very impressed, thanks. (

*awaits the inevitable cascade of scorn and derision*

---

(1) I unfortunately can't get most buttons to do anything because currently the game map doesn't seem know when the mouse is over a GUI object, and so clicking on a control that's over, say, grass, makes the cursor select the grass and therefore deselect the unit. Since having no unit selected hides the dynamic GUI, that means I can't do very much interaction at the moment.

(2) Basically we'd need to look into creating controls that are aware of an object in the gameworld, can be anchored to and follow them, and so on. Like hitpoint bars, and so forth. Currently the 2D and 3D view are very separate entities.

(3) Quite a few of the controls detailed in the GUI TDD unfortunately don't seem to be available yet (or maybe I just can't figure out how to use them properly). This includes input box, tooltip, checkbox, radiobutton, and progressbar. A bit of a shame, as I was really amped after reading the docs, and spent hours revising the script trying to make them work.

(4) Also I think we're going to have to create some additional entity flags that the GUI can recognise. For example, I have to update the info for the selected unit every tick, which is coming to be a lot of code to do every time with all these dynamic groups. If we were able to check for an event that a different entity(s) has been selected, then we could cut down on some overhead.

[Wijitmaker]

Well, I don't have much to add about this because I have been giving Stuart comments that leads up to what see here.

I think we could squeeze in text for the names somewhere too. True, you memorize what the units are after playing for a bit, but I think we do need something somewhere to at least throw up the name of the player who owns it and the generic name.

We are going to hopefully have a lot of random helmets, textures, and shields for the units (more historical, more realistic, and pleasing to the eye [i HATE Rome Total War's attack fo the clones])

So its going to be important for players to be able to see what they are.

But, I must say: Given the choice between this and the ES GUI, I would rather use this one hands down.

[Acumen]

I think we do need something somewhere to at least throw up the name of the player who owns it and the generic name.

Well, we could use a tooltip for that, and hover the cursor over any portrait to get the unit's name, class, owner, etc, as mentioned (Cry of Indignation #5), but yeah, I could see where we could fit that.

[Mythos_Ruler]

I like the overall concept, but here's the thing - the GUI you designed looks like it's for a space game or something like Starcraft. It looks more like a HUD from an F-16 cockpit than a GUI for a historically based game.

Also...

As an added bonus, it keeps the Resource Pool where Agers expect it to be. smile.gif

I have been playing AOM for 2 years now, and it puts the resource pool at the bottom left.

[Calefaction]

I think it looks awsome. Or course, the GUI elements need to be more "themed", perhaps some stone or wood textures or whatever, I will leave that up to the art folks

Also, that's a pretty snazzy mini-map, kudo's to whoever coded that

[Acumen]

the GUI elements need to be more "themed",

Yeah, currently I just used placeholder images to convey the overall intent (black bordered backgrounds), etc. Hopefully the GUI artists could then redo them and give the interface some personality (which hopefully might make it look less space-agey).

I have been playing AOM for 2 years now, and it puts the resource pool at the bottom left.

Well, I was mainly referring to AoE/AoK. I can't immediately think of any other game than AoM that puts its resources in the lower left; it's an interface in a league of its own.

[Phoenix-TheRealDeal]

You seem to have 'forgotten' that I had a dream, too. A dream upon awakening is often the synthesis of the compilation of a multitude of 'facts' coming together that enables one to think entirely anew about something he has been muddling over for a long time... thinking out of the box.... thus a "breakthorough". Kudos to you, and kudos to me for having palmed off GUI design consideration onto you in the first place. I LIKE it.

Give ME more of the gameworld and less of the supporting paraphanalia... as long as I can interpret or access that easily enough... anyday!

[Vaevictis_Music]

I love this, really. I do so want to see a new take on the classic RTS interface, and I do so want to see 0 A.D. look different.

I agree a lot about trying to use round shapes - it's worth a try. I have no idea whether placing it all in the top will throw off a lot of players, but I'll happily give it a try.

One thing you could look into is the left orb. There's a lot of wasted space because the four stats are placed so far apart, and because they have numbers as well as icons. Why not replace the heart and the health number with just a green health bar? People will immediately pick up that it represents health - they don't need the heart. Whether they need health expressed as a number - I personally doubt it. You'd have to do a whole lot of micromanaging to care about the exact number of hit points for an individual unit.

So what you could do is this: Convert health into a 'meter' - maybe even look into making it a semi-circle which is attached to the lower half of the unit portrait? Similarly, the chevron icon could be removed and be represented by a meter of some kind. Whatever is left (Gate, Resources, etc.) could be placed in a half-circle above the unit portrait. Then you'd have the whole area below the portrait for unit name / type, player name if you wish, etc.

This is what I mean. Sorta.

Well, just a thought. In any case, good to see that someone isn't afraid of thinking in revolutionary design.

[Acumen]

Thanks, Boris. I'll look into that. I actually experimented with circular health bars in an earlier revision (attached), but in the end decided to go with something simpler because non-rectangular progress bars seemed quite tricky to do.

Well, I must say I'm very impressed with the feedback so far. I was expecting to be strung from the yard arm.

[Vaevictis_Music]

Updated my post with a screen of what I mean, but if circular meters are tricky, then it probably won't be much use. Could be cool though.

[Wijitmaker]

Smack me if I'm crazy ... but:

Did Gee make a GUI circle element like the rectangle? Could we specify say a circle object that (however that is done), then put the unit icon inside of it using the wierd notation of making its width and height 80% of its parent? So what you end up with is a larger circle object, with a smaller image imposed on top of it with a border around it that is 10% on all sides?

*flinches*

[Mythos_Ruler]

If the toughest criticism so far is my post, then I think you did pretty good!

[Aeros]

But, I must say: Given the choice between this and the ES GUI, I would rather use this one hands down.

Yeah, honestly that's some impressive design and insight on GUI, Stuart

It'd make 0AD that much cooler if we use a different interface system, then people will have to re-adapt to 0AD - it'll be like playing a completely different RTS if we mix things up that way.

And I'm really digging the spheres and rounded objects - reminds me of the shape of the 0 in 0 A.D. (Symbolism)

[Mythos_Ruler]

I guess I reserve further judgement until we have some actual art and texture to the "controversial" interface. One thing I will say is that, as a "wage slave" I really don't have time to learn all new interfaces for each of the RTS games I play. I want to jump right in and play. There is a certain "intuitiveness" in the "standard" RTS GUI that makes it accessible to new players. One might say it is because they all (RTS studios) use it, therefore players have already "used" the GUI before, but one could also argue that the GUI that ES uses is that way for very good reasons. I can see an unease with the "controversial GUI" because of the feeling of all that "weight" at the top of the screen. Most GUIs are at the "bottom" of the screen because it gives a sense of stability, weight, or a sort of "grounding." I do realize that these things are psychological, and that players can "learn new tricks" so to speak, so like I said, I'll reserve further judgement until there is something "more" to judge.

PS: Just had a thought - we could allow for two different GUIs and make it another option to choose which GUI the player wants to use.

[MarkT]

Idly wondering: At the moment, the bit of Stuart's GUI that bothers me most is the minimap: the square-within-circle just doesn't look right to me.. I was thinking that it might look better if you move the minimap controls outside the orb, and use all the space within it for the minimap. This would allow a minimap that will rotate with the main view, either just top-down but oriented to the view angle, or going a step further and matching the view perspective also. (I think not too difficult, if the minimap is rendered to a texture... Matt?) I'm not sure that this'd work, but I'd be interested to give it a go.

Oh, and:

PS: Just had a thought - we could allow for two different GUIs and make it another option to choose which GUI the player wants to use.

should be handled by the mod system (whichever the standard is, we could ship with an 'official' mod that'd switch it to the other)

[Acumen]

Yep, intuitiveness was my major concern ... Even if another GUI might work or look better, if it stops the player from enjoying his first five minutes, the game is toast. I hoped, though, that if enough of you liked it at first glance (especially if you had a chance to stick it in the game and play around with it), that might simulate that scenario.

Sounds like the most controversial is, not surprisingly, the position on the screen. I'll see if I can do a version at the bottom of the screen too, and see how that comes out. Since I'm going on a whim with this top one, that could make this interface a lot "safer".

Doing two interfaces: It's possible, but it means double the work and double the headache, both in testing them both to make them work, and keeping them in sync (change something in one, you have to change something in the other).

For example, say I made two, one anchored to the top, one to the bottom. All the images have to be duplicated and flipped (increases size of assets), all control coordinates have to be duplicated and recalculated. Also it doubles the amount of localisation to do (and text fragments aren't always going to be in the same places or even calculated the same way).

I gotta do it anyway to get a bottom sample , so I'll give it a shot, but life would be a lot easier if we could establish one interface that pleases everyone.

Good point about the "zero" symbolism, Bobby. Makes it seem less like I stole it from BfME's Palintari. (sp?)

Mark: A dynamic 3D plane minimap that conforms to the camera angle? Very interesting. I'll have to chat to you about that when I get back (gotta head out for the weekend now).

[Phoenix-TheRealDeal]

This would allow a minimap that will rotate with the main view, either just top-down but oriented to the view angle, or going a step further and matching the view perspective also.

Now this is a very unteresting idea when it comes to speaking of immersive qualities. Picture the soldier. He is standing somewhere in the world. He has in his hand a map of some scale, perhaps 1:62,000, 1:50,000, 1:25, 000... etc. this map in his hand is his mini-map. How does he use it for navigation upon the terrain of the real_world? Well there are a number of little technique that he uses to locate himself or locate 'targets' on the terrain... we do that for our soldier/player by marking his minimap for him. But the one thing that he ALSO does... is orient the map from his viewpoint to where he is looking, or going.

As an old soldier, I've done that a LOT. MY personal job was also working in an aircraft having 'video' screens displaying areas of the terrain on them (aerial surveillance & reconnaisance systems). This was before the days of computerized touch screens, but the way in which we plotted and tracked targets on the screens was in the same manner... by having a map in lap oriented to the flight path as terrain was revealed on the screen... again, the simile of the minimap.

It is intuitive. It is easier to 'find oneself' and find 'the enemy'... or where you suspect he might be. It is the best and highest use of the gamescreen with its organic minimap that I've seen mentioned yet. And it is a darnsight better than trying to rotate the camera around that is disorienting as is done in some games. Another breakthough idea, methinks.

In actual practice, it is just as well that the minimap be on the flat plane from vertical viewpoint as the perspective on that would dither clear and instantaneous view of the whole of the terrain.

Now then, I was excited when Stu mentioned (at length) his idea for putting all the game data items at the top and related to what he said about there being a closer perspective at the bottom of the screen. But wrt to Michael's thought, and subsequent posts, if not too difficult to do I'd go for creating that at the top then having a toggle in the game setup screen permitting it to be toggled to the bottom as the player wishes. The only thing that would be 'lost' is a bit of the 'closer perspective' while nothing is really lost of the greater expanse in viewing of the gameworld on the screen itself. So, just toggle to top or to bottom as one would wish..... flip---flop.

[Wijitmaker]

nickname it the Kerry GUI

Shame on me! *slaps self*

Seriously though... I know you guys aren't used to stuff being on the top, but as Stuart mentioned... putting it at the bottom is putting it right in the way of where all the action will be. I imagine as player you would want to keep focused on the stuff that is 'closest' to you. With a perspective camera, the stuff at the top of the screen is naturally farther away. Hence, why I suggested to Stuart to put it up at the top.

For us western european folks, its natural for our eyes to be drawn from the top left to the top right to the bottom right and the lastly the bottom left. Example... Window programs, all your controls are featured in the top left.

This might also be a factor for mods and other games that use the same engine. Perhaps they want to show part of the skybox in their camera angle? Well, putting the GUI at the top would make it completely out of the way and mimize the stealing space from the important stuff on the ground.

Anyway.. that my 2 cents

Certainly could do a mod to flip it though.

BTW I like the map rotation idea Mark, especially if the buttons around the square minimap turned with it.

[Fire Giant]

Interesting proposal, Stuart. I have only briefly read over this yet and installed the OrbGUI into my binaries, and now - after almost six hours of reading forum topics - I'm too tired to write up my thoughts about it. I guess I'll sleep about it and write a longer reply tomorrow. My first impression, though, is that it is an interesting alternative which needs some tweaking in some aspects to fit my ideas of the GUI - but after all, I'm only one person, and I'll happily give in if the rest of the team votes against me

[Acumen]

Okay, thanks, Malte. And sure, there are still a lot of things that need to be finalised, particularly the Status Orb layout (and twice as many things I haven't had a chance to code yet).

I hope you don't mind, but I've released a build and updated the Art Pack with the new GUI; it was beginning to become a nightmare trying to hold onto the new scripts and art while also generating and testing builds. With two of us working on it, that situation was only going to worsen. In addition, it was getting harder to keep in sync with new additions to entities and the GUI code.

Also, it's more up to date than the one linked here, and I wanted to try and cut down on redundant versions.

The drawback is it's also a little more broken than the one above. There are a few glitches that have crept in (such as there are supposed to be three or four rows to the Group Pane, but inexplicably it doesn't exceed the first row at the moment), but I haven't had time to fix them yet.

On the upside, you can now use hotkeys to toggle parts of the interface and flip them to the top or bottom of the screen (see system.cfg for a list of the new hotkeys).

On the downside, the code's double its previous length. I'm sure it's also horribly inefficient and repetitive code, but it's a start.

I figure that even if we roll back to the old "panel" GUI, it'd still be a good idea to build on the code in this new one, since it's at least split into separate sections, there are more utility functions, etc.

I've backed up all the original art and scripts to here: PanelGUI. I recommend bookmarking that, as we'll definitely need it in the future (ie there are some icons that aren't used yet but will need to be later, like the stat icons for things like Pierce Attack).

EDIT: Uhoh, looks like I'm also getting a lot of "ERROR: Left click blocked" messages now that I've updated to a new ps.exe with the GUI fixes. I presume that means my code is loaded with 0 0 100% 100% sizes that are blocking access to the screen. Hopefully you can please help me to stamp on those and do it the right way?

[Gee]

Did Gee make a GUI circle element like the rectangle?

No, but it's possible for controls to redefine their mouse-over area (only for the programmer as of yet though). So we can definitely solve this in some way.

EDIT: Uhoh, looks like I'm also getting a lot of "ERROR: Left click blocked" messages now that I've updated to a new ps.exe with the GUI fixes. I presume that means my code is loaded with 0 0 100% 100% sizes that are blocking access to the screen. Hopefully you can please help me to stamp on those and do it the right way?

Ops, that ERROR message is really not an error message. I just added it when developing as a feedback, and I made it Error so that I could easily spot it. I suggest a new log category called "TEMP" that is easy to spot, and if you accidentally leave it behind, it's easy to find later (even disabling them in NDEBUG mode, just to be on the safe side).

Anyway, regardless what 'error' messages you get, is the world clickable? If it's not, then you've got invisible GUI objects blocking. I'm thinking of adding like a wireframe option, so you can see how the GUI objects really look.

Notice that the 'empty' control can still be "0 0 100% 100%" (and should be able to be whatever is appropriate if you want to use relative sizing), because I've made its MouseOver() function always return false. So if you can't select the world, then you've got some other kind of control blocking the path. It's easy to spot though, I could always just add the name of the control to the log output, and then you can start the game, pull down the console, and click away.

[Acumen]

Gee: Yeah, my new code is highly outside of your compliances (as the general lack of interactivity possible right now proves ). Will work with Malte on trying to fix all the controls that don't use proper x1/x2/y1/y2 sizes.

I never really got the hang of relative sizing either until it was too late (despite you telling me how it worked a couple of times), so the GUI coordinates would also be much more efficient when I finally get around to making them relative to their empty control groups (which could then be moved around to move their children).

No problem with calling it an error, as it definitely is an error. If you could output to the console which control is blocking the screen, though, as you suggested, that'd be a tremendous help, and really aid us in finding and smacking them if they ever slip through the net.

[Paal_101]

I love the new set up Stuart Good job. I have to agree with Bobby, it will make the game seem different and new. That can only help

[Fire Giant]

Okay, here's my promised reply (I hope I'll manage to write it parallel to the programming meeting and I'll manage to finish it before dinner).

When I first saw this concept, I honestly thought "Oh no, what's that - he's ruining the GUI" (please don't take that personally, Stuart - I just want to be honest), but lateron my opinion changed a little. I'll therefore exlain my concerns, ideas and suggestions.

1. The Innovation vs. Intuitiveness-dilemma

As you remember, we already had that discussion back when we were first writing the old GUI DD in early 2003 (or was it 2002? I really don't remember). The first GUI was innovative and we had a lot of great ideas in it. But then, the design team decided to go back to a old-fashioned GUI for the sake of playability and intuitiveness.

Now, it looks to me like we are rapidly going back this way and even further into the "innovation"-direction than we ever have been.

Well, nothing is wrong with that - I've never been the one who was against innovation in the GUI. The problem which is some kind of appearing to me is, though, that we will probably later flip around again and decide to go a more conventional way again (probably based on feedback from beta tests). A counterargument for that is that we can more easily experiment at this early stage, though.

This is not a major concern to me, but I wanted to mention it.

2. The top-alignment

I don't know why, but this is something I really don't like about the new GUI. Having GUI controls "hang down" from the top like apples on a tree just doesn't look appealing to me. Sure, all the argument for it are clear and theoretically right (better battlefield perspective, windows apps having controls on the top), but somehow, it doesn't look right to me. Probably it's the fact that the GUI build a solid "base" for the screen, or the fact that in non-scifi RTS games I'm imagining to have my "tools" and "documents" (the GUI) right in front of me while looking around (like a table).

In the latest version, where one can flip the GUI to the bottom, I have to say that I like the idea of the rounded and innovative GUI much more (haven't looked at the code yet though). The resource tray should go back to the top, though (okay, I've fought for that thing all the time I've been in charge of the GUI and even though I deeply know that there are good arguments against it ).

3. The lack of information

That's a major, probably the largest, problem to me. Probably I'm an exception, but I do care about exact stats for the units - I really like to know how much attack and armor my units have just now, if only for comparison with other players units. And I know I'd never open a ingame documentation during a heated multiplayer game or look at tooltips.

This lack of exact information is a major problem I have with C&C Generals as well (they don't have ANY unit stats there, only HP bars).

Especially for RPG-style scenarios it's likely to be very important to know the exact stats of a unit in order to be able to judge wheter to attack an enemy or better flee the combat. In the same kind of scenarios, the unit names are very important, because hero and object names are frequently changed in these scns, and one often need direct attention. Therefore, I would really suggest not to leave out the unit name (also, our nice random-name feature couldn't be used efficiently when the player hardly sees the names).

Maybe I'm a stats freak, but I simply don't like to have to assume wheter my unite are stronger or weaker than another players units - I want to know it by hard facts, even though I'm surely aware of the fact that this idea really isn't historically accurate (in ancient battles, they also could only assume how strong their enemies were).

Asides, I think the area representing the selected unit needs to be larger anyway. With its current size, it kind of reminds me of the advisor portrait in "Rome - Total War" - something I only liked the first couple of times it appeared and which I turned of after 30 minutes. And out unit representation is one of the most important parts of the GUI, so it should get the most prominent place and size of all GUI parts.

4. The overuse of circles vs. the overuse of rectangles

This is a general problem that occured with all the GUIs we had up to date - they used one shape, and used that extensively. But a good, "living" GUI needs different forms, different shapes, all kind of "loosening up" that it can get. This can be done through asymmetry (sp?), rough borders, ornaments, organic shapes and such - but a circle- or rectangle-only GUI is very functional but doesn't look like it belongs to our detailed, nice little world.

Because of this, I'd suggest that we try to mix different shapes. For example, the unit potrait icon IMO doesn't necessarily have to be circular, even in the new orb GUI. We could also use a rectangle here, or a overlay that gives the image smooth borders (I'd have to try it out). What I want to say is, that we should (at least in out time period) not rely on perfect, functional, black-grey circles only.

5. The placement of the menu buttons

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. I highly doubt that a new player will find them intuitively, without being told where they are.

6. The semi-transparent background of the group selection thing

Semi-transparence generally isn't a bad thing, I used it myself for the main menu tooltip. 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. Also, I personally believe that the unit portraits are too small (may be due to my high resolution, though). Besides these concerns - great work on the group selection display, Stuart. I haven't yet looked at the code, but it is looking great and I'm sure it saved me a lot of script coding

7. The developer problem

This is really minor, but an issue I won't like to forget: If we have the GUI at the top, the console will be over it once opened. And as the developers of the game, we will likely need to have the console and GUI open both in order to check something some time - and it might be really annoying if we have to switch on and off the console multiple times just to compare some data.

Okay, these were a lot of concerns and problems (and I guess there will be even more coming to my mind), but I should not forget to say some other things:

1. In general, I like the idea of an innovative and "new" GUI.

2. I'm not against reducing the screen space occupied by the GUI, too. The general idea of this new GUI certainly is right.

3. Though we should probably still discuss some details, I'm not completely against this GUI - even the opposite, I favor this one above the old one, but I think there's still the need and room for improvements.

I think I will try out some things in the next days and put up my version for discussion - as I said, I think it's generally a good idea to start off from this GUI, and so I will do and try to find a good compromise between this and the old GUI.

I'm too tired to write anything further now - I'm sure there's more to say about this, but I'll keep that for tomorrow.

[Acumen]

Thanks for your thoughts, Malte. Really. Critical opinion is the best there is, because rest assured, if the GUI isn't appreciated by players, they won't be taking our feelings into account. They'll be filling up the pages of forums with their misspelt rants.

But I'm also confident that we'll settle upon the perfect GUI through sheer use. Ultimately it's going to have to get used regularly by everyone on the team for a couple of years, plus the open beta testers, so if things don't work we should be able to fix them and find an alternative pretty promptly. When we do something that sucks, it won't be long before we know about it.

The Innovation vs. Intuitiveness-dilemma

Yep, always going to be the problem. It's very risky to experiment with an established interface. Even if something's better, if it increases the learning curve to the point that players don't feel comfortable, they'll give up and play something else, and we'll lose them in those crucial first five minutes of play.

The trick is to therefore innovate only where innovation is required, retain the convention wherever possible, and to take very gentle steps away from the standard so it isn't too scary.

The tricky part of course is establishing exactly what the 'convention' for our target audience might be.

Age of Empires. Age of Mythology. Empires. Rise of Nations. All historical RTSes, and all liable to have been played by those who want to play another historical RTS. And each one with a radically different convention about where elements should appear on the screen (the Resource Pool, for instance, is differently placed in each one).

So who do we want the game to appeal to? Well, everyone. And there lies the challenge.

The problem which is some kind of appearing to me is, though, that we will probably later flip around again and decide to go a more conventional way again

Par for the course, in my opinion. Look at the Inside the Battle movie for BfME on their interface. They went through about ten radically different designs before settling on one (and they just showed the ones that actually had completed art and were good enough to show the public; who knows how many used placeholders, were iterative adjustments, or didn't get past paper).

The GUI's going to change more often than our underwear until we get the perfect match (especially if we risk trying anything that isn't an exact carbon copy of another game's interface). I figured for that reason that now seemed like a good time to try the really zany ones, especially while gameplay mechanics are being implemented, before we get too far along in development.

The top-alignment

Yeah, this is clearly the wackiest thing in the concept, which is why I went through and made a second version so we could try both.

In fact, if I'd had the energy to make the bottom one the default (easy to do, just go to the session_gui empty control and change "FlipGUI()" to "FlipGUI("bottom")"), your first impression would have been a lot better, I suspect.

Ironically, the top GUI was initially built on the premise of retaining those parts in the top bar like you're used to in the AoK way. Resource Pool's up the top, the menu buttons were in the top right, then started building the rest dynamically on that premise.

What I also like about having it on the bottom, though, is that the (loose) conventions are automatically reestablished, or at least reasonably familiar. Unit info's in the left corner. Map's on the right. Portraits are in the middle. And it's easy on the eyes and hides stuff until you need to see it, which was the primary goal.