More NGUI UIScrollView positioning

So one major problem I’ve run across while implementing the Leaderboards with NGUI (3.8.2) was that items in a grid that are part of a scroll view initially start their positions at the bottom of the scroll view, rather than at the top of the scroll view.



This problem is well documented:

I’ve tried several of the solutions mentioned in those posts to no success. I’ve come up with a solution that works for my own purposes. It can hopefully help someone else that is having similar problems.

Firstly, the way I have my UIScrollView structured is that I have an intermediate gameObject called “LeaderboardList” with a script as the direct child of the UIScrollView, and then I have a UITable as a child of that, in vertical orientation, which in turn, contains all of the individual rows. Note that you can use a UIGrid here instead, if you would like.


I like to use UITable’s Reposition() function to align all the child elements properly. However, using the function also introduces a vertical positioning, which I’m suspecting is half the height of the resulting sum of the rows’ heights. I don’t understand this part, especially since UITable has an option to choose a pivot, and by selecting TopLeft, I would have assumed the y component to not be touched at all, or at least be kept at zero.

So anyway, after calling Reposition(), I simply zero’d out the y component of the UITable’s position. Doing this, I get a more expected result.


My UITable’s top is positioned in the center of the parent ScrollView. Ideally, I would have expected the top of my UITable to match the top of the ScrollView, since, in my UIScrollView setting, I have Content Origin set to “Top Left”. But that’s not what’s happening, so I’m clearly misunderstanding the purpose of that setting.


So, going back to my intermediate game object, “LeaderboardList”, I perform all of the table repositioning here. In this object, the table is offset by +halfHeight, which positions the Table in the scrollview area appropriately in the top left corner of the UIScrollView, except for one small detail.


I have the pivot set for each row element set at the center, so I have to account for half the row’s height, and add this to the offset.

Finally, I get a list of rows that starts at the top of the list.


This solution is by far not the most ideal, and I wonder if there are simpler ways to get this working. But it’s the one that I found to work for me, among all the other solutions that I found online. I’d like to read about other developer’s methods to solving this problem. I feel that setting up the scrollview and table like this is quite a lot of extra work that I wasn’t planning on doing, but I strongly believe that users would expect lists to start at the top, rather than in the center.

Posted in Dev, Programming | Tagged | Leave a comment

Using Android Studio for Unity Debugging

Whew! What a slowly productive day, yet productive nonetheless. I’ve been spending time trying to get the in-app purchases system working, and to a point, I wasn’t able to debug in Unity, since some of the messaging was using Android calls, via the Android Native Plugin by Stan’s Assets from the Unity Asset Store.

So, for Unity developers looking to put out an Android product, here’s a tip for you that you may or may not know. Android uses something called logcat for capturing log messages from a device or emulator. Most likely you’ll be testing on a device, such as a phone or tablet. I had been using the freely available Android Studio, which is the main development IDE for Android apps if you aren’t using an alternative authoring platform such as Unity, for debugging. I would create a dummy project in Android Studio, and open up the Android tab to expose the logcat window. And recently, I discovered that the simplest method would be to use the Device Monitor (monitor.bat) that’s available in your <android>/sdk/tools/ directory.

Either method you use, you can easily set the Log level, and filter by specific terms used in your debug output strings, or simply use “Unity” to filter the output from Unity, including your Debug.Log() calls.

Hope this helps someone. Anyway, happy coding!

Posted in Dev, Programming | Leave a comment

Number Crunchers is Coming Soon!

Number Crunchers is still under development, but I should be wrapping up soon.

Head over to the Number Crunchers Landing page if you are interested in finding out when it will be released.

Posted in Announcements | Tagged | Leave a comment


Implementing leaderboards is turning out to be a lot more involved than I initially expected.

Of course, it seems pretty straightforward to have a call from the main system to simply add a score and a name for that score as the primary key in a dictionary. Additionally, it also seems straightforward to sort the list of key-value pairs by value.

Then, the next step that you realize that you need to do is implement serialization and persistence. Sure, you can just choose a file format and read and write that format.

But then, you get to the user interface, and realize that there are quite a lot of moving parts to get it all working together.

I’m using NGUI for Unity, and it’s been great. But NGUI also is so flexible that you still need to put in a lot of effort to get what you want to look right. In this case, I wanted to use either a UITable or UIGrid. The UITable allows variable width cells, since my leaderboards will list rank, name, and score for each row.

On top of having the grid or table correctly list each row item, I wanted the view to be scrollable, so that more entries can be displayed. NGUI has a UIScrollView just for this purpose, and managing that has required some effort as well.

After having the basic structure implemented, you then go about hooking up the leaderboard system to the rest of the game, so that you can make the appropriate calls to log the player’s score. I decided to log the player’s score at the game over screen, just like old arcade games.

Since I’m planning to support a local leaderboard at this time, I realized that I needed the user to identify himself/herself. This meant that I had to introduce the Android keyboard, which actually, wasn’t all that bad, but the fact is it was something that I slightly overlooked.

So, this all sounds like a bunch of complaining, but really, I just want to illustrate that even the simplest of features requires detailed interface and technical design to get as accurate of a time estimate as possible, so that you don’t get in trouble with your development schedule.

Posted in Dev, Programming, Thoughts | Tagged | Leave a comment

Free and Paid apps or IAP to Unlock?

I’m at a point in app development where I have to decide how to publish a free ad version as well as a paid version with no ads and additional features. I’m using Unity, and since I’m fairly new to the Unity environment, I’m in the middle of figuring out a way to make a custom build pipeline so that I can share code, yet save two different configurations.

On one hand, it’s very clear to the user that there is a free and paid app, since they are different listings in the Play Store. But if I can’t figure out multiple project settings in Unity, I’ll have to manually change settings before publishing each version, which can be very error prone.

But on the other hand, it seems simpler to just support in-app purchases and allow users to simply unlock the free version right inside the game. The drawback to this method though, is that this requires the app to have the billing permission enabled, which some users aren’t always receptive to allowing.

I may go the route of doing the in-app unlock, and perhaps put up a paid version listing later on.

Posted in Design, Dev, Industry | Leave a comment

Initial Post

This is my first post on my new site. I’ll possibly get rid of this post before launch, since this is just a test, but I want to get an idea of how it is to post something here.

Posted in Thoughts | Leave a comment