Unity iPhone vs. Apple’s Developer License: Time to Worry?
For those of us using Unity iPhone, Apple's new developer licensing terms are cause for concern. Specifically section 3.3.1, which states:
3.3.1. Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
This has widely been interpreted as an attempt by Apple to prevent developers from cross-compiling Flash and/or Google Android games for iPhone. John Gruber has a good analysis of this which is somewhat sympathetic to Apple's position. For unsympathetic opinions, simply swing a dead cat to hit a few.
(If Gruber is correct then I have to take issue with Apple's thinking. If a company like Adobe tries to create their own platform on top of Apple's, I believe Apple's best defense is to keep adding popular features. That forces middleware companies to either support those features and become more Apple-like, or fall behind. But that's a topic for another day.)
So should Unity iPhone developers be concerned? Yes, of course. Unity Technologies is urgently trying to get clarification from Apple on this. But until we know the score, there are many reasons to be hopeful for a favorable outcome.
1. Many of the top iPhone games are from companies like Popcap who release cross-platform casual games all the time. Many of these companies do not write their games from scratch for every platform. They target their own internal framework which itself supports multiple platforms. Apple is going to have a real problem if companies like Popcap and Telltale aren't allowed to do this.
2. Unity Technologies is heavily invested in this issue. If in the end comes down to a matter of what language the game is scripted in, or some other technicality, they are probably going to find a way to get around it.
3. Disallowing middleware like Unity isn't straightforward, particularly for games. If the final project is built in XCode, and follows the UI guidelines appropriate for that app's category (e.g. utilities are generally expected to follow Apple guidelines and use the Cocoa controls; but games almost always use a custom user interface) then the product becomes indistinguishable from "native" code from the user's point of view. It's hard to imagine that Apple would reverse-engineer games in order to distinguish Unity iPhone games from others.
Of course, Apple has been willfully arbitrary before, so this argument doesn't hold THAT much water, but it's a point to consider.
4. People who use Unity are well-positioned to jump to another market if Apple locks this one down. It's hard to overstate this point. Competing platforms like Android are going to have a field day with this, as it reinforces their message that Apple's closed system is bad for developers. Google would welcome disenfranchised iPhone developers with open arms. And an Android edition of Unity is already in the works.
The burden is on Apple now to clarify or possibly revise the policy. Personally I think they are going to interpret it narrowly or possibly even retreat from it. It seems to me like a classic case of lawyers reflexively setting up something that in retrospect is difficult to enforce and hurts Apple more than it helps.
Here's hoping the situation gets resolved quickly.
Isometric vs Perspective Camera
Recently I've been experimenting with using an isometric camera for Pawns for the iPhone.

Isometric views have always felt a little cheesy to me, for historical reasons. In the old days it was often used to fake 3D. Since things don't get smaller as they move further away from an isometric viewpoint, you could use 2D sprites instead of drawing true 3D objects. This was useful when the graphics hardware was only good at drawing sprites. (For example, old arcade games like Q*Bert or Zaxxon painted their 3D graphics this way.)
The iPhone is of course perfectly capable of rendering true 3D. And with Unity I don't gain any speed just by switching to a isometric view. Even so, the isometric view has a few advantages.
Firstly, the squares near the rear of the board are the same size as those in front, making it easier for the player to place arrows. Pieces in the back are also more visible this way.
I can also optimize the appearance of the 3D pieces. Under perspective it's hard to make out the crosspiece on top of the king, for example, depending on the angle. In an isometric view the king's rotation relative to the camera is always the same, whether it is on the left side of the board or the right. So each model only needs to look good from one angle.
This isn't just a matter of aesthetics, or covering up my mediocre artistic skills. Pawns will not be fun on the iPhone unless each type of piece is instantly recognizable despite the small screen.
For that matter, with care I could improve the graphics by prerendering high-resolution chess models to make 2D sprites. This might improve their appearance- I've been having wrestling with lowering the polygon counts without having the pieces look too crappy. (A topic for a future blog entry, perhaps.)
Of course, if I go to billboarded sprites I can't simply reposition the camera or lights whenever I feel like. And after seeing Pawns in perspective for so many years, I'm having a hard time getting used to the isometric look. Still, I'll leave it this way for a while longer and see if it grows on me.
Reducing UnityGUI Draw Calls
When trying to improve the performance of a Unity iPhone game, time spent reducing the number of draw calls is usually time well spent.
Unfortunately one of the big draw call "hogs" is UnityGUI. A useful guideline is to only use UnityGUI for game menus and option screens where framerate isn't important. For in-game controls such as a HUD, developers resort to other methods. Alternatives include GUITextures, SpriteManager, or its commercial sibling SpriteManager 2.
However, other tricks are sometimes possible, and I found an especially easy way to speed up a ScrollView. My game Pawns has a scrolling list that allows the player to pick a puzzle:
I used UnityGUI for it, and since the game is not actually being played on this scene I was hoping it would be fast enough. However, the screen was unusably slow on my iPhone, and number of draw calls reported by Unity was 165! So a serious rewrite or redesign appeared to be needed.
The structure of my puzzle picker is a Gui.Window for the frame, containing a Gui.Scrollview. Inside of the scrolling view, I loop through the list of puzzles and paint the three elements that make up each line (a checkbox, text for the puzzle name, and a texture displaying the difficulty rating.) The code looks something like this:
scrollPosition = GUI.BeginScrollView (rScrollFrame, scrollPosition, rList, false, false); for (int iPuzzle = Puzzles.GetFirstPuzzle(), numPuz = 1; iPuzzle >= 0; iPuzzle = Puzzles.GetNextPuzzle(iPuzzle), numPuz++) { int difficulty = Puzzles.GetPuzzleDifficulty(iPuzzle)-1; if ( GUI.Button(rCheckbox, texSolved, checkboxStyle) || GUI.Button(rBtn, Puzzles.GetPuzzleName(iPuzzle), puzzleButtonStyle) || GUI.Button(rDifficulty, ratings[difficulty], puzzleButtonStyle) ) { // Code to jump to the selected puzzle goes here... } // set up rectangles for the next line rBtn.y += lineHeight; rTexture.y += lineHeight; rDifficulty.y += lineHeight; } GUI.EndScrollView();
Each GUI element causes a draw call. (If you are using GUILayout instead of the GUI class, then double that.) The more puzzles in my list, the more draw calls.
For the total number to be as high as 165, even the lines which are currently scrolled off the screen are generating draw calls. On my screen if the player can't see a line they can't tap on it, and no code depends on them. In fact, I don't need to draw them at all. If I was using GUILayout then I wouldn't know the position of each element, but I'm using GUI, which requires me to position each element myself.
So it turns out it's a simple matter to skip GUI elements that are not visible. You simply test the rectangle of each control before drawing it. In my case all scrolling is vertical, and the elements are arranged in lines, so I can skip entire lines by testing if either the top or bottom of each line is visible.
The code now looks something like this. Note the line marked *NEW*:
scrollPosition = GUI.BeginScrollView (rScrollFrame, scrollPosition, rList, false, false); for (int iPuzzle = Puzzles.GetFirstPuzzle(), numPuz = 1; iPuzzle >= 0; iPuzzle = Puzzles.GetNextPuzzle(iPuzzle), numPuz++) { // *NEW* don't actually draw the controls if this line's rectangle is not visible if ( rBtn.yMin >= scrollPosition.y && rBtn.yMax <= scrollPosition.y + rScrollFrame.height ) { int difficulty = Puzzles.GetPuzzleDifficulty(iPuzzle)-1; if ( GUI.Button(rCheckbox, texSolved, checkboxStyle) || GUI.Button(rBtn, Puzzles.GetPuzzleName(iPuzzle), puzzleButtonStyle) || GUI.Button(rDifficulty, ratings[difficulty], puzzleButtonStyle) ) { // Code to jump to the selected puzzle goes here... } } // set up rectangles for the next line rBtn.y += lineHeight; rTexture.y += lineHeight; rDifficulty.y += lineHeight; } GUI.EndScrollView();
This worked well; only 6 or 7 lines are ever visible at a time, so the draw calls now hovers around 27 no matter how puzzles are in the list. The screen is now usable on my iPhone, though I should probably cut the number of draw calls a little further.
Obviously not everyone will happen to be using ScrollViews so I'll mention a few general approaches to improve UnityGUI's performance:
- Combine elements/textures. For example, if I painted each line with a single texture instead of three separate elements, that would cut the draw calls by two-thirds. I could go further and paint multiple lines, even entire pages in one texture.
- Avoid GuiLayout. If you don't use GuiLayout at all, and your GUI script sets
[code language="csharp"]useGUILayout = false;[/code] early, such as in the Awake method, then the number of UnityGUI draw calls will be cut in half.
- Redesign. For my example I could have abandoned the scrolling interface and replaced it with page-up/page-down buttons.
I will probably need to try out alternatives such as GUITexture or SpriteManager to speed up my main game screen, so I may have more to say about them at a later date.
Reading Text Data Into A Unity Game
Unity's rapid edit-compile-test cycle encourages developers to build game levels interactively in the editor. Game parameters are often saved directly in the scene, or on prefabs. However, sometimes it makes sense to read that data from a file at run-time.
For example: Pawns puzzles are defined by a simple arrangement of game elements on a grid. By putting this information in a text file, I was able to try changes to the puzzles without leaving the game. Even better, by giving public access to the file I have the option to allow other people to mod the game (i.e. make their own puzzles) even if they don't have Unity or the Pawns source code!
Below I post the code for the two techniques I used to read text files into Pawns. I also cover some of the differences to be aware of when loading data on different platforms.
Method 1: Read a text file embedded in the game's resources
The simplest technique is to read a file that Unity has compiled into your game, just as it does for the other game assets like textures, sounds, and models. This is simple because Unity encrypts the file into your game bundle automatically. However the file is not visible to would-be-level editors, so you lose some of the advantages I talked about earlier. But if you want to avoid exposing the file's contents to the public in a shipping game, this may be just the thing.
Place the textfile (in this example, "puzzles.txt") in the Resources folder of your Unity project. Unity will automatically package it into your game. To read it, your script just uses Unity's built-in Resources class:
FileInfo theSourceFile = null; StringReader reader = null; TextAsset puzdata = (TextAsset)Resources.Load("puzzles", typeof(TextAsset)); // puzdata.text is a string containing the whole file. To read it line-by-line: reader = new StringReader(puzdata.text); if ( reader == null ) { Debug.Log("puzzles.txt not found or not readable"); } else { // Read each line from the file while ( (string txt = reader.ReadLine()) != null ) Debug.Log("-->" + txt); }
Method 2: Read unencrypted text file bundled with the game
This example reads text from a file that sits alongside other files of your compiled game. Anyone can see and edit the file, which makes it convenient for making changes without having to rebuild your game. The complication is that you have to remember to include the file with your game, either by manually adding it after every build, or by creating a Unity build post-processing script to do it for you.
The following example reads a file called "puzzles.txt" from the game's data folder as pointed to by Application.dataPath. This location varies depending on where your game is running:
| Where game is running | Application.dataPath |
|---|---|
| In the Unity editor | project's Assets folder |
| Mac build | 'Contents' folder in the package (right-click on the game, select "View Package Contents") |
| Windows build | Data subfolder |
| iPhone app | In app's writeable Documents directory; see comments below |
| Webplayer build | URL to webplayer's data folder; use WWW class to access |
(Since Application.dataPath returns a URL for webplayers, the following code will probably not work for them. You would have to use the WWW class instead.)
FileInfo theSourceFile = null; StreamReader reader = null; theSourceFile = new FileInfo (Application.dataPath + "/puzzles.txt"); if ( theSourceFile != null && theSourceFile.Exists ) reader = theSourceFile.OpenText(); if ( reader == null ) { Debug.Log("puzzles.txt not found or not readable"); } else { // Read each line from the file while ( (string txt = reader.ReadLine()) != null ) Debug.Log("-->" + txt); }
Method 1+2: Read from plain text file, with fallback to embedded resource
Pawns originally used method 2 exclusively, but since I plan to charge for the full set of puzzles I'd prefer not to have the final puzzle file exposed for all to see. On the other hand, I'd still like to have the ability to try out new puzzles occasionally, or allow others to design puzzles. A simple solution is to first look for the plain text file using method 2; if not found, load the default puzzles embedded in the game resources (method 1.)
In fact, since StringReader (used to read lines from the embedded text resource) and StreamReader (used to read the plain text file) are both subclasses of TextReader, once either file is opened the rest of the code can parse it without caring whether it's reading from a file or an in-memory string:
FileInfo theSourceFile = null; TextReader reader = null; // NOTE: TextReader, superclass of StreamReader and StringReader // Read from plain text file if it exists theSourceFile = new FileInfo (Application.dataPath + "/puzzles.txt"); if ( theSourceFile != null && theSourceFile.Exists ) { reader = theSourceFile.OpenText(); // returns StreamReader } else { // try to read from Resources instead TextAsset puzdata = (TextAsset)Resources.Load("puzzles", typeof(TextAsset)); reader = new StringReader(puzdata.text); // returns StringReader } if ( reader == null ) { Debug.Log("puzzles.txt not found or not readable"); } else { // Read each line from the file/resource while ( (string txt = reader.ReadLine()) != null ) Debug.Log("-->" + txt); }
Parsing XML in Unity
People often use XML as a convenient text file format, and the Mono libraries contain powerful classes for parsing it. So this would seem to be a natural fit for Unity. But using those functions requires additional Mono libraries to be bundled with your game. You should particularly avoid this when building a webplayer or iPhone app. See the Unity documentation for details.
Fortunately most tasks only require a small subset of the XML standard, so writing or borrowing a simple parser is an alternative. I found some alternatives being discussed in the Unity forums here.
To use the Mono libraries to read and write XML, this article seems to cover the topic nicely.
Accessing text files on the iPhone
As mentioned above, iPhone apps each have a writeable Documents directory. The contents of this directory are preserved when the app is updated. However, that directory starts off empty and there is no way to install a file directly into that directory along with your app. The workaround is for your game to create whatever files it needs the first time it is run.
The following code was posted in the Unity3d forums (and I've seen it elsewhere) for finding the location of the writeable Documents directory:
string docsPath = Application.dataPath.Replace("/Data", "/Documents/");
However, I imagine this may change in the future. Application.dataPath is a bit strange with Unity iPhone 1.5.1 in that it does not appear to point directly to a usable directory. To read from the Documents directory you need to use the above code. To read asset bundles you need to replace "Data" with "myappname.app/Data". If the folks at Unity Technologies ever decide to fix Application.dataPath to point directly to the Data directory in a future release of Unity iPhone, the code for finding the Documents directory would need to be updated. (Or perhaps they will also add a method like Application.documentPath as well.) [3/6/2010: Unity 1.6 for iPhone was just released, and I see in the release notes that they have added the application name to the Data directory, just as I predicted. So the code sample above needs adjusting- the application name will also need to be removed from the path.]
Unity Pro only: asset bundles
Developers of webplayers and online games should also look into asset bundles, a Unity Pro feature that lets you collect game objects into a file ahead of time, and then load them at run time from a local file or from a web server.
Comments and corrections welcome. Did you find an error? Did you have a particularly interesting use for runtime data in your game? I'd be interested to know.
Getting WinMFS to recognize Mac Pro internal SATA drives
I recently "hacked" my TivoHD by copying the internal drive to a larger capacity drive. The larger space is useful, but better yet, I now have the original drive as a backup just in case the one in the Tivo dies. (My old Series 1 Tivo lost a couple of drives over the years.)
There is plenty of information out there on how to do this upgrade, and I am far from expert on it myself, so I won't go into details except to say that I used WinMFS running on a Mac Pro. The two SATA drives (the one from the Tivo and the new one) were mounted internally.
Which is where I ran into difficulty. WinMFS (running in WinXP under VMWare Fusion) did not recognize the two drives. I even tried booting MFSLive in an Ubuntu VM, but again, no drives. I googled the problem, but the workaround appeared to be to buy a couple of SATA->USB adaptors for the drives.
Eventually I hit upon the obvious (in retrospect) solution, which was to boot directly to Windows using Boot Camp. WinMFS worked like a charm in that configuration.
If someone is aware of a way to get WinMFS or MFSLive to recognize internally mounted Tivo drives under VMWare Fusion, let me know. Otherwise, Mac Pro users should go with adaptors or with Boot Camp.
