Pawns! has been submitted to the App Store
Pawns! 1.0 has now been submitted to the App Store.
While preparing to submit it I discovered that the name "Pawns" was reserved for another product (though no such app currently is for sale.) So I've renamed it "Pawns!" (adding the exclamation mark.)
Fingers crossed, my game will be available on the store in a few weeks.
The Case of the Lingering Collider
Unity 3 for iPhone has some new behavior that I just ran into. When switching from one Pawns puzzle to the next, my code destroys one set of objects then creates others. This has worked for years, but in Unity 3 builds running on an iPhone, I noticed that the colliders of just-destroyed objects are now sometimes hitting objects being created afterwards.
This only happened when running on the actual device, not in the editor. Weirdly, I only see it happening for colliders on a particular type of object (the red checkers.)
My workaround was to deactivate each object just before destroying it:
foreach (GameObject gameobj in transients) { gameobj.active = false; // <-- NEW Destroy(gameobj); } // .. create new objects, etc..
I should probably file a bug on this, but since it doesn't happen for all my objects I can't say for certain that I have the problem entirely figured out. So I'll need to find time to work up a solid example. What little time I have at the moment is spent on a couple thorny GUI issues (will post about that soon.)
Sorry this is so vague, but I figured that it was worth mentioning on the off-chance that it helps someone. If I learn more I'll post.
UnityGUI Unresponsive on iPhone Retina Displays (Updated 10/28/2010)
A tester reported that Pawns for iPhone was not working on his 4th generation iPod Touch (with Retina display.) Specifically, many of the menu buttons were very flaky, sometimes requiring multiple taps before they'd register.
After some investigation I isolated the cause [EDIT: or maybe not? See my updates at the end of the post.] It appears that UnityGUI buttons are extremely sensitive to movement of the finger, when run on retina displays. The slightest movement of the fingertip on a retina display causes the tap to be ignored. (Version info: Unity 3.0 for iPhone; non-HD build of the game.)
I believe the problem is with Unity's translation of touches into "clicks". There is a movement threshold value (probably 5 to 10 pixels) beyond which a touch is no longer treated as a single tap on a Button. I believe Unity is using the same threshold value on retina displays, and that threshold is too low for the higher-resolution.
If I'm right, anyone shipping an iPhone game that relies on normal UnityGUI click logic is taking a serious risk at the moment. If you are getting complaints about unresponsive controls on retina displays, this is quite possibly the culprit.
I have filed a bug of course, and in due time I expect Unity Tech will change the threshold, or possibly something else I haven't thought of, and all will be well.
In the meantime, I've got a game to ship! So, what to do?
My plan was to add my own touch-processing logic, using the same techniques I recently used to make the ScrollView control respond to finger drags.
However, I found to my dismay that most of my remaining UnityGUI menus happen to be using GUILayout, not GUI. This means that I don't actually know where the buttons are being displayed on the screen. And without that Rect, I can't do touch detection.
So I am faced with the choice of waiting for a possible fix, or of converting my GUILayout menus to GUI. Doing the layout myself is not rocket science, but it is tedious to rewrite the menus and retest every iPhone and iPad resolution and orientation I plan to support.
UPDATE: See the comments below. It turns out there IS a way to get the rectangle of a GUILayout control. I will post some sample code once I've implemented a workaround for the responsiveness issue.
UPDATE October 28, 2010: I have coded the workaround. But: I am no longer able to reproduce the original problem! Either something has changed about my test app, or I'm missing an important detail.
I wasn't seeing widespread reports of this problem so the fact that it doesn't always occur makes sense. In a way, a relief. But I would dearly like to know how it happened originally, and not just because it would have saved me some effort rewriting the tap logic. The effect was very specific to button presses on a retina display, and all my testers noticed it. Unfortunately without owning a retina display myself I am not going to get to the bottom of this any time soon.
Coming soon- Pawns for iPad and iPhone!
The page is up for my forthcoming game, Pawns for iPad and iPhone! More than just a port of the Mac & Windows game, this version has many more puzzles, rated for difficulty. The user interface has been redesigned for touch screens. Not to mention the two most-requested features of all: knights and queens!
The game is currently in beta-testing and I hope to release it in about a month. Stay tuned!
Avoiding Performance Cost of OnGUI
The Unity profiler revealed recently that Pawns for iPhone was spending 5% of its time in a UnityGUI script that I didn't need any more. Removing it from my scene was easy enough, but it got me thinking. The script looked something like this:
void OnGUI() { if (showDialogBox) { // lots of code that never executed } }
Not much going on here! So it appeared that just having OnGUI in a script was expensive. This was worth knowing because I still have three other OnGUI scripts left in the scene. Each of them exits immediately if their dialog box is not showing. So in theory they should cost nothing during actual gameplay. But the profiler told a different story:
It turns out that there are some major setup costs associated with OnGUI. GUI.Repaint is listed as taking over 65% of the CPU! Of that, most of the time is spent in GUIUtility.BeginGUI. Note that almost no time at all is spent in my three OnGUI methods (TutorialController.OnGUI, DlgOKCancel.OnGUI, and DlgPuzzleFooter.OnGUI.) So the early exit clause was working, but the damage was done before OnGUI was even called.
To verify this I disabled the three objects in the inspector while the scene was running. The new profiler results are much healthier:
GUI.Repaint has been eliminated. The time is now mostly spent on rendering, physics, and in scripts.
Since disabling the scripts solved the problem, I did the obvious thing, which was to to disable the objects with the OnGUI scripts on them until needed:
footerDlg.gameObject.active = false;
But one trick is needed to reactivate them. Search functions like Find and FindObjectOfType do not return inactive objects. Instead, you must already have a reference to the object you want to activate.
One way is to start the scene with active = true. Your script can then Find the object, store a reference to it, and then set active = false until it is needed. (This is what I did because it worked well with the code I'd already written.)
void Awake() { // cache reference to footer dlg footerDlg = (DlgPuzzleFooter) GameObject.FindObjectOfType(typeof(DlgPuzzleFooter)); if ( footerDlg == null ) { Debug.Log("Error: DlgPuzzleFooter object is missing."); } else { // deactivate it until needed, for performance footerDlg.gameObject.active = false; } }
A second way is simply to declare a public variable for the inactive object, and then use Unity's Inspector to set the value at design-time.
A third approach is detailed in a post on UnityAnswers. It keeps a list of every object that gets deactivated.
The fact that OnGUI looks like any other Unity method is misleading. It's an expensive operation, even if it returns immediately without drawing anything.
UnityGUI itself is not recommended where performance is important, particularly during gameplay on an iPhone or Android device. But it is a convenient way to define menus, dialog boxes, high score lists, and other parts of the user interface. By deactivating OnGUI scripts until they are needed, you can often avoid paying much for that convenience.