|
At first glance, HTML5 seems to offer some huge advantages for online and mobile game developers. As a purely web-based platform, game makers can create their game in HTML5, and release it on any number of supported devices, from phones to PCs and beyond. But is it really as easy as it sounds?
The platform doesn't have a final specification yet, so its capabilities are very much in flux. It's shown clear signs of promise, and major developers like Zynga have already begun supporting it for their mobile releases, but companies such as on engine provider Unity claim HTML5 "isn't where it should be in terms of performance."
With no clear consensus on where the platform is headed, we've decided to talk to some of the developers most involved with HTML5 to get their perspective, diving into the platform's greatest strengths, it shortcomings, and where it might be headed in the future.
The following is a list of the most important things to know about the current state of HTML5:
1. It's Designed To Work Cross-Platform
HTML5's primary advantage is that it works across a wide range of devices, from PC browsers to mobile phones, tablets, and even Smart TVs. As long as a device uses a browser equipped to run HTML5, it can theoretically serve as a viable platform for HTML5 games.
This offers a huge advantage over native apps, which often have to be completely redesigned for their target operating system. If a developer wants to bring his or her iOS title to Android, for instance, they'll have to make some fundamental changes to their game. With HTML5, that process should be a bit easier.
"We've supported the drive to HTML5 for over a year now, and we see great value in the ability to outfit browser-based games for any device. This is becoming more and more important as gamers play more often and on multiple devices," said Peter Driessen, CEO of major web game publisher Spil Games.
"We think there are a few reasons to go with HTML5," said Zynga Germany's Paul Bakaus, who helps build tech for the company's numerous web and mobile games.
"One benefit is the ability to distribute it easily on mobile web browsers. You don't have to install it, for instance -- that's one significant advantage. There's also the thing with content updating and cross-platform development. If you're building a native app, it's likely that you have to build your app twice on Android and iOS, and on desktop maybe, too. On HTML5, you build your app once, and you can port it to multiple different devices," he said.
In addition to allowing developers to more easily put their games on multiple platforms, HTML5 also allows for easy cross-platform communication, allowing for a host of cloud-based features, ranging from social systems to persistent game worlds.
"What we're ultimately looking to accomplish through HTML5 is true cloud gaming. We support a large online community and it's been obvious that our players, much like gamers everywhere, are increasingly looking to play games on their mobile phones. HTML5 sets the foundation for us to create a seamless experience, which includes social functions, on browsers both on the go and at home," explained Spil's Driessen.
2. HTML5 Offers Unpredictable Performance
While HTML5 might be designed to run on a wide range of devices, there's still no reliable way to maintain performance across varying hardware specifications.
EA creative director Richard Hilleman recently shared his frustrations with the platform at the San Francisco-based New Game Conference, noting that his team's experimental 3D animations ran great on a MacBook Air, but chugged on more powerful hardware.
"On my own computer, which runs on an i7, I couldn't get more than a few frames per second [from our demo]," Hilleman said. He explained that "high performance JavaScript is obtuse at best," so it's hard to predict how an app will run on a given hardware specification.
"I don't know how to explain that to a customer. That's a big, big problem," he added.
Mobile-focused HTML5 developers are particularly susceptible to these problems, as their games need to run on a wide array of smartphones and other mobile devices.
Stewart Putney, an experienced HTML5 developer and former CEO of the recently shuttered Moblyng, told Gamasutra that his company would test its games on literally dozens of devices. "For iOS it is simple: 3GS, 4, 4S, iPad, iPad2. Android is much more fragmented; each handset manufacturer tends to make small -- mostly undocumented -- changes to the browser on their devices. For native Android apps, this is no big deal. For HTML5 apps, it can mean apps simply don't work," he said.
"To get good quality, our apps must be tested on a range of popular devices -- it is the only way to be sure apps are working properly. I believe we will see more testing tools and better standards moving forward -- but Android QA is a real pain point for HTML5 development," he continued.
|
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.