Acumen

Team Profiles · November 2, 2004

GRAPHICS DEPARTMENT

The Graphics Department is responsible for the game's visual elements. Models, skins, GUI textures, animations, cursors are created and combined to bring the ancient world to life.

PROGRAMMING DEPARTMENT

The Programming Department develop the engine and tools that act as the backbone of game development.

SOUND DEPARTMENT

The Sound Department is responsible for the game's audio elements. Music, ambient sounds, the clash of arms, and voices of the ancient world are their domain.

HISTORY DEPARTMENT

The History Department keep a close eye on the game's design, look, sound and feel, to ensure that we represent history as accurately as possible. They also research the history of our era and write articles for the website and in-game background text.

COMMUNITY/WEB DEPARTMENT

The services of this Department are shared by all Wildfire Games developers. They support and extend our forum network, and develop our websites and online tools.

Team Profiles · November 2, 2004

<html><center>DEPARTMENT HEADS</center><center><table border="1" width=100% bordercolor="#000000"><tr><td>NAME</td><td>ALIAS</td><td>TITLE(S)</td><td> LOCATION</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=76>Jason Bishop</a></td><td>Wijitmaker</td><td>Project Leader</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=80>Paul Basar</a></td><td>Paal_101</td><td>Head Historian</td><td>Canada</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=162>Boris Hansen</a></td><td>Vaevictis</td><td>Sound Department Head, Soundtrack Composer</td><td>Denmark</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=82>Tim Koschuetzki</a></td><td>DarkAngelBGE</td><td>Webmaster, Community Administrator, AI Scripter</td><td>Germany</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=79>Stuart Walpole</a></td><td>Acumen</td><td>Programming Manager, Co-Lead Designer, and Team Editor</td><td>England</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=126>Ken Wood</a></td><td>Phoenix-TheRealDeal</td><td>Head of 0 A.D. Design Department, Co-Lead Designer</td><td>USA</td></tr></table></center><center>GRAPHICS DEPARTMENT</center><center><table border="1" width=100% bordercolor="#000000"><tr><td>NAME</td><td>ALIAS</td><td>TITLE(S)</td><td> LOCATION</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=109>Kenneth Branch</a></td><td>Annatar</td><td>Concept Artist</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=114>Michael Hafer</a></td><td>Mythos Ruler</td><td>Concept Artist</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=77>Ryan Karsten</a></td><td>irishstag</td><td>Texture Artist</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=131>Bobby Ognyanov</a></td><td>CheeZy</td><td>Artist, Scenario Designer (Lead), Intern Overseer, Game Design (Scenario Editor)</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=202>Praveen Pillai</a></td><td>Childhood Trauma</td><td>Concept Artist</td><td>England</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=78>Jordan Quackenbush</a></td><td>Quacker</td><td>3D Modeller</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=197>Malte Schwarzkopf</a></td><td>Fire Giant</td><td>GUI Artist/Designer</td><td>Germany</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=136>Aviv Sharon</a></td><td>Jeru</td><td>Linguist, Concept Artist, GUI Artist, Scenario Designer</td><td>Israel</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=112>Shan Sherrill</a></td><td>Hyborian</td><td>Concept Artist</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=110>Saurabh Torne</a></td><td>Saurabh</td><td>Low Poly Modeller and Texturer</td><td>India</td></tr></table></center><center>PROGRAMMING DEPARTMENT</center><center><table border="1" width=100% bordercolor="#000000"><tr><td>NAME</td><td>ALIAS</td><td>TITLE(S)</td><td> LOCATION</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=83>Simon Brenner</a></td><td>olsner</td><td>Lead Network Programmer</td><td>Sweden</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=230>Rich Cross</a></td><td>notpete</td><td>Lead Graphics Programmer</td><td>England</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=220>Chad Heim</a></td><td>Cracker78</td><td>General Programmer</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=260>Matt Holmes</a></td><td>Calefaction</td><td>General Programmer</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=154>Alan Kemp</a></td><td>Alan</td><td>AI Programmer</td><td>England</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=124>Graeme Kerry</a></td><td>kezz</td><td>Network Programmer</td><td>England</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=81>Gustav Larsson</a></td><td>Gee</td><td>Lead GUI Programmer</td><td>Sweden</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=191>Jeffrey Tavares</a></td><td>Zeusthor</td><td>Scripting Programmer</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=229>Philip Taylor</a></td><td>Ykkrosh</td><td>Tool Programmer</td><td>England</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=84>Mark Thompson</a></td><td>MarkT</td><td>Lead AI Programmer</td><td>England</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=102>Jan Wassenberg</a></td><td>janwas</td><td>Lead General Programmer, Code Monkey</td><td>Germany</td></tr></table></center><center>SOUND DEPARTMENT</center><center><table border="1" width=100% bordercolor="#000000"><tr><td>NAME</td><td>ALIAS</td><td>TITLE(S)</td><td> LOCATION</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=251>Ron Lacy</a></td><td>Wyrmwood</td><td>Sound Designer</td><td>USA</td></tr></table></center><center>HISTORY DEPARTMENT</center><center><table border="1" width=100% bordercolor="#000000"><tr><td>NAME</td><td>ALIAS</td><td>TITLE(S)</td><td> LOCATION</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=111>Borislav Chernev</a></td><td>Sting</td><td>Historian and Publicist</td><td>Bulgaria</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=116>Joshua Gilbert</a></td><td>Shogun 144</td><td>Historian </td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=97>Federico Odorizzi</a></td><td>fede_histpop</td><td>Historian, Scenario Designer</td><td>Italy</td></tr></table></center><center>COMMUNITY/WEB DEPARTMENT</center><center><table border="1" width=100% bordercolor="#000000"><tr><td>NAME</td><td>ALIAS</td><td>TITLE(S)</td><td> LOCATION</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=193>Nathanael Barbettini</a></td><td>CodeOptimist</td><td>Community Guardian, News Poster, VB Tool Programmer</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=1684>Joshua Barker</a></td><td>Red_08</td><td>Guardian and Web Developer</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=192>Sam Carlton</a></td><td>Ph4ntom</td><td>Human Resources</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=239>Sarah Belle Green</a></td><td>Sunshine</td><td>Public Relations and Publicity Manager</td><td>Canada</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=199>Matthew Rogers</a></td><td>chichigrande</td><td>Community Guardian</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=196>Desmond Talkington</a></td><td>King Tutankhamun</td><td>Community Guardian</td><td>USA</td></tr><tr><td><A HREF=http://wildfiregames.com/0ad/viewtopic.php?t=201>Klaas Van Waesberghe</a></td><td>Rodrigo</td><td>Web Development Assistant</td><td>Belgium</td></tr></table></center></html>

November 1, 2004

Hmm, which is more likely to have an accurate awareness of the internal development state? ZeZar, or the official FAQ? *ponders*

Though we've made tons of progress in the past year, I can categorically declare that the game is not at a state where it could be released as an open beta in a month's time.

Beta, by the way, in case there's confusion, means that the product is totally feature and content complete, and just in need of thorough user testing prior to release (which itself is likely to take a year, including the internal staff beta).

I think, however, that the quoted thread referred to earlier milestones in the development schedule, not the beta milestone, which might explain the inconsistency. But yes, the *speculative* release date mentioned in the FAQ has also been pushed forward in recent months, having had the opportunity to assess our rate of progress during the last year of implementation.

Sorry, chaps. The FAQ's preliminary date is more feasible, but we'll have to see when we get there.

October 31, 2004

Actually the building is a couple of variants of Iberian house if I recall correctly. And yeah, that's much higher-poly than we're doing now, since at the time the buildings were going to be 2D for increased detail.

The female statue is Athena, which I think Jason did for some graphics art contest.

October 28, 2004

I used some preproduction renders from Jason for promotional material when doing some programmer recruitment on gamedev.net. So I'm probably (also) to blame.

It was stuff that looked good at the time (this was before we were up to even releasing in-game screenshots), but as Malte says it's all obsolete now, so hardly worth worrying about.

October 19, 2004

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).

October 19, 2004

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).

October 18, 2004

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.

October 16, 2004

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.

October 16, 2004

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.

October 16, 2004

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.

October 15, 2004

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?

October 9, 2004

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).

October 9, 2004

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.

October 8, 2004

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.

October 8, 2004

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.

October 8, 2004

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.

October 1, 2004

I cried when the ewoks got killed... now I cheer.

I cheered then, and I cheer now.

Team Profiles · September 28, 2004

Job Title(s): Guardian and Web Developer.

Joined: 6th November 2003.

Department: Web & Community Development.

Job Responsibilities: Moderate the Introductions, General Chat and Homework Help threads.

Location: San Antonio, TX, USA.

Birth Year: 1991.

Home Town: York, Maine.

Interests/Hobbies: Piano, HTML coding, beta testing, playing AoK with friends.

Favourite Musician/Band: Chris Rice would have to be my favourite :lol:

Favourite Computer Games: AoE 2, America's Army, Star Wars Galactic Battleground.

Long Bio: Joshua Barker was born in York, Maine on the 26th April, 1991.

When he was 8, he began taking piano lessons and trying to become familiar with computers. At about 10 years old, he got a VB learning CD that was easy to understand, but very buggy. It finally stopped working, so he decided to go to HTML instead. When he was 11, he started learning HTML on and off with free online courses and a HTML book.

He is currently learning XHTML, continuing piano and is helping with the WFG RPG.

Now he is on Wildfire Games' staff, moderating the Introduction, General Chat, and Homework Help threads, and is on the web development team.

Short Bio: Joshua Barker is a HTML web developer, Pianist, and is trying to learn Visual Basic. He enjoys computers and wants to learn more about them.

Currently working on: Learning XHTML and working on the WFG RPG.

Quote: "If it weren't for electricity we'd all be watching television by candlelight." George Gobol.

September 15, 2004

No. Internal Server Error.

September 13, 2004

Well said, Malte. I hope you don't mind, Argalius, but I've added Malte's disclaimer to your FAQ to make that abundantly clear.

August 9, 2004

Okay, done. Thanks.

August 5, 2004

This isn't exactly a bug, but more of an amusing workaround. In Baldur's Gate, they had a fallback mechanism should it be scripted for a character to speak dialogue, but for some reason he's not on the map (you've killed him, he didn't spawn correctly, etc). A mysterious character called Biff the Understudy would materialise and read his lines for him. The show must go on.

August 5, 2004

Just for the record, we're planning to make 0 A.D. available under Win2k+ and Linux systems, and currently the engine works perfectly on both platforms.

August 4, 2004

Klaas: Good idea about the wooden temples. It'd be ideal if we didn't have to do some forest grove, as it needs to be able to produce units, do research like a normal building. Would be a bit strange.

Sign In

Acumen

Posts

Joined

Last visited

Content Type

Profiles

Forums

Posts posted by Acumen

Departments

Staff

Some confusion about the beta date at WL (warlord)

2 things I've found about 0AD

2 things I've found about 0AD

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

Experimenting with Controversial GUI

The Best Star Wars Movie

Joshua Barker - Red_08

First Poll

Modding FAQ

Audio Design 5 - Voice List

Best Game Bug

What 0S Do You Run?

New Screenshots - 8/1/04

Forums