Implementing A New UI

[MishFTW]

Around the middle of 2012, I was going through 0 A.D.'s GUI code. It looked somewhat inefficient and intimidating. On top of that I saw many suggestions and changes (most notably the match setup screen). I thought to myself (remember this was during the development of the new website), why not replace the entire GUI with something that can be easily modified, looks nice, and is much faster than the current GUI? I decided that HTML could be used to write the content, CSS could be tapped to really make this thing look awesome on various screen resolutions and finally the actions could be handled and integrated into the engine with the existing Javascript engine. I searched for various solutions and one of the top hits was a 3 year old post made by Ykkrosh (Phillip Taylor) that was aimed a creating a similar system. There was mild interest along with skepticism when I brought up the topic 3 years later. Community members pitched in and offered various solutions including XULRunner, EA's version of Webkit, and libRocket. More recently, Yves has started work on a Javascript debugger for the game. Since the engine uses SpiderMonkey, a web-based UI (theoretically) can be easily implemented through bridging it with Gecko, Mozilla's HTML rendering engine. Until this point, it has all been speculation. But here is our chance to try it out. In the process we could address many of the GUI tickets and just create a better UI.

Pros:

• Highly modifiable
  
• More people can quickly pick up the HTML and CSS vs XML
  
• With CSS the entire UI can be "reskinned" or rearranged in a fairly easy manner without touching the content side of things
  
• Using CSS media queries, designers get more flexibility for different layouts depending on screen size
  
• Using CSS, designers don't need to get programmer help in order to change the UI
  
• Using jQuery, designers can create "drag and drop" components for the UI
  
• Allows for implementation of a more content rich UI with possible server-side documentation and help
  
• Opens a whole new level of awesome things to come (POTENTIAL)
  

Cons:

• Might have negative impact on memory
  
• Some would argue that HTML isn't the best way of doing UIs
  

Steps for testing:

• Set up a fork from the Git repo
  
• Select an engine (Webkit, Gecko, etc.)
  
• Use what we need only (cut out the bloat)
  
• Test embeds of various apps
  
• Create a source/gui/html directory to store all the files
  

[zoot]

Since the engine uses SpiderMonkey, a web-based UI (theoretically) can be easily implemented through bridging it with Gecko, Mozilla's HTML rendering engine.

Let's be abundantly clear: replacing the current UI engine with something else will not be easy. Anyone who thinks otherwise should just go ahead and do it.

The fact that SpiderMonkey and Gecko both happen to have a Mozilla logo on them does not make it any easier to change all the existing code that relies on the old engine.

Since no one has been able to come up with a HTML mockup of how the UI could look, I'm a bit skeptical that it will ever be suitable for this purpose. If we can't even come up with the HTML, how should we be able come up with all the deep C++ integration code it would require?

That said, I still think it's worth considering overhauling some of the existing UI engine code. It has many little shortcomings (like not being able to change colors dynamically) and the XML format isn't overly easy to grok (what are 'sprites'?).

[MishFTW]

Let's be abundantly clear: replacing the current UI engine with something else will not be easy. Anyone who thinks otherwise should just go ahead and do it.

...

Since no one has been able to come up with a HTML mockup of how the UI could look, I'm a bit skeptical that it will ever be suitable for this purpose.

...

(what are 'sprites'?).

I know its not going to be easy. The whole point of posting it was to convince those who have the understanding to do it

In fact, I did start a mockup. Its not much and its definitely not ready for primetime but I plan on adding a bit to it whenever I get the chance.

And sprites are thoroughly explained right here.

[zoot]

Not CSS sprites The ones in the current UI engine.

[feneur]

A couple of comments: First, I'm not sure this is really a Design Committee issue now that I think about it as it doesn't have anything to do with the game's design or actual gameplay but rather with how it is implemented. Still, as it's such a major change if we were to go through with it I think it can warrant an overall decision here.

Second, it would be relevant to create a post in the public forums as well as the Design Committee isn't necessarily the best equipped to make decisions on programming issues as only one member is a programmer. Good, I see now that you have

Third, understandably as you are a proponent of this idea you list more pros than cons, but there certainly are a few more things to take into consideration:

• If we'd change to another system for the GUI all the existing implementations would have to be redone, which could take more time than it would take to finalize it using the existing system (especially since XML isn't that different to HTML (CSS might be a good comment pro though, but you've mentioned it thrice so... ).
  
• Adding an HTML engine would either add another dependency for users who build the game themselves or add another library that we would have to keep updated if we decide to include it with the game.
  
• Adding an HTML engine to the game (as opposed to just including it as a dependency, which I have no idea whether or not we can do, at least on Windows which doesn't do those things as easily) would mean that the size of the game on disk would increase. Probably not too much, but still, it's better to mention all the things now so we are sure we make the best decision.
  

Some comments on the pros:

• Highly movable
  

Could you please explain what you mean by this? (You should at the very least be able to edit your original post) I'm assuming you might mean the possibility to move things around on the screen?

• Using CSS media queries, designers get more flexibility for different layouts depending on screen size
  

In the case of completely different layouts this is an argument pro an HTML based system, but afaik you can still do a fair amount of things with the current system since you can use relative units (might even be the only way, I haven't been looking too closely at the GUI code/XML).

• Using CSS, designers don't need to get programmer help in order to change the UI
  

You don't need that now either, you need it to add completely new functionality yes, but you'd still need that with a new system as that would still be done via JavaScript.

• Using jQuery, designers can create "drag and drop" components for the UI
  

Could you please explain this a bit more? I mean if it's just about copying and pasting pieces of code you most certainly could do that now as well. Though I guess you might need to edit it slightly to e.g. make sure you don't put two buttons in the same place, but I can't see how that would be different in an HTML based system.

• Allows for implementation of a more content rich UI with possible server-side documentation and help
  

It's one thing to make it possible to connect to/update the documentation, but we should most definitely not make server-side documentation the only way to do things as not everyone will want to be connected to the internet to play the game. We have to make a game for single-player users as well. This is not really an argument against the use of an HTML based system though as this could be done even with an XML-based system (though it could definitely be made easier with an HTML based system).

• Opens a whole new level of awesome things to come (POTENTIAL)
  

The existing system could hypothetically do things we can't do with HTML, so this argument goes both ways. After all, if we want to add some new feature to the engine (rather than the GUI) we'd need to add it ourselves regardless of whether or not we'd be using an XML or HTML based system.

All in all, I think this is an issue where we really can't make a theoretical decision. In other words, as zoot said in the public discussion thread, someone needs to make it before we can make a decision.

[quantumstate]

Merged this thread with the one in the Design Committee forum. The Design Committee is for game design decisions not technical decisions.

[MishFTW]

Thanks for diving in and taking the time to reply Erik. I've got some rebuttals to make if thats alright. I'm just not as good as you when it comes to words though

If we'd change to another system for the GUI all the existing implementations would have to be redone, which could take more time than it would take to finalize it using the existing system (especially since XML isn't that different to HTML (CSS might be a good comment pro though, but you've mentioned it thrice so... ).

The beauty of picking HTML over others is that there are people readily available to switch over. With even three people the whole thing could be ported in less than two weeks. (Actually the numbers seem a bit arbitrary but my point is there are people ready for this, myself included.) And I was listing specific features of CSS

• Adding an HTML engine would either add another dependency for users who build the game themselves or add another library that we would have to keep updated if we decide to include it with the game.
  
• Adding an HTML engine to the game (as opposed to just including it as a dependency, which I have no idea whether or not we can do, at least on Windows which doesn't do those things as easily) would mean that the size of the game on disk would increase. Probably not too much, but still, it's better to mention all the things now so we are sure we make the best decision.
  

I'm not saying that Pyrogenesis should be packed with a web browser. That would be counterproductive. We merely need an engine that can be easily modified (to remove the excess not needed for our applications). It is no easy task but it has been done before. A great example would be Overgrowth.

• Highly movable
  

Could you please explain what you mean by this? (You should at the very least be able to edit your original post) I'm assuming you might mean the possibility to move things around on the screen?

Sorry I meant modifiable. Autocorrect is to blame Basically, chances are that more people can understand HTML/CSS/JS vs XML. Also an HTML solution would mean cleaner organization . The entire UI could be changed very quickly by modifying only certain CSS properties.

• Using CSS media queries, designers get more flexibility for different layouts depending on screen size
  

In the case of completely different layouts this is an argument pro an HTML based system, but afaik you can still do a fair amount of things with the current system since you can use relative units (might even be the only way, I haven't been looking too closely at the GUI code/XML).

Modifying the current system to only get a portion of the benefits of a new system? With media queries, there can be a resolution independent UI.

• Using CSS, designers don't need to get programmer help in order to change the UI
  

You don't need that now either, you need it to add completely new functionality yes, but you'd still need that with a new system as that would still be done via JavaScript.

I meant in terms of adjusting the layout or content. For example, the new match setup screen or the unit portrait panel (recent examples) required changes the most artists couldn't just go in and make.

• Using jQuery, designers can create "drag and drop" components for the UI
  

Could you please explain this a bit more? I mean if it's just about copying and pasting pieces of code you most certainly could do that now as well. Though I guess you might need to edit it slightly to e.g. make sure you don't put two buttons in the same place, but I can't see how that would be different in an HTML based system.

Well with HTML, we could get the DOM (document object model) which allows for interactions of objects and other great things. Here is a draggable demo.

• Allows for implementation of a more content rich UI with possible server-side documentation and help
  

It's one thing to make it possible to connect to/update the documentation, but we should most definitely not make server-side documentation the only way to do things as not everyone will want to be connected to the internet to play the game. We have to make a game for single-player users as well. This is not really an argument against the use of an HTML based system though as this could be done even with an XML-based system (though it could definitely be made easier with an HTML based system).

No, it was just a potential suggestion. But you're right, its a lot easier

• Opens a whole new level of awesome things to come (POTENTIAL)
  

The existing system could hypothetically do things we can't do with HTML, so this argument goes both ways. After all, if we want to add some new feature to the engine (rather than the GUI) we'd need to add it ourselves regardless of whether or not we'd be using an XML or HTML based system.

Yes, but in my opinion the HTML solution has a better chance because more people understand it. On top of that, many innovations are happening in terms of web technology that we could implement vs writing our own. I guess I'm trying to say... why reinvent the wheel? Moving to an HTML system means there are alot of demos and examples.