In the thousands of HTML5 games I’ve seen and played, the biggest downer is that so many are just using “HTML5″ as an alternative way to create either “mobile” or “Flash” games. The problem with that approach is HTML5 is neither Flash nor a native mobile language. Building a game with HTML5 just to put it in the iOS and Android app stores is pointless, you’re going to have a game that performs worse than it would with Unity or Adobe AIR. Rather than trying to emulate native mobile games with HTML5, we as developers need to develop games specifically for HTML5 – taking advantage of the unique offering it brings.
Often times the easiest way to drill home a point is to analyze historical examples. Let’s look at two of the biggest names in gaming in the past 5 years, and how they got where they are by building for the platform.
Zynga blew up to a $9 billion dollar evaluation because it completely understood the Facebook platform and how to effectively distribute and monetize their games through it.
There were plenty of good games on Facebook before Zynga Poker and FarmVille… heck, there was even Farm Town (the same idea as FarmVille – before FarmVille). Zynga just really understood how to build a game for Facebook and have it spread virally by taking advantage Facebook’s social features: inviting friends (in a more personal way “be my neighbor”), posting progress to a player’s wall, and various achievements.
The notion of really understanding a platform and building for it can also be seen in Zynga’s sharp decline. They were slow to make the shift to mobile and are no longer able to take advantage of some of the Facebook features that caused them to grow so quickly.
A Physics-based Cannon Game wasn’t something new Rovio came up with for Angry Birds - Crush the Castle from before Angry Birds looks awfully similar – but Rovio turned it into a game that works flawlessly with touch, something the iPhone made possible at a large scale. If Angry Birds had used the same mechanic of a cannon instead of the more touch-friendly slingshot, the game arguably wouldn’t have become the cultural icon it is.
It did take Rovio 51 games to get to Angry Birds’ success, but during those first 51 games they clearly learned how to develop for the iOS platform.
So what’s the “touch” and “social” of HTML5? To find those we have to look closely at what makes HTML5 and The Web as a platform unique.
Distribution is often cited as a major issue for HTML5 app and games – for good reason. We still haven’t seen an HTML5 game that masters distribution.
What we’re forgetting is how powerful of a distribution model we already have with how the web works. We have links, and more importantly, we have ways for people to virally spread links. Content, articles, videos, etc. reach millions of views and plays just through links – games however haven’t seen the same success. To some extent, Flash games have done well, but I still don’t think games have reached the level of success videos and content have (especially on all devices including mobile).
I haven’t seen many games creatively use links – certainly none off the top of my head. They link to the game’s “play” page, and that’s it. I should be able to join a friend with a link, resume a game based on a link, challenge a friend to beat my score with a link and so on.
Part of this falls on the tool makers – developers don’t want to spend time getting these things to work; features that aren’t completely about the gameplay. At Clay.io, we’re trying to help with this, and have implemented a “Links” API feature that makes it easy to do the three scenarios I mentioned.
I’m sure there are still a ton of cool things we could be helping developers with that we’re not… Game developers are the most creative bunch of people I’ve ever worked with, so if you have a creative idea to take advantage of The Web as a platform, and you think we can help, reach out to me at firstname.lastname@example.org.
HTML5 is the perfect vehicle for games that make use of multiple devices. The Wii U was the first to really bring this mainstream with its controller acting as a second-screen for the TV… The thing is, you developers don’t need a Wii U or special controller to make this happen – the Wii U controller is pretty much a standard controller with a phone screen shoved in the middle.
The best example I’ve seen of this is in a year old demo video by EA. The game is called Strike Fortress and it’s a game that takes advantage of the phone + PC setup. You can see the demo video here.
Battlefield 4 is doing a variation of this where, because the game is complex enough, there are different game modes based on the device used (tablet vs PC/Console). On a tablet, you act as a team’s “Commander” with a 2D top-down view and certain specialized abilities. See the trailer for Commander Mode here. This type of gameplay seems like a perfect place for HTML5 to fit in, especially when WebGL is mature enough to provide console-quality experiences.
I have no idea what technology stack EA is using for Battlefield 4′s Commander Mode, but it’s the type of thing I think HTML5 is built for.
This is one is obvious, but I feel obligated to include it. I still see countless HTML5 games that are built just for the desktop web that don’t take mobile into consideration – keep in mind, these are types of games that would actually play well on a touch screen…
If you’ve built an HTML5 game, distribute it as many places as you possibly can. Off the top of my head: the iOS App Store, Google Play, Windows App Store, Chrome Web Store, Facebook, Firefox Marketplace, Amazon Appstore, Flash Portals, and the list goes on.
This whole post encompasses building for HTML5 as a platform, but that also consists of building for all of the platforms HTML5 works on – it is a bit more work, but it’s worthwhile. That includes supporting input on a variety of devices (touch vs keyboard & mouse) and having the game scale to many different sizes.
Search engines have long been the best way to get people viewing content. Social media has made a huge impact in the past few years, but SEO remains a powerful tool for The Web, even on mobile. Games aren’t very optimized for search engines though. The portals games are found on are usually optimized, but as an HTML5 game developer you can do that optimization on your own. Clay.io does it, as does Kongregate, etc.. but if someone is searching for something relevant to your game, wouldn’t you rather them directly visit your page?
The canvas element itself obviously isn’t indexable, but you can surround the game with some description text to help, and apply some common SEO techniques to try and get more search traffic.
For reference, Slime Soccer on Clay.io consistently gets 2,500 unique plays per month from search traffic on one keyword.
You can find a plethora of articles on how to choose keywords (the fact that it’s a game shouldn’t matter too much), but one of the best is How To Do Keyword Research.
Your game doesn’t need to be in the iOS App Store or Google Play to be played on mobile devices. That is a huge benefit. Sure, it’s good to have it in both of those stores (and is easy enough to achieve), but the fact that it can be played without requiring an install and the extra bulk of the stores is a big opportunity.
Consumers are now discovering games through chat apps like WeChat and Kik – both of which have had some success on the HTML5 front primarily in Asia. The App Store model is generally good, but it can make discovering unique new games very difficult – apps like WeChat and Kik are a different approach to finding games. More info on this can be found here and here.
In addition to these chat applications, there are the more established mobile apps like Facebook and Twitter where games can be played directly from the app’s webview. That’s a much better user experience in that sense then going through the app stores. Build games that work well with this model.
HTML5 is a beast of its own; let’s break free from trying to emulate native mobile apps, and start developing games that take advantage of everything HTML5 offers!