UI engine revamp

[zoot]

If we are considering revamping the UI engine, we might as well begin by determining our requirements. Here are some relevant tickets:

- #107 Improvements to Styles

- #108 Retrievable Sprite Properties

- #109 Various Bugs/Requests

- #110 Relational Coordinates

- #112 Expansive Controls

- #114 Style Skinning Support

- #116 Entity-Aligned Controls

- #698 Better support for keyboard input

- #850 Improve mouse button 'release' event handling

- #885 GUI code improvement

- #1090 Improve load game UI

- #1338 Add 'learn to play' item to in-game menu

- #1386 Bug in GUI text wordwrap logic

- #1532 Dropdown improvements

- #1538 Improve health / status bar appearance

- #1616 Support umlauts in all in-game fonts

Other suggestions:

- Data-driven by a standard layout format like HTML/CSS.

- Must support integration of scripting with SpiderMonkey.

- Support for Unicode strings and integration with a future system for translations.

- Support for standard font formats like TrueType.

- Support for SVG images, for scalability.

- Support images of any size (non-power-of-two) natively.

- Easily extensible, to accommodate future changes in requirements, not 'sandboxed' to simple presentation of text.

- Not bloated with useless features like geolocation

- Must be GPL compatible.

- Must be usable inside SDL, alongside OpenGL graphics.

Your suggestions?

Edited August 23, 2012 by zoot

[dvangennip]

- Not bloated with useless features like geolocation

I just came up with a reason to have use for it -> if a multiplayer lobby is added, it could be a good way to find people nearby (if that is someone's preference). Also game statistics could be helped by this.

[zoot]

Certainly for statistics, the IP address should be sufficient (unless you want to track stats down to the street level?)

[myconid]

• Avoid deprecated fixed pipeline functions for GUI rendering.
  

[zoot]

Another point to consider is that if it is capable of doing what we need with standard HTML5 (as opposed to custom markup), the UI doesn't break if we want to try making the game run in a browser one day.

Edited August 18, 2012 by zoot

[MishFTW]

Here are some notes I've been updating.

Some things that would be great to have:

• HTML5 (canvas and SVG)
  
• CSS3 media queries
  
• CSS3 animations!!
  

These two things above can help make a responsive GUI (a UI that adapts and changes layout to fit the screen size) very, very, painless.

I'm glad we're considering this guys

each civ/type must have a Aesthetic design in UI to be specific in Session in game.

for example Greek must have Architectonic greek ui, with columns, greek patterns, plants, i dont know.

This can be easily done I believe.

Edit: zoot: Chrome is the flagship browser at the moment for HTML5. The W3C has already gone past its last call for the standard in 2011, and will release it by 2014. By then, most (if not all) browsers of the day will support it. (Off-topic: MS is killing IE6 in 2014 too)

[azayrahmad]

each civ/type must have a Aesthetic design in UI to be specific in Session in game.

for example Greek must have Architectonic greek ui, with columns, greek patterns, plants, i dont know.

+1 for this.

Also, if it's not too much to ask, 'citizen manager' in-game session,

Unlike any other RTS, the citizen-soldier type really requires more management. In other RTS, economy handled by workers, while soldiers are either patrolling or amassed in preparation to attack. In 0 AD, I',m sure many people don't just amassed idle citizen-soldiers. They better be workers until you have enough of them to attack. And when you ready to attack, you probably have lose track already of who's working where. So I propose citizen manager

This is will be a table of resources and amount of female/soldiers who gather them/

For example:

wood 3/5 means wood resource is gathered by 3 female citizens and 5 citizen soldiers

[Mythos_Ruler]

each civ/type must have a Aesthetic design in UI to be specific in Session in game.

for example Greek must have Architectonic greek ui, with columns, greek patterns, plants, i dont know.

I disagree. Civilization V is a very successful game, but it only has one UI aesthetic for all its factions. Same goes for the Total War games. One can argue that the current UI is ugly and that it needs redesigned. But if one were to make such an argument, one should be prepared to give specifics.

[zoot]

In any case, that is a content issue. Engine-wise it is easy to support either case.

[historic_bruno]

The most obvious requirement is JavaScript integration and in particular, behaving nicely with Spidermonkey, since I don't think anyone wants to change our script engine at this point, nor transition to a different language. Well irrespective of whether someone wants to do that, I don't know if anyone is willing to put the effort in designing and troubleshooting such a massive change So whatever the system, UI events should pass down to JS via Spidermonkey. It should integrate well with SDL and OpenGL too.

I wouldn't call this a requirement per se but a "nice to have" feature is the ability to design a modular UI, so that for instance the minimap is one module, the unit details panel is another, the command panel is another, etc. We could then leave the exact configuration (position, style) of these modules to the user. People who like corner layouts get that, people who like center layout get that instead. Currently our GUI pages are very monolithic, which makes modding and style changes difficult and as for different layouts and code reuse - forget about it. Imagine if all that was required to radically change the UI layout and appearance was loading a different CSS?

Also, the current GUI engine is all static objects, created at load time (the lone exception I know of is sprite textures which can be scripted, but of course the object itself must support the "sprite" property). It would be nice to have the ability to dynamically create UI elements and not have to define everything in advance in XML or even HTML/CSS.

More radical idea: could we ditch wxWidgets and integrate the Atlas scenario editor UI into the engine itself? This would have an added bonus, possibly, we could make a web-based scenario editor (I've dreamed about a web-based random map design tool for some time, why not go all out?) We'd lose the benefit of platform specific appearance and behavior - not sure if styles would fully solve that, but we'd ditch a massive library that's only needed for Atlas.

More tickets:

http://trac.wildfiregames.com/ticket/114

http://trac.wildfiregames.com/ticket/116

http://trac.wildfiregames.com/ticket/850

http://trac.wildfiregames.com/ticket/885

http://trac.wildfiregames.com/ticket/1386

http://trac.wildfiregames.com/ticket/1532

[historic_bruno]

By the way, if anyone is tempted to work on this, I would point out the list of planned gameplay features, which should be higher priority http://trac.wildfiregames.com/wiki/GameplayFeatureStatus

[MishFTW]

I disagree. Civilization V is a very successful game, but it only has one UI aesthetic for all its factions. Same goes for the Total War games. One can argue that the current UI is ugly and that it needs redesigned. But if one were to make such an argument, one should be prepared to give specifics.

I think no layout should change, the UI must be a globally recognized one. Just slight aesthetic changes such as a panel background texture (kind of like how the selection panel has the emblem) would work.

[Almin]

I disagree. Civilization V is a very successful game, but it only has one UI aesthetic for all its factions. Same goes for the Total War games. One can argue that the current UI is ugly and that it needs redesigned. But if one were to make such an argument, one should be prepared to give specifics.

Well, AoE2 was also a very successful game and did exactly the opposite. And I have to say, that I really loved the UI of AoE2, but that's just my personal opinion.

[abral]

I think XULRunner would be a good solution, it's certainly simple to use SpiderMonkey with it.

[zoot]

I guess XUL isn't quite HTML/CSS (not that HTML/CSS has to be an ultimate requirement), but it does seem like an improvement over hacking together our own format.

I wonder if it can play nice with SDL, though.

[abral]

I guess XUL isn't quite HTML/CSS (not that HTML/CSS has to be an ultimate requirement), but it does seem like an improvement over hacking together our own format.

I wonder if it can play nice with SDL, though.

XULRunner can render also HTML/CSS, somewhere in one of the Mozilla pages there's an example of a small browser written using XULRunner.

[zoot]

XULRunner can render also HTML/CSS, somewhere in one of the Mozilla pages there's an example of a small browser written using XULRunner.

Sweet! From their FAQ:

If I use XULRunner do I have to write my application in XUL?

No! You can write your application in any language supported by the Mozilla web platform, including HTML, XHTML, SVG, or XUL.

Do you happen to know anything about its memory footprint?

[zoot]

By the way, HTML will also make it much easier to do things like help pages and tech trees in-game.

[abral]

Do you happen to know anything about its memory footprint?

It should be pretty light. Firefox has made huge progresses in memory footprint lately.

[zoot]

Apparently, 'sprites' in the UI are basically immutable So no softly fading or pulsating UI elements

[MoLAoS]

If its of any interest I am currently attempting to integrate and test out libRocket with my significantly altered version of GAE, the Mandate Engine. I could post some opinions on how it works out after I get it tested over the weekend.

[historic_bruno]

If its of any interest I am currently attempting to integrate and test out libRocket with my significantly altered version of GAE, the Mandate Engine. I could post some opinions on how it works out after I get it tested over the weekend.

I'm sure people will be interested, but my enthusiasm for libRocket waned substantially when I discovered it doesn't use standard HTML/CSS

[MoLAoS]

I'm sure people will be interested, but my enthusiasm for libRocket waned substantially when I discovered it doesn't use standard HTML/CSS

My understanding was that there are some slight differences between libRocket and the browser versions. But most of the basic features are identical. I haven't checked it all out but the differences are minimal in most senses. A test RML document in the samples/shell that was copy pasted from my website appeared to work fine. libRocket lacks some features but, adds others.

I was thinking of maybe making some changes to make it more standards compliant since its open source.

I am taking a break from adding support to my engine to work on stuff that is more fun for me, I don't particularly enjoy graphics programming in any of its forms, I like to write game logic and other stuff is just something I have to do to do that.

I should have a great deal more useful information after I finish integration next weekend.

[MishFTW]

I downloaded libRocket for a personal project and first impressions are pretty good, despite some cool CSS3 stuff. I have started on a replica of the main menu using libRocket. Will update in a few days

Edit: its not standard and kinda sucks. I've already contacted the Awesomium guys and for non-commercial projects it is free but to get the source code we will have to buy a license. I suggest implementing the full Webkit library instead of depending on third parties and their conflicting licenses.