GUI Scripting interface / game setup

[historic_bruno]

Civ selection and info are working now. It's not the most exciting thing to look at, but the thought that all that info can be changed by editing one XML document - is pretty cool. In fact it is a copy and paste job to add new civs. It's all specified in JSON.

It could be livened up by maps, timelines, and GUI themes for each civ (also specified in JSON of course).

Screenshot:

[Ykkrosh]

The ease of manipulating JSON data in scripts makes me think much or all of the civ data should also be in JSON. Inside an XML document seems to work well for those things that *might* be engine specific (since we have a quite capable XML parser). I'll write one up and see how it looks.

Our approach until now has been to use XML for everything, but we haven't needed to pass data directly to scripts until now. (Most XML files are only processed by the engine, and entity template XML files are heavily modified by the engine before the simulation scripts get to look at them). It feels kind of weird and inconsistent to start using JSON, but I can't think of any serious technical disadvantages - it's easy to read and write in JS, it's easy to process in external tools written in Perl/Python/etc, it's easy for humans to read and edit (as long as they don't want to add comments). Only problems I can think of are that it's harder/slower to parse in C++, but if it's necessary we could add an API to make it easier (though it'd probably still be slower), and that it's harder to do automatic validation of the file format, but we don't really do that for XML files anyway and it hasn't been a big deal.

So I think using JSON is probably good now.

Whatever diplomacy variables were added have likely been lost by now.

Yeah, there's no diplomacy stuff in the rewritten simulation code. I've tried to make sure some components (RangeManager (used for finding enemy units) etc) support players in alliances (e.g. their API takes a list of players to consider, not just a single player), so hopefully it won't need any fundamental changes anywhere, it just needs all the little details to be added in.

Civ selection and info are working now.

Sounds great

[Jeru]

Civ selection and info are working now.

So great to see a mockup I made a year ago is brought to life in code!

[historic_bruno]

Any thoughts on dynamic GUI controls? It looks like the GUI manager is static now, meaning it loads all controls from XML. Which is fine most of the time, and it may work all the time. But I'm trying to think of ways to have controls that change number and position based on game data.

For example, it would be nice to have a tooltip button next to each entry for civilization info (see above screenshot or Jeru's mockup). The content changes from one civ to the next. That presents it's own challenge in trying to find absolute coordinates of the displayed text.

I guess I could pre-define the maximum number of such buttons needed (which constrains the amount of e.g. techs and heroes available for mods), and then hide the ones I don't use. It just seems like not the optimal solution.

What about a special character sequence that could be inserted in text and creates a button? Kinda like how the tag works now.

// Example of dynamic button
techCaption = "Othismos " + '[button name="techToolTip1" sprite="infoSprite" sprite_over="infoSpriteOver" size="0 0 100% 100%" tooltip="The classical phalanx formation was developed about VIII century BC...." /]';

Possible / impossible?

Edited September 29, 2010 by historic_bruno

[Ykkrosh]

Dynamic creation/deletion of controls would be hard, since the whole GUI engine was designed with the assumption that it would be static, so I expect many things would potentially break (mostly by crashing with invalid pointers) and I'd prefer to avoid that if possible.

For the special case of tooltipped icons in text, it might be easiest to add special support for that into the GUI engine - it already supports "[icon=foo]" to insert symbols (defined in common/setup.xml), so I guess we could add tooltips to those icons somehow. Probably depends largely on how powerful/generic we want this to be.

[historic_bruno]

Awesome, I had completely overlooked icons. That's one piece of the puzzle

I like the idea of tooltips for icons, if it's not too complex to implement. The reason is they can (optionally) tell the user what an icon means, which is typical in GUIs. Good example: a help screen which references icons from the game in the text.

Possible solution is to add a child object for each icon in the text box, with properties that it has the identical size and position of the rendered icon. Also a unique ID would need to be associated with each icon instance. If the icon object were placed "in front" of the textbox, it would be the mouse_over object (for that event). The event handler would need to pass the icon's ID to the script callback function (may or may not be implemented). That would allow arbitrary handling of the event. We would have to make sure to clean up those objects properly when the textbox is updated, as the icons could change or even disappear. I guess that's a lot of overhead, but then icons shouldn't appear in text boxes too often.

I haven't been familiar with the GUI engine for very long, so maybe there are good reasons why that wouldn't work.

Edited September 29, 2010 by historic_bruno

[Ykkrosh]

I think the danger with adding child objects is that the GUI engine might have pointers to the objects (when tracking focus, or when in the middle of an event handler on that object, or via a script value corresponding to the object, etc) and then delete the objects (e.g. when replacing the parent text box's content) and then try to use the pointers. That would be the same problem whether the objects were created dynamically by scripts or dynamically by special icon-handling code.

I'm not really sure what's a good solution, though. I'd guess maybe keep a single GUI object and have some extra code in GUITooltip to make it trigger tooltips based on some function of the mouse position determined by the GUI object, so the text box can trigger it when the mouse is over an area it knows is an icon (and then it can update the tooltip text too), or something like that, but I don't know the details.

[historic_bruno]

Here's a new ticket which encapsulates the above changes (across a number of other tickets)

#590: Game setup / civ selection improvements

[fcxSanya]

What about to slightly redesign this page:

to something like this:

I changed header colors to "128 0 0" and "names" font to bold. Also I removed info icons, because as I far as I understand they are not working for now (not show tooltip on hover, I mean). Maybe my version not better (or even worse) - I offer it simply as a variant.

[Jeru]

I agree there's no point in having info icons if they don't work as tooltips.

The red-on-grey is hard to read.

Can someone implement something closer to my original mockup? (Zero margin between certain boxes, semi-transparencies closer to the mockup where the titles are a little darker and the content is much lighter).

In a later stage I will gladly reproduce some images and we can keep working on this.

Edited October 4, 2010 by Jeru

[Mythos_Ruler]

I would also like to create a faux-parchment texture for the background.

[historic_bruno]

Thanks for the responses. The icons can be removed for now, indeed they are not implemented yet, only for mockup purposes.

I was lacking some graphics, like several transparent sprites for the background, so I didn't make it look as close to Jeru's mockup as I would like. And I wasn't sure I wanted to make those in the first place.

It raises the question of whether there should be a different sprite for each level of transparency, or a way to control transparency for a single sprite. Just an idea. If transparency property could be added it would save clutter and data size, vs. having to upload many different sprites to achieve similar effects:

<object type="image" sprite="bkTranslucent" size="0 0 100% 39" transparency="50%">

Edited October 5, 2010 by historic_bruno

[Jeru]

I would also like to create a faux-parchment texture for the background.

Go for it.

[historic_bruno]

Random thought: There may be some value in hotloading maps and civs, which is not currently done (Now you have to reload game setup or civ info dialog in order to see changes).

Edited October 5, 2010 by historic_bruno

[historic_bruno]

Ok, I decided to go ahead and implement icon tooltips Also made several other changes to bring civ info closer to Jeru's mockup. I found that you can in fact set sprite transparency, at least when it's a solid color (do this by specifying alpha level 0-255, the 4th element of the "backcolor" property), so disregard that comment.

Making some more changes to game setup in general as mentioned here.

See what you think:

Edited October 8, 2010 by historic_bruno

[k776]

Awesome work. Hopefully look forward to seeing this in Alpha 2. How far off are you from completing it?

Some quick comments:

* IMO, the number of players shouldn't be a choice dropdown, but determined by the number of town bases in the map, and the amount of player rows should be determined by that too.

* Player 4 and Player 6 are a bit hard to read. Infact, they could all do with being on a darker background.

* Reveal map / teams locked etc would also be nice to have in a semi transparent box like the other elements.

* All three columns in the civ info screen should be equal width.

* Can probably get away with 1px less font size

Edited October 8, 2010 by k776

[Mythos_Ruler]

I think these screens should be all about functionality for the time being. The graphics will definitely be redesigned sometime in the future.

[historic_bruno]

* IMO, the number of players shouldn't be a choice dropdown, but determined by the number of town bases in the map, and the amount of player rows should be determined by that too.

Oops, that's a bug. I think when going from random maps to scenarios it doesn't hide that control again

As far the player colors being hard to read, I fully agree. Not decided on a way to address that yet. Maybe the player colors should be in the "assignment boxes" only - with the white background that is more legible.

Thanks for the comments, it should be completed soon, once I make sure there are no major bugs introduced.

[Mythos_Ruler]

For reference, here is how Rise&Fall and Age of Kings do their setup screens:

Rise&Fall uses a separate box for the player color, while in AOK the "player number" is the player color. If you choose the same player number/color as someone else, then you play co-op.

[Jeru]

The usability of these forms is terrible. (And they are usually ugly too).

[historic_bruno]

Shouldn't non-hosting players be able to choose their own player assignment (slot #, civ, team # if applicable)? Right now the host has to set everything. Of course if it's a scenario with predefined civ and teams, then those dropdowns would be disabled.

At the risk of UI clutter, there could be an option like "lock settings" for the host, so only then can choose player assignments.

A "Computer" player assignment should be added for when AI will take the spot.

Edit: And while I'm on the subject of dropdowns being disabled, maybe the disabled state could be text with no dropdown visible. Would look less cluttered.

Edited October 8, 2010 by historic_bruno

[historic_bruno]

Here's a crazy idea, create a border around the player box with the player's color. That way it combines multiple related concepts into one control.

[historic_bruno]

OK, I added player color boxes (with a new sprite type for solid colors). Also chatting shows the user's name in their player color, but if they're not assigned yet, it will be black. I'm thinking maybe the host should have a different font or something to stand out if there's a lot of chat, but right now players don't actually know who the host is (since even the host is a client treated like all the others).

[Mythos_Ruler]

The usability of these forms is terrible. (And they are usually ugly too).

Explain. I always felt the AOK multiplayer setup screen was the penultimate example of good usability for such a purpose (there is always room for improvement though).

[liamdawe]

Explain. I always felt the AOK multiplayer setup screen was the penultimate example of good usability for such a purpose (there is always room for improvement though).

Me too i never ever had a single problem with them.