Dear community, once again I’d like to start by offering my thanks to everyone for their patience through an unclear situation. We’re grateful for the dedication and commitment many of you have shown through all this and it once again serves as another reminder of just how awesome our community is.
Like everyone else who’s excited about mobile development, and in particular using Unity to create awesome games for the iPhone, we’ve been following the development of the iOS 4.0 Terms of Service closely. While we’ve had some reason to believe Unity using C# and JavaScript would be okay, Apple has not confirmed anything and in general very little information has been forthcoming. However, as of today Apple is still approving every game we know of and Apple has recently featured several excellent Unity games in the App Store. And all along we’ve continued to invest heavily in our Unity iPhone line, including a number of new features that will be coming soon in the Unity 3.0 release. But as soon as the new terms of service were revealed we also started working on a contingency plan, just in case Apple decides to stop approving Unity-based games. Allow me to explain that contingency plan so everyone out there knows what “plan B” looks like.
As you probably know, Unity is mostly written in optimized C++ with assembly optimizations and Objective-C wrappers thrown in for good measure. Game logic is written by the developer, using C# and JavaScript, both of which are running on top of .NET. The beauty of this scheme is that we’ve been able to sidestep the old scripting-versus-native question as .NET provides for very rapid development (and almost near-instant compilation), while at the same time generating highly optimized code. And on the iPhone we actually ahead-of-time compile .NET to completely static machine code for speed and conformance with the old iOS Terms of Service. Also, on the iPhone it’s easy to drop into Objective-C code to access fresh APIs like the Game Center, Core Motion, etc. This is truly a case of best of both worlds.
Since Unity’s .NET support may conflict with the new terms of service, we are working on a solution where entire games can be created without any .NET code. In this proposed scenario all the scripting APIs will be exposed to and can be manipulated from C++. This is of course not ideal as there are thousands of code examples, snippets, and extensions created by the community can no longer be copied into your project, .NET assemblies can’t simply be dropped in, and C++ is more complex than JavaScript or even C#.
But honestly, it’s not as bad as one might imagine. One still has the full benefit of the asset pipeline, the shader language, an array of tools and of course the engine and its optimizations. We are also working on maintaining the elegant workflows of the JavaScript and C# in Unity: “scripts” will still be able to be edited live, variables will still be shown in the inspector, and a number of other sweet features that one doesn’t usually associate with C++ development. Essentially we are creating a .NET based C++ compiler that will allow us to write purely managed C++ code in the Web Player and other Platforms. On iOS C++ code will be compiled by Apple’s Xcode tools. This indeed is a very powerful combination. In the Unity Editor, you have fast compilation times and a completely sandboxed environment. On the device you have native C++ performance and low memory overhead. This combines the key strength of scripting languages and C++ code.
When you combine those with the fact that when it comes to straightforward game logic, C++ really isn’t as complex as it’s often made out to be (and as it can be) hopefully you can see that life won’t be so bad after all. To help demonstrate my point, let’s look at a few different examples.
Here is a simple JavaScript function to rotate an object around the world origin:
And now here is that same bit of code written in C++:
As you can see the code required isn’t all that different in simple case scenarios, but what about a more complex example?
Here is a bit of JavaScript that peeks accelerometer and looks for user touch input on an iOS device, then uses that to fly a craft and fire a missile in the game:
And again, here is that same set of code in C++:
Again, the code doesn’t get that much more complicated just by writing it in C++ versus JavaScript, and the difference is even smaller compared to C#.
We continue to be excited about the iPhone, iPod touch and iPad as platform targets for Unity developers. While we don’t think C++ is the best language to write game code, using C++ as a scripting language has memory and performance advantages on low-end devices. This is a great feature to have for developers who want to squeeze the last ounce of memory & performance out of their games.
We still can’t believe Apple will force developers into choosing a specific language for development. And as mentioned, Apple is still approving every Unity-based game we know of. In case the situation changes, rest assured that we are working this Plan B.
We’ll be ready to talk more about this as well as share some time-line information with you soon, while of course waiting to find out if any of this will actually be necessary.
