[Official]New UI System.... coming in Unity 4.6

HTML-based UIs aren't anything new. The thing to keep in mind is that HTML is just the language used to define and store it, and that's only one small part of the overall system used to design, implement and run a UI.

The main advantage to using HTML would come from being able to leverage existing tools and/or experience you may have which are based on that technology.

 

Please answer my question

 

Your question is not related to the topic. Create a new thread and ask your question there.

 

I think the main advantage is actually the separation aspect.

Having UI declared in raw source code (like OnGUI or java swing gui or similar) will clutter up the source code and there's just no good paradigm to do it. It's also way more messy if there are multiple people involved in a project.

Having UI built in prefabs/scenes is possibly even worse (like the new 4.6 UI or NGUI/Daikon Forge). Scenes/Prefabs are hard to version control and having multiple people work on a UI becomes a nightmare. There's been so many times when we in our project have had to call out over the office "don't touch scene 4 right now" or "Oh whops I edited that prefab too, ok we have to redo my changes", and so on.

It all comes together with markup code.
You have your source, and that source has an exposed API for the markup to interact with.
You have your scenes, which can be safely used to build/contain elements that simply have to be in the scene. Like cameras, terrains, meshes using Marmoset-skies and so on.
Finally you have your UI in markup, that can be worked on separate from the rest, and can have its own versioning going on. Changes in UI doesn't require source changes (that can be potentially harmful, especially if they are done by a junior programmer), and also doesn't require changes to the scene/prefabs, which we all know are very delicate entities.

Another great benefit for us at our company (we don't do games, if you hadn't already guess that), is that we often recieve content from customers to put into our application. Text/images and often a combination of both; and even more often with specific requirements regarding text formatting. These things are always a nightmare for us to deal with; and we often end up having to explain the limitations with Unity GUI and the (not so-) Rich Text over and over to the customer.

 

I understand that it can be tricky to have the UI in the same scene as everything else. Though, if you are using e.g. Git for the version control, it often becomes quite easy to even merge scenes.
If you having that kind of issue, I don't understand why you aren't taking the UI out of the actual scene. You may have another scene just for the UI. As the scene is loaded, you call LoadLevelAdditive for the UI scene. Alternatively you may have an asset bundle containing the UI or in the future we hopefully get nested prefabs which will help with that as well. Of course, you may have to change some things in the code, because there can't be references between scenes, but you would have the same problem with an HTML solution.

You can solve those issues on your own! In my opinion this isn't an argument for an HTML solution at all.

 

Replying to both here.

Of course you can lock files, but that will in itself slow things down, and can become a hassle. You run into the whole "I need this you have to unlock it", "but I haven't finished yet, I can't commit". Of course it's better than having to redo things, but that's why I want the ability to separate things as much as possible/needed and then merge when required. Markup can be fragmented down to individual lines if need be, and the cascading nature of the system makes it easy to manage in my opinion.

I also haven't had any good luck at all with merging scenes/prefabs. And of course we split the UI scene from the other scenes, but that still means that the UI scene can only be touched by one person at a time pretty much.

Even if they make prefabs/scenes less delicate, I still don't think they are objects well suited for building UI:s. I think that's evident from watching the videos the Unity team has posted so far. The way the UI is built just seems clunky and messy; and involves a bunch of windows and editors to do the simplest things.

Also, let's take an example: User testing near the end of the project suggests that the UI feels outdated and boring because everything uses linear interpolation. How windows expand, how buttons appear, how elements fade in. A request is made to try other easetypes for the whole UI.
If you work with Sass, and has set up the project correctly, this change is literally 1 line of code.
If you work with CSS it comes a matter of a number of string-replace-calls.
If you have animations in Animator in Unity, things become harder.

I could come up with a bunch of more examples like this one, but I think the history speaks for itself. There used to be a bunch of graphical drag & drop editors that were used to create web pages, and people used to use Visual Studios / Flash builder with drag & drop as well. But then industry moved on from that; and started using XAML, MXML and more importantly things like Sass/LESS. When working with games there of course has to be a deep integration with the engine; easy ways to make UI elements follow world elements or render in world space for example. But even for games UI it is handy to change the colors/border-width/easetypes/whatever of all your elements with a few lines o code, instead of having to open a scene, manually edit properties of a bunch of items using inspector, open Animator a bunch of times and change properties, save prefabs, save scenes; and at the same time making any other changes anyone else might have done to those elements invalid or just very hard to merge.

 

Again, the technical basis that we get with uGUI will allow others to create the kind of solution you have in mind. The decision has been made long ago, that can't be changed and I think the decision was correct. You don't share that opinion and that's fine.
Having that kind of discussion will lead nowhere.

 

While it's less than ideal for games in particular, it really doesn't have to "clutter up the source code", and there are definitely effective paradigms. I agree that it's less than ideal in any case where your designer isn't also a programmer, though, and since they're two very different sets of skills... well, that's not an assumption I make.

I've always worked with fairly small teams, so the scenes/prefabs issues you cite haven't effected me much really at all. I guess another influencing factor there is that we plan ahead well enough with the limitations of our tools in mind that we design those problems away at the workflow level.

So, while I agree that separation is of very high importance, I'm not seeing how defining a GUI in HTML as opposed to any other way they can be defined is of benefit in that regard. Yes, using HTML means that it has to be separated in a Unity environment because Unity in and of itself can't do anything with the HTML - it needs to get some dedicated thing to handle that, and in doing so it's effectively separated and that in turn solves a lot of issues. However, that's not the only way to achieve that separation.

 

Just to clarify; it doesn't have to be HTML imo. What I wanted was a system with markup deeply integrated into the engine. Just like you can still move things around and drag and drop elements in the Android Eclipse UI editor or the Visual Studios editor (which both produces markup in the end), you could have something similar in Unity. It's just that having markup as the base data container for UI instead of a bunch of properties set on scene/prefab objects with manually set references and Animation curves is just better imo. Way better.

Btw, when uGUI finally hits, we ar our company will most likely build as much as possibly using code, and maybe step by step abstract that into some kind of markup for some element types. It will never be as good as something integrated into the engine itself though.

 

NO! The Android UI Designer is awful!

 

@Horp1, call it "markup" or whatever you want, any which way it's all "data". I don't see any problem in principle with the data being stored in the same way as everything else in the scene and, in fact, see a lot of elegance in that. What about it do you not like?

Also, what do you mean when you say "never be as good as something integrated into the engine"? The engine is a bunch of low level, cross-platform functionality which other stuff is built on top of, including the GUI system. What do you want to get out of it being more "deeply integrated"?

 

Have you ever, while working with an engine, said to yourself "If I had source access I could do this and this". Being able to do that is the benefit of having deep engine access. Having direct access to the render pipeline, and engine pipeline in general, allows you to do so much more. It would also allow you to possibly tune the pipeline to better suit the UI, when needed. Make sure elements are created without any extra allocation and weird GC behaviour, which plagues the C# in Unity as it is right now. In general it would be better to not parse complex markup and build the UI in slow, single threaded C# at all.

Regarding data; having data stored in prefabs and scenes sounds like really bad encapsulation and just bad design in general, to me. Prefabs and scenes aren't good data containers; they serve a bunch of other purposes, while also having the ability to store data. I just can't fully believe that after having worked with Unity, you actually think that storing UI declarations in prefabs is more elegant than having separate files.
Let me put it this way:
Say you're going to store something in your Unity project.
Do you create a monobehaviour, attach that to a gameobject, set properties in inspector, then save the gameobject as a prefab?
OR, do you create an XML, JSON or other file format and contain your data there? I would hope you do the latter.
I want to do the same for my UI.

 

I feel that we're getting way off topic here. In answer to the question about wanting source access, almost never. In answer to the question about where I want to store data, it's going to depend on the use case - I'll use the right tool for the job. Happy to discuss all of this stuff further, but really don't want to take this thread further off track - it's for feedback on the new system, and I think that's pretty important. (I'll also report this post so the mods can split out the conversation if they think it's a good idea.)

 

Ok that's effectively a non answer to my post. How can I be way off topic when I straight up answered your questions?

But ok, let's agree to disagree then, this is getting so evasive and pointless anyways.

 

What on earth are you on about? I said I was perfectly happy to continue the conversation but that I don't want to do it here because our conversation wasn't the point of the thread.

*shrug*

 

Interesting... Any ideas on how we could make a Tree View in this new uGUI? It's currently a bit complicated and inefficient in NGUI...

 

I submitted a bug report + project for line spacing in rich text size markups. Font used was the standard Arial that I think Unity grabs from System.

I just noticed when trying another font that the issue actually only occurs when the word is the first one on a line. Sorry, didn't get that into the report.

Case# 618319

 

I'm starting to get the impression that what a lot of people here were hoping for was a vector-based GUI solution - like Flash/Scaleform. In my opinion, that's best left to other developers, and Unity has taken the correct path with this new solution.

With that in mind though, you can use existing vector tools like RageSpline with the new GUI system, providing most (if not all) of the versatility you're looking for when it comes to vector UI designs.

 

Could the unity guys at least tell us if Unity 4.6 will be out in July 2014

 

Summer

 

Then what does summer mean? Till when? July, August, September? Early summer, mid-summer, or late-summer? At least give us a public beta now.

 

I've no inside knowledge. Though, given past-performance on the UI front, I'd wager it'll be late as they can, so mid-to-end of August, which is still summer.

Gigi

 

I don't see OnPointerHover or something like that. Does it exist?

Imagine an inventory. You click on a slot, then move the pointer to some other slot and the item's icon you've clicked on should follow the pointer somehow. It's like OnDrag event but not quite the same because you don't hold the button.

 

Enter and Exit should handle that, I would think.

 

But OnEnter and OnExit handlers are called only once when the pointer enters or exits a certain zone.

The reason for the OnHover event is to be able to move/drag the selected item along with the pointer until the player clicks somewhere else.

 

From the looks of it, there will have to be some sort of a build available by Unite 2014 because Training Day includes training on it, unless of course... it gets yanked from Training Day http://unity3d.com/unite/unite2014/training

Learning outcomes
The specific topics that will be covered include:

• General Unity operation, tips and tricks
• Communicating between scripts.
• Public vs private references in programming.
• Static variables.
• Vector Maths for gameplay mechanics.
• Using timers.
• Using different camera settings.
• Creating Game Objects at runtime.

• Using the Animator for Generic characters.
• Animation Events.
• Simple use of Audio.
• Using the New UI system.
• The use of Prefabs.
• Use of effects such as Line Renderers and Particle Systems
• Using the Nav Mesh for enemy characters.

 

That doesn't tell us much more than we have already. Unite is August 20th-ish, the end of summer by anyone's definition is no later than early September.

 

Can you do better?

 

As I recall, they had a similar presentation at Unite for their 2D system before it was released too. This doesn't really mean anything.

 

I believe what StarManta was saying was that you can (and should) make your own OnHover functionality - you can probably make a more efficient one.

Basically you make OnEnter set a bool "isHovering" to true and OnExit set it to false. Then in the appropriate Update function, you can check if isHovering is true, and run MyOnHover. Better yet, if OnHover is the only every-frame functionality you need in this particular script, you can skip the isHovering variable and just set this.enabled to true/false (assuming OnEnter and OnExit still get called when the component is disabled).

 

uGUI was originally based on NGUI, which gave it a solid basis that was then heavily modified.

 

It makes sense, thanks. I hope the conversions between screen space and local space of UI controls are just as easy as for usual game objects.

 

It's actually been done before:

CGS is not technically CSS itself, but it's pretty much the same thing but specifically built for Unity.

 

@ForgottenCheese
Yes those tech exist already and it is nice especially for people having a web background. And it will be possible to build simple "language" on top of Unity UI system, i just don't see Unity integrating this kind of tech inside the core of the UI. When the UI comes out, there is no doubt that you will still have access to different mark up languages or use the UI as it is. You could also easily build your own with simple xml, if i remember correctly (many years ago) World of Warcraft was using some sort of XML to create UI with a mix of LUA i think (not sure anymore), but you could also built that on top of Unity system.

People will still have the choice to build the UI the way they want throw plugin or custom made program, but you will not be forced into one specific way.

 

I've suggested that prefabs be improved to let them have cascading/inherited values from some parent. That would perhaps work well with GUI button prefabs and whatnot.

I'll at least agree with @Horp1 that I hate using the Animation editor window for GUI animations. If we have to use that for GUI, I hope it gets improved, specifically the animation curve editor, coming from someone who uses Blender and Photoshop. (Maybe I should post screenshots of what I mean)

 

ok, one thing i'm thinking about is how to have a scrollable window with this new gui system, i'm sure it should be easy, like getting the mouse position and converting it to screen coords and then moving the game object towards the coords but tbh, i'm not good at converting coordinates. it should be really small video to teach noobs like me how to do it.
thanks

 

Scrollable window will be imperative for chatboxes, achievements windows, and all sorts of things. It's bound to be there.

 

ah my bad lol i didn't really mean scrolling in window, this happens when you type late at night i mean dragable windows, like you get the title of window and drag it around to re arrange the UI in game.

 

How exactly clicks on GUI and clicks on objects can be distinguished? I`ve looked through this thread and found a notification about general possibility of this. But what is the concrete solution? Something must be called from OnMouseDown()? I`m making a game and planing to implement new UI when it will be released. Should I somehow prepare my architecture for this task?

 

This looks amazing, well done to the team. I have a slightly noob question, but I just got my head around the scripted GUI system. I looked at NGUI but was worried about the fact that scripts where attached to elements.

Will there be a clean way of interacting with buttons through scripts that we have already written. So an OnGUI button that im drawing in code has an if statement on it. Can that reference a button made in this new system?

Just a little confused on how the two things work and if I will have to rewrite my current GUI.

Cheers

 

Hey Superpig,

Thanks very much for the reply, it seems that my basic understanding of unity GUI might have finally paid off when it comes to changing to the new system. Pretty much everything in my GUI is as basic as that. With some sets of GUI wrapped in if statements on if they should be drawn or no, so as long as we can go that easy enough then I'm chuffed.

 

Hey guys at unity, you guys are making this gui look so badass, Something I would like to see in the new gui is to be able to search for buttons in the gui. We make presentations and business apps with unity that some time have a lot of buttons and it would be great to have a feature to search for the name or label of a button. Thanks for listening

 

Since buttons and all the GUI widgets are game objects, wouldn't that make the hierarchy list so long and cumbersome to look through? Any improvements on the hierarchy window to address that?

This is what my hierarchy window looks like for a project that uses NGUI:




For example, complicated GUI systems like, say, a Diablo 3 style inventory system where each item is a draggable sprite arranged in a grid.