SuperBombDeath! – Learning Unity iPhone / iOS development pt.1

As a developer,  I have not played with Unity iOS since its first ever version, when development for iPhone and iPod touch was a more complex affair – more so on the Apple side than for Unity – I’ve returned to playing with Unity iOS and am blown away by how straightforward it is to get a game demo up and running.

So I came up with a simple concept I felt would work nicely on mobile – a typical bomb survival idea that I wanted to get made, and spent about 5 hours coming up with the first incarnation – see the video below.

I started out with the iOS standard assets – aka ‘Standard Assets Mobile’ that are provided by Unity Technologies. One of the example scenes offered is ‘Sidescroll Setup’ a simple dual screen pad system that uses the lower left of the screen (landscape) for movement, and lower right as a button for Jump. In order to test correctly, I downloaded the ‘Unity Remote (v3)’ app from the app store on my iPhone 4 and made sure to create a wireless network with my laptop for the app to connect to. This is how the Phone receives / controls Unity when testing. I then switched my build platform to iOS in the build settings, and set my game view to ‘iPhone 4G Wide’ as I would be working on a landscape designed game, rather than portrait.

From this standard asset scene, I duplicated the scene and began working. To create shooting I began by placing in a large box in the background, a simple cube primitive that I could cast a ray towards using simple touch commands to establish a Vector3 location that I could aim some kind of ‘gun’ transform at. Then using this location I utilised transform.LookAt to point an ‘arm’ – empty child object of my player character at it. Attached to that child object is another empty child object (gun) that I used to instantiate a bullet.

The script for this looks like this -

The only real difficulty I had here was making sure that I could receive multiple touches in order to shoot and move at the same time. This was accomplished by simply running a for loop for the amount of current touches every frame. Because this loop only runs when touches occur, hopefully it shouldn’t be too inefficient – but with a prototype like this, I won’t see true performance dips until I start making the game more complex and adding artwork and character / scenery / prop meshes.

After this was done I created a rigidbody bullet from a simple sphere primitive and attached a trail renderer for a bit of visual polish. Then I built a bomb prefab out of a capsule and cube, and created a script to spawn them randomly above the scene from 10 potential positions in an array. I then made collision detection scripts for the player to check for being hit by the bomb and for the bullet and bomb to test if they’re hitting each other, or any scenery, causing them to explode – ie, destroyed and replaced with a particle burst.

I then designed particles in photoshop and imported them, making two slight different particle systems and saving them as prefabs. I made sure to keep particle numbers low in order to maintain performance. I then designed sounds in the very awesome CFXR, a great little 8bit sound design app that you can download for free here or get the PC version SFXR here. It looks like this -

Once the sounds were in place – making sure to uncheck ’3D audio’ on import options, I set about designing textures for the GUI – a simple 1 texture overlay for the title and ‘jump’ and ‘move’ text made in Photoshop. On import I made sure to check GUI as the type, instead of texture in the import settings so that Unity compressed them properly. I had designed my textures at correct size and ratio, but then realised that Unity would not convert them to PVRTC format unless they were a power of 2. So I duplicated my photoshop file, and squashed the texture to the next appropriate power of 2 size – 512×512 for example, which allowed Unity to compress the texture properly and bring the size right down. Because I had made my GUI Texture with the original correct ratio file, I had a GUITexture set up with the correct pixel inset settings, and all I needed to do was swap the texture for my new 512 x 512 texture.

I knew from past experience that it is important to keep draw calls down by ensuring you have as few objects in a scene as possible. I wasn’t ready to implement any plugins like Sprite Manager, and I have a feeling that something GUI based is on its way from a future version of Unity so I stuck to just a single GUI Texture for now, testing on the device showed that this doesn’t really hinder performance as its only 1 call anyway, which is fine for my game.

After that I built a simple start and end screen, designing fullscreen GUI Textures in photoshop at 960 x 640 as I was targetting iPhone 4G. I then duplicated these when finished, scaling them to the nearest power of 2 and swapping out the texture on the GUI Texture component as described above. Finally I wrote a simple script that checked for touches to move from the start screen to the main game scene. I then wrote some simple health and score scripts to score when the bullet hits a bomb and to lose health when the player is hit by a bomb.

Finally I filled in the Player settings in Unity. I designed an icon at 114 x 114 in photoshop and applied it to the Player settings ‘Default Icon’. I also filled in the product name here and wrote in the name of my provisioning profile under ‘Other Settings > Bundle Identifier‘ – this bundle name com.someone.productname profile for apple development you download from the apple developer site and install on your machine.

Then it was just a case of going to File > Build and Run, which built my game into an xcode bundle inside a folder, and launched xcode to install it on my device (I’d done some work behind the scenes to register my phone to xcode dashboard, but it was fairly self explanatory from the steps on the apple developer portal). And that’s it – the first incarnation of SuperBombDeath was installed and playable, w00t!