Build GUIs in HTML/CSS/JS instead of native elements

Disagree.

I want less control over the gritty details of rendering.

I can make a webpage look however I want without writing a patch for how Chrome renders HTML. The whole point is that there is a standard. There are probably 100 million people who already have some idea of how to make a page using HTML. If we change it even slightly now there are 0 people who know how to make a page in your slightly different system.

On top of that DOM updates are already hella expensive. Imagine what would happen if we built an HTML renderer in Lua. Gross. And then we want to update the native GUI system slightly and we break it all. Gross.

11 Likes

Just because you can work around something doesn’t mean the default behavior is good. OP entails better defaults for GUIs – better defaults that can be used by everyone without requiring every person who makes a GUI ever to develop their own, personal, independent library.

6 Likes

I can’t really argue about the GUI system being a nightmare to work with. However, I don’t think writing in a markup language is the best way to go about with handling this. Do you guys really think modern game engines use HTML to handle their UI displays?

I think they should provide better built-in functionality for snapping GUI elements to certain points and resize in certain ways, instead of completely dropping the current GUI system in favor of HTML.

If anything, I get more used to HTML/ CSS/ JS via Roblox :wink:

Oh- oh god… like… 95% of my programming experience comes from Roblox now that I think about it…

2 Likes

Yes.

10 Likes

What we really need is a UI system similar to what Apple offers with Xcode. Even though HTML/CSS would be cool to work with, I don’t think it’s really meant for game UI (just like JavaScript isn’t meant to be a server sided language, but NodeJS is awesome).

3 Likes

I agree. The ROBLOX GUI system is too limited for even what I’ve wanted to create with it. Being able to use CSS would be a huge improvement.

5 Likes

There are also a lot of people using http://www.autodesk.com/products/scaleform/overview

What’s the deal with this Merely1 guy. We want the real Merely.

4 Likes

How dare you reveal his true identity!

2 Likes

I’ve wanted this for forever. Thanks for bringing attention to it :sparkling_heart:

2 Likes

Awesomium does not work on half of the platforms we need it to work on.

Web technologies in general are very very very very painful to implement. There’s no way we’re doing any HTML/CSS/JS implementation ourselves.

Performance implications are unclear.
Hell, they are clear - performance will be a huge issue.

In VR you have to rethink UI anyway.

So, yeah, the likelihood of this happening in the next few years is… not very high.

8 Likes

Here’s another way to think about this.

In ROBLOX - and in any other engines or games I’ve worked on really - every single technology problem is your problem.

You’re using FMOD to play sounds? FMOD is crashing on this input? There’s no version update? You have to work around this issue or fix the code yourself.
You’re using PhysX for physics simulation? It is slow on this level? You have to work around the issue or fix the code yourself.
You’re using CURL as an HTTP implementation? It does not compile for Xbox One? You have to make it compile, or stop using it.

Basically, every single dependency you have is a liability. Games are memory constrained, performance constrained and aggressively multi-platform - and making the libraries you use work in these constraints is fundamentally your responsibility.

It should go without saying that the size of the dependency (e.g. in lines of code) is inversely proportional to your ability to solve the issues as they come up.

Any web browser implementation is several times bigger than the rest of ROBLOX codebase.

This gives you an idea of the cost that we’d have to pay for “just embedding a web browser”. Studio is using a web browser (QtWebKit), runs on just two platforms on a fixed set of web pages without memory or performance constraints. And we had to solve WebKit issues many times, including patching the source.

10 Likes

Back in like 2007-2008, Roblox did actually support HTML GUIs. It was before I started learning how to script so I never used them and I can’t remember the reasoning for removing them, but they did exist.

3 Likes

Personally, I would think something like XAML would be better. It’s more suited to being played about with code, and has support for advanced features like event binding, data binding (e.g. instead of updating the Text property, you update a table entry and the UI automatically updates) and also ‘markup’ extensions so you can make your own ‘classes’. (e.g. a TextBox with autocomplete)

1 Like

do you mean something like this @zeuxcg?

http://devforum.roblox.com/t/in-relation-to-more-gui-design-power/15698

Building out a reasonable GUI framework from scratch is also a huge project.

I wonder if there is middleware that could help make the ROBLOX GUI system nice to use/modern in the near term. I want to spend more time thinking about what should my GUIs be and less about how do I implement this.

From the developer’s perspective the current pain level in terms of both managing fiddly bits (rescaling (especially text), images, fonts, etc) and in limited range of expression is high.

2 Likes

https://playrust.com/friday-devblog-10/
Would be neat to see how Rust did it in Unity since it still maintains being cross platform.

1 Like

I’ve always had a fascination with LUA and have made recent ventures into dabbling with more widely used languages (in terms of the web).

With a broader understanding of these concepts, I think this would be something that should have been implemented a long time ago.

this was necrobumped for some silly reason but you should probably read this reply

tldr: extra dependencies add extra complexity

we would get ui blur from elements and wayyy advanced ui using html and css

backdrop-filter: blur(10px);
1 Like