Hi,
I have progressed well enough in a personal project of mine to tell you that soon, managing GUI within Unity and playmaker will be taken to a whole new level
Basically, I am working on a xml based definition of gui, and a series of actions that goes with it so that you can manage, edit gui elements as Unity should always have done; as persistent Objects, like we do in the 3d world, not having to declare them each update... which might be more powerful yes, but that's just not satisfactory without a framework on top of that).
The major advantage over the current implementation is that you don't need to have all your gui in one state, instead when you create a button, it will live until you want to destroy it ( and a check box is there also so that is get destroyed when the state is exited of course). So you can finally start to take full advantages of playmaker Fsm system for the gui.
the current alpha version can already do the following:
-- send playmaker event on gui events like button down, value changed, etc etc. All this xml driven!! no script nor fsm involved at all!
-- binding of FsmVariables and gui properties: like the text of a textfield, or the rect of a window. Again, All xml driven!
-- more goodies like referencing element by user defined id: create a window and give it an id "My very own window" and then simply add an action to add a button and specify that the container should by that ID, it doesn't care if it is a window, a group, vertical or horyzontal, etc etc, and you can of course specify where to put it, ( last element, first element, or next to a specific element id).
The other huge advantage is that you completely remove the need to script the layout, structure of your gui, and instead only implement what need to be dynamic: for instance, you want to show all your current players in your game, the xml will define the position, title, etc etc and the group where all player should be listed ( and give it an id like "playerGroup". Within playmaker you then only add, remove buttons within that "playerGroup", your playmaker doesn't know and doesn't care about where it is or what it is, it will simply add that element in that ID, end of the story, clean and efficient playmaker Fsm
A lot of precaution and thinking currently goes in caching details, because essentially, the xml parsing happens on each OnGUI and it's obvious that it has to be optimized: Currently, I can't even spot a difference in the profiler
between the same gui on screen handled via script or within my framework: so I am pleased, I parse only once an element content, when first parsing or when it is changed or edited.
The feature list goes on of course... and opens wild possibilities like creating your own element and only define it simply within the xml gui ( I working on creating a way to easily extend xml elements). Things like dropdown menu, tree views, radars, complex list, tables, would then fit within that framework and remain very easily to implement AND reuse.
The power it gives and the perspective in terms of flexibility, reusability and integration within playmaker is clear and promising, despite the fact that Unity gui is not optimized for mobiles because of the number of drawcalls, it still has a lot of concrete application for desktop application, simulation,non games stuff and application with intense gui, not requiring fancy artwork...
So stay tune for a beta preview soon.
Bye,
Jean
