Jump to content

GUI Scripting interface / game setup


Recommended Posts

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:

celtsinfo.th.jpg

Link to comment
Share on other sites

  • Replies 50
  • Created
  • Last Reply

Top Posters In This Topic

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 :victory:
Link to comment
Share on other sites

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 by historic_bruno
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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 by historic_bruno
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

What about to slightly redesign this page:

post-9635-1286226333_thumb.jpg

to something like this:

post-9635-1286226415_thumb.jpg

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.

Link to comment
Share on other sites

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 by Jeru
Link to comment
Share on other sites

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 by historic_bruno
Link to comment
Share on other sites

Ok, I decided to go ahead and implement icon tooltips :victory: 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:

post-10080-1286503033_thumb.jpg

post-10080-1286504227_thumb.jpg

Edited by historic_bruno
Link to comment
Share on other sites

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 by k776
Link to comment
Share on other sites

* 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 :victory:

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.

Link to comment
Share on other sites

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 by historic_bruno
Link to comment
Share on other sites

  • 2 weeks later...

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

gamesetupmp10192010.th.png

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...