This year, there are lots of little keynotes and much less big bang show business flash, at least so far. GDC is about content and developers, not entertaining bloggers. Making content king is a welcome trend, as is deprecating the flashing lights. The first panel SemiAccurate attended was entitled, “Guidelines for Building Cross-Platform Games”. It was moderated by Linda Tong of Tapjoy, and her questions were answered by Martin Chamrad (Craneballs Studio), Kyu Lee (Gamevil USA), Jamil Moledina (Funzio), Perry Tam (Storm8), and Mike DeLaet (Glu Mobile).
Rather than going over individual questions and answer, lets look at the broader themes, mainly because all of the people stressed how much things are changing fast. Details that are critical today may not be next week, but the overarching ideas tend to still matter quite a bit. The broadest theme plays a part here, basically that everything is evaluated on a case by case basis, and the best things available at the time of launch are usually used. This brings us to an obvious conclusion, we are still at a very early point in mobile game development, and there is no right answer to any one question.
To kick things off, the first question was on how cross platform games are started at a developer. Most panelists agreed that a specific platform was not targeted, the game features were fleshed out first along with play mechanics. One mentioned making a generic isometric RPG first, then implementing it on all targeted platforms after, and others had similar approaches. You design a game independently of the hardware and implementation.
Most don’t stray from known gameplay mechanics much, which explains the rather bland state of the industry more than I would like to imagine. Tools were similarly generic, Perl and C++ tended to come up a lot, as did OpenGL and OpenAL. HTML5 was somewhat downplayed, with one response saying it is still a case by case tool, and is used when it suits the game. This works out to be more casual games, but a lot of games use HTML5 even if they don’t call it out. Some may be totally hidden behind a proprietary wrapper for the store they come from, others not. Proprietary tools were pretty much sneered at, even if they came from a big vendor.
The first platform picked for development also tended to be decided on an individual project basis. Most companies try to do a simulataneous release on all platforms usually to save marketing and PR money. Since sales on one platform have been shown to influence the others, simultaneous releases tend to pay off in both savings and returns. The platforms eventually targeted for release tend to be based on sales, and that means Android and iOS, with Windows NextBigThingWePromiseThisTime being mentioned more as a possibility than something worth investing in now. Casual games are said to do marginally better on Android, iOS being more ‘hardcore’, something most think is the other way around.
Once a game is designed, it tends to be written first on one platform, and then ported to any other as the first is being finished. What is first, iOS or Android, is once again a case by case decision, and money can influence it to one degree or other. If someone will pay you to develop on their platform first, then take it and work from there.
Most companies were either talking about, or have already made the back ends for all platforms the same. For obvious reasons, one communications protocol, one set of servers, and one set of problems to debug are a huge benefit. Every panelist who commented all said that their back end tools were proprietary, with the caveat that they constantly look at 3rd party tools, but none use any at this point. All of the panelists said they did not share their back end tools with others, and don’t plan to either.
Shared back ends also bring up what is multi-platform? Does it mean the same game on the same on different OSes? By same, is it exactly the same, or familiar enough to be recognizable? Do you allow cross platform play, or exclude social groups of friends with different phones? Are graphics exactly the same, even if one platform is radically more capable than the other? “Do you risk lowest common denominator banality?” was the underlying question that no one touched. Most are talking about dropping support for older and less capable platforms to one degree or other, but that is a tangential issue.
When evaluating a new platform, money was the common theme, and that simply means installed base. Barriers to entry are in full force here, don’t have any illusions that they are not. Tools play the next most important role, with MS being singularly criticized for forcing C# use and not supporting OpenGL, meaning there is almost no chance of cross platform compatibility. Give the company’s success with Win7 on devices, you can see how they hope to leverage it into Win8 sales, but the devs don’t seem to be buying that particular line as dutifully as the mainstream press. One dev who is currently doing XBox and Windows games currently said that WARM ports are essentially a line by line port, meaning death for something without an installed base.
In the end, a new platform is chosen based on players. Will there be enough? Will they make us money? Will they play the type of game we are making? If not, the chances of a company bothering with your new OS are pretty slim. OK, lets just round it to none without a large financial incentive. Any guesses why Blackberry is not leaping back into the game?
Success on a game is measured in simple terms, did it make money? 10 billion downloads with huge financial losses are not something you want to repeat when you do a sequel. In fact, one company said that unless a game basically makes $2 million, it isn’t worth making a sequel to period. Other than net money, Lifetime Value (LTV), Average Revenue Per User(ARPU – ARPPU adds ‘paying’ to per user), and user engagement, multiplayer or single, all play a radically lower part in the metrics.
The biggest challenges seen by most are about what you would expect. Headaches caused by not planning ahead for cross-platform development, hardware limits on different platforms, and not anticipating hardware limits on older variants of a supported platform. The last challenge is not really a programming one, just social, and that is don’t piss off users. If you can figure out what things will annoy your buyers, don’t do them, things are very hard to fix once you have driven a customer away.
Then talk turned to what the panel thought were the key takeaway messages from their cross-platform work. The best piece of advice was to keep mobile habits in mind, basically to allow users to multitask and use phone features while the game is going if that is what the targeted users want to do. This was more for social type games, if you are playing a casual game, you probably also want to text friends you are playing with directly. A game taking over the UI will block this and force users to work around you. An in-game box that ties to your phone’s text system would help this out and help engage users.
Similarly, if you have a hardcore 3D game with critical timing sections, interrupting the user every 2 minutes to tell them Aunt Betty is texting to see if they are OK for the fifth time today is probably going to highly distract users. Blocking might be a good option here. If you recall, one of the things to plan in from the start was to not annoy your users, either directly or indirectly. UIs can help this out if done carefully, but those are hard to change on this scale once a game has been deployed.
Same for multiple resolutions, they can be dealt with if planned for, but many don’t. 3D games scale really well to different resolutions, but menus, text and bitmaps don’t. Most games use menus, so a flexible, floating, and scalable menu system can be a lifesaver.
If you do all of this well, then comes the slightly less glamorous work, localization, channels for distribution, and where to market it all. If you are careful and don’t do things without a reason, you can reap rewards. Localization to a market that has consistently shunned your type of game is money badly spent. Same with distribution channels that force things in front of the wrong type of player. Grandmothers probably won’t by many chainsaw-oriented 3D FPSs, nor will they buy things in languages they don’t speak. Anime fans just might find both to be attractive. The tried and true rules still holds, know your audience, don’t do anything without a reason, and never do anything that can’t pay for itself. It is ok to try things out, but know why you are trying it, and avoid 3-platform, 71-language simultaneous releases for a glorified test of a potential niche.
When it came to the crystal ball gazing on what the state of the world will look like a year out, the results were all over the map. Current Microsoft focused developers pointed out how huge WARM/Win8 would be, most others shrugged. Some said Apple would stay number one because of their quality focus, but most pointed to the sheer number of Android devices as holding the upper hand. It just goes to show that the more you know, the less you may actually see.
The last piece of advice worth passing on is that partners are a good thing. Since the panel was filled with some of the largest mobile game devs out there, they meant partners like carriers, OS vendors, and similar behemoths. Having Apple feature your app is worth its weight in gold, and the same holds true for a large phone company pushing your wares. What it takes to get there varies, but the results are usually pretty good.
In the end, there was a lot of common sense advice, don’t be foolish, and if you think you know better, still make sure. It doesn’t take a genius to see that most successful companies do just this, and many that had a single hit didn’t. Very few can sustain luck, even if most think they can. Users matter, follow their desires, wants, and dislikes, and it will pay off. This formula may not be the engine that new genres are born from, but it does mean you can keep the lights on and keep doing what you like. And you can do it on multiple platforms.S|A
Latest posts by Charlie Demerjian (see all)
- More on Intel’s 10nm process problems - Sep 17, 2018
- Intel puts out another 14nm 2020 server platform - Sep 11, 2018
- Why Can’t Intel Supply Enough 14nm Xeons? - Sep 10, 2018
- Intel can’t supply 14nm Xeons, HPE directly recommends AMD Epyc - Sep 7, 2018
- AMD reintroduces the Athlon name with two CPUs - Sep 6, 2018