Every software executive throughout the hallowed history of computing has had this brilliant thought: If my product is making $X on Platform A, let’s toss it on Platforms B, C, and D and make four times $X!
Freeing a Poor Guy Pinned Between Train and Platform
In fact, that’s one of the great things about software. The logic that allows interactive content to work well on one system can almost always be ported to a different system that has a similar processor, input device, and video screen.
Smart game executives know the nuances of going cross-platform. Audience demographic, expectations, context, and style of play can differ incredibly between the Xbox One, XBLA, Playstation Vita, Nintendo 3DS, Retail PC CDs, Steam, an iPad Air, and a cheap Android phone.
That said, when it comes to mobile, all modern tablets have basically the same form factor … and so do all smartphones. A game that performs well on the iTunes app store will almost always do well on Google Play, too. Yes, there’s Android vs. iOS nuance regarding marketing methods, tolerance for ads, in-app purchases vs. premium pricing, and leader board integrations. But those details aside, it’s safe to proclaim…
it’s a no-brainer that rolling out your game on all major mobile platforms will increase your audience size and revenue.
In fact, when a game has connectivity and is social, there are even more benefits to having it be cross-platform. It means that groups of friends can play the game together, no matter whether their platform of choice is Facebook, iOS, or Android.
To meet this clear need, there are dozens of amazing game frameworks available that not only make it easy to deal with complex sprite, audio, or physics issues — but also enable writing once and running anywhere. And many of them work!
It’s like magic. Push a button and the same game will scale itself and execute perfectly on Android, iOS, and sometimes even PCs and consoles.
But beware! I’ve seen the wrong choice of cross-platform frameworks delay or cripple otherwise great games and even, at times, decapitate entire companies.
That’s why when our agency sets out to work on a new game, the very first thing we discuss with a client is which technology to use.
Here are some criteria that aren’t often thought about until it’s too late:
- The demo that comes with the framework is sick! But how many hit games have actually shipped using this tech? Do you want to be the guinea pig?
- How much longer will it take to produce a first playable? Having the ability to “crank out” a game on Android and iOS is great — but what if it loses you valuable months of playtesting, live analytics, or community involvement of that first beta? Depending on your budget and timeline, the extra time spent building that perfect cross-platform baseline of code may delay your game beyond the breaking point.
That’s why we advise our clients to ship first on one lead platform, even for an eventual cross-platform game.
- How much distraction and overhead is there, overall, to support more than one platform? Every time the game is touched, it will involve incrementally more engineering, QA, server work, segmentation of analytics, and marketing focus. Can you afford that? Can you really?
- How adaptable is the framework to use for a team, not just an individual engineer. For example, Unity3D is a fantastic tool for 3D artists, level designers, system designers, and sound designers to jump in, touch the game directly, and immediately see results — if they already know Unity3D, that is. If not, it can add a whole lot of ramp-up time and dirty fingers stuck in the same rancid piece of pie. Also, Unity is a pain for multiple programmers since multiple engineers can’t easily work on the same scene at the same time, leading to tons of merge conflicts (a problem somewhat addressed in Unity V5).
- What is the actual time to build the game — both in an emulator as well as on real devices? A lot of game development involves making tweaks, actually playing the game, seeing how it feels, and tweaking some more until the fun is found or the animation looks just so. If a framework takes 20 minutes to do a build of a game onto a tester’s iPad, that’s hours and hours utterly wasted per week.
- How well can the game be debugged on a target device? Often the frameworks that make it the quickest to “throw a quick game together” make it difficult or even impossible to step through code, see the value of variables in real time, and essentially work through bugs in a modern and efficient way.
- What is the game’s binary size and loading time? Some of your framework’s awesome features mean a huge download that needs to chug and chug at startup.
For mobile games, quick load time is one of the most underrated keys to success.
- How well can 3rd party SDKs be integrated? These days, mobile games often live or die based on which ad, analytics, attribution, customer support, social, or other SDKs are rolled in. Some platforms have active communities/teams maintaining the most popular SDKs, but if you want a less-popular SDK you’re out of luck. Other platforms make it possible — but complex — to write a bridge to allow any native SDK to work. It’s important to know which are which and also acknowledge that SDK requirements often change as a company forms new marketing partnerships or discovers a useful new 3rd party tool.
- Related to the above, how easily can native libraries be accessed? Sometimes you have to get “close to the silicon” to fix a particularly bad bug or deal with a specific optimization, such as threading or memory. Some frameworks let you write your own native code or tap into existing libraries, others just give you a big black box and a blank stare.
- And finally, is it future-proof? What if the framework company goes under, lessens its current amazing level of support, or becomes greedy and pushes for royalties or onerous license fees. Someone who knows something about law should carefully read the terms for any software that will act as the basis of your business.
All that is why many of the top mobile games in the world (Candy Crush Saga, Words with Friends, Clash of Clans) opted to first create a native iOS version and then — sometimes years later — do a quality port via a dedicated Android team, once the initial game proved successful.
To help you make a more informed decision, we’ve put together a detailed matrix of popular mobile game frameworks and how they stand up to this sort of scrutiny.
Note: These frameworks are focused on 2D, mobile games. 3D frameworks such as UnReal Engine, CryEngine, or Vision Engine are not included.
We hope you find it helpful!
Effortlessly leaping from platform to platform can definitely feel magical… but don’t let the dazzle distract you from what really matters: Creating a mega-hit game — tough enough to do on even one platform.
Leave a Reply