Ryan Tyrrell  Ryan Tyrrell

Sugar coated HTML5 Games and Apps

Home > Blog > Sugar coated HTML5 Games and Apps

Question: How many HTML5 frameworks and engines are there?

Answer: A lot.

If you’re looking for some HTML5 tech for your next project, then you really are spoilt for choice. Two we’re using right now are Phaser and CreateJS. Both are very good at things like rendering sprites over multiple devices and browsers. But frankly, in 12 months we’ll probably have moved on to something new.

Why? Because as a studio we are committed to producing great products for our clients and our users. So, we can only be loyal to whatever technology currently allows us to produce the best product. And as technology changes so frequently, in practice we aren’t very loyal at all.

Therein lies a problem. That frequent switching of technology is a requirement for us, but it means that our studio have to constantly learn new things. It’s hard to become great at doing something when what you’re doing constantly changes.

To address this we’ve built our own internal framework called Sherbet. The first phase of Sherbet is now boxed up and ready to be delivered to our studio.

Wait, not another HTML5 framework!” I hear you cry. Why does the world need yet another one?

First of all it’s important to say that Sherbet is our own internal framework. At the moment we have no plans to release it into the wild. However, I do want to share the strategy behind Sherbet and reveal some of the benefits it is bringing us. Perhaps you will consider how a similar approach might help you?

Here’s how it started:

We did a review of our project build process and realised that there were big efficiency gains to be had by standardising the technology and tools that we use across our studio teams. The challenge for us is to find these efficiency gains without limiting our ability to update, swap and change the technology we use as and when that improves.

So we created Sherbet, a modular set of code, tools and automation processes that has an API that we’ll use across all our HTML5 browser and native mobile product builds from now on.

Here are the key benefits that Sherbet brings us:

  • Speeds up development
  • Works on desktops and mobile devices for both games and apps
  • Allows more time to go into product quality and less time into bug fixing
  • Enables technology to be switched in and out transparently – even toward the end of development, so the product gets the best tech possible
  • Reduces our code base and the repetition of similar code over multiple projects
  • Makes our products load faster and run faster

Here’s an overview of the phase one components that make up Sherbet:

Audio Manager: converts and compresses audio, handles loading and classifies sounds. Handles playing of audio across browsers and devices through one API.

Build Process: automates code concatenation and minification to improve load time for all platforms. Produces unique file-sets over dev, staging and live builds, optimised for each platform and device. Runs quality tests (see later).

Sprite/Image Library: builds and manages sprite sheets from multiple files. Directly integrates them within our code. Compresses images for each platform.

Note that Sherbet doesn’t attempt to provide an API for drawing sprites and images. That’s because those functions are handled so well by other engines and frameworks, at the moment we just use those, and we probably will for the future; we’re not in the business of reinventing the wheel.

XML: most of our client’s tech people like XML, but JSON is more useful. So Sherbet automatically converts XML into JSON and visa verse.

CSS: transparent use of SASS, making CCS more manageable, optimisable and faster at runtime. Also allows global definitions of styles, making updates and changes to styles and formatting across entire products really quickly.

Server Component: Sherbet creates a common local server environment for each developer. In future we will expand this to match final deployment server configurations.

Code Quality: seamlessly uses JSHint to test the quality of our code and flag any issues with things like syntax. Warns if we’ve used depreciated code or anything that’s too browser specific.

Watch Task: Sherbet runs a background task that pre-builds assets for developers whenever an asset is changed. So there’s no more building assets on demand, everything they need is there and ready for use when they need it.

One aspect that may get you thinking is the efficiency that a modular API can offer. In many places Sherbet is simply a neat layer of indirection between our simple product code and the complicated technology we choose to build the product with.

Here’s some code to prove the point.

This is how a developer using Sherbet loads a piece of audio and plays it under a game’s loading screen:

var assetManager = new SHERBERT.assetManager({
    audio : SHERBERT.audioManifest
});

assetManager.loadByClass('loading', function(){

    assetManager.play('loading_screen');

});

Without Sherbet the full code looks like this:

var filePath = 'assets/audio/high_quality/loading_screen.mp3';

var request = new XMLHttpRequest();

request.responseType = 'arraybuffer';

request.addEventListener('load', function(e){

    var audioContext = window.AudioContext ? new AudioContext() : new webkitAudioContext();

    var gain = audioContext.createGainNode ? audioContext.createGainNode() : audioContext.createGain();
    gain.connect(audioContext.destination);

    audioContext.decodeAudioData(e.target.response, function(decodedBuffer) {

        var source = audioContext.createBufferSource();
        source.buffer = decodedBuffer;
        source.connect(gain);

        var playMethod = source.noteOn ? 'noteOn' : 'start';
        source[playMethod](0);

   });

}, false);

request.open('GET', filePath, true);

request.send();

Even with the shorter example using Sherbet, the code does a lot more than the second chunk, including:

  • Auto populates the audio manifest based on files in our ‘assets/audio’ directory.
  • Checks the best method of playing audio (the second example assumes the webAudio API is supported in the browser).
  • Checks which audio format is best to load (mp3/ogg/wav) – the second example assumes that ogg format is supported in the browser.
  • Automatically loads different audio qualities for the audio file based on the device/platform.
  • Catches any errors that may occur and fails gracefully.

Summing Up

We were hesitant to launch into yet another HTML5 framework when there are so many out there that do a great job of things like rendering and runtime performance. But then we realised that our biggest gains would come from knitting the development process together and seamlessly swapping in and out whatever external technology happens to be best right now.

There isn’t a framework out there that gives us what we need and works over both games and apps, so building our own made sense in this case.

I’d sum our internal roll out of Sherbet up by saying that as a studio we’ve just gained a key strength – we’ve managed to gain the efficiencies that come with a long-term, stable internal framework, yet under the bonnet we can easily switch to whatever external technology works best right now.

Our clients, and the people who use our apps and play our games, can now expect a higher quality experience, quicker load times and a more responsive product from us.

__

Ryan Tyrrell

About Ryan Tyrrell

Ryan is a the studio technical lead at fish in a bottle, he specialises in web technologies and works across apps, web platforms and games.