NGUI developer leaves Unity, New GUI?

OK, I'll explain who I am, but really having no time for going deep into GUI implemention discussions.

I'm the author of eDriven.Gui, one of the GUI frameworks for Unity.

And yes, I actually communicated on this subject a lot:

- I wrote a lot of suggestions about building a GUI system throughout the forum
- also in descriptions of my early YouTube videos and answering to subscriber questions
- answered a lot of e-mails to lot of people
- commented on few Unity announcements
- suggestions via other channels directly to UT guys
- in my speaking proposal for Unite 2012 talk (April 2012, answer: "aren't sure it's a good match for Unite's audience")
- in my job application (Summer 2012)
- in an interview with Unity tech lead, face to face via Skype (September 2012)
- etc...

Without going into details: I think that Unity's 2D sprite system is really great. However, the GUI framework built on top of it could be much better. Back in 2012 they've shown a serious system. Now it seems like they gave up all the vision and made a safe fallback to the NGUI type of ACS system.

I admit I am biased and maybe spoilt by using other systems on other platforms. That's why I don't like arranging GUI bits and pieces by hand, but instead creating a new instance of components programatically (however complex they might be) and add them to the component tree. I'm a programmer. That's how I imagine the essence of a GUI system.

 

Over and over you tell us that the so-called ACS system is bad, but not once have I seen you explain why. Your article mostly says that "better" stuff exists, and the closest it gets to unearthing an actual flaw is to suggest that the collision system is "overkill" without any form of analysis to demonstrate why.

To be honest, all I really get from your article is that the so-called ACS system doesn't suit your style preferences, largely based on personal expectation derived from the huge amount of prior work you've done in systems of other styles. That's perfectly reasonable and there's nothing wrong with it, but it's not the same thing as the ACS system being as terrible as backward as you imply.

Also, for what it's worth, creating components programatically is often fine for programmers if you only think about programmers. The issue with that as an approach, when considering game development as a whole and that you usually have more people on your team, is that having visual design tools often allows you to optimise your workflow at a higher level:

1. Why have a programmer spending hours typing in and tweaking GUI layouts when a graphic/UI designer could just drag it all out themselves?

2. Why increase the turnaround time between the graphic/UI designer and changes they want to make by having a programmer in the middle when you don't need to?

Between both of those things, a good visual design tool leads to much faster iteration and a potentially better quality output in less time, while simultaneously freeing up some programmer time to add more features, fix more bugs, or otherwise polish something that couldn't be done by a non-programmer. In short, everyone gets to work to their strengths.

 

I think you have an incorrect expectation of whom you expect to be using Unity. Unity is not a programming tool. It's front-end focus has always been more on design side of the game creation process than the engineering side. (As you can see when you need to launch an external IDE to edit code.) Are programmers still necessary part of the equation? Absolutely! However, Unity should not have a code-driven user interface for something that can be WYSIWYG and friendly to all disciplines. Even if you have to sacrifice some functionality to do so.

In your argument you seem to bash the A(tlas)C(ollider)S(cript) approach a lot. However, Unity is fundamentally not a OO design paradigm but actually a component based one. I actually feel an ACS approach fits a lot better with how Unity as a whole is intended to be used with behaviours/components attached to GameObjects and each component driving a specific aspect of the GameObject as a whole. I'm not saying it's perfect, and I completely respect your opinion to disagree. However, you don't usually get the best system for YOU, you get the best system for US.

Also, for those clamoring to remove the IMGUI, please don't. It's still useful for UnityEditor scripts. Although it being deprecated and not ported/tested on non-editor platforms I could definitely get behind if it means less overhead for Unity Technologies.

 

People keep saying things like this as if OO and CO are somehow mutually exclusive. They are not. Components can be (and usually are) implemented as objects as per OO, and that's how it's done in Unity. It's not one or the other, it's both.

I think that what most people mean when they say this is that Unity favours composition over inheritance. And, in that regard, the so-called ACS approach to GUI implementation is spot on in line with the way everything else in Unity works. And, for what it's worth, it's not Unity specific - I remember using a similar system in Java way back when I was in university as the example system for component oriented design.

 

Yes, that is a more accurate description. Thanks!

 

Good luck with that, guys.

IMO Unity had a chance to become much more than a game engine, and become a platform - much like Flash - after Flex was built on top of it (back then everybody thought of Flash as an animation tool). It could have become really huge in many areas, given the ability to export to multiple platforms, and C# scripting. Much like Xamarin.

But yes, for games - the ACS type of GUI is probably good enough.

 

I don't see the logic here, though that could be because I've no idea what you mean by "many areas". For instance, there's a lot more than the GUI system that makes Unity sub-optimal for non-real-time applications. An ACS GUI system, for instance, is a very small issue compared to the fact that game engines fundamentally update at 30+hz regardless of whether anything is happening (side effects of which are things like extreme power inefficiency while idling).

Having said that, I'm not familiar enough with Flash to know if it has the same drawbacks. Does Flash, like a game engine, also update at 30+hz even when nothing is happening? (That would explain Apple's resistance to it...)

To me, that's far more "overkill" - and with measurable, real world impacts - than using a collider-based click detection system on a component oriented GUI.

 

I don't even believe this is true, not in my experience anyway, and I'm a programmer.

A couple of years back I wrote a UI system that had to be 'programmed', and it's been used in most of our projects (and is still being used in one ongoing project by a colleague). More recently I wrote a UI system that was 'visual' and pretty much everything is setup in the editor, and I'll never go back! It probably halved the time it took me to get HUD/UI elements/screens into the game.

 

Another programmer here. I absolutely hate having to do everything in code for something that's fundamentally visual in nature. It's tedious to create and tweak. That's why Unity has a visual editor for 3D stuff and not just code. The GUI is the same.

That's not to say there shouldn't be full code support, though. Sometimes, you really just need to code things to get it done right. Whenever possible, both methods should be available.

 

I'm with ya. To be honest I mostly wrote that to highlight the contrary case. While I'm also not one of them, there are coders who'd happily or even preferentially do this stuff in a code based manner. But even if they do like it, I was pointing out the wider spread effects that has on a team and a project - it means that graphical/design stuff is bound to a programmer, the graphics people have less direct access, the code guy is spending more time on that and less time on other things, so on and so forth.

But yes, I personally agree, to me the very act of having to code it by hand is also a downside. I don't mind it too much with purely functional stuff (eg: editor tools), but for something that's meant to be polished for presentation? No thanks!

 

Indeed! So long as I can use code when I have to (for lists of code objects, etc.), I'd far prefer a visual-first solution. Even for boring application GUIs this is true, so for the far simpler yet far visually fancier GUIs of games, it's a no-brainer. Is the new GUI system up to it? So far it looks promising: we already know how to create GameObjects programmatically, and that seems the entire basis of it.

 

It's all about the level of abstraction. Both Flex and eDriven have visual GUI editors, but properties being set visually are at different abstraction level than with ACS GUIs. For instance when you put the list control on stage, you don't deal with positioning individual cells, labels etc., but instead setting higher-level properties like DataProvider, list's total width and height (as a whole) and similar.

Now, although having the visual editor available, the fact that you can do it from code makes the system more powerful/robust/extendable/performant.

For instance, a list control is also created programatically using the same code-based system the one would use with coding approach. However, it is adapted for using in the editor.

That's why I keep repeating myself that the visual editor should only be a sugar on top and not the core feature you are starting with when building a framework. Or else, you are looking for trouble.

The GUI system could work perfectly and recursively if and only if complex controls could be built programatically, using the same system. Also, this is the way for 3rd party vendors for building and distributing their custom controls.

With GUI systems like HTML, WinForms, Flex and Swing - putting the control on screen (visually) edits the XML tree and also the code part called "code behind". The XML markup is then during the compile time (Flex) - or at runtime (eDriven) - being "replaced" with "real" comoponents. Much like your browser turns the XML markup into the DOM tree holding interactive elements. This way you are dealing with componentes indirectly.

This preprocessing phase - in styleable systems - allows processing of the CSS; this process maps CSS properties to components targeted by given selectors. This is then a centralized place where you could tweak GUI look and feel visually. Changing the button color in one place changes all the targeted buttons on the screen.

I always felt that the CSS abstraction gives designers more freedom and power then in the old system - where they were supposed to set everything inline in HTML. And ACS systems totally remind me of old prehistoric pre-CSS HTML because there's almost no abstraction (btw Unity prefabs are not the solution to this problem).

Here's a video of tweaking the GUI created with eDriven using CSS-like stylesheets:

 

My "engineers" are experiencing so many issues with NGUI, mostly on a bug that incapacitates a person to make a keyboard entry. Their only solution was to have him access the participants' browser to go full screen. Can someone suggest me a solution so I can communicate to my "engineers" to fix me?

HumanoidMe

 

But the abstractions you provide to your GUI don't need to have anything to do with how stuff is implemented under the hood. If you want to give high-level controls (which, I completely agree, are missing from at least some of the currently popular solutions) then it shouldn't matter whether it's an ACS system or a windowing toolkit or a web browser or someone painting it on a canvas under the hood... it's your job as the editor designer to handle all of that for them.

Agreed again. But a) you can always do it from code in Unity anyway and b) that's still not an argument for "code first" as opposed to the unified approach that's commonly being taken.

I absolutely agree with this. However, once more, it's an implementation/design problem, not an underlying tech problem. The fact that I'm using an atlas and a collider and scripts has nothing to do with why I can't easily re-style my GUIs. That comes down to the people designing the GUI system not considering that flexibility past the concept of swapping out atlases (which is plenty for more than 95% of use cases, so I'm actually ok with that).

You've got a whole bunch of genuinely good feedback and ideas here. You're just trying to pin every problem in the world on underlying tech that has little or nothing to do with it. Styling is in no way constrained by the use of atlases, colliders or scripts, nor do any of those things stop us from being able to make high-level design editors, nor do they stop us from having decent code APIs (though, again, I'll accept that writing a GUI in code in currently available systems would be ridiculously verbose compared to systems actually designed for that).

 

I did check new Apple's Swift language, and its Cocoa framework is pretty standard and similar to all the major GUI frameworks (programatic in nature).

It seems that only Unity has a totally different concept (if there's a concept at all).

 

Here's another video:

Notice that Cocoa layout is constraint-only based, much like it was presented in new Unity video.

AFAIK iOS doesn't have container layout managers, which is a pitty.