Nevermind… the uGUI was much simpler and more logical than I had thought (based my initial impression off a video and a couple random tutorials I found online). After I just ignored that stuff and dove in it was dead easy in practice.
Hey folks.
I am just wondering if anyone knows of a free GUI system for Unity that is easy-to-use and logical?
One of the things I’ve never liked about Unity is their methods to create GUIs. It seems to be yet another “custom” system that to me at least seems very odd to work with.
A good example of what I consider an intelligently designed GUI system? Well… launch Visual Studio and make a C# Windows Form Application project. Design the GUI on your form. Did you see how incredibly easy & fast that was? That is what I am looking for.
And for hooking up events… again… look at how it is done for the controls on your Windows form. Simple. Common sense approach.
I know I can dig through the store as well as the open source projects online and see if there is such a system but just wondering if anyone already knows of one.
I’d even be happy if there was just an easy to use GUI designer that created the GUI GameObjects/Controls or whatever is used in this case and then I could then go into the code and manually do the event handling code.
I should say in fairness maybe it is not as bad as I am thinking. But going by the fact thisLive Training session on simply building a main menu in Unity is 1 hour long (for something that could be knocked out in about 5 minutes in Visual Studio) tends to make me think yes it is way over-complicated. lol
I didn’t find anything on the store so I guess I will play around with uGUI and see how it goes. Sometimes it just surprises me like Unity seems to be such a visual design drag n drop style tool and yet when it comes to things that are basically always visually designed drag n drop that is when they decide to do it in a somewhat different way. It seems to me like at nearly every step decisions were made to complicate things (again in comparison to having done this stuff in many other tools).
It is very hard for me to find the logic that is used here sometimes. Like I am thinking just make it so the dang canvas/GUI design pops open in its own window like the Animator state machine thingy does and then let a person just drag the controls from a toolbar that is visible on the side of the window. Drag them around with them logically snapping in place. Give a list of available interaction event types… I mean there are only so many that are possible… for a button that would be things like OnClick, OnMouseEnter, OnMouseHover, OnMouseExit. So you select the event and then point it to a method someplace (this bit seems to work this way as far as wiring the event handlers). Simple. Logical.
But enough of that let me jump in and see how it goes.
I highly recommend to take a look at Qt 5 for non-unity GUI.
Unfortunately, there’s no Unity equivalent for Qt 5 GUI system. Unity UI in general should be sufficient to make stuff, even though it lacks some basic things like grid snapping.
The live training sessions are incredibally slow. They are designed to cater to essential beginners. Check out my channel for some faster tutorials with the Unity UI. Or just dive into the docs.
I think you are borrowing a problem which doesn’t actually exist.
Alright thanks guys. Maybe it is just a bad impression from the video and they are making it seem much more complicated than it is. Because I am thinking in comparison a video in VS about designing that menu should take at most 7 to 10 minutes and that is with plenty of narrative rambling on.
I guess what I need to do is dive into the creation of Editor tools at some point. Because I would completely throw out many of these things. I mean I would have it of course use the same internal code, generate the same objects that are being added now and so forth but for the design of the GUI itself that just seems like it could be simplified & streamlined considerably from where it is now.
In my mind knocking out a simple menu GUI for a Blacksmith shop should take maybe 2 to 3 minutes.
But I don’t have time to get into all of that now. So let me dive in and see how much work it is to implement a Blacksmith menu.
EDIT: In fairness, I realize that a big part of me smh is because I add a button it appears in the Scene and then I double click on it thinking that will create an event handeler and take me to it. And stuff like that. lol Ah VS has a beautiful system. So fast to develop with. So probably it is just because having used other things far more often than Unity they spoiled me. They just did it right for super fast dev speed. And it confuses me when I come to Unity which is supposed to be so fast & easy to work with and there are so many more steps involved.
You can place buttons quickly, and mark areas for item lists, but then you’ll get bogged down dealing with event handlers and scripts. And this part will take longer than 2 or 3 minutes.
To be honest, Unity GUI has some similarities with Qt GUI (layout/anchor mechanisms… or at least some layout mechanisms), so generally putting together an UI will be quick, the main trouble is that compound components of Unity UI have trouble handling scalable interfaces.
This stuff first appeared in Borland Delphi and predates WPF.
The issue here is that in this case you need inheritance-based workflow, with a form being defined by a class. Unity is component-based, so you’ll need to figure out into which component the code needs to go, and it doesn’t really have forms.
Okay, I just spent the last 30 minutes playing around with uGUI doing various tests and seeing what all and how all event handling can be done and so forth.
You are right @Kiwasi it is actually much more straightforward than my first impression from seeing the video was 1 hour long to make that menu.
It’s not nearly as efficient in working in VS but I followed the same patterns and it is workable.
@neginfinity yeah I meant just the GUI design itself going to stub event handlers not actually implementing it all.
You’re comparing how long it takes you to do a thing you know… to how long it takes to explain a thing you don’t know. That’s not a fair comparison. Once you know what you’re doing, it will be a lot faster and more flexible than the VS dialog editor.
The instructor in this particular video spends ten minutes getting you from absolutely nothing to having a panel on the screen for the game menu, which - once you understand it - is just Create → UI → Panel and a resize. It won’t take more than two or three seconds. At the 18 minute mark, he adds the first button. That, again, is Create → UI → Button. Just a couple seconds.
But you need to know what he covers in those 18 minutes.
@cdarklock Yeah that makes sense. It is not so bad. I have it down now. I generally learn much better just diving in trial-and-error than watching videos and things. Of course sometimes I check out a tutorial depends on how complicated something is. Next time I will know the Live Session videos just drag things out big time. I didn’t know that. I only knew I wasn’t going to spend an hour just watching a video to end up with that simple menu.
Anyway, it is all good I have my basic menu implemented and have a straightforward workflow down for how I will do it going forward. This seems like a great thing to make into a prefab actually so I have a template ready to drop in.
I watched about eight of those videos before I ended up with my menu, and I still needed to suss out how to make a slider control audio level. Burned an entire day for “volume” and another one for a few basic options.
Part of that was the problem I mentioned in another thread where GetComponent doesn’t work because that’s not a component so I’m supposed to use the gameObject property of the Panel instead which nobody ever explained anywhere and also there’s no entry for Panel in the documentation.
It’s going to be frustrating, because the standards here are just not up to Microsoft’s level. MSDN was a quantum leap forward when it first came out, has only gotten better, and if you hold pretty much anything else up to that standard it is not going to look very good.
My strong suggestion is to make sure that you understand how anchors and pivots work, and make sure you’re constantly checking your UIs at different aspect ratios so make sure things resize as desired. It’s fiddly, but it’s also necessary, and gives you a great level of control over how your UI responds to different situations.
Also on the comparison to WinForms… of course WinForms is more straightforward! It has more features, but it only has to deal with a fraction of the usage scenarios. It has to support window resizing, but it doesn’t have to support the same variety of input methods or things like DPI variations.
Also layout elements, which I still do not entirely understand and am trying to wrap my head around.
Honestly, does nobody remember what it was like the first time they encountered message-based programming? It was insanely difficult to make the leap from structured. DOS wasn’t all that hard a nut to crack, but Windows was clearly the product of a diseased mind.
You put a VerticalLayout or similar Component on a GameObject, and that component configures the RectTransforms of all immediate children. The BlahLayout itself has some configurability, but it’s only half of the story. To use them effectively you also need to add LayoutElement Components to the child objects. That lets you set things like minimum and preferred size, and what resizing (if any) should happen above the preferred size.
Unity’s UI system is just regular GameObjects and Conponents. The only thing special about it is how GameObjects are positioned. Once you get that down the rest is just standard Unity 101 stuff.
You can get into the EventSystem and Raycasters if you need to do detailed stuff. But its not strictly needed.
It’s also worth pointing out that you don’t need to use any of Unity’s event handling stuff in the inspector if you don’t want to. You can intercept the events yourself and deal with them as appropriate.
Right. That’s the hard part: turning “this is what I want to happen” into the proper combination of anchors and canvas scalers and layout groups and content fitters. There are about twelve things that all need to work together. It’s no more complex than other systems that do the same thing, but it’s different and I don’t know how this one works yet.
Panel is an odd one. I suspect it’s only in the menu at all because people commonly look for it (which is a good reason, and also a good reason for it to be in the documentation), but there is actually no “Panel” class or component. When you use GameObject → UI → Panel it makes exactly the same thing as GameObject → UI → Image, but with a default image in it.
As long as I can knock out some stuff and it works I am happy. I was just going to throw together a bunch of sprites for the GUI but figured I’d look into using the actual GUI system instead. I won’t get into all of that stuff you guys mentioned up there. I’d knock out simple sprites and build everything with those first.
I mean sure there is value in learning all of this stuff but good Lord at the end of the day I just want to be building a game. The reason I would be using Unity in the first place is to simplify game dev not add more complexity to it. So I think the smart thing to do is use it when it makes sense to do so and do it ourselves when doing so can simplify everything.