HTML5 Games and Consistent Timers

Due to the wide array of CPUs, graphics cards, and hardware acceleration options, HTML5 games need to deal with varying performance conditions.  This implies that HTML5 games need to track their internal game times to ensure everything happens in a predictable and deterministic manner.

An "internal game time" is a clock that the game maintains, independent of the system's clock.  The internal game time can start at zero when the game starts and tick itself forward as the game progresses.

To illustrate why the internal game time is important, consider the case of requestAnimationFrame.  Both Chrome and Mozilla have implemented requestAnimationFrame, a mechanism to hand off the animation frequency and sync to the browser.  This is A Good Thing, because the browser reduces or eliminates tearing effects because requestAnimationFrame is called when the browser is ready to paint the screen.

requestAnimationFrame is also very smart, as the browser will not run animations or paint the screen if the tab or animated element itself is not visible.  This greatly reduces CPU usage and increases battery life, both very good things!  However, this implies that the game itself pauses when it's not in view.

If the game can pause, and your game is using standard system times, then you will have a big problem.  When you calculate your delta time, the time between last check and this check, right after you come back to life after a pause, then the delta time will be huge.  And this means your game will skip ahead many many frames.  This means, not only will the user be confused by the big leap through time, but any events that should have happened will be missed and skipped.

You can avoid this by using your own internal game timer, which clamps the delta time to a known, fixed rate.  This solves the pause problem, as any pause length will be clamped to maxStep when the game wakes back up.

Finally, here's some example code:


Timer.prototype.step = function() {
        var current = Date.now();
        var delta = (current - this.lastTimestamp) / 1000;
        this.gameTime += Math.min(delta, this.maxStep);
        this.lastTimestamp = current;
}


Or, you could not worry about and get a game library that does this for you, like Impact.
7 comments

Popular posts from this blog

  • Sponsor:  Register today for  New Game, the conference for HTML5 game developers . Learn from Mozilla, Opera, Google, Spil, Bocoup, Mandreel, Subsonic, Gamesalad, EA, Zynga, and others at this intimate and technically rich conference. Join us for two days of content from developers building HTML5 games today. Nov 1-2, 2011 in San Francisco.  Register now ! This is the second article in a Box2D series, following the Box2D Orientation article. The Box2DWeb port of Box2D contains a nice example to show off the basics of integrating physics simulations into your web app. This post will provide a walkthrough of the example, explaining the high level concepts and code. First, let's see the example in action. The code for the above is open source and available on GitHub. It was adapted from Box2DWeb's example . Animating Before we look at Box2D, it's important to understand how the above simulation is animated. You might think setInterval or setTimeout is
  • In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F
  • Angular and Polymer, sitting in a DOM tree, B-i-n-d-i-n-g. First comes components, Then comes elements, Then comes the interop with the node dot bind. Angular , a super heroic MVC framework, and Polymer , polyfills and enhancements for custom elements built on top of Web Components, can live harmoniously in the same app. This post shows you how to connect Angular-controlled components to Polymer-controlled elements via data binding. And we do it all in Dart . Angular and Polymer I get asked "Should I use Angular or Polymer?" a lot. My answer is, "Yes". That is, both libraries have distinct strengths, and you can use both in the same app. Polymer excels at creating encapsulated custom elements. You can use those custom elements in any web app or web page, regardless if that app is built with Angular, Ember, etc. Angular excels at application engineering, with dependency injection, end-to-end testability, routing, and services. Here are som