So it appears as though the new UI system is so flexible, we still have to code in our own state manager to handle transitions between higher level objects such as canvases and panels?
For the sake of having a clean hierarchy, I’m parenting all widgets to panels, even if the panel has no texture and then panels to canvases. To me this is the logical approach regardless of animation behavior, but there doesn’t appear to be anything in place to handle transitions between those containers. I can use a WaitForSeconds controller, but… I really was hoping we’d be getting away from that sort of thing. nGUI provided such a thing if I recall.
Man I’m bad about checking back on posts…
Thanks Daniel, I gave it a whirl and I’m finding it VERY irritating. Mechanim is not suited for UI state handling.
Overall I’m getting a really bad feeling about the new UI.
I’ve never used Mechanim for my UI purposes. I’ve always associated it with character animations. It seems like its more work to create a state machine inside Mechanim and tap into it through code, than it would be just to code the entire thing externally. Unless there’s something paramount I’ve missed.
I have no idea how complicated your UI is, but I’m making a 2d game that exists entirely inside a canvas and the entire game is nothing but UI elements, and I’m managing UI switching with just a couple of scripts with arrays of gameobject references. What in the world can you be doing that needs a state machine so complex that you’re leery of the entire new UI system because of?
JAKJ, Fore me it’s not a matter of complexity. It’s a matter of writing clean and flexible code. A state machine is, what many consider, the proper way to handle a UI in games. Sure I could hack something together in a series of scripts and use timers or enumerables to get everything right, but that’s not a professional way to do it, that’s all I’m saying. Particularly if you plan on having elaborate animation sequences. I just would have preferred a complete UI system. I get that it’s still in the works but the foundational peices like state handling should have been there first. I also don’t necessarily believe it’s a bad thing if the UI system forces you to code a particular way, provided it’s flexible enough to do all you want it to. (i.e., no one complains about Mechanim because it works great for animation blending, but it is very much a ‘you should really do it this way’ design) and consequently the open source angle to all of this means less things are provided for you.
@rakkarage - That’s good to hear that about the Mechanim Start/End and behavior changes, that should be plenty for most users to implement something practical.
