do you mean you store a large set of possible text responses and the dialogue GUI can dynamically resize itsellf based on the amount of text?

Even more general than that - I need a dialogue to be whatever size it needs to be to hold its content. I should never need to specify its size. HTML does this - elements grow to the correct size for their contained elements.

So to create a grid like inventory system GUI for example, the children entities would have a 90 degree step and 0 degree random variation.

This sounds rather more complex than what a GUI should typically need to do. If I want a grid, I just want to be able to create a Grid object, and then feed it several rows of data.

So, a scrollable panel parent should either be able to dynamically resize itself or force a dynamic rescaling of the children objects to fit a fixed parent size. The input system is all based on one ray cast to determine where your mouse is currently located and which actions are available depend on the GUI prefab your on. I'm pretty surprised this requires custom shaders in NGUI. Are the items you want to fit within a scrollable parent all different sizes or something?

Usually when you have a scrollable region, you render everything within that region (optimisations aside) but the renderer can restrict the actual drawing operations to the viewport through which you view the region. Unity lacks that exact functionality so it's hacked in by using a custom shader on scrollable regions to achieve the same effect.

That's a separate issue from NGUI using colliders to stop you accidentally clicking on the objects that are invisible. That just implies that their input handling system is completely different to pretty much any other sensible GUI, which would propagate mouse clicks down through the GUI hierarchy to see what was clicked on, which would reject clicks on objects scrolled outside the viewport by design.

The size and shape of the items on the scrollable region should be irrelevant to how to implement the scrolling behaviour.

Even more general than that - I need a dialogue to be whatever size it needs to be to hold its content. I should never need to specify its size. HTML does this - elements grow to the correct size for their contained elements.

Yea, that makes sense.

This sounds rather more complex than what a GUI should typically need to do. If I want a grid, I just want to be able to create a Grid object, and then feed it several rows of data.

Yea, I realized I was trying to make one thing be generic enough to work for a multitude of things, but it will be better to create a bunch of different simpler parent panel type scripts / prefabs.

That's a separate issue from NGUI using colliders to stop you accidentally clicking on the objects that are invisible. That just implies that their input handling system is completely different to pretty much any other sensible GUI, which would propagate mouse clicks down through the GUI hierarchy to see what was clicked on, which would reject clicks on objects scrolled outside the viewport by design.

Ok, yea what I am doing currently is RaycastAll() on the entire GUI and then sending event messages for every GUI hit using an event handler system. The GUI elements themselves in addition to the editor can receive and process the input events.

What I meant with the top-down processing is that traditionally in 2D you go top-down to find out what was actually clicked on, and then from there you go bottom-up to find a handler for that click. The 3D aspect does change things, but I'm sure there are often pretty trivial ways of implementing clipped areas. For example, Unity has a RayCastAll() which returns all the objects hit, not just the first. To implement clipping to a parent you can discard any object in that list whose parent is not also in that list.

To be fair, that's only one of my complaints about NGUI - I hate the fact that you're expected to manually set up materials and atlases and sliced sprites and all kinds of other graphical esoterica that I think should be handled by the engine, but most of that is Unity's fault. You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

Aye. 3D strikes me as largely unnecessary for GUIs - plus, you want anything interactive to be flat to the screen anyway...

On PCs, yes, you'd want it to be flat for sane interaction with a mouse cursor. But on a console, you don't have to worry about that with 3D UI since your interaction is via focus and not mouseover, so you can do more interesting stuff in 3D space. Think of the Borderlands 2 inventory UI... not necessarily saying I'm a huge fan, but there's not as much as a usability issue in that case.

You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

Aye. 3D strikes me as largely unnecessary for GUIs - plus, you want anything interactive to be flat to the screen anyway...

On PCs, yes, you'd want it to be flat for sane interaction with a mouse cursor. But on a console, you don't have to worry about that with 3D UI since your interaction is via focus and not mouseover, so you can do more interesting stuff in 3D space. Think of the Borderlands 2 inventory UI... not necessarily saying I'm a huge fan, but there's not as much as a usability issue in that case.

You pay the 3D price and get the 3D benefits, but lose a lot of the 2D simplicity.

Aye. 3D strikes me as largely unnecessary for GUIs - plus, you want anything interactive to be flat to the screen anyway...

It's unnecessary?! Come on now we all know making games isn't about what is or isn't necessary, it's about what's AWESOME. No wants to interact with a boring lifeless 2d GUI.

I think the main point here is that the GUI is largely functional only in 2D, but can do some cool 3d animations for the wow factor. I don't think anyone is actually designing a functional 3d scrolling component for example, that would be craziness.

This is the kinda GUI that I want to make very quickly through an editor->

Skip to 3 minutes 30 seconds

To make that should only take 10 minutes tops, if I can't make that in the editor I'm creating for Unity in 10 minutes then I've failed because it took me a whole lot longer than 10 minutes to manually code what you see in that video, and the whole point of the editor is to greatly reduce the manual coding

See, that looks slick and you might think it's awesome, but I notice 2 things:

1. The skill popup windows are all exactly the same size. This implies someone has had to hand-make that specific window with some fixed-size labels inside. And it means that if I ever write a skill with too much text, I have to go back and edit the GUI, and that's exactly what you don't want.
2. Earlier in the video (1:30) I see a portrait with left and right buttons next to it. Again, it's just an implication, but that is the classic thing you implement if you aren't able to support a scrolling selection area (which is usually preferable since a player can more easily compare potential choices).

If I can have cool 3D effects - great. But they're secondary to gameplay and usability, and often these 3D GUIs come with compromises that affect those aspects.

And even Borderlands 2's PC UI **still** has several bugs in the vending machine and bank/shared stash UIs.

This just reminded me of several UI bugs in XCOM, which uses Scaleform. Trivial things like mouse-overs not working first time, or buttons apparently being unable to stretch to contain their text. Why are these simple things still problems in 2013? Baffling.

See, that looks slick and you might think it's awesome, but I notice 2 things:

The skill popup windows are all exactly the same size. This implies someone has had to hand-make that specific window with some fixed-size labels inside. And it means that if I ever write a skill with too much text, I have to go back and edit the GUI, and that's exactly what you don't want.
Earlier in the video (1:30) I see a portrait with left and right buttons next to it. Again, it's just an implication, but that is the classic thing you implement if you aren't able to support a scrolling selection area (which is usually preferable since a player can more easily compare potential choices).

Yes this video is a few months old when I was just quickly prototyping my GUI from scratch. The editor I'm making will of course allow 3d animations in addition to the diverse functionality of GUI elements that can scroll / resize / etc. I was just pointing out the 3d stuff