We’ve been developing iOS applications with Unity since our first App Store release in 2009. Unity ships with an excellent development environment and provides a high quality pipeline into iOS application delivery.

As a product compiled with Mono, direct access to iOS APIs from Unity applications is restricted. In terms of gameplay and 3D performance this is of little consequence as runtime game logic and screen rendering is fully encapsulated in Unity, with API bindings provided for interactive features such as accelerometer data and touch detection. However, it’s our belief that user experience suffers when interfaces are built in Unity rather than with the UIKit framework and the iOS SDK. iOS has a rich heritage of interface conventions and behaviours, and it’s necessary to leverage these native features to produce the kind of sophisticated experience users expect from iOS apps.

Our preferred solution is to build our game interfaces in Xcode utilising native code. This allows us to play to the strengths of each platform – Unity provides the 3D engine, and the UIKit framework enables the seamless interactions and behaviours iPhone users are accustomed to.

Additionally, maintaining a game wrapper written in Objective-C gives us access to the full iOS SDK without being restricted to the native APIs that Unity has re-implemented. When multiple developers are working on a game, developers can contribute significant iOS features and compile the project regardless of whether they have access to or familiarity with the Unity development tool.

A native code bridge

For two-way communication between Objective-C and code running in Unity we make use of Unity’s plugin architecture to create a bridge between the execution environments.

Objective-C to Unity C#

We utilise UnitySendMessage to call methods in Unity from Objective-C. The Unity docs reveal that UnitySendMessage takes three parameters: the name of the target GameObject, the script method to call on that object and the message string to pass to the called method. These parameters must be sent as UTF-8 strings.

// call a method in Unity from Objective-C
// we are limited to sending UTF-8 strings to communicate with Unity
- (void) sendMessageToUnity:(const char *)methodName msg:(const char *)msg {

	// the main game object in Unity that holds the C# NativeInterface class
	const char *gameObj = "NativeInterfaceReceiver";
	UnitySendMessage (gameObj, methodName, msg);

}

Unity to Objective-C

We can expose C functions in Xcode, and then add the same method signature to Unity. This ensures that Unity is aware of the external methods it can call at runtime. The method below logs a message from Unity to the Xcode console.

extern "C" {

	// log a message from Unity to Xcode console
	void XcodeLog (const char *msg) {

		NSString *logMsg = [NSString stringWithFormat:@"FROM UNITY: %s", msg];
		NSLog (@"%@", logMsg);

	}

}

The work flow in action

NAVY SINK’EM is a multiplayer game that has UI and networking on the iOS side, talking to a Unity game environment. These environments have defined responsibilities corresponding to their unique strengths, and commands are fired between them to facilitate the execution of these responsibilities.

Layering UIKit and Unity

In the gameplay scenario pictured below, a UIView is layered over the Unity OpenGL view. When Unity detects that a ship has been touched, the camera centres the ship on the screen and a command is sent through the native interface to Objective-C. In response, UI elements detailing the ship’s status are prepared and the OS takes over touch detection. When a touch on the ship is detected a second time, this time courtesy of the ship’s coordinates mapped in the UIView screen space, iOS tells Unity to pause rendering and initiates drawing a shooting interface on the screen with Core Graphics.

We chose to draw the shooting interface (represented in this instance by the circular device overlaid on the ship) in a CGLayer with CGPath definitions based on the player’s touches. Drawing this in Unity would be visually less impressive, and would involve a greater code overhead as various effects (e.g. the ocean shader) would need to be independently toggled to free CPU cycles. Furthermore it’s our experience that Unity does not handle continuous touch detection particularly well, as Unity receives touch input asynchronously. This makes responding to multiple touches difficult. We greatly prefer the immediate event based touch input we receive from UIKit.

Once the player releases their shot, the OS sends a normalised vector representing the shot’s velocity and direction to Unity, which takes over calculating and rendering the shot’s trajectory. The results of the shot are shared with the OS.

Saving and recreating state

In any game of sufficient complexity, it’s necessary to save and recreate state across gameplay sessions. In an asynchronous multiplayer game like NAVY SINK’EM, players’ moves are shared over the air. A local copy of the game is updated as the player’s turn is taken, and synced with the server on completion. This reduces network traffic and allows players to take their turns in the absence of a network connection. When a player refreshes their games list, or in response to a remote push notification, the server pushes out updated games to the player’s app to replace the local copies.

iOS sends the current game state to Unity when a game is launched from the player’s list of active games. To comply with the restrictions on the native interface bridge, we serialise the relevant game data structures and pass the whole game through as a JSON string. In return, Unity sends JSON chunks back to iOS with the updated data as moves are made. In the case of NAVY SINK’EM, the OS piggybacks on the methods used to serialise the game object for sending it to the server.

iOS and Unity implement the game data packet independently of one another, according to the needs of each environment and the features of the respective languages.

Handling audio with Unity

Unity takes all the work out of handling audio. As the Unity environment is persistent throughout the life of the application, we can take advantage of this and route the entirety of the app’s audio playback through the bridge to Unity with a simple Objective-C one liner from anywhere in the app.

[[NativeInterface sharedInstance] sendMessageToUnity:"playSound" msg:"buttonSound"];

Performance gotchas

Rendering Unity’s OpenGL view in iOS is an expensive exercise. Native UI performance is highly degraded when used in conjunction with an active Unity scene. To alleviate this we pause Unity and avoid repainting the GL view when complex UI elements are placed on the screen.

// AppController.mm
- (void) Repaint {
	if (unityDisabled) {
		return;
	}
	//...
}

Unloading assets from the Unity scene may also prove helpful.

Our iOS/Unity game catalogue

We built the following games (yeah granted, CityGT is not a game as such!) using the techniques discussed in this article. Check them out from the App Store and leave a comment if you’ve got any questions, criticisms or wisdom to impart. We don’t hear a whole lot of buzz about Unity game development for iOS in Australia and we love to hear stories from fellow Unity developers.

The site relies heavily on JavaScript and CSS to create the parallax effect. I chose to use jQuery as the primary supportive JavaScript library as it provides many useful methods for traversing HTML documents and manipulating CSS properties. It also supports a wide range of browsers.

Parallax animation

When the site data has finished loading, the jQuery onReady handler kicks off an initialisation process which reconfigures the site layout, enables the parallax effects and starts the animation timer. The timer executes an update method thirty times a second, which reads the value of the offset variable and repositions all parallax elements appropriately.

Sections of content are contained in independent division elements. When the site is initialised, these containers are repositioned horizontally relative to a parent container div, and their left style values are modified by script depending on which section the user is currently focusing on. Structuring the content in this manner allows the site to maintain accessibility when a user’s browser lacks Javascript support.

Parallax effects on the background were achieved via the multiple background image support introduced in CSS3. The background is composed of five tiled layers containing transparent PNG images. At the back is the sky which is the only layer with a fixed position. Moving forward are the clouds, distant buildings, closer buildings and a layer of grass and trees right at the front. The front four layers are positioned multiplied by the offset with values 0.125, 0.25, 0.50 and 0.55 respectively. The values are low, as the background should move slower than the foreground. In an early development version of the site, the clouds were constantly moving, but this frequent update greatly affected performance of the site.

In the foreground is a div which sits in front of the content. This foreground div contains a tiled image of some small hills and is positioned at twice the value of the offset. It also acts as positioning guide for some additional elements, such as the skater, plane and hot air balloon which are generated by jQuery and absolutely positioned within the container. The skater is the only element which is repositioned within this container, so it appears to be anchored in a fixed position on screen. This element features frame-by-frame animation, an effect achieved by offsetting the position of a sprite sheet that is used as the background image in the div.

Diving in to HTML5 audio

The main content and the Sea of Support are contained in two independent sibling divisions which are children of the body element. When you toggle between sections, both elements have their height values adjusted at the same rate. One element will open and the other will close, depending on which way you’re going, and this creates the effect of moving up to the surface or down below the ocean. The surface scene also has its top margin decreased (into negative values), so it appears fixed to the bottom of its container.

When the Sea of Support is initialised, a list of comments is retrieved from another server via a PHP API. A bubble element is created for each comment. The bubbles are positioned independently inside a container div. Where possible, the positioning is applied via the CSS transform property. This will enable hardware acceleration, where available. The scene runs reasonably consistently with a frame rate of 30 frames a second, up to about 60 bubbles. Any more than that and performance starts to suffer.

When you roll over a bubble, a details div is displayed and its contents are updated with information about the bubble. Some of the bubbles contain an audio excerpt which is played via jPlayer, a jQuery audio plugin. jPlayer attempts to play the audio via the HTML5 audio element. If the browser doesn’t support HTML5, it will pass the audio file to a Flash component. However, if the user doesn’t have Flash, they will be linked to the audio file directly. In this instance it is acceptable to use Flash as a fallback as the plugin is still able to deliver the requested content through alternate methods.

It hasn’t proved as difficult as I expected to create immersive interactive websites without Flash. Especially with so many solid Javascript libraries about. For this site, the main issues that arose were related to performance and cross-browser compatibility. Debugging in older versions of Internet Explorer is especially challenging.

Check out My Great Big Adventure and let me know what you think!

Inspired by the original Flash version of the game, Millipede developed the game for iOS, incorporating a host of the device specific features along the way.

As a player your task is to pilot a paper plane through an obstacle course of gorgeous paper scenery, attempting to cover the farthest distance. Power boosts and invincibility lighting strikes can be collected and used at your discretion to aid you in your flight.

The Builder App directory can be browsed in full, or manually searched with the aid of intelligent suggestions. Tradesman or suppliers can be added to favourites for fast access to their details. The Builder App really takes the pain out of finding a tradesman and obtaining quotes.

Download the app for free from here.

If you’re a tradesman or supplier and want to be included in The Builder App database and be found by all the website and app users, sign up here.

Millipede were introduced to the lovely Builder App team by the fine crew at Red Crayon. The Builder App were in need of some urgent help to bring their current release ‘up to speed’ with the applications of today. Enlisting the help of Inspire9 to look after the existing RubyOnRails backend overhaul, and Red Crayon managing creative direction, Millipede completely redeveloped the application’s information architecture and user experience, bringing it from the edge of dysfunctional (and hideous), to a cleanly designed and beautifully executed system.

Yellovator is the result of a collaboration between Yellow Pages®, Clemenger Proximity Melbourne and Millipede. And we are thrilled with said result. A sincere congratulations to all involved. It was an amazing effort.

What is Yellovator? Get on with it you say?

Yellovator is a game that can be played via rich media banners, on incredible outdoor metrolites, or at yellovator.com.

So what?

Well, it utilises the Flinders Ninjas Engine, enabling users to use their smartphone as the game controller! Help Smasher Dan send phones with helpful Yellow Pages® searches to the folks in the street below.

Here’s the buzz from Smasher Dan himself on the launch party held in Hosier Lane, Melbourne.

Also, while you’re knocking about town, keep an eye out for our Yellovator game locations around Melbourne at Southern Cross Station, Flinders St Station (Yarra River side) and South Yarra Station. If you happen to be up in Sydney soon, you can play the game at our Martin Place or Alfred St, Circular Quay locations!