Unity Technologies released a new preview build of Unity 3 this week, so I revisited the issues I mentioned in my previous post. Most have already been fixed.
Updated Issues
My paper is now lit normally. Apparently this was a Unity bug after all, or I needed to restart Unity for some reason.
Some sounds that hadn’t been playing are now working. I hadn’t even mentioned this one last week, assuming that it was just another example of assets becoming disconnected by the project conversion.
Lightmapped textures now display correctly in the material inspector.
I worked through the compiler error, that System.IO.FileInfo.Open() no longer accepts 0 or 1 arguments. Some of the documented overloads appeared to be missing:
public void WontCompile()
{
FileInfo theSourceFile = null;
Stream reader = null;
theSourceFile = new FileInfo (Application.dataPath + "/puzzles.txt");
if ( theSourceFile != null )
{
reader = theSourceFile.Open(FileMode.Open); // COMPILE ERROR: NO OVERLOAD TAKES 1 ARG
reader = theSourceFile.Open(FileMode.Open, FileAccess.Read); // NO ERROR
}
}
It was easy enough to add the missing arguments. But while I was reproducing the problem for Unity Tech support (who were very helpful by the way), we managed to clear the error by doing two things: changing the API Compatibility project setting from .NET 2.0 Subset to .NET 2.0; and creating a standalone build of the game. And now that the error is gone, I can’t get it to come back, even by setting API Compatibility back to 2.0 Subset. Strange.
New Issues
I noticed two issues that I hadn’t before. One is a bug, the other is a change that I’m going to have to get used to.
Clicking on a texture of a Material brings up the new,, nice texture selection dialog. Unity used to instead jump the Project view to the texture. I’m finding it inconvenient that I can’t jump from a material directly to the texture’s import settings. Meshes and Materials have little dots next to them; clicking on the dot jumps you to that asset.
The inspector shows a hotspot next to Meshes and Materials that take you to that asset. Textures don't have it.
Hopefully a similar shortcut will be added for textures.
Maximize on Play doesn’t restore the editor windows once the game has stopped. This is accompanied by an error in the console.
I finally got access to the Unity 3.0 preview build last weekend, and was able to spend a couple of hours with it. My goal for the session was to add a lightmap to my A Tack game. Here’s how it went.
Installation
Always rename your old Unity install folder(s) before running a new Unity installer. (This goes for all Unity upgrades, not just the Unity 3 preview.) This lets you return to old versions. For a disposable beta version this is obviously useful, but I’ve sometimes found it handy to open a project in an old version for comparison.
Obviously you should also make a backup of projects before letting Unity convert them into a new format, which Unity 3 does.
Converting the Right Project
There is a pitfall I ran into even though I had made a backup of the project I wanted to convert to Unity 3. I tried to open it, but then ran into the registration screen. Once I’d gotten past that, Unity opened and converted the last project I’d worked on instead of the one I’d just picked to open.
I imagine that it was the registering screen that caused this problem. After registering be sure to read the dialog carefully and note which project Unity is about to convert.
MonoDevelop
I have been eagerly looking forward to both the debugging and code completion features, so the first thing I did was set up Unity to use MonoDevelop. The steps to do this are:
Create a MonoDevelop solution file.
Open that solution in MonoDevelop, build it, then run it.
(optional) In Unity’s preferences, set MonoDevelop to be the default script editor, so that opening a script doesn’t bring up Unitron.
The manual has a section on this; I also found the following video demonstration (courtesy of BergZergArcade.com) helpful:
Autocompletion and C# syntax highlighting in MonoDevelop worked well. These will save me many trips to Unity and Mono references. (I didn’t try debugging with breakpoints yet.)
Bug: unrecognized method FileInfo.OpenText
The first project I opened (unintentionally) was Pawns. I was able to build it in MonoDevelop, but the Unity IDE refused to run it, claiming that one of my scripts was using an unknown function. System.IO.FileInfo.OpenText is a perfectly legitimate method though, and I’ve been using it for months with Unity 2.6 and Unity for iPhone. (MonoDevelop’s autocomplete also thought it was legit.)
This was a showstopper unfortunately, so I closed Pawns for the time being and converted the project I’d originally intended: A Tack.
Conversion Then Repair
Perhaps its because I’m editing projects that were originally created with Unity 1.x and have gone through many edits and conversions since, but almost any time I convert to a newer Unity format I lose some asset assignments. This time was no exception so I spent a little while re-assigning models and scripts to objects that had lost them. This was my first exposure to the new texture picker, which makes selecting the right texture much easier:
Scalable, searchable texture picker
A Tack reads and writes pixels from some of its textures. This is a setting on the texture that defaults to off. so I had to go through my brush and paper textures to enable read/write on each. (Unity gave a helpful error message for this so there was no mystery.)
Speaking of texture settings, there are a few new import settings for textures. The settings now include support for normal maps and lightmaps, and towards the bottom there are settings that can be overridden when building for different platforms (I’m licensed for Mac/PC and iPhone, so next to the Default there are two additional icons.)
Unity 3 Preview's texture import settings
Finally it was time to try out the feature I’d been looking forward to: lightmapping.
Lightmapping
The main reason the spotlight exists in my scene is to make that nice-looking circle of light on the desk; a lightmap for the desk will let me get rid of the spotlight, saving on lighting calculations.
The steps I followed to lightmap the desk were:
Toggle the lightmapping checkbox on the texture I wanted to lightmap (in this case, the desk.)
Select the desk (a plane) in the scene Hierarchy view, then click on the menu Tools->Lightmapping.
Select the static checkbox, then click bake.
The lightmapping calculations churned for about a minute. I then turned off the spotlight in my scene, but the lighted circle on the desk remained. Success! So simple.
Spotlight facing the desk was replaced by a lightmap
I finally called it a night when the paper object stopped reflecting any light. (Haven’t solved this one yet; it seemed to start when I tried to lightmap that texture, and nothing I’ve tried since has fixed the problem.)
Conclusions
This was a preview release, and probably not even the most current beta. I ran into pretty much the kinds of bugs and conversion issues that I expected. Some were minor; only one was a definite showstopper. So overall my impressions are positive.
I’m thrilled about the lightmapper and the use of MonoDevelop for coding and debugging. Plus there are dozens of other useful features that I haven’t played with yet. I’m feeling the same sense of excitement and discovery that I felt the first time I tried out Unity, way back in 2005.
I recently added a profile of my forthcoming game, Pawns for iPhone, to the website IndieDB. As I was generating screenshots I found to my dismay that I could not generate high-resolution screenshots of games in progress. The iPhone version of Pawns is currently hard-wired for iPhones in landscape mode.
I had planned all along to look into iPad and “retina display” support later on, possibly after the first release for iPhone. It never occurred to me that I would find those higher resolutions useful myself. Oops.
Even more embarrassing, the original version of Pawns supported many screen resolutions. It’s something I lost as I tuned the game for iPhone.
The original version used Unity’s GUI objects, which are always sized proportionally to the screen. To make the graphics crisper on the iPhone I had converted much of it over to UnityGUI. But pixel-correct textures come at the cost of needing to draw gui elements at every resolution that you will need them. The plan is to rebuild my gui elements at a much higher resolution and let them be scaled pretty much wherever they are used. Hopefully the result won’t be too blurry.
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.
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.
