Pirates Love Daisies: HTML5 Lessons Learned

As announced on the Windows blog this morning, today Pirates Love Daises - a new HTML5 tower defense game - has been released!


Grant Skinner, the leader of the team that built the game, reported his experience on his blog. He shared some interesting thought about the shift of paradigm for an experienced Flash developer approaching HTML5. He also described some of the unexpected (but pleasant) surprises and challenges he faced during the development phase.

In this post, I’d like to complement his comments with further lessons we’ve learned along the path.


Let’s start talking about Performance. We heard many times that IE9 is fast…but I think this is the first time IE9 has been defined “smoking fast”! Grant, you are a primer!

I like to think about this game as a real world performance benchmark. No secret functions, no ray-tracing algorithms, no synthetic tests. Just a well designed HTML5 game.

The best way to test the performance, it’s to try it on your machine with your browser. For those of you that don’t have 7+ browsers installed on your machine Angelo, I recorded a video where I play the game on all the latest browsers builds available today.

Get Microsoft Silverlight

Based on my personal experience, I reported the results in the table below. The CPU and Memory (Private Working Set) values have been captured using the Windows Task Manager, after about 5 seconds playing in the easiest map. A better measurement should take count of an average over time, since the complexity of the app increase quickly during the game.


Firefox 3.6

Firefox 4b7 Chrome 8 Chrome 10 Safari 5.0.2 Opera 11
Full Game Excellent Very Bad (crash) Bad Good Terrible NA
Simplified Game Excellent Terrible (crash) Very Bad Good Terrible (good/bug?)
CPU (%) 13 49 NA 44 48 45 40
Memory (MB) 100 144 NA 175 143 180 240


  • IE9…what can I say, it’s fast. It’s really fast.
  • Firefox 3.6 can run the basic site, but it struggle to catch-up when you turn on all the game effects
  • Firefox 4 Beta 7 is not able to render the website. At every page refresh I get a different result.I suspect there is one (or more?) bug in that build
  • Chrome 8 can run, although slowly, both game modes. Seems to be faster than Firefox 3.6
  • Chrome 10 Canary Build is the most promising, although it doesn’t meet yet the same performance bar of IE9
  • Safari 5.0.2 has intermittent issues not better identified that prevent the game to (always) run. It was a surprise, since it works on Safari for MAC
  • Opera 11 (the one released just few hours ago) feels good, but few seconds after the game starts it hides all the pirates and creeps (the game keep working in the background). It could be a bug in the game (although weird, since it works on other browsers), a bug in Opera or an interop issue. Let me know if you are more lucky than me

According to Grant’s tests, the game runs on Mac and iOS as well, although with poor performance. I don’t have any of these machines, can any reader record and share a video of the game playing on a Mac or an iPad (or any other device with HTML5 support)?

Working with HTML5

As we stated many times, HTML5 is doing great progress and this game is yet another confirmation of its capabilities. Let’s see a few key learning we made along the path.


I hope Grant will share more insights into his development experience with the Canvas. It’s exciting what he achieved in terms of complexity – it almost doesn’t feel any more like HTML!

A common technique that he used for the game is called “sprite animation”: you build a large image (composed of many sub images) and then you draw only one part of it at a given time. If you need to do an animation, you can re-draw very quickly on the same location – and all the human eye will see is an animation!

For example, here’s the Kraken sprite:


If you are interested to build your own animation, have a look at the library used in the game and gently made available by Grant: http://easeljs.com/

One of the interesting questions we got was: what is the max size of an image that the <canvas> can handle? 1000, 2000, 4000 pixels width? More? In this case I think the answer is “it depends”. It depends probably on the browser architecture (not necessarily the browser itself!) as there is a tight dependency on the video card and the OS. Having a browser that supports hardware acceleration helps, but there are still technical boundaries that can’t be overcome. Based on empirical experiments, we found that ~4000pixels seems to be the current limit. I’d be interested to hear from other people what they experienced on their machines.


There are hundreds thousands of fonts available today. For this project, Grant’s team got one that fits perfectly within the game. During the development of the project, they started with the ttf (True Type Font) format. They realized however that it was better to use an open font format…and what better one than WOFF, the new standard submitted by Mozilla and Microsoft to W3C!

We used Font Squirrel to generate the @font-face Kit (also check out TypeKit) and we initially generated the compact CSS rule:

 @font-face {
     font-family: freeBooterFont;
     src: url('../fonts/freebooterupdated.woff') format('woff');  
     font-weight: normal;
     font-style: normal;

It was working fine on all browsers, except Safari (both on Windows and Mac). Looking at online resources, we realized that – although committed to – they don’t support WOFF yet in the current build. Interesting, since it’s already on Chrome WebKit (shouldn’t the code be the same/shared?). I’m sure it will be added soon…and in the meantime we adjusted the CSS syntax (luckily super easy to do!) to include a fallback format.

 @font-face {
     font-family: freeBooterFont;
     src: url('../fonts/freebooterupdated.woff') format('woff'), url("../fonts/FreebooterUpdated.ttf") format("truetype");  
     font-weight: normal;
     font-style: normal;


Having one <audio> element on a page playing without plugins is already awesome.

Having 40 of them playing together is an orchestra! There are topics however that the spec doesn’t cover (and I think shouldn’t cover) where IMHO a little more documentation should be given by browser vendors to developers (IE Team already took note). For example, what’s the best practice to pre-load multiple audio samples? How many audio files can the browser play at the same time? I’m planning to spend some time on this topic in a future post.


I didn’t build the game, but I was reviewing the interim builds using the Developer Tools in IE9. They come with the browser, no need to install anything special, you just press F12 and they fire up.

The feature that I love more than anything else and that was very helpful in this project is “Format JavaScript”. If you go to the site now, you’ll notice that the code has been compressed and crunched to optimize performance.


If you are like me and you want to understand what’s behind it…you can go to the Script tab and press the “Format JavaScript” button. The result? A nicely “reverse-engineered” formatted source code! (Sorry Grant, I hope you won’t be upset Sorriso)


There is much more to cover and to explore, but I’ll let you play the game now.