Well good news, after the massive frenzy of 3.3.1 in the App Store Terms of Service, Apple has been wise to loosen restrictions on the AppStore for native apps that use scripting such as Mono, Actionscript, Lua and others as long as it doesn’t download any code (for security reasons). The apps have to be AOT Ahead of Time compiled which Unity, MonoTouch and the AIR iPhone Packager for Flash apps all use or the script has to be downloaded with the binary that was approved or an update (Lua scripting for instance).

This is a huge change in stance for Apple and basically allows Adobe Flash based AIR apps to run on the device natively again. I think this is a very wise decision by Apple to let the market decide on what is a quality app while respecting Apple’s concerns about downloading and running code that might create security concerns (non compiled script outside the web sandbox).

The only bummer is that we won’t see a C++ Unity version which was plan b. But the benefits are really great for all types of developers as long as it is safe and with Apple’s latest update, quality.

Developers using Unity, MonoTouch, Adobe Flash AIR Packager, Lua scripters etc are now all safe as long as it is AOT compiled and scripts it uses are downloaded with the binary and not downloaded later (only content and data can be downloaded unless it is in an approved app update).

All your technologies are safe… for now.. dun dun dun…

However Apple also tightened quality control so they will be rejecting bad or duplicate apps, so at the same time this has made it harder to get apps approved if there is questionable quality or too many of one type of app.  It is good on the surface but also I believe the store should be an open market where the best app wins, crap will naturally filter out.  This is probably a stop-gap for all the apps that will be submitted with AIR or other less complex platforms because more novice users will be submitting them.  So this is good for skilled developers on any platform making quality and original content.  But it could cause some problems.

Engadget has some nice covereage if you dont’ have access to the iOS developer site:

• Apple’s Official Statement regarding this
• Apple backpedaling on some iOS development restrictions, will allow third party tools and ad services
• Apple’s App Store Review Guidelines: ‘we don’t need any more fart apps’
• Daring Fireball on the new changes

We continue to be excited about the iPhone, iPod touch and iPod 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.

The Unity Plan B is that the C++ engine code that mimics as closely as it can to the Mono .net C# or Javascript code. From the samples on the blog the C++ and Mono (javascript in this case) samples are really similar.

Many current engines are legacy or have lots of bloat, unless you write your own, or maybe even still then. Though this is looking really clean for C++ game engine code, at least in comparison to current industry leaders for indie engines.

It would be a beautiful C++ library to use even if Apple doesn’t require it. Compared to the other indie game engines out this would be a sweet C++ engine for indies and hope they do this no matter. C++ can be written cleanly and with influence from a simplified C#/Javascript engine and clean API it makes for a killer C++ engine that makes sense. Right now native is really attrctive on embedded for some years to come.

A very basic comparison from their blog:

Javascript Sample

function Update(){
    //Spin the object around the world origin
    transform.RotateAround(Vector3.zero, Vector3.up, 20 * Time.deltaTime);
}

C# Sample

using System.Collections;
using UnityEngine;
public class Example  : MonoBehaviour {
    void Update(){
        //Spin the object around the world origin
        transform.RotateAround(Vector3.zero, Vector3.up, 20 * Time.deltaTime);
    }
}

C++ Sample

#include "UnityEngine.h"
class Example : public MonoBehaviour {
public:
    void Update() {
        transform.RotateAround(Vector::zero, Vector3::up, 20 * Time::GetDeltaTime());
    }
};

Things I am wondering…

• Will this help porting to Android versions if they use the NDK?
• How much smaller will my app be if I use the C++ version (attractive feature since the mono dlls are pretty big – even though I really dig mono)?
• Wouldn’t a C++ version be a better base with pluggable scripting in C# if you want? Maybe an option for Lua with a similar API signature for all? Ok maybe over-engineering there…

The unity3d platform is about to realize about 900% or 9x more possible market for selling their wares and I believe will blow up with unity 2.5.  Unity3d 2.5 will bring a windows IDE and development environment to unity3d developers. Many game companies are heavily invested in Windows and having this option is breaking down a huge wall to get this development platform and engine into many new hands and companies.

The best part about unity 3d development is the hardware acceleration, the fantastic pipeline, the ability to publish desktop, web, mobile (iphone) and console (wii) is pretty amazing.  All using the powerful mono open source .net framework as a base.

Full update list:

Windows Editor Support

Unity 2.5 adds full support for Windows Vista and XP, with 100% feature parity and interoperability with Mac OS X. The Unity Editor has been rebuilt to look, feel, and function identically on both operating systems, each running the same underlying engine. The best part? Unity on either platform can build games for either platform — cross-platform in the truest sense.

A Whole New Look

Find the tools you need quickly and easily. The Play buttons are front and center, clearly visible and inviting you to play, test, and improve your work. And when you do, they light up, dimming the rest of the application, drawing your attention to the most important things in the play experience you’re creating.
Precise Navigation and Placement Tools

Improved Usability

Snap any object to customizable increments of position, scale, and rotation values. Drag objects around, clamped to any surface collision. Manipulate objects in local or world space. Use the new flythrough controls to get around easily. And did we mention the completely redesigned rotation tool?

3ds Max Importing

Drag and drop your .max files right into the Editor, including support for all skeletal based animation, multiple UVs, and vertex colors. Autodesk 3ds Max now joins the existing support for Maya, Blender, and all other 3D applications that integrate with the latest FBX plugin on the Windows platform.

Completely Customizable Editor

UnityGUI, Unity’s own GUI creation system, now powers the entire Editor and allows you to integrate your own unique level design tools, AI control tools, debugging tools, difficulty tuning tools, or anything else you need. Over 130 new API entry points enable you to create specialized, customized editor tools and build them into the existing Editor interface.

Tabbed Interface

We took cues from the best designed applications, and the rewritten editor has received dozens of improvements. The most visible change is the tabbed interface, where every part of the interface can be moved, undocked to a secondary monitor, and even stacked to achieve logical grouping.

Information at Your Fingertips

We’ve gone to great lengths to make sure that you always have the info you need, when you need it. Model files have previews right inside the inspector. Audio Clips show their waveform with click-to-play behaviour. Meshes show the detailed rendering stats – and that’s just scratching the surface.

Argiris Kirtzidi (one of the developers behind Managed OGRE) modified Moonlight to run inside the Ogre3D engine. You can render Moonlight applications or XAML files inside Ogre3D.

Some details in no particular order:

-Moonlight uses cairo for the graphics. I developed a new backend for cairo that fully utilizes the GPU (through Ogre’s RenderSystem) for rendering. This is completely independent from Moonbeam and can be used standalone.

-Moonlight’s core is a native C++ engine and is not dependent in Mono. It is flexible enough to be scripted by anything, javascript, managed code, native code, etc. I’ve got it working on both Mono and the .NET framework and I plan on embedding and trying out Lua for more lightweight stuff.

-If you opt for using managed code, it should be possible, in theory, to utilize the silverlight controls, develop a silverlight widget using visual studio and have it run through moonbeam with full debugging support.

-Getting it to work on Windows was no small task as the moonlight team is completely focused on linux, and there doesn’t seem to be much consideration about cross-platform-ness. I think this is reasonable, though, since moonlight is a young project and their specific goal is to implement silverlight for *nix systems. The downside is that it reduces its flexibility, e.g. in order to inject keyboard/mouse events I will have to create and pass to it GDK events or make heavy patches to it.
Hopefully, there will be more push in the future to get the *nix dependencies abstracted away from the core moonlight engine.

• The Moonlight Calculator Example.
• Miguel’s post about this
• Original post about the technique from the author