By Michael Scholz Jan17th 2012.
Michael Scholz was the
CTO of Gamzee, a startup whose mission is to create cutting-edge HTML5 mobile
social games.
HTML5 game development is a popular topic for discussion
amongst startups, investors, and game developers. The question: “Is it ready
yet?” invariably comes up; and it’s a hard one to answer. In this post, I will
provide notes from the development of Skyscraper City that might help answer
the question.
What is HTML5?
One challenge in answering the question ‘is HTML5 is ready
yet’ comes down to definition, what is HTML5? The terminology means different
things to different people. On Wikipedia’s page, it references the variety of
new APIs and web standards and sums it up as “(tech)
…. intended to subsume not only HTML
4, but XHTML and DOM Level 2 HTML as well.” In conversations with game
developers the emphasis tends to be on new display APIs: canvas for 2d and
webGL for 3d. Since our game Skyscraper City makes minimal use of WebGL and
canvas, we occasionally get asked ‘how is it that we are considered to be using
HTML5? [without doing canvas]’ The long answer to that question lists all the
various browser improvements we rely on that were not present a few short years
ago. The short answer is that we are HTML5 game developers because of our
decision to make pluginless browser games that won’t work in Internet Explorer
8 or earlier browsers. That’s the
choice that frees a developer from needing Flash and enables one to consider
what HTML5 era application interfaces have to offer.
Why reduce your
targeted market size?
IE8 is the default Windows XP browser, so giving up support
for it may not appear to be a good idea. Why give up a sizeable segment of
browser marketshare? The reason is simple: the growth of mobile. Mobile and
tablet web browsing are clearly the direction the worldwide web is headed, and
as readers of this note are likely aware, IE8 era technologies range from not
very good to does not exist on the millions of new mobile devices that are
entering the market every month. So HTML5 is a way to make games for desktops
and mobile devices with minimal effort to go between one and the other (for
both the players and the developers).
Which HTML5 APIs are
actually available for mobile devices?
The answer to this one evolves over time, it’s best answered
with links to third party references. One of my favorites is the page caniuse.com. I direct the reader there for an
in-depth list of what the evolving situations looks like regarding browser API
support. For example; the question ‘When can I use typed arrays’ is answered http://caniuse.com/#feat=typedarrays
where it shows typed arrays are almost supported enough to be used. But an
untyped fallback path is still required.
Is HTML5 Ready: Yes! J
· Device
Portability
One of HTML5s biggest promises is that it will eventually
become the common client development language of web and mobile applications.
Future application developers will be able to code HTML instead of today’s mix
of java, Flash, C++, Objective C, and so on.
Skyscraper City was
intended to leverage HTML5’s potential portability and deliver a game with a
single codebase running on all devices. And HTML5 delivered on this promise in
full. Our game runs successfully on mobile Opera, Dolphin, Android, and Safari;
as well as desktop versions IE9, Safari, Chrome, Firefox, and Opera. The
primary extent of our portability layer is delivered in the CSS; where we have
different layouts for desktops, phones, and tablets. Other than those screen
dimensional differences, the game is identical from one platform to the next.
The only difference worth mentioning was in our input
handling. When playing from touch devices, we use handlers for ‘touch’ and
‘touch-and-hold’ mapping to desktop ‘click’ and ‘hover’, respectfully. That was
done as an optimization since mouse events on mobile devices have greater
latency than the touch events.
· Common
Codebase (Node.js)
Browser specific code is
less than 1% of our codebase, and so choosing HTML5 is a big success on the
benchmark of code coverage and reuse. We also found that since our game was a
javascript application, we could write our server in node.js and it could
efficiently simulate on the server everything that happens on the client. We
have previous experience with Flash clients in combination with Java or .NET
backends. But by using node instead, we could hire specifically for javascript
skills and move developers between the client side and the server side
interchangeably. This reduced our development overhead, and while perhaps not directly
related to HTML5, it is our strong recommendation for javascript as our
development platform of the present and future.
· Libraries
HTML5/Javascript gets a new
library every day, and that speaks volumes regarding its popularity, and says
something about the readiness of a community that helps transitioning
developers pick up this craft. Skyscraper City uses a few libraries, and we
have learned from even more than the ones we chose to deploy. JQuery is an
omnipresent choice for DOM manipulation and utility functionality. Q has been
very handy for dealing with asynchronicity on the client. The twilio github
repo allowed us to implement SMS text messaging in an afternoon. Lastly I
should mention that pdf.js is quite clever, and we have benefited from its
image loading code.
Is HTML5 Ready: No? L
·
Facebook mobile platform
We began development of Skyscraper
City months before Facebook's mobile HTML5 support plans were known. This
required some speculation on our part of what the platform would look like.
Would it be a native app? Would it be a website? Would our game be running in a
frame or would it launch with a redirect? Today the answers to all those
questions is 'yes', and the Facebook Javascript SDK is a key component to
implementing the Facebook integration. But with our early adopter status of the
platform, we get the dubious pleasure of discovering which components are fully
functional and which should be considered 'beta' still. For example, at
Skyscraper City launch time, iOS devices didn't support requests [since fixed],
launching the game from the native app did not authenticate, and a few
inexplicable error states will break the integration, requiring a browser
refresh. We do our best to log these sort of problems to
http://developers.facebook.com/bugs and it's our experience and expectation
that all of these types of problem will be resolved in short order.
· Remote debugging
The biggest problem we encounter
developing mobile social games in HTML5 is debugging the mobile client. Some
notable tools are weinre, alogcat, and iwebinspector. But they are pale
versions of what is really needed, which is a mobile remote debugger along the
lines of node-inspector. Node-inspector is such a useful tool for node.js, it
makes the absence of a mobile equivalent all the more painful. Fortunately,
because HTML5 is reasonably platform neutral, we don’t have too many
mobile-only bugs. Those we end up diagnosing with console.log() debugging. But
that’s definitely a caveat for HTML5 developers, needing to rely on print
statement debugging rather than have a fully integrated inspection and trace
tool. Hopefully the mobile browser guy solve this problem in 2012 and we’ll be
able to celebrate mobile remote debugging this year.
·
Mobile audio
The issues
with Facebook being minor and resolvable, they present no strong argument
against HTML5's readiness. By far the most significant issue we encountered
making Skyscraper City is mobile browser <audio> tag support. iOS does
not allow programmatic play() invocation (all play()s have to callstack back to
an input event type) nor will it allow more than a single clip to be played at
one time. These are extremely limiting considerations that only Apple enforces
on us. Android suffers from some <audio> tag immaturity issues, but
should work reasonably well as the Android browsers mature. The best advice I
can offer on this topic is to log bugs against Mobile Safari and research sound
sprite implementations. Zynga has generously open-sourced their HTML5 sound
sprite implementation, check it out here: https://github.com/zynga/jukebox
Is HTML5 Ready:
Maybe… >#:/
·
Javascript vs. Ecma4
The
programming language of HTML5 is ECMAScript 5 as described in ECMA-262, edition
5. It’s commonly referred to as javascript and the readiness of the language is
a topic of some debate. Personally I’m disappointed that proposed the
ECMAScript 4 standard was implemented by Macromedia Flash as its Actionscript 3
language; but it never received support from browser vendors.
Recently Google invented the Dart language
for the web, with its optional strong types, class inheritance, library import
structure and more. Javascript actually was a better language in its 4th
edition with the inclusion of those features (back in 2005). Now that Dart is
reintroducing those concepts, javascript receives some criticism for the
missing pieces. But what is different today from the past is the existence of
compensating tools and runtimes on the javascript side. Googles’ closure
compiler has the ability to typecheck annotated code and inline optimize
function calls. The execution time of javascript has improved dramatically. A
quick profile on my pc shows Skyscraper City is 94.5% time spent in Chrome and
5.5% executing game code. During development of the game we worked on trying to update and display DOM elements faster; the time spent
in game code more often than not negligible by comparison. (Except when there's a perf bug) The answer
regarding readiness is inconclusive at this point. The execution environment is
good enough and reasonable speedwise, but it’s not optimal, and visibly less than perfect. Depending on
what environment a prospective HTML5 developer is coming from, it could be
better, or it could be worse. But for Skyscraper City, good enough was enough.
·
Content delivery
The
optimization of content delivery is topic enough for a separate article. It’s a
challenge to minimize HTTP requests, filesizes, load times, and display a
traditional loading progress bar with any degree of accuracy.
Some
HTML5 games make a separate request per asset, especially DOM engines like ours
where assets are loaded into IMG elements. This is a dire situation at first
launch load time, where ~60 small assets are requested from the CDN
simultaneously for display, hammering a mobile browsers download queue and
spending more time creating and closing connections than actually downloading
content.
A
technique I came up with to mitigate this circumstance was to base64 encode the
initial image assets into strings. Then we deliver a gzip compressed js file
listing of those strings, thereby eliminating the overhead of the requests in
exchange for decode/decompress on delivery change. It’s unfortunate that the
HTML5 platform does not offer more help to solve this sort of problem, but it
is interesting that there are viable implementation solutions to most delivery
problems. The argument that it should not be necessary to jump through such
encoding hoops is true; but it is what it is. Since there are solutions, I’d
save HTML5 is ready enough today.
·
DOM vs Canvas vs WebGL
As
previously mentioned, our renderer is a browser driven manipulator of DOM
elements. Ones other options include canvas as well as WebGL. We can eliminate
WebGL from consideration for lack of mobile support. Although there’s no reason
not to expect WebGL on future phones, certainly the hardware specs are
improving fast enough.
Canvas
is kind of slow compared to both WebGL and DOM renderers. It can be fast,
especially on desktop PCs, but the corresponding performance on mobile is such
a drop-off, it is hard to recommend, unless you can get very creative with
minimizing your game’s fillrate.
For
Skyscraper City, DOM element rendering won by default. It was faster than canvas on mobile
devices, and it exists in the same shape everywhere, unlike canvas and WebGL.
Summary:
In conclusion, Skyscraper City is living proof that HTML5 is ready as a mainstream platform for
building games that are social and available on a multitude of devices. There
are issues to deal with, like with any platform, but the browser vendors are increasingly
responsive to the issues developers face, and it is likely that this will be
the year that HTML5 is acknowledged as viable way to reach game players where
they play.
Or simply check out Skyscraper City and draw your conclusions from what we accomplished.
No comments:
Post a Comment