React.js for UI?

I heard Battlefield 1 did this for their in-game UI.
I was wondering if this is a viable option. Does anyone have any opinions or experience?

 

I am quite sure that UI Toolkit isn't using any Javascript engine, so you cannot use React.js with UI Toolkit,

 

I was thinking of borrowing some concepts from VueJS to make the package as amazing as it can be

 

HTML/Javascript for UI sounds interesting on the one hand, but on the other hand it costs overhead for a separate HTML/Javascript engine on top of the game. Chromium on electron can be fast on Desktop/Consoles but on mobile it could be problematic from the performance as well as build size.

 

I like the idea of pure html / js for UI. Not sure how hard it would be to put in the game engine and support all platforms but for mobile there is the react native. But that might force react as the framework if this was ever to become a thing. I am sure they looked at pure html / js and found a bunch of problems they would need to overcome vs writing their own that could take advantage of direct integration with the rest of the engine.

 

If you think HTML/JS is a good idea for a Game UI, just remember in prior Unity Editors the Asset Store was one... putting an entire browser into the game is a bad idea, they chose a reasonable compromise I think.

 

I read somewhere that some AAA games using HTML/JavaScript for the UI with chromium on electron. A bad example is warcraft ||| reforged, that use it for the main menu. With bad performance.

 

The core difference between Unity and engines by triple A companies is that Unity needs to provide a platform that is good for all types of game and software on literally every relevant platform for devs of all skill levels which leans towards their new ethos of "performance by default".

That being said, I'd love to see a community driven UI engine based on VueJS or ReactJS. The thought of just throwing in Vuetify or Bootstrap for my UI makes Unity for software / app development significantly more attractive.

 

You need also a good communication interface between javascript and the gamecode/data, a simple menu send probably only events, but if you make an inventory / crafting system as example, that makes things a little more complex.

With an C# based UI you have also the power of Burst and the JobSystem, with an different engine Unity would no longer have control over it.
And with JavaScript also has limitations, more prone to errors, difficult to debug, slower, no multithreading...

 

It's a really viable options, web browsers are really light-weight, portable and small in size. Not to forget to mention HTML/CSS is one of the most powerful UI tool you'll ever use. Most desktop applications are running inside a packages browser such as Spotify and Slack. I'm using this approach in all of my studio's games both desktop and mobile. We're using a chromium fork and run a React application inside of it. -- It's true more big games such as Battlefield 1 use this approach.

 

No they are not. e.g. basic Electron app is over 100 megabytes. Chromium install package for Mac is 128 megabytes. You need certain compiler per platform to even compile Chromium, and there isn't e.g. RISC support at all.

 

I agree with kaarloew that having the browser layout engine in games is not an option. However, as an experienced web developer I have implemented many solutions over the years that use browser layout as base for other formats, mostly PDF but also SVG and AutoCAD (DXF) formats. What you do is basically iterate the DOM and extract dimensions, coordinates and styles of all elements. Then you can use these to draw the layout in a coordinate based system without layout engine, for example Unity UI. As long as the UI is not too dynamic (requiring re-layout) this should work fine. So maybe that is what Battlefield 1 did.

 

I know this thread is a bit old but in case anyone is interested, I am working on ReactUnity, which lets you create Unity UIs in React.

Stable release for runtime is still far away, but editor support is slowly getting there. I am hesitant to announce it yet but I saw this thread and cannot ignore it.


https://github.com/ReactUnity/core

 

I grabbed this to check it out. Is there a tutorial to get something running and understand your architecture better. I was making a bunch of widgets to match React components and was going to parse returns from the Firebase server. Then I was told by the Firebase guy that I should just take what he outputs which is no JSON objects. I got the sample to show the gridcell widget and it appears to parse the index.js file. Do you have any insights?

 

There is no tutorial yet, and most of the documentation is incomplete. There is only sample project you can check which I already linked in the repo.

ReactUnity does not work with HTML. The backend of the React components are actually Unity UI (UGUI or UI Elements) components.

If your Firebase app outputs something that can only be run in a browser, my project can't help you. Are you trying to get only the data from Firebase, or a complete view?

 

I as of yet do not know what the returns are, whether a .js file or I was hoping a JSON object as with other projects I worked on. The Firebase guy essentially said I should accept whatever he gives me. So I set about going thru the Adobe XD app flow and reconstructing it expecting to be able to parse the returns from Firebase. I pointed out this thread from to the project manager as it had constructive data about React and Unity. He said he had been looking at your framework before and was glad I pointed it out. Being this was time critical and your notes said it was not tested extensively and as you said docs are shy I expressed concerns about a 3rd party framework. This was seemingly misconstrued into a lack of cooperation scenario and was told to stop working immediately..thank you.... So I figured I will get in touch with the actual dev..as frankly I had set about making the same Unity framework as I saw in your C# runtime component scripts.

 

I tried the reactunity and I can see the potential. I can code the fastest in terms of UI in react so I have high hopes this project keeps going. Good luck!

 

Looks like this is exactly what I did for OneJS: 1-to-1 interop between Preact and UI Toolkit (plus Tailwind support & Live Reloading and all that jazz). No browser is involved. Integration is pure C# via Jint (Hi @KurtGokhan !)

Though this one is not free ($60 on the Asset Store, and just released 2 weeks ago).

 

Minecraft is currently doing this on bedrock: https://portal.gitnation.org/contents/using-react-to-build-performant-game-uis-in-minecraft

 

That's awesome! So they are building a React stack using coherent-labs. Some points I noted:

1) Much better onboarding.

I agree 100%. Even devs with no game engine experience can jump in on day one.

2) Keep core state on the c++ side.

Yup, that's the way it should be. Separation between UI and core game logic.

3) react-facet and fast-div stuff

While I do like how react-facet eliminates some boilerplates, I think after you identified an expensive re-render, the best performance tweak you can do is to just turn the responsible declarative code into imperative code.

For example, for the following UI sample I'm working on for OneJS, all the tweening is done on the JS side.

It's super quick to iterate when you are working with a dynamic language, especially so for the heavy Vector API usage here. I was using setState for the health bar at first and realized the dom re-rendering was a little too expensive. So I just swapped out the setState with explicit value setting and calling

MarkDirtyRepaint

, then the perf became acceptable.

So the best React Game UI workflow I have now is:

1) Just quickly do everything through your useState hooks
2) When you identify a perf issue, turn that responsible code into imperative
3) When you need even more performance (usually the case for heavy animation/tweening), do a custom VisualElement and move the tweening to C# and possiblly bursted jobs if you want to pool lots of them)

For the majority of UI, they don't need to change state every frame, and you can certainly stay in JS-land most of the time.

 

Very impressive!