#cross-platform development

Is Cross-Platform Development the Future of Mobile Apps

It can certainly be worthwhile releasing games on new platforms. The biggest benefit to going to a new platform is that there are many players who engage with those platforms and have not played your game yet. Releasing on a new platform grants your game exposure to a large number of potential new players and sales. However, the cost of releasing a game on additional platforms is not trivial. This is where the business side comes in - is it worth spending all of that money to bring the game to the new platform?

We'll put aside the choice of cross-platform development at the start for today and consider only the paradigm of making the decision to bring a (mostly) complete game to a new platform after launch. This is often the only choice for smaller developers who are budget-constrained - they often don't have the money to buy dev kits and pay for cross-platform development until their game is actually released and earns some money back. In this situation, you've got two major sources of costs - direct costs from platform itself and indirect costs to cover all of the bug fixing, optimization, and additional work needed to pass cert.

Direct costs in this case would be the costs to establish a working relationship with the platform and the ensuing costs for hardware and certification. Sony, Microsoft, and Nintendo all require some kind of business relationship with their licensees. They won't let just anybody make a game for their consoles - you actually have to pitch your game to them and get their approval before they will let you buy dev kits and create developer accounts. Once you set the relationship up, you must buy [dev and test kits] from them (often several thousand dollars each) in order to connect your workstations to the consoles and you will need to pay for [certification] (also often several thousand dollars) before you will be allowed to launch on that platform. Some platforms like GOG, iOS, Google Play, etc. don't require these fees, but some will still require specific hardware (e.g. Android devices, Apple devices, Mac computers for developing iOS games, etc.).

There are also indirect costs of moving to a new platform - most games that work absolutely fine on PC will have bugs and problems when brought to a new platform. Things like UI and control schemes will need to be redesigned and rebuilt even if the old game already supported controllers - certification will require very specific button icons, images, and text in the UI. The game or the assets will also likely require optimization and bug fixing because of differences in the hardware or performance issues. If your game has an online component or DLC, it will also likely require some fairly extensive work to make sure all of the old online stuff works with the platform’s online network (e.g. PSN, XBL). Many of these platforms also require additional platform-specific content such as achievements. These changes will require a non-trivial amount of development time, including time spent learning the ins and outs of the new platform itself. This additional development time must be paid for.

As you can see, there’s a lot more to bringing an existing game to the Switch (or any other given platform) than just paying some fees and getting the thumbs up. The cost can be so significant that there are several third party game studios whose entire business model is being hired guns for platform port jobs like this. The cost of bringing an existing game to a new platform is not trivial and should be carefully considered. The decision must be made based on whether you think there will be enough customers on the new platform to justify the costs of porting the game.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

We usually get a heads-up from the platform if/when they decide to pull the plug on their platform. If a game is still in development at that time, the publisher usually has to make a decision - release the game for a now-unsupported platform, spend the additional time and money to bring the game to a new platform, or (worst case scenario) cancel the game altogether. There are cases to be made for each of these scenarios. 

Releasing on a platform that’s no longer supported isn’t necessarily a terrible idea. The most common example of this is probably releasing PC games that run on Windows XP, which Microsoft officially stopped supporting in 2014. However, there are millions of old Windows XP PCs all across Asia and Eastern Europe that are still in regular use, which means new games that run on the old 32 bit operating system can still make a good amount of money in those regions for the effort required to get the game running on those minspec machines. If the cost to hit those platforms isn’t too high, it is often worthwhile to do so.

Sometimes the publisher decides to take the project to the new platform in addition to the old. This can happen independently of launching on the old platform as well - both Persona 5 and Legend of Zelda: Twilight Princess were basically built on and for the earlier platform (PS3 and Gamecube, respectively), but were brought over to the newer platform for various reasons (and still released on old platforms as well). If the old platforms are still in use (Sony didn’t drop full support for the PS2 until 2018), it isn’t unreasonable to release a game for it if the costs line up and they think they can sell enough units on that platform.

Of course, if the publisher cannot secure the resources or contractual approval to change development to the new platform and the old platform is no longer viable, the publisher may have to cancel the project and call it a loss. Licensed games may have this issue if the licensor is particularly picky, but financially vulnerable publishers or studios may have similar problems.

Overall, it’s just a question of the publisher making what they think is the best choice for the cost involved. If the cost-benefit prediction is favorable enough, they’ll usually go for it. If it isn’t, they’ll cancel it. It’s just another of the myriad of factors to consider in the business of video games.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

We on the development side usually get our information from our publishers. They usually have fairly accurate business information because it is primarily the publisher’s responsibility to determine when and where to publish games. That kind of information is much more useful to a publisher since developers typically work on one or two games at a time at most, but publishers are generally looking to release multiple games regularly every year. The publishers themselves spend money on market research for this reason - accurate market information is valuable for the decision-making process, after all. So... the information is (kind of) public but it’s generally compiled and analyzed by experts who are paid for their expertise so it is usually much more precise than just reading press reports. On the development side, we get the information we need to know (e.g. these release windows, these platforms, these localization regions, etc.), while other information that’s less relevant is only shared if we ask for it (e.g. other platforms we’re not releasing on, other regions, etc.).

For your second question, yes - attach rate is absolutely a concern in addition to overall install base. The main goal of compiling these kind of data is to figure out how many units we think we can sell or how many players we think we can reach. The rate at which the players buy games is an absolutely useful metric. The best example for this was the Nintendo Wii. The Wii sold an enormous numbers of consoles but the attach rate for third-party games was abysmal. When combined with the higher relative cross-platform development cost (making PS3/X360 games fit within Wii hardware specs and adding motion controls), major third-party publishers made the decision to drop support for the platform for their flagship titles. It isn’t the only factor, but it is one of several factors that are used to make business decisions.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Honestly, it’s usually because we’re busy trying to make the game work on all of the platforms we’re shipping on. The main thought is this - we have a limited amount of development time and resources (i.e. “zots”) we can spend to build the game. If we have 100 zots to spend, do we want to spend them developing a feature that is only supported by one platform or all four platforms? This restriction applies to anything that’s platform-specific, like a touchpad, motion or gyroscopic controls, those weird SPUs on the PS3, and so on. 

This is why platform exclusives tend to take more advantage of the unique elements of the platform. We know that the return on our zot investment will be good - everybody who plays the game will be on the same platform, so we can invest more zots into the stuff unique to the platform. We aren’t spending our 100 zots on a feature that will only be used by 25% of the audience, we’re spending them on a platform-exclusive game it will be used by 100% of the audience.

That said, some platforms will include “exclusive content” in their certification requirements, often to make it a selling point to customers. This means we on the dev side must include something that is unique to the platform if we want to release on that platform. Unfortunately, this generally means we spend as few zots on the exclusive content as possible for the mentioned efficiency reasons - we want to get the biggest bang out of our zots that we can. For a cross-platform game, that means to spend our zots on things usable across as many different platforms as we can so the features/content we create with those zots can reach the maximum numbers of players.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

The main reason it is “only” a mobile game is this - Mobile devices have inherent design constraints that are very different from PCs, which (likewise) have very different constraints from consoles. When you design for the phone, you need to consider a lot of technical constraints like different operating systems, battery life, vastly different hardware profiles, display aspect ratios, disk space needed, etc. We need to answer questions like How long should a session last? What kind of rendering tricks can we use with the hardware we have? How much memory do we have to work with? Can we run at 60 fps? These sorts of constraints absolutely must be taken into account when designing the game and are very different depending on the device the game is built for.

One huge consideration is the game’s control scheme. The style of controls have long decided what kind of games are possible on the platform. For example, it took nearly a decade to bring the FPS genre from PC to console - not because the consoles weren’t powerful enough, but because nobody could figure out a workable control scheme. We still have yet to bring RTS as a genre to consoles. PC games don’t have to worry about anything blocking the view from the monitor, but using your hand as a pointer device can occlude screen space. Your PC is typically stationary on a desk when you play games on it, but you’re often holding your phone or tablet in one hand while navigating with the other. These are all major design considerations that must be taken into account.

I’m not saying that there’s no room for a PC Diablo game. Far from it - I’m as certain as I can be that there’s a team at Blizzard working on a new mainline Diablo title as we speak. What I am saying is that Diablo Immortal, given all of its design constraints for its target platform, would not be a quality PC title if they did cross platform development. There are just too many differences that would have harmed the final product. It’s the same reason why so many Wii ports were lackluster compared to their mainline versions - the games weren’t built with the Wii’s strengths in mind. A good game takes advantage of the strengths of the platform and avoids its weaknesses. This is why games developed specifically for the PC tend to play fundamentally differently from console ports, and vice versa. You can usually feel it in the control scheme - some games just feel more natural on a keyboard/mouse or on a controller. For a game like Diablo Immortal, there’s just not enough crossover in the design constraints to make cross-platform development worth pursuing at the level of quality Blizzard requires.

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter