Ways to create UI for Unity outside of Unity

I'm searching for the ways to create UI for Unity projects outside of Unity to avoid taking innocent UI designers along the scary road of learning UGUI, prefabs and all the quirks of Unity workflow.

As of now I've found several major options:

• Rive + Noesis: Rive is online animation/design/FSM creation tool that exports to .riv files that can be played in the Unity with Noesis
  
  
• Noesis by itself: works by presenting XAML-defined UI that can be created in Microsoft Blend for Visual Studio, for example
  
  
• Coherent Gameface: renders web stack inside the engine, so all the Web infrastructure is at our disposal.
  

Do you know/can recommend any other solutions?

 

No, unless you have unlimited amount of cash to burn. I wouldn't want to deal with third-party stuff in the UI case. UI Toolkit and/or UGUI aren't that complex that UI people couldn't learn fairly quickly.

 

Licensing and/or pricing is pretty bad for these external tools. They're typically aimed at AAA and Industry. Unless you have multi million dollar budget, it's likely not worth the hassle and the inevitable integration issues that come with external tools like these.

Imo, asset store is the best place for UI alternatives right now. I'm looking forward into diving in Nova UI now that WebGL support has been added: https://assetstore.unity.com/packages/tools/gui/nova-226304#description

And for the web devs there's OneJS that adds TypeScript support for authoring UI in Unity: https://assetstore.unity.com/packages/tools/gui/onejs-221317

 

Noesis is free until you hit $100k.

 

There's also the small print at the bottom:


A lot of these are not acceptable to me, but the last one is cherry on top.

 

Figma.

https://www.figma.com/
https://assetstore.unity.com/packages/tools/utilities/figma-converter-for-unity-198134

 

I know your pain but to be honest, it's best to let the UI Designers hack away mockups in the tool of their choice, and a programmer then converts this into Unity UI layouts. As long as they talk to each other this is probably going to be less painful than any third party solution.

The third party GUI framework solution is risky in that it is likely to simply take away burden from the designers but then slams it onto the programmers tenfold. They now have to figure out how that API works and why this file has stuff missing or that file throws an error on import and how to hook up events and how to make it not drain so many CPU cycles and so on. It's hardly going to be a win-win unless you evaluate the solution(s) extensively, and even then it's risky because the bad stuff might only rear its ugly head when the project is half-way done.

 

You are blindly follow into the trap, of the design and integration spagetti bolonese.

If you use any third party API, i.e. by implementing web browser, to allow wite UI with HTML5, or other, you also need have the interface, to communicate with an engine. So now you entering the region that you, or other dev need design and write an interface, so the other dev of UI can work. As most likely person won't know Unity.

If you work with native uniy API, you got high probability that person knows Unity well, as well as can design and build UI, while integrating to the game/application.

 

Wouldn't they have to learn the quirks of those programs? It feels like moving the problem, rather than addressing it.

If the problem is designers needing to implement their own designs in-engine, they're going to need to learn new software either way; there's no getting around that.

I would personally suggest just letting the designers design the UI in whatever program they want (my guess is XD or Illustrator), then have an actual programmer/technical artist implement their designs in-engine. No one needs to learn new software, beyond their already relevant fields of expertise.

 

Adobe XD is not that great if the design needs to be responsive. The way that XD does responsive resizing is not a 1:1 match with Unity's RectTransform and Layout components, and more often than not, Unity can do some layout with UGUI that XD cannot do as easily.

However, my project currently does end up using Adobe XD for easy collaboration with Cloud Documents vs passing around screenshots and PSD files. The designer would change something and I can see it realtime, and I would chat with them to iterate on details. Once the design is finalized, I'll take over the process by exporting a rendered board and replicating the design in Unity with UGUI components.

The thing that bugs me with using any middleware is that if it is not powerful enough to justify bringing in the extra size and complexity, it would ended up being a pain in the A and I have to just go fully native, e.g. UGUI or UI Toolkit in Unity's context. And TBH with this line of thinking UGUI is even more native as it's just GameObjects, where UI Toolkit has its own realm that uses a different system for manipulations.

 

UI can be very problematic for performance targets if not taken care of. Might be much less of problem for desktop/console games (most consoles), but still you can easily chug the UI of those if care isn't taken. A third party tool may exacerbate the issue by being overly generalized. You really want your UI person (or team) to not only know the UX and Design part, but how those choices are going to impact performance. And to understand the tech to knoq what is practical and not.

If and when UIToolKit is mature and stable, it will come closer to that, as it has an editor and there is a strong separation of view and model. Plus it leverages layout from tested web tech like the pdl, css, yoga, box model, etc. ...when it is ready.

(edit: horrible grammar)

 

Thank you! I will definitely look into those.

Programmer's time is also quite costly. And when a studio works on a mostly-UI project and finds its developers spending big portion of their time recreating in UGUI visuals authored elsewhere, pricing starts to look differently.

 

Designers do have to learn their software. Still their software is made to create visuals. Unity was not. And as far as I understand, for a designer Unity UI authoring presents quite a learning curve.

Yeah, mature UIToolKit would have solved the issue, I think.

 

That licensing term should not only be unacceptable to you but to everyone capable of rational thought. INDIE DEVELOPER BEWARE. Insanity like this could kill your project. Avoid at all costs.

 

Yeah, websites or apps, not Unity UI visuals. You will walk this back as soon as you encounter UI generation problems and you will have to touch all of your UIs by hand because it is: slow, sluggish, doesn't work, animation doesn't match, whatever.
Meanwhile if you ask the people to learn Unity's basics and maybe watch some UI performance presentations, they (and you) would achieve the same but they actually would do what is your goal is: UI visuals in Unity.
I am not against middleware by any means I think for example Fmod or Wwise are great for audio. But I also have contacts who already use those software so they don't need to learn it from scratch. Also audio is more simpler, less things can go wrong.

But that's just me, obviously.

 

UGUI's constraints based relative sizings and (therefore) innately responsive design facilities are a boon to designers. It will take a little time for them to familiarise themselves with it, but once they do they'll love it.

Your developers should work on helping them see when and where to use new/extra/more canvases, as dirtying of canvases is the single biggest performance drain if the canvas has a lot of nested objects in it, as all objects in a canvas must be re-solved, and so on, for all constraints of all things in it, when one thing moves, or changes size, or is otherwise dirtied.

Apart from that, prefabs aren't a difficult concept for designers, they're the same as what's called "symbols" in most design programs.

The other quirks of Unity's workflows are somewhat OK for designers. They can point their output (most likely from an image editor like Photoshop) to export into folders and hit refresh to see changes.

All in all, UGUI is probably one of the most designer friendly features in all of Unity, I think.

 

Further, and possibly separate, hence a different post, there's 3 massive advantages to using UGUI:

World Space! You can put elements at angles like Division's UI, or much more complexly. And move between them via cameras, or move them around, or both.

Animation Legacy is PERFECT for all animation and juice needs within UGUI, and is a similar timeline to AE, that which just about all good designers have fought with at some time in their lives.

Audio is built into Unity, and can be somewhat rigged through ScriptableObjects so your designers can try out different sounds easily, as they'll be wanting to match/sync the audio responses to their animations, and vice-versa.

Steer them clear of Animator Controllers and everything to do with Animator and Playables workflows. They'll get infuriated with these things. Similarly, avoid Timeline. It's a pig.

And I know you want more... UGUI is fully TextMesh Pro compatible and its ideal host. TextMeshPro is the unsung hero of Unity.

The below is 100% TextMeshPro, on a UGUI Canvas, using Legacy Animation:

 

Just quoting because this can't be said often enough.

 

This is sweet!

 

UIToolkit is not that bad, unless you need game controller support then welcome to Hell.

 

Has anyone actually tried Nova UI?

I will not try an external UI system again after NGUI I think, which was/is flawed & Unity managed to introduce a bug that destroyed that system in one project and they took years to fix it (if it even is fixed!).

I plan not to try UIToolKit until they say it is actually fully functioning for runtime use (tend to do complex UIs)