Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Building Games for HTML5, Not with HTML5
by Austin Hallock on 09/05/13 09:38:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

Past Successes

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.

Facebook → Zynga

FarmVille

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.

Angry BirdsiOS → Rovio

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.

HTML5 → ?

Building For HTML5

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.

Hyperlinks

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.

HyperlinkWhat 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 austin@clay.io.

Multi-Device Use

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.

JavaScript is the perfect language to build a multi-device game with. Just like Node.js has become incredibly popular by keeping the language between the frontend and backend relatively the same, so can be said for keeping the language consistent between device 1, device 2, and the backend. Why write an iOS version of a game in Objective C, and the PC version in C? Performance would be the only reason, but that’s becoming more and more of a moot point.

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.

Games Everywhere

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 Engine Optimization

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.

Freedom From The App Store and Google Play

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.

Moving Forward with HTML5

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!


Related Jobs

Zynga
Zynga — Chicago, Illinois, United States
[10.21.14]

Senior Software Engineer (Front End)
Harmonix Music Systems
Harmonix Music Systems — Cambridge, Massachusetts, United States
[10.21.14]

Senior Product Manager
Harmonix Music Systems
Harmonix Music Systems — Cambridge, Massachusetts, United States
[10.21.14]

Web Developer
Cloud Imperium Games
Cloud Imperium Games — Santa Monica, California, United States
[10.21.14]

Marketing Director






Comments


Leszek Szczepanski
profile image
"WebGL is mature enough to provide console-quality experiences".

As an API yes, as a platform no.

And it won't be for time. JavaScript is fine for making simple games, 2d platformers, puzzles. The overhead is gigantic and because of that the performance is lacking.

I did see some nice 3d demos in WebGL but they could get 30 fps only on a really powerful machine. Apart from that there is a long line from a 3d demo to a 3d game.

Austin Hallock
profile image
In context it says "when WebGL is mature enough" :)

JavaScript engines have improved by an incredible amount over the last 3 or 4 years, and will continue to do so.

I'm not sure if you're familiar with asm.js, but in early tests it was able to perform about 2x slower than native - and that was just after a couple of months developing asm.js.

More on that here: http://mozakai.blogspot.com/2013/06/what-asmjs-is-and-what-asmjs-
isnt.html and some benchmarks here:
https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun- dalvik-vs-spidermonkey/

Bryan Wagstaff
profile image
Actually when you look at published numbers, the JavaScript interpreters themselves have not improved much. JavaScript performance in Chrome has been basically flat since it was released in 2008. Published stats for Firefox, Opera, and everyone but IE have also seen no major improvements since that time. IE has seen improvement, but only because it was awful and they have been getting it near the level of the competitors. There was a bit of excitement as companies began to JIT compile their JavaScript, but otherwise there has been no news for five years.

The current fatal flaw in JavaScript is memory problems. Memory management routines are virtually non-existent. The memory requirements to do non-trivial work add up quickly. The language encourages creation of objects everywhere and it is difficult to prevent it. The nature of the JS garbage collection routines just make the problem that much worse. Heavily scripted pages can require a gigabyte or more to run their scripts that spew out temporaries and copies of data for even the most trivial things. JS programmers spend more time than they ought to trying to tame the memory waste that is encouraged by the language.

Austin Hallock
profile image
Based on http://blog.chromium.org/2010/12/new-crankshaft-for-v8.html (older, but more recent than 2008) and http://arewefastyet.com I'd say it hasn't plateaued since 2008.

Memory can be a problem, but there are techniques to counter it - just as their are guidelines for how to intelligently develop for every platform. Of course, that means game development in JavaScript is significantly different from what folks were building on the web a few years ago, but former web developers will adapt, and folks new to JavaScript won't have to fix those old habits.

asm.js removes garbage collection from the equation. In case there are people here not familiar with it, the first link in the other comment and http://asmjs.org/faq.html help explain it a bit better. Keep in mind that asm.js is more of a compilation target from other languages like C and C++ (maybe TypeScript eventually), and not something you're going to write from scratch.

Andreas Ahlborn
profile image
I personally find it misleading how you treat the term "platform", so that it ends up being meaningless.
Facebook (a social network) is a platform, iOS (a operating system) is a platform and then HTML/Javascript (a programming language) is a platform, too?

No, not buying it, sorry.


The whole premise of this article falls apart, because I am getting what you are trying to say: make a killerapp that is best suited in playing to the strengths of HML5, like Nintendo made Sports the Killerapp for Wii, but why didn´t you just say so?

A Programming Language has only one problem, anything one language can do, can be done by any other language (that is the main feature of a consistent language, its universal).

In games, there are certain things that one programming language handles better, than another, better means: quicker and with less overhead and with higher compatibility.

Actionscript is better than C in creating User Interfaces, C is better than C# in handling 3d manipulations and javascript is better (versatiler) than VisualBasic in running inside a browser.

At the moment I simply can not see that HTML5 is superior to any other language in any of the mentioned departments, its too immature, ill-adopted.

Austin Hallock
profile image
It's "The Web" as the platform. And the whole point is that it's a pain that there are so many languages out there - in your case, many for one game. JavaScript is poised to take over the roles of every one of them, and while it may not be the best in a certain area, it can get to the point where the difference is negligible.

Mohamed Almonajed
profile image
Amazing article! Thank you a a lot Austin :)


none
 
Comment: