iPhone, Mac, Android: Designing for Multiple Platforms

platforms_header

iPhone, iPad, iPod, Android, Mac, Web, PS3, Xbox – with more and more platforms and markets emerging in both the mobile and desktop arenas small developers (like us) need to plan and work efficiently to maximize return. Going forward every game we create we plan to release multiple versions on multiple platforms:

  • iPhone Paid (with IAP)
  • iPhone Free/Lite (with ads)
  • iPad (or HD) Paid (with IAP)
  • iPad (or HD) Free/Lite (with ads)
  • Android Freeย (with ads)
  • Mac Paid

Here are a few tips that should make porting your games to different platforms easier:

  1. Use a development tool that supports multiple platforms
  2. Maintain a single code base
  3. Code for elastic screen sizes and aspect ratios

Use a development tool that supports multiple platforms

We’ve been using Unity since before the iPhone App Store opened in July 2008. Initially we were using it to make 3D web games, but the Unity devs were very quick off the mark to make it compatible with the iOS platform. If you haven’t come across Unity then I highly recommend that you download a free copy and try it out.

Apart from being a great 3D and 2D rapid development tool it also supports multiple platforms, so if you design with that in mind from the beginning you can target iOS, Android, Mac, PC, Web and also consoles including Wii, Xbox360 and PS3 (we don’t have any experience with the console side of things, as we haven’t taken the time to jump through all the console company requirement hoops and extra licensing fees).

The base version of Unity is free and gives you an unlimited license to publish Mac, PC and Web versions of your game. The basic iPhone publishing license is a one-off fee (currently US$400) that allows you to publish as many iOS titles as you like.

Screen1

To give you an idea of how versatile Unity is we were able to take our existing Unity iOS game “Galactic Gunner” and convert it to a Mac App Store game in less than a day.

Another multi-platform authoring tool that I’m aware of is Cocos2d, which can create native iOS and Mac apps. Because I am so happy with Unity I haven’t really researched Cocos2d but there have been a lot of great games made with it.

Maintain a single code base

In the early days we made the mistake of having multiple projects for the Full and Lite versions of Crazy Snowboard. We launched the full game in October 2008 (actually it was the first Unity iOS game published in the App Store), and didn’t release the lite version until much later down the track. When we did release the Lite version we thought it would just be a quick one-off promotional vehicle to drive sales of the full version, so we just took the existing full version code and pulled out any unnecessary assets and code. The problem was we also added a few new features.ย This soon became a nightmare as any updated code in one version had to be transcribed to the other.

After a couple of painful updates we decided to go back in and consolidate the code into one project. We added a variable to identify which version was being built and use that to determine which features (e.g. levels, iAds, IAP, etc) are included in which version.

We also went on to create a ‘Pro‘ version of Crazy Snowboard, which again uses the same code and a different variable to define the target. The one thing you need to watch is to make sure you update the product names, version numbers and provisioning profiles.

cs_android

The same Crazy Snowboard master project file is also used for the Android version (read more about our Android experience here: Adventures in Android-Land). ย Again we just update the platform variable to define which platform we are building for. Unity also has a neat feature where you can change the platform target in the editor to switch between and test your build on different platforms.

platforms_build_targets

Using the same code base for multiple platforms means that you need to plan a bit more carefully, and make sure you don’t introduce a bug in one platform when adding features to another.

Code for elastic screen sizes and aspect ratios

More platforms means more screen sizes. Gone are the days of a single 480×320 iPhone/iPod screen – we now have a huge range of sizes and aspects to support:

  • iPhone/iPod: 480×320
  • iPhone4/iPod4 Retina Display: 960×640
  • iPad: 1024×768
  • Android: 320×480, 800×480, 854×480 (and more!)
  • Mac: 1024×640 (and more!)

When coding your UI make sure to determine the screen width and height and use these values to scale your buttons and other elements. For example, rather than hard coding a button location like this:

GUI.Button(Rect(400,280,100,30), “Play”);

Use something like this:

GUI.Button( Rect(Screen.width-80, Screen.height-40, 100, 30), “Play”);

You can also add a scale factor in there to resize the elements.

Hopefully by using these methods you will be able to easily port your games to other existing platforms, and also have the flexibility to sell them through future platforms and app stores that are bound to crop up.

Ezone

Ezone.com is the home of Indie game making brothers Jamie and Simon Edis. Weโ€™ve been making games since 1994.