Grant Skinner

The "g" in gskinner. Also the "skinner".


Atari Arcade: Classic Games Reimagined in HTML5

The Atari Arcade has launched! We’ve been working tirelessly with Atari and the Microsoft IE team to re-imagine classic Atari games for the modern web. The games are multi-touch tablet friendly, use the latest crop of modern web standards, are built on top of CreateJS, and run on pretty much any popular current generation browser. We had a ton of fun trying to balance modernizing these games with preserving their iconography and gameplay faithful to the originals.

There’s a lot more to say, but we’re all still recovering from the launch rush, so for now I’d encourage you to check out the arcade, read through the dev center articles on how we built it, and wander over to to learn about the libraries the games were built on top of.

Update: We have published a Case Study on our site.

Reducing File Size for Images With Alpha Channels

We’ve been building a lot of spritesheets and other images for use in HTML5 projects. To preserve alpha channels, you need to use PNG32, which can get pretty large for some types of content because it’s a lossless compression format.

I wanted to find a way to reduce these file sizes, so that games and other experience would load more quickly. Ultimately I settled on a solution that separates an image into two parts: a JPG with all of the RGB information, and a PNG32 with the alpha channel. In my testing, the end results vary wildly – some content is larger when split, but some content can see a reduction in size of up to 70%. This is can have a pretty significant effect when applied to a 2MB sprite sheet image!

To enable this, I added a utility method in EaselJS that takes these two images and merges them back into a single canvas, which can be used for sprite sheets, drawn to other canvases, added to the DOM, or used as an image source via toDataURL(). The great thing is, it runs REALLY fast (a few milliseconds for most large images), because it leverages composite operations.

var combinedCanvas = SpriteSheetUtils.mergeAlpha(rgbImage, alphaImage);

For initial testing, I prepared my images using Photoshop, but this was slow, time consuming, and cumbersome. To make the process easier, I wrote a simple AIR application codenamed “Omega” (as in, alpha and omega – such boundless wit!). It will prepare multiple images at a time, and display a report showing the original and total resulting sizes, so you can decide which assets to use it on.

It’s currently very barebones, and requires you to do everything via the command line. In some ways, this is kind of nice – you can create batch files or commands to quickly run it on specific files or folders of images – but I plan to add a UI soon. I’m also planning to open source it the not too distant future, but I thought I should share it in the interim so others can use it.

You can grab “Omega” here. It comes with a text file that describes all of the available arguments and shows some examples. It works great with Zoë or your spritesheet creation tool of choice.

One important note: if you’re using Omega on OSX, you’ll need to quit the application before running it a second time. For some reason AIR apps on OSX do not receive parameters with invocation events if they are already open.

Prep For Zoe JSFL Command

We’re recently been working on some pretty cool CreateJS projects with heavy dependencies on sprite sheet animations. Our sprite sheet export tool, Zoë, does a pretty good job, but it’s limited to exporting the main timeline of a published SWF. To facilitate an efficient designer/developer workflow, we really needed a solution that would let us maintain a single FLA, containing multiple animated symbols, and export them to a single combined spritesheet.

We considered using the new export to spritesheet feature in CS6, but it was missing some features we needed. Zoë offers multi-image sprite sheets (important when exporting smaller sprite sheets for mobile compatibility), configurable smart frame reuse, and flexible registration point export for EaselJS. It’s also open source, so we could modify it to work the way we needed.

To facilitate this workflow, I wound up writing a (fairly) simple JSFL command called “Prep for Zoe”. It takes multiple symbols, copies them as Graphic instances, distributes them to the main timeline, and copies their labels appropriately. If no label is specified on the first frame of a symbol (or it is a bitmap), it will automatically add a label based on the symbol’s name. It will even warn you about duplicate labels. Finally, it publishes your FLA to generate an updated SWF.

The end result is a single SWF with all the animations and labels on the main timeline, which you can bring it into Zoë to export them all as a spritesheet.

To use it, you just place all of the symbols you want to include in a single guided layer on your stage then run the command. Your main timeline will be prepped for you, and the SWF will be automatically published. Need to make changes? Edit your guide layer, and run the command again – it will automatically delete all the old layers, rebuild the timeline, and export a new SWF.

By default, the registration point (aka regX/Y in EaselJS) for every symbol will be set at the symbol origin. It is represented in the built out timeline with an empty symbol instance named “registrationPoint”. If you want to set up custom registration points for each symbol, you can do so by putting each symbol on it’s own frame in the guide layer, and adding a “registrationPoint” instance for each. These registration points will be preserved in the prepared timeline. Check out the included “advancedExample.fla” file to see this in practice.

Once your SWF is ready, just bring it into Zoë, configure the settings as appropriate, and push “Export”. Once you set up a SWF once, Zoë will remember the settings for it, so exporting a new sprite sheet from your FLA is as simple as running Prep for Zoë to update the SWF, then running export in Zoë. Hand the updated image(s) and JSON data to a dev, and it’s ready to be integrated into a game or other experience.

You can grab the JSFL command here, including a couple of example FLAs to get you started. To use the command, either double click the JSFL file (this will immediately run it on the front-most FLA if Flash is open), or copy it into the Commands folder in your Flash config directory – it will then be available in the Commands menu. You can download Zoë here.

New CreateJS Version Launched

I’m excited to announce the launch of new versions of the CreateJS libraries and tools. CreateJS is a suite of open source libraries and tools to make it easier to build really rich, interactive experiences using modern web standards.

This release added a ton of new features, including masks, multitouch support, run time generated sprite sheets, and better support for fluid or multi-resolution experiences. We also refined functionality, fixed a bunch of bugs, and added tutorials on a number of major topics for EaselJS.

The biggest change, which you’ll want to be aware of if you’re going to migrate existing content to the new versions is that all classes are now in a configurable namespace. You can either use the default “createjs” namespace, switch it to something more convenient, or configure it to not use any namespace at all to retain compatibility with legacy content.

I’m hoping to write up a more detailed overview of this release when time permits – things are very busy here at!

You can grab the latest, and get more info about CreateJS at

Disable Local Security In Chrome (More Easily)

This is a quick follow up to my previous post about disabling local security errors in Chrome on OSX.

I’ve been working a lot with command files lately and thought I would share a simple one that you can double-click in the Finder to launch Chrome with the -disable-web-security flag set. This lets you test content locally that uses “sandboxed” JS features like accessing the pixel data of local images. Handy when working with EaselJS.

This comes with the obvious warning that you probably shouldn’t surf the web in this mode.

You can download the command here. For it to work properly, you need to quit Chrome prior to running the command. You may also need to open it up in a text editor and change the path to Chrome if it’s somewhere other than /Applications, or you want to use this command with Chrome Canary.

Command files are pretty handy – they let you package Terminal commands into a file that can be double clicked in the Finder. Definitely worth learning about if you’re a developer on OSX. There are also .terminal and .term files, which provide similar functionality with a little more control, but they seem to have some issues in the current version of Terminal.

Announcing CreateJS

We’ve been working really hard on a lot of great stuff over the last couple months, and I’m thrilled finally to be able to share it with the world.


We’re going to be releasing EaselJS and a number of companion libraries under the new umbrella name “CreateJS”. CreateJS will be a suite of modular libraries and tools which work together to enable rich interactive content on open web technologies (aka HTML5). These libraries will be designed so that they can work completely independently, or you can mix and match as suits your needs. The initial offerings will be: EaselJS, TweenJS, SoundJS, and PreloadJS.

Along with the new name, we’ll also be launching a new site at which will consolidate demos, docs, tutorials, community, and showcases for all of the libraries and tools. If you have a project or tutorial you’d like to see featured, tweet it to us: @createjs.


EaselJS provides a display list and interactive model for working with rich graphics on top of the HTML5 canvas (and beyond). It provides an API that is familiar to Flash developers, but embraces javascript sensibilities.

We’re planning a minor v0.4.1 release soon, which includes bug fixes and some minor feature additions. Following that, work will commence on v0.5, which will focus on some larger features, API clean up and consistency, and improved documentation. If you have features you’d like to see in v0.5, add them to the issue list, or tweet them to @createjs, and we’ll see what we can do.

Along with the CreateJS site launch, we will be releasing much improved examples, and links to resources and tutorials developed by the community. Again, let us know if you’ve written a tutorial, or have something cool you’ve built with EaselJS you’d like us to showcase.


TweenJS is a tweening and animation library that works with EaselJS or independently. It offers a deceptively simple interface, and a huge amount of power with support for delays, easing, callbacks, non-numeric properties, sequencing, and plugins.

TweenJS v0.2 will be tagged soon. It will incorporate some fixes and tweaks, along with a full plugin model. After v0.2 our next focus will be on performance and providing better demos and documentation in preparation for the CreateJS launch.


Audio is currently a mess in HTML5, but SoundJS works to abstract away the problems and makes adding sound to your games or rich experiences much easier.

We have a huge v0.2 release in testing right now. It is a ground up rewrite that incorporates a target plugin model that allows you to prioritize what APIs you’d like to use to play audio. For example, you could choose to prioritize WebAudio, then audio tags, then Flash audio. You can query for capabilities (depending on the plugin that is used), and it offers seamless progressive enhancement (for example, panning will work in WebAudio, but will be quietly ignored in HTML audio). Following v0.2 our focus will move to fixing bugs, and delivering plugins for mobile and application platforms like PhoneGap and Win8 Metro for a v0.2.1 release.


The newest addition to the suite, PreloadJS will make it easy to preload your assets: images, sounds, JS, data, or others. It will use XHR2 to provide real progress information when available, or fall back to tag loading and eased progress when it isn’t. It allows multiple queues, multiple connections, pausing queues, and a lot more. We’re hoping to get a v0.1 build out in the next couple weeks for people to start playing with, and then will focus on fixing bugs, improving documentation, and just generally maturing things for v0.1.1.


Zoë is an open source AIR application that converts SWF animations to sprite sheets. It supports some advanced features, like configurable frame reuse and multi-image sheets (important for mobile).

For Zoë v0.2 we’re planning to add support for reading the symbols in a SWF, and letting you select multiple symbols to include in your exported sprite sheet. It’s also worth mentioning here that Flash Pro CS6 will include direct support for exporting sprite sheets for EaselJS, offering a more integrated workflow than Zoë can provide.

Toolkit for CreateJS

We’ve partnered with Adobe to build a fantastic tool for leveraging all of the existing Flash Pro skill that’s out there to build amazing HTML5 experiences. The Toolkit for CreateJS is an extension for Flash Pro that allows you to publish content (including symbols, vectors, animations, bitmaps, sound, and text) for CreateJS & HTML5 as a library of scriptable, instantiable objects.

We’ve worked really hard to develop a workflow that makes sense, and to generate code that is completely human readable, and very small (in some cases the output is smaller than SWF when zlib compressed). You can even write JS code on the Flash timeline, and it will be injected into your published tweens.

Exciting times! If you’d like to stay on top of CreateJS updates, please follow @createjs on Twitter.

Disable Local Security Errors in Chrome

I’m blogging this mainly for my own benefit, so I can look it up easily whenever I need to:

If you’d like to disable security errors generated from accessing local content in Chrome (ex. reading pixels from a local image), just launch it with the “–disable-web-security” param. So on OSX, you’d type this into Terminal:

open /Applications/Google\ –args -disable-web-security

It lasts until you close Chrome. Handy for testing EaselJS content on your local file system.

Update: I’ve posted a .command file that you can double click in the Finder to run this more easily here.

The Evolution of (Web) Development Tools

I’ve seen a few people complaining about and/or questioning the lack of mature tools to develop content for the modern web (aka HTML5), and it got me thinking about the evolution of these tools, and how challenges are solved for technology platforms in general.

In my (albeit limited) experience, there is a natural progression for a maturing technology stack, particularly one without a single master (ex. Flash and iOS development differ somewhat because the tools and platform are directed/developed by the same entity).

First, you will see the development of a lot of frameworks, starting with micro-libraries that address a single challenge, and evolving to macro-frameworks like JQuery that tackle an entire workflow. Developing frameworks has a very low barrier to entry, and provides an ideal way for developers to explore and share a variety of potential solutions for challenges. Because the libraries are written in the domain language, it also means that any developer encountering a problem can address it directly with a language they are familiar with.

As problems become better defined, and specific solutions begin to emerge as more dominant, you start to see single purpose tools created, often as command-line utilities. These have an increased investment compared to frameworks, and require that the developer has knowledge of both the problem domain, and basic desktop development.

Next, you will see partial workflow tools, which aggregate and leverage the single purpose tools (either directly, or by borrowing approaches). These put a UI on top of a number of solutions to make them more accessible to users. Again, these involve increased investment, and require additional capability (UX/UI design, more advanced desktop development).

Finally, you will see the emergence of full-scale workflow tools. These represent a major investment, generally require a team of specialists to create, and are built over the course of months or years. As such, they need to build on top of standards, approaches, and frameworks that have been well vetted by real-world use. Even then, their early releases will be limited, and will require a huge amount of community feedback and multiple revisions to “get it right”. With this in mind, early release with rapid iteration is a critical practice for any tool that aims to be successful in this space.

As an aside, code editors tend to follow an accelerated path, simply because the problems they are solving are less tied to a specific technology platform, and have been thoroughly explored for other languages.

Of course, none of these steps happen in isolation. In the JS world, you can see all of these underway simultaneously. There is an unending stream of new frameworks, as developers explore challenges, with a number of more mature ones gaining traction. There are a number of popular single-purpose tools (ex. LESS, Closure Compiler, Zoë). There are a few partial workflow tools (ex. CodeKit). And finally, there are a number of early entries in the more robust tool category (Edge, Sencha Animator, Flash Pro’s Wallaby, etc).

Further, this evolution is massively complicated and slowed in the HTML/JS world by the constant flux of the technology, the non-trivial issue of supporting multiple browsers/platforms, and the question of legacy support. Tool makers need to wait for a standard (or more frequently, a collection of standards) to stabilize and be broadly adopted/accepted before they can risk the investment to build on top of it.

This is obviously a simplified look at the problem, but hopefully helps illustrate where things are today, and why we don’t have access to fully mature tools for HTML5 development yet. They are coming, but it’s going to be an incremental process.