A technical guide to cross-platform development

What must developers be mindful of when planning to develop a cross-platform game? What do they need to consider about each platform they target?

A few years ago, cross-platform used to mean targeting PCs, consoles and maybe Mac with distribution via CD or download. Today cross-platform almost always includes mobile: particularly iOS and/or Android. For more traditional titles, this means adding mobile to an existing PC and console target set. For casual, or perhaps better titled ‘mass-market, games the cross-platform targets now tend to be mobile and web – both the open web and Facebook – with distribution through app stores and browsers.

Also with a traditional pay-first game, the time it takes to install the game is largely irrelevant, since your customers have already paid and will take whatever time is required to get the game installed and running. With the shift to free-to-play games, install time and any other hurdles that impact a player’s ability to quickly start playing the game – permission dialogs, downloading browser plugins, and so on – will likely have a huge impact on future sales. So this needs to factor into the consideration of any cross-platform tools used.

What do they need to consider about the audience of each platform?

Probably the main audience consideration is customer acquisition costs which vary widely by platform.

Some game studios target only mobile and some even just one platform within mobile – typically iOS. This strikes us as a very risky strategy as customer acquisition costs are typically much higher – perhaps five times higher, on mobile compared to other channels – so a game must earn five times as much money per installation on mobile for a pure mobile strategy to be successful.

Other platforms, notably Facebook, will provide an easier path for viral acquisition of customers, although this requires work for any viral strategy to be successful. It’s important to ask why should a player actually want to bring their friends into your game. Will it make it more fun for them in some way?

What do they need to consider about input?

Clearly with the rise of mobile devices, touch input is now a must-have for most games. That impacts design by requiring a move away from using mouse-overs for important functionality. It also means designing larger button and control sizes, so that our relatively fat fingers can easily direct the interface.

Targeting iOS only is a very risky strategy as customer acquisition costs are five times higher so a game must earn five times as much money per installation on mobile to be successful.

For tablets in particular, it’s also important to consider where a player’s hands will be placed on the device and making sure that controls are in easily reached parts of the screen. It’s likely poor design if your interface requires a player to point with index fingers from both hands in order to play your game – that’s hard to do while holding a tablet.

Either one hand should be sufficient to play or the design can assume thumbs will be used to manage the controls – although in that case it’s important to recognise that thumbs have a much shorter range than a finger. Basically, there’s no substitute for putting the design onto a tablet early and experiencing it there.

What tools, middleware and skills are required when tackling cross-platform development?

The biggest decision points in choosing a toolset is probably whether the web is included in the platform set. If you are not aiming for the web, then you can potentially focus on just C++ as your development language and target PC downloads, consoles and native mobile. Android is a little awkward as it’s a Java-based platform, but you can still make C++ work by using JNI (Java Native) to load up the entire game as a native extension and running it that way.

Another reasonable choice if you’re not targeting the web is to use Unity. This allows you to develop in C# and still target PC downloads, consoles and mobile. Unity does list the web as a target platform, but it’s a very weak option there. Today it requires the user to obtain the Unity plug-in, which has a pretty low penetration, and that is in the process of being deprecated in favor of an OpenGL and JavaScript-based solution. However, even that approach is weak as it requires around a 10MB download prior to the game starting, causing a very slow initial experience and the likely loss of a lot of players.

If you are targeting the web, then the choice generally comes down to either HTML5 or Flash. Both can be workable options, although HTML5 seems to be on an increasingly difficult path. The approach for HTML5 is usually to deliver to PC and Mac in the browser and then wrap the HTML5 content into an app using a toolkit like PhoneGap, so you get presence and discoverability in the app stores. The problem for a game is that performance of a wrapped HTML5 game on a mobile device is generally going to be significantly worse in terms of frame rate and responsiveness than any of the competing technologies. So while it’s a fine choice for less graphical intense applications, for games it’s a challenge.

The other option if you’re including the web in your target platforms is Flash, which remains surprisingly viable. Many developers mistakenly believe that Flash is not an option as it fails to run on iOS. However, the restriction is that Flash content fails to run inside a browser on iOS – it runs just fine as an Air application on iOS devices. So Flash and Air together provides a solid platform for cross platform development, reaching PCs and Macs through the browser and mobile devices as Air applications.

For those who don’t like Flash’s performance on the web, another option is to use the programming language Haxe combined with the OpenFL toolkit. This allows for cross-compilation from Haxe code to HTML5 and also from Haxe to native mobile apps for Android and iOS. It gives the benefits of HTML5 on the web, without limiting you to HTML5 on mobile devices, which doesn’t perform so well.

What languages are best suited to coding cross-platform development?

If money is no object, then C++ remains the gold standard. You get native performance on all platforms including mobile. However, the cost will likely be the highest of all choices because, as we know, C++ is a more difficult language to work with than the more modern languages that handle memory management.

Also if you are building native solutions on each platform, you will need most custom code for each of those platforms – compared to solutions where somebody else is working fulltime on the porting or cross-compilation problem for you.

C++ remains the gold standard: you get native performance on all platforms including mobile. However, the cost will likely be the highest of all choices.

Assuming budget is a concern, then C# (through Unity) or ActionScript (through Flash/Air) are both excellent choices: they’re first class languages with strong typing and full feature sets and backed by strong companies. The built-in memory management makes development easier, but care with memory is still required, especially on mobile platforms.

Which ones should be avoided?

HTML5 brings you into JavaScript, which is a more challenging language. It’s certainly possible to write very clean solutions using JavaScript, but it’s also very easy to write very poor JavaScript code (see Crockford’s book JavaScript: The Good Parts), which places a premium on processes like code reviews and unit testing if that’s the language of choice.

What are the biggest advantages of creating cross-platform games?

If you choose a good cross-platform development solution, then cross-platform gives you access to a much wider potential audience for close to the same development cost as a single platform solution. Also if I tell my friends, "hey there’s this great new game I just tried" and they say "great, can I play it on my device?", whether it’s PC, Mac, iOS tablet or Android phone, you want the answer to be "yes". This way, the game can pick up a viral audience more easily. Also a cross-platform title allows players from a given community (such as a group of friends) to all play the same game together. Forcing them to all be on the same platform is a huge loss for any sort of social gaming title, which is the area we focus on.

What are the biggest challenges, and how can these be overcome?

There’s always the risk of developing for the lowest common denominator and reducing the quality of the experience as a result. But that can be addressed by making the content scale in quality and features with the platform. In our case we felt that handsets in particular wouldn’t support a rich virtual world like a fully social casino, so we have handled handset development as a separate product from all other versions of our games.

If someone tells their friends about your great new game and they say ‘great, can I play it on my device?’, whether it’s PC, Mac, iOS tablet or Android phone, you want the answer to be ‘yes’.

Another major challenge is the need to submit apps to Apple’s review process. This is chronically slow – averaging about a week from submission to review – which is a major challenge if you are pushing out major updates every two weeks, as we do, and if players on different platforms can play together. The iOS players are always living somewhat in the past and that needs to be carefully planned for in the design and implementation. In our case, it means that the server side components must always be backwards compatible with the previous game client, so that iOS users are not left high and dry for a week after we update.

Anything else you’d like to add about the challenges of cross-platform development?

While developing for multiple platforms is a challenge, it’s also generally the norm in our business so I think it’s important to embrace the challenge rather than fight against it.

Choosing to avoid cross-platform development and focus on a single platform seems like a much bigger challenge to us. Certainly the technical challenge will be easier, but the business challenge of ultimately making your game a success gets vastly more difficult if you limit yourself to just one channel.

If that channel turns out to not work as you had hoped, it’s good to be able to switch the focus to a different platform. In our experience most successful development requires listening to and finding where your audience really is within the gaming universe – rather than imposing your own opinion ahead of time of where that audience lies and exactly what game they are looking to play. So cross-platform flexibility is a huge advantage in ultimately making a successful game.

Douglas Pearson is CTO of FlowPlay, creators of ourWord and Vegas World. He has more than 20 years experience as a professional software developer leading dozens of projects for organizations like Real Networks and the Department of Defense. Today he is responsible for all technical aspects of FlowPlay’s virtual game worlds with a particular focus on the challenges of delivering high performance, massively multi-threaded software targeting a wide range of platforms.