EZGUI VS NGUI

from:http://blog.heyworks.com/choosing-gui-framework-for-your-unity3d-project-ezgui-vs-ngui-part-i/

The following post might be helpful for those standing on the crossroad which GUI framework to go with in Unity project. Among lots of more or less advanced 3^rd party options there are just two which can be seriously considered: EZGUI and NGUI. I’ll clarify major differences I’ve noticed in my experience working with both of them.

EZGUI and NGUI provide great features for making in-game UI easily and efficiently. However they use different implementation approaches. EZGUI comprises lots of instruments and controls with plenty amount of settings, so you can tweak almost every parameter of any UI element. In opposite, NGUI provides lots of small components and I like its minimalism, short, clean and understandable code. Both EZGUI and NGUI target “1 draw call for UI” and they’ve got very close. Of course “one-draw call for UI” isn’t the main concern, but why not to have such a great addition to your well-structured and optimized code.

The following table contains a comparison of both frameworks with features I find important:

Pixel perfect	Scale of controls is adjusted automatically once on a scene start. Note: it has issues losing render camera reference when instancing UI as a prefab	Scale of controls is adjusted automatically every time resolution changes. Also has ability to apply half-pixel-offset
WYSIWYG	Generates ordinary gameobject with geometry, so everything is visualized by Unity itself	Uses several ways of visualization: “geometry” and “gizmos”, since all UI elements are a part of a single mesh
Access from code	Methods from a specific controller-script are linked with control events. There can be some issues with instancing objects and losing references. Another way –using delegates can be more convenient in some cases	Similar as EZGUI, but here you have helper components, such as UIButtonMessage, which send specified message to a gameobject (or to itself, if target is null), on selected type of interaction. Also you can access to last used control through static variables such as UICamera.lastHit or UICheckbox.current
Ease of controls creation	Empty GameObject is created and attached with necessary components	Provides handy wizards for creating all kind of controls.
Workflow speed	Smooth, but slow. Searching scripts which aren’t included in common menus, adjusting tons of settings, fixing broken atlases and lost camera references (most likely I’m not the only one who experienced these issues)	Supersonic! Just a little slowdown when creating atlases for sprites in the beginning, and then pure enjoyment of future process!
Drag and Drop	Both frameworks have this feature. Just a little note: any object in NGUI with a collider can be draggable
Atlases creation	Atlas has to be recreated every time you want to add/change an image in it. EZGUI can scan all objects, even in a project folder, find all  using the same material and then regenerate the atlas. This process takes lots of time and you should be very accurate not to break something	Atlas can be managed in two ways: either using fast and handy Atlas Maker to add, delete or modify images in atlas or managing sprites in atlas already created via Atlas prefab inspector
Panels switching	Making menus with switching panels has never been easier due EZGUI’s powerful abilities	Panels can be switched easily as well, but some additional scripting is required. Panels can be switched through animations and helper components, but I haven’t found any direct way to enable one and disable another panel
Additional stuff	Since EZGUI is based on Sprite Manager, classes (e.g. Sprite etc.) can be quite useful in 2D games for environment creation, backgrounds etc.	Sprites can be used, however with some restrictions like any control must have a parent like panel or UIRoot.

And here is a comparison by controls implemented in the frameworks.

Control
Label
Sprite
Sliced sprite
Tiled sprite
Filled sprite
Simple button
Image button
Toggle button
Radio button
Checkbox
Progress bar
Slider
Input
DropDown list
Scrollable lists

I was really excited with Sliced Sprite from NGUI. When there is an objective to create a resizable window that should be pixel-perfect in different sizes, have a frame outside of it and be filled with a pattern - that’s exactly when Sliced Sprite can manage everything, just specify areas on texture to be used as a frame, corners and filling.

Tiled Sprite can be implemented manually with EZGUI, however it won’t be so easy. Tiled sprite always stays pixel-perfect, and it tiles the texture you’re using when scaling. That’s very handy for creating backgrounds for example.

NGUI extends Unity with a bunch of useful hotkeys which are really nice-to-have, e.g. Ctrl+Shift+N to add new empty GameObject as a child to selected one, hotkey for toggling gameobject’s activity, handy buttons for resetting transform’s position, rotation and scale.

Both frameworks are provided with detailed documentation describing every script, every component, property or method. Additionally, NGUI is shipped with a lot of step-by-step tutorials, video and write-up lessons for beginners.

EZGUI is based on Sprite Manager 2 (developed by Above and Beyond Software). SM2 provides features for creating 3D mesh sprites, customizing and changing their parameters in runtime, as well as creating texture atlases, so that all sprites in a scene are a part of single batch and are drawn in one draw call.

And here’s my subjective comparison of these both frameworks:

Usability
Functionality
Flexibility
Reliability
Extensibility

…that means I like NGUI much more, however I haven’t described another very important difference between NGUI and EZGUI - the way of working with them. I’ll demonstrate it in my next post, stay tuned.