5. Browser Compatibility Isn't Uniform
If your players are running more recent browsers such as Chrome or Firefox, they should be able to play your HTML5 games just fine. But what about those still using older browsers like Internet Explorer 6, or previous versions of Safari or Opera? If users aren't updating their browsers, they won't have access to all of your HTML5 content.
At times, these browser compatibility issues work against one of the platform's greatest strengths: its ubiquity. If users are still using older browsers, they're excluded from playing HTML5 games.
Some developers, like Zynga's Bakaus, believe the best way to overcome this problem is to simply push forward with development, even when limited to newer browsers. By creating quality games that don't work with older software, users will be incentivized to upgrade, he argues.
"People are scared to abandon users at less than Internet Explorer 9," he said. "But sometimes, giving people what they want isn't helpful, since nothing will change. Try to come up with great new stuff that only works in modern browsers, and that will create incentive to upgrade," he said.
But if all users are running HTML5-enabled browsers, does this mean web apps will run equally well across all of them? Not necessarily.
Even when you look at browsers that support HTML5, that support is not uniform; older HTML5-enabled browsers might support only a limited number of features or APIs, meaning certain game features are only available to those who keep up with the latest browser releases.
And of course, if you're working with a limited budget, you might now have the resources to make a game that works across all browsers. At the New Game Conference in San Francisco, Bocoup's Darius Kazemi recalled that he encountered that very problem when porting Subatomic Studios' Fieldrunners to HTML5.
Kazemi explained that due to time and budget restrictions, he and his team chose to develop the game specifically for Google Chrome and the Chrome Web Store.
"Here's the dilemma," Kazemi said, "Do I reach the widest audience possible, or do I create the highest quality game? Can I have both?"
"In the end, do we get it on other browsers, or do we just create that quality experience on one browser? We ended up doing [the latter]."
Kazemi added that the game benefitted from some of the APIs that shipped with Chrome 14, but in the end the game was bound to a single browser. If you're going for platform ubiquity with your HTML5 games, be careful to plan your resources accordingly.
6. There's No "App Store"
One of the key ways in which HTML5 apps differ from native apps on mobile devices is that they lack a centralized app store to keep everything in line. This comes with its own set of pros and cons, but it's certainly worth noting before diving into the platform.
Of course, the main benefit of working on the web is that there's no approval process to submit, launch, or update your game. Unlike closed platforms like Apple's iTunes Marketplace, HTML5 allows you to update or launch your game whenever you like, with no need to wait through the bureaucracy of a platform holder.
While this freedom might seem appealing to up-and-coming developers, it comes with at a cost. Without a standardized distribution platform, getting your app in front of players becomes much more of a challenge.
"Right now, we do not have a major HTML5 'app store' to aid in discovery," said Putney.
Without a single destination for HTML5 apps, it becomes much more difficult for players to even learn about a new release. Putney said, however, that Facebook could certainly help in this regard.
"With Facebook enabling the social discovery of HTML5 apps on their mobile platform, it is a huge step forward," he said.
Google, on the other hand, views the open nature of HTML5 as one of its greatest strengths. The company's Seth Ladd explained, "I might say that it's actually easier to publish and distribute, because there's no governing body there, there's no up-front approval process. Everyone gets the freedom to monetize the way they want, log in to users the way they want, and publish they way they want. This is one of the strengths of the 'open' part of the open web platform."
7. It's Still Evolving
With all of HTML5's advantages and shortcomings, you'll have to decide for yourself whether it's right for you. Currently, there's no final specification for HTML5, but web developers are constantly adding to the platform, so who knows what things will look like in the coming years.
Google's Seth Ladd has high hopes for the future of HTML5, and notes that with such rapid iteration coming from the various working groups on the web, the platform is evolving faster than ever.
"I think what you're seeing now with Chrome, and Firefox, and even Internet Explorer to an extent, is that the specifications that come out of the different working groups in the spec bodies are moving at a much faster rate than they've ever moved before," he said.
With so many parties actively working on the platform, some HTML5 developers say it will only become more robust as time goes on. HTML5 developer Dominic Szablewski added, "This is HTML5's greatest strength. There's competition. After years and years of IE6 and Flash there's finally some progress with web technologies again and it's only just beginning. There's so much going on right now: WebGL, fullscreen mode, mouse lock, new audio APIs. It's truly exciting."
Companies like Zynga admit that HTML5 still has a long way to go until it can really compete with native app development, but if the platform can maintain its growth, the playing field could eventually even out.
Zynga's Bakaus said, "We're still early and that native apps have focused on game development for a long time already, so they've just had a ramp-up that we haven't yet."
Despite the optimism from existing HTML5 developers, the platform is still a challenge to work with given its ever-evolving state. Putney said, "We are essentially working on a car that is moving," noting that the changing specifications can introduce a number of technical hurdles in mid-development.
"But if we get things right, we can reach hundreds of millions of users with a successful app -- so we believe it is worth it," he said.
|
Number 8: With HTML5, your game MUST be open source (client-side, at least).
I think open source is super cool and I'd like to push myself to publish more source for my projects, but being forced to by the platform is, shall we say, a non-insignificant detail.
Even though alternatives like flash are dead easy to decompile with the right tools, that's still one step removed from having your source just all hanging out, flapping around naked in the wild internets.
Not a deal-breaker for me personally, but seems just as important a "Thing to know about HTML5" as the other ones mentioned here.
There are some workarounds for this problem, but they're not exactly pretty.
You could keep key portions of your game's logic server-side, so that the publicly-visible code is more or less a "dumb reader," querying the server for the game logic and anything interesting.
You'd still be exposing any clever graphical tricks you're using, as well as I/O and network logic, but someone won't be able to copy your code wholesale, slap in new assets, and market it as a competing game.
Hackers can dig into your game code, but they have to deal with an unreadable mess and the owner is still "protected" by usual copyright laws (just like any other game).
Nice article!
You can decompile AS3 to an almost 1:1 representation of its original form. Some information is lost (variable names) but this isn't that hard to overcome.
Meanwhile in JS land there is minifying. Although primarily to save bandwidth, using Google's Closure Compiler with the advanced minifying turned on (beware: it modifies a subset of JS, so not all JS code is usable this way) will dramatically alter your code's structure and remove nearly all hardcoded variables and properties.
I'd rather use JS than AS3 in this regard.
JavaScript needs to be up to par. From page 2:
"... HTML5 has actually surpassed Flash... But Flash has some very significant advantages too."
Yes. It's called ActionScript, and it blows JavaScript out of the water.
From page 2:
"... "HTML5 is completely free -- to get started, you just need a browser and text editor, no need to purchase an expensive application."
That's a big plus. However, you can develop with Flash without spending a penny also: FlashDevelop + the Flex SDK, which reduces its barrier to entry. In addition to Flash CSx costing 3 arms and 5 legs, it isn't all that great anyway. It's built-in code editor sucks, and the tool crashes a lot.
"There's No "App Store"
There's also no "HTML5GameLicense.com" either, like Flash has FlashGameLicense.com. It's probably too early for that, although I'd like to see it in the future.
_________________________
- Ziro out.
I wish some of Adobe's proposals for ECMAScript 4 had gotten more traction. Despite the massive gains in JIT compilation of JavaScript, ActionScript still tends to perform better for the moment. And ActionScript makes it much easier to write a medium-sized project with multiple developers without stepping on each others' toes.
I hope this is just a temporary phase of HTML5's evolution, and that in a few years the latest version of JavaScript will have improved or been replaced as the language of the web by something more robust.
In web browser flash its still the king and the fact is that most people have the plug-in to play flash than people who have browsers that can run html5. And most web game developers have to learn html5 because "its going to be better" "its going to run faster" "its going to be true cross platform" and maybe you can monetize them.
And in mobile html5 its still not an option for games, native apps its still the way to go.
I canīt see the incentives to learn html5, and "because its free" its not an answer because you can create flash content for free.
HTML 5 is also really unstable, and I cannot count the number of times I've seen chrome and Firefox just suddenly go "Sorry, script is not responsive" and never come back since implementing HTML 5. They'll need to discard Javascript in it's entirety before HTML 5 is really viable for anything except "gee wiz" value.
The open source side of it is unsettling. I like open source as much as the next guy, but I also don't like the idea of uncompiled code sitting there in the breeze. It just feels negligent somehow.
part_of_HTML5_that_aren%27t
- WebGL
- FileReader
- XMLHttpRequest
- querySelector(All)
- Geolocation
- ECMAScript5
- CSS3
- XBL2
- Web Workers
- Web Sockets
- Faster JavaScript
The WebGL one is the biggest: "Well, Flash has this new Stage 3D API, while the web has WebGL". WebGL != HTML5
And pragmatically HTML5 is defined by what WHATWG does, not the W3C, and their "HTML Living Standard" contains what's traditionally called HTML as well as JavaScript, web sockets, web storage, etc.
Technically, we are in a state of affairs where "HTML" includes e.g. web sockets et al., but "HTML5" does not. So until the people making the standard figure out what's in the term and what's not, it seems foolish to criticize anyone else or to make broad declarations about what is or is not part of the standard.
As a project decision, when choosing platform, if you have audio, there is no reason that your platform of choice should be HTML5 given that workaround.
It's unbelievable that simple, cross browser implementation of audio isn't available.
For example, the browser version of Rage of Bahamut will often be played in very short sessions and in public places where it would be difficult for the player to make any use of audio. Even if the player is wearing headphones, he may be listening to music while switching between browsing several tabs, so making the usability dependent on audio could be considered more disruptive than beneficial.
"And of course, if you're working with a limited budget, you might now have the resources to make a game that works across all browsers."
Might not, surely?
Good article!
It's fast, better even than AS3, and lets you target JS (and Flash, and C++, and several other things). It's pretty much the secret weapon of web development.
Not to mention that it's still being implemented in parallel by numerous parties and so the issues of item 7 are still applicable. The fact that the target is now properly defined doesn't mean all implementations are suddenly up to date.
Not that constantly evolving is bad thing, just that point 7 is actually still valid.