Thursday, March 24, 2011

Who are the HTML5 Game Developers?

An HTML5 game is classified as a game that:
  • runs in a modern web browser
  • is written in JavaScript
  • uses Canvas or WebGL for graphics
While there is a large and growing collection of HTML5 Game Engines and Frameworks, who out there has actually written a non-trivial, professional HTML5 game?  Here's my quick list:

Wednesday, March 23, 2011

Measuring HTML5 Browser FPS, or, You're Not Measuring What You Think You're Measuring

Update: Ilmari Heikkinen has written a helpful Browser Rendering Loop blog entry.

Everything you know is a lie.

OK, not everything.  But everything you know about measuring the FPS for your HTML5 game is probably wrong.  Turns out that measuring the frame rate, or FPS, for an HTML5 game written in Canvas or WebGL is surprisingly difficult.


http://weblogs.mozillazine.org/roc/archives/2010/11/measuring_fps.html will tell you that trying to measure framerate by counting how often your setTimeout runs is not accurate. The browser can run your Timeout callback multiple times between screen paints.  All you're probably doing is measuring how often your game loop runs, which is not FPS.
Turns out Mozilla has a window.mozPaintCount available, which should provide an accurate FPS. However, this only works for Mozilla.
There's an open issue for a clone of window.mozPaintCount for Chrome, but doesn't look like there's much traction there.
A manual way to check for hardware accelerated FPS in Chrome is to grab the Chrome Beta channel (as of posting date) and go to about:flags and turn on FPS Counter. However, on a Mac, acceleration only turns on when using WebGL. So, no way to check FPS for Canvas on Chrome for Mac.
Enter requestAnimationFrame.  This little doozy works its butt off to get your game running at 60hz (in Chrome) or 50-60hz (in Mozilla).  Instead of writing your own setTimeout loop, you ask the browser to call your draw function when its ready.  Yup, that's right, you're putting your game's draw loop into your browser's hands.
This is a good thing, though.  The browser knows when it's painting, so it knows when do call your paint function.  This reduces tearing, as the browser can draw at the same time as your monitor's refresh.  Also a big win: if the tab isn't visible, the browser won't animate, thus saving CPU and battery.
One small hitch with requestAnimationFrame: Firefox 4 just fixed a bug (as of the date of this post) which gets the frame rate up to acceptable levels, but we'll have to wait for the next push of Firefox to get the fix (yay for autoupdates!)
Moral of the story is: you're probably not accurately measuring your HTML5 game's FPS, and you can only programmatically measure it in Firefox with window.mozPaintCount.
Second moral: Use requestAnimationFrame if your user is on Chrome, and soon Firefox 4.

Monday, March 21, 2011

HTML5 Game Talk at Google IO

Good news!  I'll be presenting on HTML5 Games at Google I/O, to be held May 10-11, 2011 in San Francisco.  I know it was very hard to get a ticket to Google I/O this year, but if you were lucky enough to grab a ticket I'm really looking forward to meeting you and talking HTML5 for Games.

The title for the talk is "Super Browser 2 Turbo HD Remix: Introduction to HTML5 Game Development".  I'm working on both the game and the agenda for the talk, but my basic premise will be "it's easier than you think" and I'll be aiming at the beginner/intermediate JavaScript and web programmer.  You'll come away with the confidence and tips to build your first HTML5 game, along with perspective for distribution and monetization.  Plus, we'll look at some fun games! :)

My initial agenda looks a little something like this:
  • Why games are different than traditional web programming
  • Game loop
  • Input detection
  • Animation
  • Coordinate system
  • Asset loading
  • Collision detection
  • Text
  • Sound
  • Performance tips
  • Distribution
  • Monetization
Of course, that's all subject to change, but it's a start.

What topics should I cover?  What did you find interesting as you were starting out?  What do you want to see at an HTML5 Games talk?  Let me know in the comments below.

Thanks!

Sunday, March 20, 2011

HTML5 Storage and Offline Presentation

I was lucky enough to be able to present HTML5 Storage and Offline Technologies at the Bocoup Loft in Boston on March 10th, 2011.  Bocoup is a really cool web development agency, and I appreciate their offer to host and facilitate the talk.

Many thanks go out to Mr. Eric Bidelman for putting together the awesome slides from which I poached and remixed.  And by remixed I mean more or less stole.

HTML5 enables offline applications and local data storage and caching.  This leads to quicker start up times, faster processing and less network and server utilization (always a good thing).  With offline and storage, we have many technologies at our disposal:

  • App Cache for cached static assets like images, CSS, and JavaScript
  • Local Storage, basically replacing cookies
  • WebSQL DB for full relational SQL
  • Indexed DB for a very JavaScript-y object storage and retrieval system
  • File System APIs for sandboxes, virtualized filesystems accessible from your web app
If you're confused and just getting started, I highly recommend the HTML5 Storage and Offline presentation.  There's more info at HTML5 Rocks Offline page as well.

Happy hacking!  And remember, Target Smart Browsers!

Saturday, March 12, 2011

HTML5 Audio Needs Your Help

HTML5 is gaining traction as a gaming platform, but there's still one problem before we can achieve the vision of a great native-to-the-browser gaming experience.  HTML5 audio, specifically the <audio> tag and its implementations across browsers, is more or less broken for games.

For details on the HTML5 audio problem, learn about The State of HTML5 Audio (hint: not good) and the troubles with Multiple Channels for HTML5 audio.  Dominic, the author of those posts, knows what he's talking about: he created Impact, the JavaScript game engine.

We need your help!  Star these issues, add comments, and even better add test cases.  Tell Chrome that you care about HTML5 audio and these issues are important!

http://code.google.com/p/chromium/issues/detail?id=47381
http://code.google.com/p/chromium/issues/detail?id=47761
http://code.google.com/p/chromium/issues/detail?id=59369
http://code.google.com/p/chromium/issues/detail?id=59370
http://code.google.com/p/chromium/issues/detail?id=60678
http://code.google.com/p/chromium/issues/detail?id=73045
http://code.google.com/p/chromium/issues/detail?id=74576
http://code.google.com/p/chromium/issues/detail?id=75725

Disclaimer

I'm probably required to say that the views expressed in this blog are my own, and do not necessarily reflect those of my employer. Also, except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the BSD License.