I’m extremely excited to announce the launch of one of our recent projects: Pirates Love Daisies!

Microsoft approached us a few months ago and asked to work with us to build a best of breed tower defense game in Javascript and HTML5. I was a bit hesitant at first – it’s been quite awhile since I worked with JS and HTML in any great depth, and most of my memories were of fighting browser incompatibilities and cursing the lack of decent developer tools. However, we did some quick code spikes to get a feel for what was possible and decided that this was a great opportunity to gain some applied experience with a new technology while working on a fun project.

Concept

We teamed up with local illustration group Pulp Studios and started brainstorming ideas for the theme of the game. Fairly early on we latched on to the idea of pirates (I mean really, who doesn’t like pirates!), but we needed something for them to defend. We considered going with the typical tower defense model, and simply have the user prevent creeps (enemies) from getting from point A to point B, but I’ve never liked that narrative. What exactly is at point B that’s so important?

We decided that the creeps were out to steal something valuable from the pirates, but we weren’t sure what that should be. Gold was an obvious choice, but it was boring, and it made more sense as the currency for purchasing units and upgrades. Then it hit us… Daisies!

Why daisies? Because Pirates Love Daisies, of course. The fact that daisies are visually iconic, seemed to be appropriately fun and quirky, and would work well aesthetically may have factored in as well.

With the illustrators working on sketches, we got down to writing code.

Coding

We started out by building core game logic, and a simple library to manage canvas state. We profiled performance, then revisited some of our initial ideas to work with the limitations we found.

Overall, we found working with JS to be a lot easier than we expected. Picking up the language was a breeze, and we were able to apply the processes and approaches we’ve developed from years of working on interactive content with Flash. For me, working with Javascript again actually had a certain pleasant nostalgia to it, as it recalled the days working with ActionScript 1. There is a certain amount of fun and freedom afforded by a dynamic scripting language, though the lack of strict typing, compiler time errors, and language-level support for inheritance (ie. no super keyword) were frustrating but manageable.

We also ran into some browser incompatibilities, though far fewer than we initially feared. The worst of them revolved around audio. It seems that every browser has its own set of irritating quirks related to dynamic audio that we had to stumble our way through. We wound up building an audio manager to resolve these issues that we may clean up and share in the future.

All round, things went fairly smoothly from a coding perspective. We ran into some challenges and had to make some compromises, but we surmounted all the major obstacles and learned a ton.

Performance

Overall, I was really impressed by the performance we were able to obtain. Code execution speeds are fairly similar to AS3 (which is impressive if you consider all the extra type data the AS3 JIT has to work with), and graphics performance is, for the most part, reasonable.

IE9 was the big stand out on graphics performance – its GPU-enabled engine is smoking fast, especially with large bitmaps. Interestingly, we found that iOS had terrible performance (when it worked at all) – something like 4-5x slower than Android on comparable hardware.

One other thing we found that’s worth noting is that drop shadows are ridiculously slow in canvas. A few small drop shadows rendered to canvas could drop our framerate in half.

HTML5 Features

HTML5 is actually a collection of standards at different levels of completion, so while it’s easy to refer to this as an HTML5 game, it really just leverages a few of the new features that are included under that umbrella.

Specifically, we used canvas for drawing the game board (terrain, units, creeps, effects, etc), local storage to save local scores, the audio element for all of the sound, and embedded fonts throughout.

Tools and Libraries

One of the challenges we encountered was the lack of good tools. For JS development, we tried a few different options but ultimately settled on Dreamweaver – it’s not a fantastic JS code editor, but it’s decent, cross-platform, and everyone in the office already had it.

The game art was created in Illustrator, then animated in Flash Pro. We built a custom AIR tool for exporting SWF animations to a sprite sheet (a grid of animation frames) which helped out tremendously. We also built a super simple AIR app that preps our JS files, runs level 1 of the google compiler on them, and then runs the result through the YUI compressor. We’re hoping to release both of these apps in the new year, once we have a chance to clean them up.

For testing and debugging, we used the debug tools in every major browser. Roughly half our developers were on Macs using Safari and Chrome, and the other half were using Windows with IE9 and Firefox. This let us spot cross browser issues early on. We also found different problems were more easily solved with different browser’s dev/debug tools.

In our code, we leveraged JQuery, JSON, and a new library we developed called Easel. The Easel library provides a hierarchical display list, similar to the one in AS3, that makes it much easier to work with the canvas element. We released the alpha version of Easel today at EaselJS.com under the MIT license. It should make it much easier for both Flash and JS developers to get started using canvas.

Gameplay

When building a game it’s essential that you don’t underestimate the huge amount of time required to balance gameplay. Our level designer built spreadsheets, graphs, and formula to help model the characteristics of the units, creeps, and maps, but it took hundreds of plays through the game (a sacrifice, to be sure) to get the balance right.

We tried hard to make the game very approachable, with a short tutorial, and easy start, but also layer lots of strategy into it for the more experienced gamer. Our scoring system involves lots of trade-offs. As an example, you get points for defeating creeps and ending waves faster, but you also get points each wave for hoarding gold. You have to decide how to balance these two opposed reward systems.

It was only when, having opened PLD to test some specific feature, I caught myself in my third game trying to beat another developer’s high score (and getting yelled at by my wonderfully patient wife) that I really started to feel like everything was coming together. If you can completely lose track of time while playing your own game, after being immersed in planning, designing, and coding it for a couple months, I think that’s probably a good sign… though it can have a negative impact on office productivity.

Overall

Microsoft was a fantastic client. After suggesting the tower defense genre, they trusted us with all the technical and creative details to make the project a success, while offering great feedback throughout. They put a lot of faith in a company that’s really not known for Javascript or game development, and I’d like to believe it was well placed.

I never thought I’d say this, but Internet Explorer 9 actually looks to be a great browser. It has impressive performance, and seems to be very standards compliant. I would definitely recommend checking it out, you might be surprised.

Everyone involved with the project had a huge amount of fun building it out. We had a great time brainstorming ideas, coming up with ways to tweak gameplay, and spending (way too much) time play testing. We’d love to hear what you think of the game in the comments below.