Hi,

I have a project in mind, which would be mostly played in a GUI-like interface (think Democracy, Uplink)

Is the GUI-toolset in Unity up for the part?

Also, there are tons of examples on how to create a jump and run game, isometric strategy etc. in Unity, but not many resources which cover GUI-centric games. I would be grateful for any tips and links.

Thanks.

The UI in Unity is just about up to the task, but you will have to do one of the following:

1. spend a fair bit of time building the widgets that you need. Most of the Unity UI is focused on HUD elements and although there is support for generic layout, it's poorly documented and you can't really get any support with it. So if you, like me, find yourself trying to make resizable list views with variable column widths and the like, expect to have to invest a lot of time into this before it starts working well. The Unity UI is very powerful but also very complex, so it takes some time to coerce it into doing exactly what you want.
2. look around for 3rd party assets that can get you most of the way there. Just the other day I was pointed at this asset - https://assetstore.unity.com/packages/tools/gui/new-ui-widgets-27226 - and although I haven't tried it myself, it looks very useful. There are also free add-ons for the Unity UI - e.g. https://bitbucket.org/UnityUIExtensions/unity-ui-extensions - but documentation is sparse. But if you are time-rich and cash-poor, this is a useful option to have.

My other suggestion to you would be to seriously consider whether you could make the same game in HTML/Javascript. Visual effects are harder to do there, but the layout algorithms are much more widely known and understood.

Thanks, very helpful.

How do you build your own UI-widets in Unity though? Is there a tutorial for that?

Also, instead of relying on Unity UI, I thought about basically simulating an UI. Define the custom UI elements as regular assets and animate them just like you would do with sprites etc. Of course, it's more of a hassle that way and lots of custom behaviors need to be added, but one would be far less restricted to the Unity UI framework rules and such.

Your thoughts? By the way: How pixel-perfect is Unity? If you put a button somewhere, does it stay there in that position without any hacks or will it float around the screen and you need to anchor it through some kludges?

There isn't a specific definition of 'widget' in Unity, the way that there is in typical desktop UI systems. You get given a small number of primitives - Image, Text, Button, Scrollbar, a couple more - and you just have to manually combine them in ways that make sense to you. This is already how some of the more common widgets work, like a scrolling list view. (Video example here: https://www.youtube.com/watch?v=lUun2xW6FJ4)

So when you say "Define the custom UI elements as regular assets and animate them just like you would do with sprites", this is pretty much what you have to do anyway, because the Unity UI is very low level. For example, apart from very basic default transitions, it's expected that you might hook up your buttons or panels to explicit Animations (as in this video: https://unity3d.com/learn/tutorials/topics/user-interface-ui/ui-transitions)

Regarding being 'pixel-perfect', Unity is not designed in such a way that you would expect to place things on pixel boundaries. It's a 3D engine foremost and apart from generally not working in pixels it attempts to work at all aspect ratios and resolutions. Ideally you would layout the UI the same way one would lay out a UI in HTML, by creating a hierarchy of objects that have position and size relative to their parent element in some way, so that it is responsive to the window size. As such, the question of "does it stay or will it float" only makes sense when considered relative to your expectations in the face of changing window shapes. If I anchor an element to the bottom right of the screen then of course I want it to move down and to the right if I increase the width and height of the window. Does that count as "staying" (because it's remaining in a fixed position relative to its anchor) or "floating" (because it's moving relative to the background)?

Thanks.

Hi

I'm still a beginner, too, so maybe take my input with a grain of salt

I'm currently building a small trading game in Unity. It's going to be 2D and relies heavily on Text-, Sprite- and Button-Elements. Honestly, almost everything I have built up until now (which is the trading- and craftingsystem) falls in one of these three categories. I know exactly what you mean about finding lots of tutorials about non-GUI-things, but there are a couple good resources out there. First, there is a small Unity Tutorial about making a Tic Tac Toe-Game. Yeah, not exactly thrilling, but it gives a good, basic starting point on how to work with texts and buttons and won't take you long

From there, you might want to search for tutorials on building menues or inventories. They might not cover what you want to build, but you might be able to take lots of ideas from them (I surely did). Be careful, though: There a ton of tutorials out there which use an older Unity-version. Sometime during the last couple of releases, they seemed to have changed the way Unity's GUI-Elements work and sometimes, stuff you'll see in "older" (2-3 years ago, for example) tutorials won't work anymore.

When it comes to assets, you might want to have a look at TextMeshPro. Brackeys did a good, short video on how to use it and it will be an awesome addition to your game, if you want to display any text at all. Seriously, I want to hug that asset, it's awesome. Plus, it's free.

In general, I can recommend Unity for building stuff with tons of UI-Elements, at least from my limited experience. It's kind of intuitive to me, even though finding the right tutorials/solutions to problems can sometimes feel like the newest episode of Indiana Jones, starring oneself

I want to add in here that Unity's new UI system is slow when used too much. It's anchors is really slow and can get worse when you don't use the "overly" mode.

Also never use the "best fit" option on the fonts, don't know why they even allow it, because if your UI scales or animates it will add a new font page to the memory at real time; slowing the game and using memory. The older GUI of Unity is faster than the new UI and a better choice for animated GUIs.

For pixel perfect you just need to adjust the canvas pixel ratio and the camera. I explained it a bit here: https://www.gamedev.net/forums/topic/696034-pixels-and-units-in-unity-explanation/?tab=comments#comment-5375364

Just use the canvas instead of the Unity units.

15 hours ago, Scouting Ninja said:

never use the "best fit" option on the fonts, don't know why they even allow it

It's because it's very convenient for designers, being able to just resize the text box and have the text scale to that size.

15 hours ago, Scouting Ninja said:

The older GUI of Unity is faster than the new UI and a better choice for animated GUIs.

The older GUI - at least, the most recent IMGUI - is an atrocity and completely unsuited to any serious work. It doesn't even integrate well with the animation system so it's hard to see how it would be a better choice for animated GUIs, unless you expect to animate everything manually from code..?

Also be aware that sprite-based graphics are a terrible fit for modern hardware and you won't begin to approach their high-power rates without enormous work.

In ages past graphics cards were designed around sprites. Rendering was passing an array of which sprite belonged in which position, with rotation and flip flags. The entire display could be updated by transferring kilobyte or two to the card.

Cards today are built around complex point clouds and textured, shaded, heavily-processed surfaces.  Attempting to render sprites as a bunch of individual tiles to be rendered will saturate communications to the card. Rendering can still take place by loading all the sprites to textures and then manipulating your tiles into point clouds and then issuing a few small commands to the card,  but it is far more effort than you likely expect.

8 hours ago, Kylotan said:

It's because it's very convenient for designers, being able to just resize the text box and have the text scale to that size.

Yes, that is exactly why it shouldn't be allowed.

What happened with me was that I hired a designer then animated the end score on a mobile game. Score -= score *AniTime *Time.DeltaTime.

What I didn't know was that my UI designer used the "Best fit" option and, that little math above basically translated to: Make a new font page every frame for as long as the animation continued.

It wasn't noticeable on desktop and made it past the first tests. Then on mobile the animation dropped performance to 4 FPS. I was stumped till I found this, where it says best fit should never be used:

"use of Best Fit will rapidly overwhelm the atlas with many different glyph sizes."

After reading that I unchecked the "Best Fit" option and just set the font manually. The result was more than 80FPS on mobile and almost half the loading time with over 400mb saved in memory.

8 hours ago, Kylotan said:

, unless you expect to animate everything manually from code..?

Not manual, the Unity animator can animate public variables. It's a bit of extra work but worth the performance boost for heavy GUI games that should have a lot of animations.