Thanks for posting the game,
Would love to get some feedback on the following:
1. Pain points with NGUI
2. What and how it could be improved.
3. Would having components that have DataProvider functionality help. Ex: Feed in an xml or json to a scrollList comp and it auto populates. Something like Adobe Flex but without the bulk. Just a dataProvider and more developed component architecture.
Pain points:
Depth! Mostly fixed by the big update in December. This actually caused us to explore using Scaleform early in the development cycle, because we had artists that wanted to do a lot of animation in the UI, and sliding one panel over another was nightmarish. Having lots of dynamically-added children, as we do, made that worse.
Memory usage. This helped drive decisions about how many cards you were allowed to have in inventory, because we ate a huge amount of memory by naively spawning cards and adding them to grids. Not necessarily a problem unique to NGUI, naturally. One of our engineers ended up adding an infinite scroller, similar to the one in the most recent update of NGUI, which addressed this problem.
Another big issue for us was it seemed like any time we had an issue with NGUI, the next release would fix it. Which is great, but having to constantly upgrade your UI library on a project with a relatively short dev cycle was at times terrifying. We had to fight really hard to get the December update in (4.0.5, I think?), but as it turned out, the performance benefits were huge and the depth fixes saved us a lot of sanity points.
How it could be improved:
I am actually really happy with NGUI. It's featureful and stable, not generally a resource hog, and ArenMook has been incredibly responsive to questions and bug reports throughout the development process.
There are two big improvements I'd like to see. One is dependent on functionality that doesn't currently exist in Unity, and the other is kind of fanciful.
First, the ability to compose UI elements, which probably requires nested prefabs. For example, you have a stock dialog and a stock button. If you add the buttons to the dialog, then you change the buttons, you have to crawl inside the dialog prefab's object graph and update the embedded copies of the buttons directly. We got around this with a solution that dynamically builds UI at runtime, but A) that means you can only see the UI at runtime, and B) it's a little difficult to wrap your head around, which makes it a tough tool for solving some UI problems. So yeah: prefabs inside prefabs, Unity, let's go!
Second, and currently nobody in Unity UI-land does this, is an improved workflow. The ideal workflow, for me, is for an artist or graphic designer to build UI pieces in the editor and just have engineers wire them up. Presently, all of our UI has to be hand-crafted by an engineer (aside from creating textures and comps, obviously), which shifts the burden to the people with the wrong skillset for the job, IMHO.
DataProvider stuff:
I've actually done a ton of work with data binding in WPF and Flex (the latter in a shipped Facebook game for Zynga), and it is very handy, especially for rapid prototyping. However, I have also found that it's easy to become reliant on it. Once all your data management lives in a black box, if you run into performance issues, it can be painful to debug and sometimes even more painful to fix (occasionally to the point of having to rip out the data binding and replace it with hand-crafted data population). So while it's cool, I don't see it as a panacea or a must-have feature. I guess you would say I am lukewarm on the matter.
Show Posts
