Grant Skinner

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

@gskinner

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 CreateJS.com to learn about the libraries the games were built on top of.

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

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.

CreateJS

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 createjs.com 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

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

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.

SoundJS

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.

PreloadJS

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ë

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\ Chrome.app –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.

Updates to EaselJS, SoundJS, TweenJS & Zoë!

I’m very happy to announce that I’ve pushed major updates to a number of our javascript tools and libraries for developing rich content with HTML5. It’s very exciting for me to see these starting to realize some of the vision I’ve had for them over the past year, both as individual pieces and as a suite of tools to make great interactive content using web standards.

Here’s a quick breakdown of what was released:

EaselJS v0.4.0
The latest release of EaselJS (our HTML5 display library) has a completely reengineered sprite sheet engine, which includes a host of new features: multi-image sprite sheets, variable frame dimensions, frame reuse, image preloading, and a new data format. Note that this change will require some minor updates to existing content using sprite sheets in EaselJS.

We’ve added filter effects, and a few sample filters, including a box blur filter by Mario Klingemann, who has agreed to write a number of other filters for the library.

There’s also a fantastic new build system, built on top of Node.js by Adobe’s own Mike Chambers. And, of course, a whole pile of other feature additions, optimizations and bug fixes. Check the VERSIONS file for full details.

Zoë v1.5.0
We’ve released a major update to Zoë, our tool for exporting sprite sheets from SWF animations. It supports EaselJS’s new data format, and adds some great new features like variable frame dimensions with more optimal rect packing, and intelligent frame reuse. The latter allows you to set a threshold for how similar frames can be, and Zoë will automatically remove similar frames and reuse them in animations. Testing on some old content, we saved 20-50% on file size with this feature, with virtually no decrease in animation quality.

This release was a bit more rushed than we would have liked, so you should expect to see a v1.5.1 release before too long that polishes things up and adds additional features such as multi-image export.

TweenJS v0.1.0
This is the first “official” release of TweenJS. TweenJS uses a simple API of chained commands to sequence tweens and actions to create complex animations and timed events. For example:

Tween.get(ball).to({x:200},500).wait(750).to({alpha:0,visible:false}).call(onComplete);

TweenJS makes a great companion to EaselJS, and also has some basic support for working with CSS properties, which will be extended in future versions.

SoundJS v0.1.0
This is also the first official release of SoundJS, our library for working with the HTML5 Audio tag. Sound in HTML5 is a complete mess to work with, and this library aims to make it a bit easier. It handles preloading, allows you to assign a fixed number of tags to a specific sound, provides volume control, and manages sound interruption.

This library is still a little rough, but we’re planning to continue to clean it up and add functionality (ex. WebAudio support) as time permits.

in summary
All of these projects are free and open source, released under the highly permissive MIT license, and are hosted on GitHub. I’d like to thank everyone who contributed to these releases, even if just by providing feedback or encouragement. Hopefully people find these useful in their own quests to build amazing content for the web!

As an aside, now that these releases are out of the way, I’m considering doing a series of posts or videos on getting started with some of these libraries. I think it would be particularly relevant as Flash developers start looking to create content in HTML5, and web developers look to create more interactive content.

EaselJS v0.3 Released!

I’m very happy to announce that version 0.3 of EaselJS has been released. Even better, it’s now on GitHub, so you can fork it to your hearts content.

This version makes it even easier to build compelling content using the HTML5 canvas element and javascript. It has a rewritten rendering engine with support for skewing, an improved and optimized interaction model (5-10x faster), and a slew of other new features and fixes. Here’s the whole list, in no particular order:

  • renamed Tick to Ticker
  • adding a listener to Ticker twice will now move it to the end of the listener list
  • added Ticker.getMeasuredFPS()
  • added Ticker.setFPS()
  • renamed Stage.tick to Stage.update and made Stage.tick point to Stage.update
  • made the pauseable param “true” by default on Ticker.addListener()
  • added Stage.toDataURL(backgroundColor, mimeType)
  • renamed Rectangle.w/h to width/height
  • improvements to commenting and documentation
  • formalized inheritance model to make code more readable
  • changed color to null instead of 0 in Shadow.IDENTITY
  • fixed an error with simple sprite sheets that weren’t set to loop
  • implemented “tiny” instructions for Graphics. (ex. myGraphics.f(“#0FF”).c(x,y,r) )
  • fixed problems with Graphics.clone()
  • fixed bug with passing instructions to a Graphics object constructor
  • complete rewrite of the render engine to be cleaner and more flexible
  • added .decompose() method to Matrix2D
  • added .skew() method to Matrix2D
  • added .skewX/Y on DisplayObject
  • added SpriteSheetUtils.extractFrame(spriteSheet,frame) method
  • added basic multi-line support for Text
  • added DisplayObject.suppressCrossDomainErrors property
  • complete rewrite of the hit testing system to be cleaner and run 5-10x faster
  • improved the interaction model:
    • added .onPress, .onClick callbacks on DisplayObject
    • removed .mouseChildren from Container
    • made .mouseEnabled true by default
    • added .onMouseDown, .onMouseUp, and .onMouseMove callbacks on Stage
    • added MouseEvent
  • Stage.getObjectsUnderPoint() has been moved to Container
  • added Container.contains(child) method
  • added DisplayObject.compositeOperation
  • added appendProperties() and prependProperties methods to Matrix2D
  • added DisplayObject.hitTest() method
  • added stage.snapToPixelEnabled and displayObject.snapToPixel
  • added DisplayObject.updateCache()
  • renamed minified file from easeljs.js to easel.js
  • Re-factored directory layout

Check out EaselJS.com for more info or to grab the latest build.

JavaScript Stalled, AS3 Orphaned – Microsoft to Blame?

As you may have already read, the ECMAScript 4 standard, the standard on which AS3 is based, and the draft proposal for future versions of javascript has been rejected in favour of ECMAScript 3.1, which proposes small incremental changes to javascript for the foreseeable future.

This leaves Adobe in a somewhat awkward position. Firstly, it casts ActionScript back to being a proprietary language. Secondly, it means they have released an extremely valuable chunk of intellectual property (in the form of the Tamarin ES4 execution engine), without gaining the expected benefits for the Flash platform.

It’s also very disappointing for the web at large. This decision means that Javascript will effectively stagnate, and is unlikely to become a robust language for supporting rich/complex client side applications any time soon. Had ES4 become a ubiquitous standard, I would certainly have looked at doing a portion of our work in the AJAX space. I’m sure other Flash developers and traditional programmers would have done the same. I suppose from that perspective, this could be good for the Flash platform, but I prefer competition, options, and thriving innovation.

So why did this happen? When I heard the news, I analysed it in light of who has the most to gain, and in context of previous discussions / information I’ve read. I guessed that the most likely reason that ES4 was dropped, was due to Microsoft. They would have to either write a new execution to support ES4 (which costs money), or swallow their “not built here” pride to use Tamarin. By crushing the standard they would avoid having to do either of these and take a stab at their rival Adobe by pulling the carpet out from under AS3’s standard compliance. Being that they control 80% of the browser market, they are also one of the few groups that could unilaterally block adoption of the standard (having a standard that’s only supported by 20% of browsers isn’t very useful).

So to me, it looks like a power play by Microsoft. And it seems that I’m not the only one – Hank Williams over at whydoeseverythingsuck.com has written an article mirroring my thoughts almost exactly.

These situations are frustrating for developers (well, for almost everyone, I imagine). Standards bodies are so hampered by politics and corporate interests, but of course they are the lesser of two evils (no one wants to return to the wild west of HTML coding). Almost makes you glad that the Flash player is a proprietary product, eh?


UPDATE: Adobe has just made their public response here. Quite candid, and definitely seems to follow the lines of my speculation with mentions of “a morass of bickering, infighting, and sometimes, out and out name calling”.

A Flash of Silverlight? My Analysis.

By now, everyone has heard of Silverlight (previously WPF/E), Microsoft’s answer to the Flash player. There have been a lot of posts on the topic of Flash versus Silverlight, but I thought I would chime in with my own thoughts on the subject. I have not played with Silverlight in much depth, so please feel free to correct me if there are mistakes.

From my perspective, the discussion can be broken into four categories: opportunity, runtime, tools, and intent.

Continue reading →