Author Topic: Our game, with extensive NGUI UI, now available on all mobile platforms  (Read 11526 times)

MrTact

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 32
    • View Profile

beermoney

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 80
    • View Profile
That looks very nice, installing it now, I'd be interested in your thoughts about using NGUI for your game. Would you use it again? What was the development cost? How much time did you spend on the UI versus other area of the game dev. 

wallabie

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 200
    • View Profile
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.

stevej

  • Full Member
  • ***
  • Thank You
  • -Given: 1
  • -Receive: 0
  • Posts: 117
    • View Profile
Would love to hear your thoughts in my Font thread:
http://www.tasharen.com/forum/index.php?topic=8898.0

Been playing this game for a few days and it's a good example of very small but very crisp fonts.

Nicki

  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 33
  • -Receive: 141
  • Posts: 1,768
    • View Profile
Downloading now. ;)

MrTact

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 32
    • View Profile
That looks very nice, installing it now, I'd be interested in your thoughts about using NGUI for your game. Would you use it again? What was the development cost? How much time did you spend on the UI versus other area of the game dev.

We would absolutely use NGUI again, although by the time we get around to doing our next title, uGui will likely be out, and we will probably evaluate NGUI against that. Still a good chance we would continue to use NGUI, since we have built up considerable expertise in its use at this point.

I can't really comment on dev costs, but we spent almost exactly a year in development, including prepro. We probably started looking at GUI development around August of last year. We don't have dedicated engineering roles, but during that timeframe, I guesstimate that we devoted between half and one whole engineering FTE to UI, plus art resources on which I have no visibility :-)

MrTact

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 32
    • View Profile
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.


wallabie

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 200
    • View Profile
Thanks for the great write up on your experience with NGUI.  Very helpful tips.

1. Definitely agree with an improved workflow that allows designers and engineers to work independently.  Later versions of Flex enabled this type of separation of concerns.

2. DataProvider.  Good to know that you've also have Flex experience.  I agree that the data binding in Flex is a bit of a black box and often times, we did have performance problems with their system.  In regards to NGUI, I'm not proposing a Flex data-binding situation, I was referring for components to be able to be "Data Aware".  Take for example a horizontal scrollList, currently, there is a UGrid that we can attach that will nicely layout the items into a grid structure.  The data provider is another component or widget that we can attach to the scrollList that takes in a Json, array, List, etc.  The scrollList then populates itself with the contents of the data.  Very much like Flex but  much more lightweight and as a component that we can customize using the inspector editor.  With the upcoming building blocks of databinding and parameterized delegates, this could be the next step. 

What I am thinking of is being able to more easily assemble new GUI components from prefabs, tack on a custom provider component, customize it, then feed in the data.  This kind of workflow will make NGUI much more powerful.  ATM, it's a lot of very tedious work to individually hook up each individual UISprite or widget. 

As an example, if one were to build a data-aware scrollList like a photo gallery.  How much work will it take ?  The flex or old unity gui data driven approach is quite different.  Start with a scrollList base, re-skin and add custom layout code or handler code for customization.  Feed in the data and done.


 





MrTact

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 32
    • View Profile
This is very similar to what we actually did on SWAT, although it's all hand-crafted code.

wallabie

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 200
    • View Profile
You see what I mean,  each user of NGUI has to "Repeat" himself again and again, this is completely against the core principle of programming.  Why is it that each person who buys NGUI have to go through the same level of tediousness.  There are many best practices that can be learned from other GUI packages that makes life easier.  These extras should not be implemented in a fixed and obligatory way, but rather in a unity's component architectural way so one can tack on as needed.  When uGUI comes out, if NGUI doesn't provide substantial differentiating value to the customer, then it will be very difficult to ask dollars for something that one can get for free.  It was mentioned that NGUI has better support, but the idea of paying $95 extra for better support on what is essentially a bare-bones GUI is not going to cut it.  It's worth spending the money if the GUI system included many built-in components that one can quickly get productive with rather than building everything from scratch. 


drjeats

  • Newbie
  • *
  • Thank You
  • -Given: 1
  • -Receive: 0
  • Posts: 13
    • View Profile
Re: Our game, with extensive NGUI UI, now available on all mobile platforms
« Reply #10 on: April 07, 2014, 02:46:29 PM »
Cool, we were just playing this at work just the other day!

Feeling the same pain points: any UI that has dynamically-added child widgets usually gets mocked up as a static UI by our artist, which I then take to convert repeated things into prefabs that get dynamically instantiated. Any workflow tips on this, or is that as good as it gets?

Nicki

  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 33
  • -Receive: 141
  • Posts: 1,768
    • View Profile
Re: Our game, with extensive NGUI UI, now available on all mobile platforms
« Reply #11 on: April 08, 2014, 03:01:58 AM »
@wallabie: You'd think that competent developers that use a tool build up a library of elements and structures that is reused for future projects. As a professional developer, I'm fairly certain I wouldn't use anything as-is in the package. I tend to want to look around the code to figure out these best practices. Furthermore, there's quite a few examples showing of how the usage was intended.

UI is almost always handcrafted each time, since it's always designed differently. If you design it the same, there's lots you can reuse.

While I think NGUI and the other external gui alternatives will lose quite a bit of traction when uGUI comes out, I doubt that well will dry out just yet.

As long as the external tools have an edge, then they will sell. While it may be hard to see NGUI's edge right now, I think that's only because we haven't seen uGUI in action yet, so we're filling in the blanks ourselves. Once it comes out, it will become very clear if it obsoletes NGUI and DF-gui and all the rest altogether or not.

wallabie

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 200
    • View Profile
Re: Our game, with extensive NGUI UI, now available on all mobile platforms
« Reply #12 on: April 08, 2014, 08:36:25 AM »
@Nicki,  I semi agree with you about saying that no competent developer would not use anything as-is in the package.   This is quite dependent on the package.  I'm coming from Flash and Flex, in the beginning days, we had to build everything ourselves.  Over time, more and more GUI framework and packages came out and they took the most common use cases and made things much easier.  Sure we could not use everything as is out of the package but if the package was well designed, then we could customize very quickly.  If I compare NGUI with the Flash analogy, NGUI is the bare-bones model.  Unity is getting quite mature and the GUI should reflect this level of maturity.  At the end of the day, anyone who is buying a package first considers how much time they will save.  What can this thing do for me , How can it help me to be more productive and less grind.  This is the bottom line.  This is the Value added proposition that NGUI can leverage if it wants people to spend money.  Add a variety of ready-to-go GUI components that makes people druel, make these components easy for people to customize and bingo, you've not got a very strong competitive edge. 

MrTact

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 32
    • View Profile
Re: Our game, with extensive NGUI UI, now available on all mobile platforms
« Reply #13 on: April 16, 2014, 01:53:16 PM »
Feeling the same pain points: any UI that has dynamically-added child widgets usually gets mocked up as a static UI by our artist, which I then take to convert repeated things into prefabs that get dynamically instantiated. Any workflow tips on this, or is that as good as it gets?

I wish I did. Sadly, I don't have any useful advice beyond "acquaint yourself well with the NGUITools class."

Ferazel

  • Full Member
  • ***
  • Thank You
  • -Given: 1
  • -Receive: 2
  • Posts: 150
    • View Profile
Re: Our game, with extensive NGUI UI, now available on all mobile platforms
« Reply #14 on: April 16, 2014, 05:23:12 PM »
Hey it looks pretty good! Thanks for sharing!

Although as an engineer myself, I would argue that separating the engineer away from the design/art is often a bad idea for workflow. Granted, a designer should come up with the basic needs, but I feel that it is often in the engineer's best interest to actually be a part of the design process of the UI so that he can provide optimization tips/recommendations to the artist. Also nudging the design to be a little more reusable is also always good. Also pushing the design to fit within the already created NGUI components/restrictions is always a plus. Otherwise you end up with 60 similar dialogs instead of 1 dialog that is more modular. Maybe it is just the artists that I have worked with in the past, but most do not think of the optimizations (slice9, flipping half sprites, fill rate, etc.) or maintenance (Dialog/view reuse) that is often critical for successful UIs.

Edit: We might want to move this thread to the Developer's Cave forum.
« Last Edit: April 16, 2014, 05:29:46 PM by Ferazel »