NGUI developer leaves Unity, New GUI?

But you and Goldbug aren't quite saying the same thing. To quote you previously:

Goldbug is saying that you can plan for a tool that might come out in the future, and still not put yourself in a high risk position.

Say you know there is a 50/50 chance the new Unity gui will come out in the next 4 months. You can come out ahead (on average) by planning your time differently. If you put most of your time into non-gui work, and only use a bare-bones gui to tide you over, there is a chance you'll benefit from the new gui when it comes along. Of course, there are limits to Goldbug's strategy. If you run out of other stuff to do, or you get to a point where you really need a bigger gui, it becomes less and less beneficial to wait for the new gui.

 

Yes, fair enough. What I meant in that first statement is that you shouldn't plan such that success relies on something that's not yet available. Plan based on what you do have, but indeed plan to take advantage of stuff that you know might come along in the case that it does.

 

The conflicting stories...ergh.

No offence to ArenMook at all, but I bought NGUI and I liked it because there wasn't anything better at the time. But I want something better and different from Unity; not a fork of NGUI.

 

Sure, but the issues with NGUI aren't with the output, they're with the tools and processes, right?

 

For me, it was clunky at times to work with, and organize so that sounds about right. Except, I wanted something that was more sophisticated with dynamic content. A system that let me focus less on UI programming and more on my game specific coding. If that makes sense.

 

Ugg... Here's a pro-tip: high quality, high efficiency, high maintainability professional work is almost NEVER done by dragging S*** around until it seems to look OK. For instance, of all the billion dollar dot coms based on websites or any of the "wow, this is awesome" web demos you've seen, you can bet ABSOLUTELY NONE of them coded their freaking sites in Dreamweaver. Prototype / concept sketches, maybe, actual production code, hell freaking no.

Are there really people who have high hopes that the "new gui" will be significantly better than the alternatives and some kind of revelation in API design? I've pretty much lost all hope after spending another day with Shuriken, which is the probably the most utterly and amazingly brain damaged "API" I've seen in a long time, yet Unity are super proud of it like a parent putting their 2 year old's finger painting art on the fridge... Hey, guys, ever heard of simply passing a Func instead of trying to enumerate the uncountable by putting a bajillion differnt knobs and thresholds on a bajillion diffferent types of duplo blocks? It's freaking mindboggling how hard and ridiculously labor intensive it is to kinda sorta approximate things that would be done for real with 1 simple line of code, like say, time squared alpha fading.

 

Blast from the past but if you had used the Delphi (version of pascal) windows GUI toolkit, drag and drop, WSYWIG development it was a thing of beauty. Combined with the fact that it used it's own clean, simpler but powerful UI class architecture that was way better to use than Microsoft's. Funnily enough I think MS ended up employing the Delphi language designer for C#.

Out of interest what is the best UI development environment that you have used?

 

qtDesigner is a true pleasure to use

 

Makes perfect sense. Even in Master Thief there was a lot of time spent on what is ultimately a small number of quite simple GUI screens. NGUI definitely gets results, but it takes time to get there. It's very much nuts-and-bolts oriented, rather than output oriented, as far as fitting into a production pipeline goes. The person making the GUI has to understand what a whole bunch of stuff does that, in other graphic design related areas, they don't. So a good GUI with NGUI currently requires two somewhat disparate skillsets. Though it does seem to be getting better as it goes.

 

Doesn't need to be. As long as it's integrated, available to everyone, and has comparable features to the alternatives... I'd be very happy.

You shouldn't have to buy an alternative to get a decent ui setup, and you shouldn't have to use the current ui for play mode asset interfaces just to be sure that everyone can use it. It's a pain to use. Coding dynamic sizing and positioning, building basic things like scrollable combo boxes.. nobody got time for that.

 

Dear Unity (And all y'all GUI hopefuls),
After 3.5 years of waiting for the Saviour, the ultimate GUI, the new GUI, that probably was the most talked about must have feature we could never have, I think it will be a good idea to stop pursuing this never ending adventure. Unity on it's own is a wonderful engine and I'm sure all of us devs agree. At this point, I feel like this mature engine should focus on reach and optimization for more platforms. DFGUI, NGUI, EGUI, and GodKnowsWhatElseGUI are all doing a pretty good job at fulfilling our GUI needs for now. Yes they come at a cost, but every dev (even indies) serious about monitizing their games must not see $70 as a set back? And if you do, the Immediate mode GUI should be more than sufficient to fulfill your indie needs. Also, let's not forget the awesome 2d framework which can double as a GUI Builder of sorts, with a little work. And yes the Immediate mode GUI is less than sufficient, but I feel the reason why there's been an uproar from the community about the need for a new GUI is because unity took up that responsibility in the first place, even Unreal leaves that stuff to scaleform to handle.

In short, all I'm saying is, dear Unity, please drop the FGUI project! (F for forever) and focus your energies on everything else that makes Unity the Awesome Game Engine it is!

Best regards,

 

While the new GUI will be out, I can't help but think you make a very decent point. Going forward I'd like less peripheral work on things that middleware does indeed cover very well and more options to be able to make efficient middleware instead. So that's things like opening up parts of the engine more, giving developers better control. That sort of thing enables people to create the solutions in asset store.

We could start with proper nested prefabs, lower level access to the engine's inner workings, proper asset streaming with editor support - instead of a GUI that everyone *thinks* they need but already have a large amount of solutions for.

I'm not taking away from the somewhat heroic effort on unity's part to bring a GUI to the masses, but its a lesson both Unity and the community need to learn: don't ask for what you can already do well enough. What next? 3D package built in? How about Photoshop? just no. I need to see optimisations, bug fixes and features completed. I need to see a more open engine - even if it means breaking things here and there.

My grandfather was a royal engineer in the army. And he'd say things like "no good can come of a bad start", "Start a job and finish it" and "A job worth doing is a job worth doing right". Of course he's right.

Stop spreading thin, focus on the core next gen features done fast. 2D and GUI was well catered for with middleware. Regardless, that's over with now and I hope Unity don't make the same mistake again.

 

After seeing this thread quite a time recently in gossip forum, I am wondering if it is necessary to gather all the GUI building techniques and make a tutorial . Unless your game is really really GUI heavy(lot of GUI) and you want your GUI to be build magically over short time, you DO NOT need a new GUI or any third party GUI tools to buy, period.

 

Relax it's going to be here once it's done Unity's Tim has confirmed that it's nearly ready, can we please lock this thread already or just leave it alone and let it age gracefully!

ED: Wish I never mentioned it now, apologies to the UT New GUI team!

 

To be honest I think the issue could potentially have been 90% addressed with documentation rather than engineering. I'd love an official and awesome GUI solution, but as I've been saying for quite some time, the majority of the problems people have with the existing GUI functionality stem from using the wrong tool for the job in the first place. There have virtually always been other GUI options available, including the built-in scene-based stuff.

Getting people started on the right foot and managing expectations could have handled a lot of the negativity about GUIs reasonably well, I think. For instance, an official tutorial on a simple, mobile-friendly GUI could have gone a long way. Also, having the documentation on OnGUI point people towards other options for mobile / GC-critical apps could have been helpful. I think a huge part of the issue was a large number of people thinking that OnGUI was the expected way to do things instead of being aware of the other options.

Still, I'm very much looking forward to what's coming.

 

This, god damn, this.

And next time you guys design an API, design it for POWER, SIMPLICITY, AND FLEXIBILITY FROM CODE, then have optional components that give artists an inspector friendly "make game" layer with all the knobs and controls you can think of ON TOP of that. Or let the numerous asset store entrepreneurs do it for you. Cause, lets be honest here, you guys are not the best (read: terrible) at designing APIs. (Shuriken, Curves, etc)

Design a clean, solid, SCRIPTABLE, allocation minimizing core with proper documentation and the community will do the rest.

 

I really couldn't have put it better myself.
Thank you.
It's a really good thing that some of the core components of Unity are as good and bug free as they are (things like the Asset Importer and the Scene View + Inspector), cause many parts of Unity are amateur level stuff with little to no use for professionals.

 

That's the kicker, right? I can't imagine working on the new GUI being any less than a crucible of a job. It's kind of like the Duke Nukem Forever of GUIs - after so long and so much hype there's very little chance that it'll live up to expectations*, and everyone and their dog has jumped in and filled the gap to such a degree that much of the intended benefit has already been realised in some way.

I won't be upset about it whatever form it takes, within reason. It will be a new tool to add to my collection to use if and when it suits the job at hand. As long as it's a good advancement on what's built in I'll be happy, as I wasn't expecting a revelation in the first place. But I do think that many people are probably expecting something that is to the best Asset Store GUIs what they are to the built in stuff... and that's probably not going to happen, because that's not really a reasonable expectation.

But the guys working on it are probably under a lot of stress because of the time pressure, the expectations, and the competition. It's certainly not my ideal job.

* On the other hand, this is the internet and expectations are ridiculous, so who cares? Still, it can't help stress levels.

 

Smooth P described the problem very good. I think the main question is: Does the unity wanna be generic-purpose engine, with the "complete" API where user could tweak or better override the stuff in core (Doesn't mean that the whole core should be replaceable, but the things that make sense); or the drag-and-drop application with half-baked API, where the greatest new feature of the year is embedding the Ads into the game (sarcastic note).

 

Artist here - Shuriken is pretty cool and I really like it. Please talk for yourself and not for everybody. Personally I do not share your oppinion.

 

Shuriken is fine when using the UI. But if you have to go in and change something programmatically, it's very hard to access some of its functionality. Legacy was better in this regard. The same goes for mecanim too imo. Good UI, but annoying API.

 

A robust API is extremely easily to extend with a fancy UI, either by Unity themselves after a while, or even better, by people like us. I've already created tons of fancy Inspector UI:s for all kinds of custom code stuff, and I bet most senior Unity programmers have done the same. Learning to not base any kind of software system around a UI is probably one of the first things any programmer will learn. The only major developers that seemingly hasn't realized this is Unity and Apple (with the horrible XCode).

 

Shuriken could and would have everything you like about it AND MUCH, MUCH MORE (including the aforementioned time squared alpha fading, and sqrt time alpha fading, and, ...) if it had an actual programmer friendly API behind it instead of a API tied directly to the specific knobs and controls they thought up in the brainstorming session for the UI at the time.

By speaking on your behalf, programmers who can make UIs for artists and other editor users will make your job easier and increase your artistic freedom and ability to do cool and amazing new things. (If UT listens...)

 

Well, about the only bugbear I have with shuriken right now is that I can't easily set which image of a tilesheet each particle uses in code without some frankly pathetic hacks. I also would like to have a programmed particles give be some feedback as well and I'm not sure that part is working well. Unity have said "we listen to feedback" but where? Certainly not listening that hard at navmesh or shuriken complaints. I guess they are busy at the moment. I am ok working around it. Is everyone?

 

I concur and would add Lightprobes. Seems like many of these systems / components could use some love and be easily improved if someone was assigned / tasked to look over them a bit more.

p.s. throw in nested prefabs too ... whatever happened to that? We saw a demo several Unite's ago and then silence.

 

Yeah, I also get the impression that some stuff is rushed to release and then stagnates where some relatively straightforward improvements could go a long way. Shuriken in particular I found to be nearly unusable on initial release.

Having said that, I do think they listen to feedback, I just think that there's pretty huge disconnect between the feedback given here on the forum in particular and the actions eventually taken, potentially a fair way down the track. I know that when I've wanted to discuss things with them outside of the forum I've got a response every single time, and some of the fairly recent updates for Mecanim have allowed me to address issues I was discussing with them via email just a few weeks ago (possibly a complete or partial coincidence). Also, on the professional front, we've had Unity reps come to our office (in a pretty out of the way corner of the world) more than once, and Pro license holders (and possibly normal licenses? Not sure) do get surveyed from time to time about future direction and where we'd like Unity to focus.

 

Didn't they say that nested prefabs would come before or with the new GUI system, as it was a requirement for the new GUI?

 

Ah - okay. I didn't know the API was that bad. I agree that it should absolutely be as good ans the UI interface.
The thing is: Extending a good API with good extensions surely is a very good and also certainly an extremely powerful thing to do.

BUT - firstly not everybody has time, money, and/or a programmer to extend API first. Even if I had that possibility every day of my life - I would first have to KNOW what the API is capable of. Knbos and UI usability are a very important factor - otherwise Unity would not be where it is today. Saying otherwise is a rather narrow view of a programmer who does not understand the needs of other people.

The way you explained it the problem made complete sense sense to me and I think both are important and the way you explained it it.

 

I think the NGUI component that Unity hired the developer to do has been finished and the usefulness of that component was overestimated - Unity was already capable of such things the NGUI developer simply formalized it and now has done so in a similar way for Unity.

The part that the NGUI developer had no good knowledge in was a 'business and government centric' 2D GUI - one that could easily bind 3D simulations with 2D summaries and user controls: something to replace all those failed platform-independent Java client solutions that never took off.

 

The new Gui system will be released in the 4.6 version.
I found this in the official Unity blog (http://blogs.unity3d.com/2014/03/18/unity-5/)

 

The asset store eventually needs a package system like pip / npm / apt-get / yum etc (allowing old versions as well) and sharing the code development on github like Epic would be very beneficial at least for releases. I probably should make a thread or request about this. It would make everyone's versioning much easier but you can still do this internally.

As for the GUI, any software project that has been delayed a long time usually falls short of expectation. Any timeline over 6 months will be at least double that or more for a system of this magnitude. What will be nice is sharing semi performant samples/code with the new Unity GUI rather than the old one that should have been incrementally replaced. Here Unity has built up a large wall they need to scale to be successful, that is why I think they released Shuriken particles and Mecanim before they were done really. Both awesome but the former was missing particle collisions for a long time and Mecanim is still lacking in code access over the editor which I think is backwards but plays to their strengths/selling point of the editor.

I am sad to hear the NGUI developer left, late to the party, but making a UI is hard to please everyone. I think that NGUI had the best approach. I use EZGUI, NGUI and DF and they are on a scale of components to simplicity. I like components that you can still 100% code over just editor approaches for re-usablility. I think the NGUI approach refined would have been the best for the Unity GUI. I need to spend more time with DF but found it slower on mobile currently which will probably improve but it is new and well designed.

But third party assets and the asset store are great, Unity makes great software but the power of crowds and the 1% in that will be better than internally almost always because they have different constraints. Unity being augmented by the asset store and finding better assets in the asset store to plug areas in Unity is a good thing.

Unity is doing a good job while moving incredibly fast and the asset store has been a saving grace and something revolutionary really that makes the Unity platform one to mimic.

 

Finally some new footage released - an overview of the new GUI system:
http://blogs.unity3d.com/2014/05/28/overview-of-the-new-ui-system/

Also wrote an article about this amusing piece of Unity3Ds history - Feel free to add to it in the comments, someone already made a great addition there:
http://www.previewlabs.com/unity-gui-saga/

 

So, what do you predict? A stable GUI? Performant? Recursive? Sibling-aware? Styleable? Skinnable?

It's still the A-C-S GUI, right?

What do you think, will they scrap it?

btw I also wrote an article on it: http://edrivengui.com/my-take-on-unitys-gui-struggle/

Greetings from the HTML5/JS/Angular/WinJS world!

Danko

 

Everything gets scrapped eventually as it's replaced by something better.

However, I think you're completely wrong about how complex the GUI layer is. You even said you come from an HTML world and your 'ACS' and colliders and scripts is exactly how it works. (HTML can technically use atlases, but it's a pain and could be dramatically improved.)

As for not everything needing colliders... Of course they don't! That's why you don't put colliders on *everything*, only the components that you want to get mouse/touch info from.

I also notice that you don't suggest the proper way to go about it. Instead of ACS, what *should* they have done?

 

Yes, but the legacy consequences would be horrendous. They couldn't possibly introduce a new system every now and then - once they make one official. Future Unity versions should support each system forever.

First of all, reading (and learning from) tons of the source code of (open-source) frameworks published for other platforms. Then building the code-first GUI (with an abstraction level GUI programmers are used to), with designer as sugar on top. I believe I've shown Unity is a fully capable platform for doing this.

You cannot build a BMW by looking at it's photo. If blueprints are available, you got to go through each one of them and learn how it works internally (starting with the engine).

 

That's just bloat and added complexity for no viable reason. Future Unity versions should drop systems once they are no longer useful...being overly concerned with legacy is harmful.

--Eric

 

Unity still supports IMGUI.. for 7 years now? (let's not mention GUITexture)

In technology years this is... well... forever.

 

IMGUI is necessary because that's what the editor is written in, nor does it make much technical sense to replace that with the new GUI system. They have different usage targets and the new system wasn't meant to be a direct replacement. GUITexture can go away (finally) once the new system is out.

--Eric

 

My thought was actually about the New New GUI. I don't believe it will be removed in the next 5 years, and that's a long long time in technology terms.

I could tell you that being a Flex developer:

- Flex 3 (built on top of AS3) was introduced in 2007 and Adobe got rid of it at the end of 2011 (after 4 years!)
- however, Flex is still used now in 2014 (as Apache Flex), with majority of the classes written back in 2007
- legacy actually "killed" Flash and Flex

In GUI world you cannot afford to produce something half-baked, because during all those years other systems are being built on top of the GUI system and they must not break in the future (or users going mad, after spending many developer years on it).

 

Unity has done a great job of keeping systems between major versions of Unity, but the man purpose of major version number changes is to signal breaking changes. Dropping an old system is generally done by marking it as deprecated for 1 major version and then dropping it in the next one. That means in just 2 major versions of Unity, they could drop the new GUI system without a major hassle and with *plenty* of notice to developers that they are doing so. They aren't stuck with anything.

You still haven't said how the GUI should be designed. You've outlined the steps to take to research that design, but you don't actually know that they didn't already take those steps and end up with the current solution.

There are plenty of existing GUI solutions out there and open source versions of practically all of them. There's no need for them to reinvent the wheel here. The ideas already exist, and they can do their research simply by using existing systems and evaluating their pros and cons. In additional, they've got all the feedback posted about those systems by their regular users, since they'll all have public forums as well.

 

In fact I did. In many occasions, to many people. And it's not something that I could compress in a single post. GUI systems are complex and hard - it would take days or weeks for a proper introduction.

To get a feeling about the code-first approach I'm talking about, see the new Xamarin:

A bit off-topic news: Apple yesterday announced Swift, a new programming language: https://developer.apple.com/swift/.
I'm curious how it will play in terms of GUI abstraction...

 

So why not link one or two of them? "A single post" isn't really an issue, since you've written a whole article on the matter...

 

I do agree that legacy stuff can be removed (maybe after deprecating it for a couple of months). However, I'd prefer it there would still be an immediate mode GUI system - I do like the immediate mode GUI a lot more over any other system. It's perfect for prototyping as it allows you to get a basic UI in place very quickly.

The only drawback is the speed on mobile in case you're doing something more elaborate with it, though that's getting better with each device generation
(note: someone fix the newlines added before and after smileys please?)

Each system generally has some advantages and disadvantages over others, so it depends a bit on what you're trying to accomplish. Quite a while ago (long before Unity 2D), I wrote an article about how we saw the different ways of doing 2D in Unity at that point:
http://www.previewlabs.com/2d-game-development-in-unity3d-overview/

 

GUIText and GUITexture are a really very small part of Unity engine, and I think it is unnecessary to remove them.

 

They can easily be replaced with uGUI which gives automatically a lot more freedom. There seems to be special drag and drop support in uGUI according to some posted videos. That is not that easily achievable with GUITexture. On touch devices, it is not possible to have several touches being handled with GUITexture or GUIText, but it will most likely work with uGUI.
If it is still there, it will be used, even if it is hidden. But if it is removed, people are forced to use the better approach.

 

^This
I mean, come on people. It's a major release. When porting an existing project from Unity n to Unity (n+1) you should expect breakage.
It UT isn't allowed to get rid of obsolete features with a new major release, they're forced to keep this stuff around forever.

 

It may surprise you, but I have no clue who you are. I haven't got any clue how many articles you've written on the subject. All I've got is what you posted here, none of which answers the question I asked at all. Did you come here prepared for a discussion, or did you just want to rant about Unity not doing things your way? Because saying something along the lines of "I've discussed it elsewhere and I won't repeat myself here" is not conducive to discussion.

I may also surprise you that I am genuinely interested in hearing how it could be better. I'm not just trolling you, slapping you down every time you fail to answer. I want you to answer. I want to hear that answer. And I doubt I'm the only one.

Take this opportunity to educate people, instead of just calling them ignorant and dropping the mic.

 

This is not animation, where Unity had to keep legacy as they were creating a unique and non standard system(mecanim). The GUI system is so horrible at the moment that no one in their right mind should continue to use it. Assuming you have all the textures, rewriting any GUI should not take too long at all.

 

Actually, I think his point is that the new system won't be *horrible*, but it won't be nearly as good as it can be.

"Good is the enemy of Great."

Something that's "good enough" can get entrenched and hard to replace, where something that's bad is easy to replace. By making a half-way solution now, they may be preventing themselves from making a great one later.

Nobody's worried about UT replacing the existing crappy solution. The discussion is about possibly replacing the new GUI later, a few years down the road, when something better is conceived.

 

Everything can always be better, more specialised, and cover a mode wide range of situations. This is not Unity's job, there purpose it provide a solution that works fairly well for most, pretty much like everything else in Unity's engine. Remember you can still use Asset store GUI solutions, and they may improve also with the new GUI system.