HTML5 vs Apps for Branded Mobile Games

Filed under: Branded Games — Simon Walklate

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.

Technical Considerations

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.

Timescale

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.

Potential Exposure

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.

Hosting

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.

Never Use Online Game Scores to Award Competition Prizes

Filed under: Branded Games — Simon Walklate

We get asked a lot by clients if we can incorporate a competition into a branded online game. This isn’t a problem in itself and obviously many clients want to use a competition as a way of increasing interest. What is a problem however is running competitions where prizes are given based on the highest scores (or other game outcomes) and this is usually what they want to do. It doesn’t help that clearly inexperienced developers are doing just that for their clients, so other people assume it’s ok.

Only yesterday I discovered another Facebook game that included a competition based on players’ scores. And as expected the scoreboard was full of scores that were impossible to attain in normal gameplay. This is the fundamental problem with doing this, players can cheat to win prizes and any experienced developer, quite frankly, should have known better.

I’m not going to go into too much of the technical side but I am going to explain the two main methods players use to cheat in order to win prizes.

It’s unfortunately unavoidable, although there are some limited precautions we can take to help prevent cheating, if players are determined enough they will get around them. And it goes without saying that the more worthwhile you make it for them (the bigger and better the prizes they can win), the more likely you are to attract some serious hacking attempts. For this reason we always strongly recommend to our clients not to base in-game competitions on high scores.

Scoreboard Hacking

This is one of the most common method used to cheat, in order to win competition prizes. Global scoreboards have to be implemented by using a remote server-side script to send the score data to a data file or database.

If the player knows where this server side script resides (and it’s fairly easy to find out by checking the calls from the browser) they can fake the act of sending a new high score. So they can effectively add whatever score they want to the scoreboard, without having to even play at all.

Another method involves changing the score as it’s stored in memory, during runtime. There are freely available programs written specifically to do this. These types of hacks are generally how you end up with scoreboards full of impossibly high scores into tens or hundreds of millions.

There are limited methods to combat this. In the case of hacking the script call, verifying scores as they’re submitted and discarding impossibly high ones is one solution. This won’t stop people finding the limits of that range though and filling up the scoreboard with equal, highest possible scores in a attempt to win.

It’s also possible to use something called a cryptographic hash to send the data. This adds a basic level of security to the data you send, which means in order to cheat you’d need to crack the code first.

To help combat memory hacks, it’s also possible to apply some encryption to the score data in memory. These types of methods can make it much more difficult, but not impossible to hack and as I said before, make it worth their while and they will hack it.

It’s also worth mentioning that this isn’t something that’s technology specific whether your online game is Flash, HTML5 or something else, the risk of cheating to win competition prizes applies to all web based technologies. However, HTML5 is potentially the easiest to hack because the code is viewable by anyone with a web browser.

Cheating on Timed Games by Altering Frame Rate

This will involve a bit of techy explanation, so I’ll try to keep it as simple as possible.

Game timers can be implemented in one of two ways:

Tie It Into the Main Game Loop

This has the disadvantage of only having accuracy based on the frame rate. A game running at 30 frames per second (which is the frame rate we usually use) will be able to count the timer in steps of 1/30th second. This is usually fine (and preferable) for games where the timer just counts down a limited gameplay time, such as in a timed puzzle. Although this can cause it’s own problems (which I won’t go into here), the timer is not independent of frame rate. If the game slows down or speeds up, the timer slows down and speeds up with it.

Tie It Into the Computer Clock

This has the advantage of much greater accuracy, allowing timers accurate to thousandths of a second. If the player’s score is directly tied to the timer, e.g. a racing game where the quickest time is the highest score, this is usually essential. Without this sort of accuracy, there’s just not enough to separate the scores of players and you’d end up with too many players getting the exact same time. The problem with this though is the timer is independent of the frame rate, so regardless of whether the game runs at 30 frames per second or 60 frames per second the timer will run in the same “real” time.

This opens the opportunity to cheat to win prizes, if your competition is based on high scores. Programs are freely available that enable the player to change the frame rate of a game as they see fit. So, if for instance you have a timed race game, the player could potentially double the frame rate, which would make the race happen twice as fast, but the timer would still run the same as it would at the normal frame rate. This could allow the player to halve their time and get a much better score and was likely the exact method used to cheat on the Facebook competition I mentioned earlier.

Again verifying the times and throwing out impossibly fast ones before sending to the scoreboard is a partial solution, but not a particularly great one and certainly won’t prevent cheating altogether. Another possible solution (which I won’t go into too much) is using something called delta time in the main loop. This is used in lots of commercial games to get around variable frame rates (usually caused by hardware performance, or lack of it) but has a number of disadvantages for small scale retro/2D games.

The Solution

Obviously none of these hacking issues are too much of a problem if there aren’t competition prizes at stake. With no incentive to “hack” to win a competition, players are far less likely to try and even if they do, there’s no harm done. Plus, any good developer should be aware of these issues (although in practice it seems very few are) and take appropriate, limited security steps to make it harder to cheat, as we always do.

The problem comes when prizes are at stake. But this doesn’t mean you have to ditch the idea of including a competition in your game altogether, there’s a simple solution. Don’t tie the awarding of prizes to scores achieved, or other game outcomes. Instead, run a free entry prize draw competition.

This gives you complete control over the awarding of competition prizes and removes the incentive to cheat, because the reward is only a chance to win a prize, not a guarantee they’ll win. You can also help combat obvious cheating through your terms and conditions, enabling you to put a limit on number of entries per person and exclude entirely players who might hack to gain many entries.

Overall, it’s a much safer solution and allows you to incorporate a competition in your game, without risking the whole thing being rendered null and void by casual hackers.