So i just have rendom thoughts literally all the time(not even a slightest over-exaggeration)
And i stumbled across the question on ‘is the UI efficiency with SH’s approach?’
As some of you know, SH uses a edited version of Chrome (or some way of it) to display and use the UI
This is sort of a Question to you Codey people, since i know little about this subject to be honest
Is the Chrome UI apporach of SH really effective?
To me, it seems like having a UI engin that isn’t custom to the game engin seems… 'Awkward’
I don’t know much, but using a UI engin built for the game engin seems more logical
This…probably isn’t a big thing, but it’s more of a ‘I MUST KNOW’ situation for me
The huge benefit of using Chromium for your UI is that you can create UI elements and interaction using Javascript and HTML. These are purpose-built for user interface. Making a custom “UI engine” for Stonehearth would take enormous amounts of work just to have it work as well as the Chromium package, and in the end I could almost guarantee that it wouldn’t be as dev-friendly as an HTML based solution.
With HTML, anything you’ve ever seen on the Internet can be put into Stonehearth. Hell, I’d wager that with enough networking chops, you could have this Discourse running straight in Stonehearth.
The downsides of this approach that I can think of include having to package an extra library with your code (that is, Chromium), but that’s not really a downside for a distributed game (as opposed to a live website, where extra libraries you load cause your page to load slower). Also, yes, sometimes developing in HTML is annoying (I particularly hate styling), and building a custom UI package for Stonehearth may result in less buggy interactions right now… but, of course, the price you pay is that your UI will no longer be moddable (or, at least, not as easily moddable). Writing your own UI engine means, for a mod-oriented game like SH, writing an API for that engine – aka a way for modders to change the UI.
If Radiant was never planning for people to mod SH, yeah, they’d probably kludge something up in QT or whatever UI library is popular for C++ nowadays. But for it to be moddable, you want the process to be a) possible and b) as easy as possible. Making UI in HTML hits both of those points.
Also, just from a personal standpoint – I am completely on the other side of the fence on this issue. I think that their using Chromium for UI was a brilliant move, and they managed to integrate it quite well into SH. That said, I am a little biased, my day job being a web developer. I’m looking forward to the day that we can package UI into our .smods.
I haven’t modded in a while, so I’m not sure. I think you can put new UI in, but you can’t override the currently existing UI. I believe @Drotten’s Hearthlings of Many Faces mod uses custom UI. But if you wanted to, say, add an extra button to an existing profession, you’d be out of luck.
Again, not 100% sure because I haven’t modded in a while. None of this is documented, either, so you need to actually go digging through Stonehearth.smod to see how Radiant does it, and then approximate your own efforts to their example. But Radiant’s got a leg up on this in that they dont need to override any of their own assets – they just change them because they own the original stonehearth.smod. Modding in general, as I understand it, is a low priority right now, so it’s understandable they’re not in a big hurry to put this functionality in.
I personally think it’s beautiful how Chromium gives them some UI debugging for free - it’s interesting in the dev streams on the UI to see Tom view the source and make some tweaks in real-time.
It’s also very stable and documented. If there’s anything wrong, they know it’s not the fault of the UI system itself.
On the other hand, HTML and CSS have gotten pretty convoluted over the years, so it’s definitely not all great.
Although there is some truth to that, to be perfectly fair, I don’t think there’s a better alternative. You could use XML, I suppose, but then you’ll have to define the rules for every XML tag yourself. Again, it might start out as easier/neater, if you keep going and adding rules on top of rules, eventually you’ll be left with a scarier, messier spaghetti than HTML/CSS could ever be.
