Now that we are well into the age of mobile and businesses, marketers and content creators are more often than not putting mobile first, one of the biggest dilemmas is how best to deploy branded content to make it accessible to mobile devices. This is especially true of branded games.
The two main choices for branded mobile games boil down to either using HTML5 or making it downloadable and installable as a standalone application via mobile app stores. Each have a great number of pros and cons and it’s important to be aware of the implications of choosing one over the other, when planning a new branded game.
I’m going to break down the main considerations and the advantages and disadvantages that go along with them.
HTML5 has a whole raft of technical shortcomings, when compared to apps, some specific to mobile devices, some not.
Ultimately most of the problems come down to the fact that HTML5 is browser dependent (i.e. the web browser is responsible for interpreting the code into what you see and hear on screen) and the fact you’re creating one version of you branded game to (hopefully) work everywhere.
It is getting better, but each browser has it’s own interpretation of the HTML5 standard and some browsers even ignore the standards entirely and do their own thing. This can lead to different behaviour in different browsers and browser specific bugs and issues. It also means that an update to a specific web browser could actually have an adverse effect, or even break your game in future, without you doing anything.
Using an experienced HTML5 game developer will go some way to mitigating the risk of everything going pear shaped in future, but there are no guarantees. So you need to be aware, there’s a chance you may need modifications in future, should this happen.
Although most mobile devices and tablets currently in use support the HTML5 features needed to run most mobile web games, there are still some device specific issues that may or may not be important to you. Some notable examples are:
Sound on iOS devices can’t start until after the first touch event
In practice, this means that your game will start silent on iPhones and iPads, with no background music or sound effects playing until the first time the user touches the screen (usually clicking a “play game” button on the main menu screen).
Running in true full screen mode is problematic
Between browser address bars and phone status bars you’re usually going to lose at least a small portion of the screen, unlike with an app, where it’s easy to take advantage of the full screen area. This can be especially problematic on small smartphone screens.
There is a “dead area” at the top and bottom of the screen
It’s not advisable to put any interactive elements in these areas. Touching here can cause browser navigation and address bars to reappear over content on some mobile devices. This is most problematic on iOS devices and further reduces the actual usable screen area, although a good experienced designer can usually work around this.
It’s web based
This means to play, you need a live internet connection (unlike an app, where once it’s installed you can usually play without access to the internet). In practice, this means that players on devices such as tablets, that are Wi-Fi only, or even players who’ve gone over their mobile data limits will lose access on the go.
Quality of the End Product/User Experience
This is where apps really do shine over HTML5 for branded mobile games.
Because apps are effectively a stand-alone software product and don’t exist within the confines of a web browser, they get around many of the technical limitations of web based games.
You get an end product that’s more akin to a “real” computer game, rather than just a piece of web based content. Better multimedia and sound support allow for a slicker experience. Plus, being able to go truly full screen (especially on smartphones) and being able to position interactive elements over the full area of the screen is hugely beneficial.
I should add, this doesn’t mean it’s not possible to create great branded mobile games with HTML5, on the contrary. But the fact is HTML5 imposes more restrictions on the design process and will almost always lead to a technically inferior end product to the app equivalent.
This is a big one and the number one reason to choose HTML5 over an app.
More often than not, when a client comes to us with a branded mobile game project, the timescale is measured in weeks, not months. Until more businesses start planning much further ahead, the number of projects where time allows a mobile app to be a viable option are few and far between.
As long as a cross platform solution such as Adobe AIR is used, actual production time for an app shouldn’t be significantly greater than a web based game. However, the problem comes with actual deployment. For small scale projects, the necessary submission/review process to get published on app stores might add as much time to the project as was spent on production.
Which leads us nicely into…
Ease of Deployment
HTML5 makes it incredibly easy to actually publish your branded game and make it available via your website. It’s simply a case of uploading the files to your server (or adding a bit of embed code, if it’s hosted elsewhere). So, once production is finished you’re usually looking at hours or days, not weeks or months to go live on your website.
Not so with apps. If you want to publish your branded mobile game in your business name, first of all you’ll need to sign up with the appropriate app stores. This can take some time and should be done well in advance of project completion. Then there’s the app store submission and review process, which each mobile app needs to go through before being able to go live on the appropriate app store. We usually recommend allowing an additional month to any branded app game project timeframe. This allows plenty of time to get through the review process and make any changes, should issues arise.
Which us brings us to…
Control of the Content
Ultimately, one of the big trade-offs with branded mobile app games is the fact that you’re relinquishing a degree of control over what the finished product is allowed to be and the speed at which you can make the content available and potentially update it afterwards.
The app stores and their review processes put up a barrier between you and your audience. Although app store guidelines rarely limit what your content can be, there is always the possibility of having to make modifications to fit within these guidelines to get your branded app game approved. You also lose control of timings to a degree, with often lengthy review procedures being a requirement in order to make your game available for download. Should updates be required in future, the review process needs to be repeated each and every time.
This is the exact opposite of HTML5, where you retain full control of your content. The choices about what it will be, where and when it’s made available are completely yours. As well as being quick to upload and make your branded mobile game live, it’s also just as quick and easy to push out updates in future, should they be required.
Ease of Access
When it comes to actually being able to almost immediately get access and play your branded game, HTML5 is the clear winner. Simply enter the web address into the browser, or click a link and you’re ready to play. This immediacy makes it easier to try your game, so is a big bonus when it comes to branded games.
With apps there is an extra degree of persuasion to get people to go to the app store, download and install a mobile game in the first place. Plus, requiring that they download and install on their device may dissuade some people.
However, you could argue that the install process with an app game brings it’s own benefits in terms of player retention. Once completed you have a nice clickable icon on their home screen, reminding them to go back and play again.
HTML5 is the clear winner here. The fact that it’s possible to deploy one version of a branded game that’s not only available on most modern mobile devices, but also on desktop computers with a modern browser installed, means you can maximise your potential reach.
A mobile app game usually limits you to not only just mobile devices, but the specific types of devices that correspond with the app stores you’ve submitted to. Obviously the iOS and Google Play app stores will cover a big majority of mobile devices, but unless you target the minority app stores (Amazon Kindle, Windows Phone, etc.), then those devices will be off limits.
Because apps are generally downloaded from appropriate app stores and use third party services for additional features like scoreboards, there isn’t usually a significant hosting requirement.
Web based branded games however need to be delivered by a web server (usually via your own website). So if you’re planning to go down the HTML5 route, it’s necessary to consider the web hosting requirement in relation to the expected traffic. For instance:
A simple branded HTML5 game might be 2-3MB in size. If you think you can realistically expect to drive 500 players per day, that’s roughly 15,000 plays per month. So the traffic volume attached to that would be around 45GB per month.
Obviously, the more complex the game and the more players you get, the more traffic volume generated (that needs to be accounted for on the hosting side of things). Although not a huge issue for most businesses with a dedicated server, it’s definitely worth being aware of the bandwidth implications for delivery to large numbers of players.
So Which is Best?
There is no right or wrong answer to this and it totally depends on the specifics of the project. But generally, if you need a fast turnaround and you can live with the technical limitations of the platform, HTML5 is usually the way to go. If having the best quality end product is a priority, you’re planning your project well ahead of time and playing on desktop computers is less of a concern, then apps are usually the best choice for a branded mobile game.