Author / Grant Skinner

Grant Skinner

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

@gskinner

by Grant Skinner

WebGL Support in EaselJS + Mozilla Sponsors CreateJS

We’re absolutely thrilled to welcome Mozilla in joining Adobe, Microsoft, and AOL to the roster of CreateJS sponsors!

We’ve been working with the Firefox OS team to ensure our libraries are well-supported and valuable tools for app and game creation on Firefox OS.

The first big announcement as a result of this collaboration, is WebGL Support for EaselJS (currently in public beta on GitHub), which is supported in both the browser and application contexts of Firefox OS (as well as other WebGL-enabled browsers). In our tests, we’ve managed to to draw a subset of 2D content up to 50x faster than is currently possible on the Canvas 2D Context. You can learn more about our WebGL implementation on the Mozilla Hacks or CreateJS blogs.

Be sure to let us know what you think in the EaselJS Community forum.

Welcome Mozilla, and a huge thank-you to all our amazing sponsors!

by Grant Skinner

Bardbarian Launches on iOS!

I’m very excited that our first big TreeFortress game, Bardbarian, has launched on the iOS App Store! Bardbarian offers a unique gameplay style (think tower defence merged with a top down shooter), and some really fantastic artwork.

Bardbarian

Check out screenshots & gameplay videos on the Bardbarian game site, or check it out on the App Store.

Bardbarian has also been greenlit on Steam, and will be coming to PC, Android, and other platforms soon.

by Grant Skinner

Embedding JS Script Tags in WordPress Posts

When you include javascript in a WordPress post, WP automatically applies formatting to the script tag’s contents, causing script errors. This has led to a large number of workarounds, including: plugins, using custom fields, including every script as a separate JS file, and stripping empty lines from the script (to prevent WP from injecting paragraph tags).

I wanted a solution that would let me quickly inject JS directly into my post content, and wouldn’t require any special prep or have dependencies on third party plugins. After unsuccessfully hunting the web for an answer, I came up with a simple approach that uses a pre tag to prevent WordPress from formatting my code:

<pre class="script"><script>
  // code here.
</script></pre>

Then just add the following to your site styles to prevent the pre tag from displaying:

pre.script {
  visibility: hidden;
  display: none;
}

It’s crazy simple and the script executes properly. I’m kind of shocked that I didn’t run into this approach at all in my search. It makes me worry a bit that there’s some glaring flaw with it, but so far it seems to be working great.

Hopefully this saves someone else some time and frustration.

Note: there’s a chance you may need to disable “Settings > Writing > WordPress should correct invalidly nested XHTML automatically” to prevent WP from encoding characters in your code. I have it disabled normally, but in limited testing I didn’t see any problems with it enabled.

by Grant Skinner

Open Source Licenses, JS, and Minification

I’m definitely not a lawyer and I detest reading legalese, but I have a strong interest in the legal considerations of the technology I work with. One area I’ve done a lot of research into in the past is the implications of different open source licenses, which led to this older blog post comparing common licenses.

Recently, one of my devs asked how this applied to JS and minification. Here’s the quick response I tossed together:

—

Let’s assume we are looking at the MIT license or an equivalent. Remember that ANY third party code requires client approval, and any license other than MIT should be run past me as well.

The MIT license specifically requires that the license is included somewhere in the software, but it does not need to be public facing. Typically, the license is included as a comment at the top of the source files. However, minification strips out the comments and combines source code into a single file. This raises three possible scenarios:


  1. All of the code in the file is under MIT license. In this case, you can inject the copyright statements for each of the libraries followed by the main body of the MIT license above the minified code. We do this automatically for the CreateJS libraries as part of our build process.

  2. Client code & MIT licensed code. I would recommend that all open source code is treated as in #1, and client code is minified into its own file (potentially with a copyright header specified by the client). This is much cleaner than trying to mix them.

  3. Code with different licenses. This gets much more complex, and should be dealt with on a case by case basis.
—

I’d be interested to hear about how other companies are dealing with this topic, or related ones.

by Grant Skinner

Upcoming Talks

I’m excited to be doing talks all over the world in the next couple of months, focusing on two related topics: CreateJS, and the Atari Arcade.

Create The Web, San Francisco, London, Tokyo, & Sydney (Sep & Oct)
I’ll be on an around the world tour with a group of Adobe evangelists (I’m the only non-Adobe presenter), talking about the open source CreateJS libraries, and how to get started creating rich content in HTML5. Adobe is the primary sponsor of the libraries, and is a great partner in helping to actively promote them.

The SF event is full, but you can still sign up free for the other locations here.

Screens, Toronto (Sep 26-28)
Screens focuses on multi-screen content, and I’ll be presenting on the HTML5 Atari Arcade project and some of the challenges we had in making it work well with both desktop and multitouch tablets. You can get more info on the conference here.

FITC Vancouver (Nov 17-18)
Once again, I’ll be talking about the Atari Arcade, and our continuing experiences building games and rich content in HTML5. Despite my (relative) proximity, this will be my first time speaking in Vancouver, and I’m really looking forward to it. More info here.

In addition to the above, I will also likely be hanging out at the MS Build conference Oct 30-Nov 2. I’m pretty excited to see first hand what’s announced with respect to Windows 8, Windows Phone, IE10, and Surface.

It’s going to be a busy autumn, but it should be a lot of fun!

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

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

by Grant Skinner

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.

by Grant Skinner

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.