Edit: 23/08/12
Check out the newest version: Brickout!
Some time last year, I started learning the HTML5 Canvas API. One of the most popular tutorials for this was (and still is) Bill Mill’s Canvas Tutorial, where you build up a basic version of Breakout step by step. After completing the tutorial, I carried on cobbling features onto it whenever I learned something new (the starfield was inspired by Mr Speaker for example).
On Friday I released my HTML5 Breakout game as an easter egg on the homepage of my freelance HTML5 game development site. The feedback I got though, was that it was such a well hidden easter egg that few people were ever going to see it! That would be a real shame, so I’ve given it it’s own demo page.
It uses the Canvas and Audio APIs, a bit of CSS3, and PHP/MySQL (with JSON output) for the back end. I’m still tacking on new features – I’m working on powerups and laser cannons at the moment, but I thought I’d put it up for people to have a play with.
Lessons Learned
The Audio API is still in a bad state. Remy Sharp’s Audio Sprites tutorial was a big help (only after I spent a couple of hours banging my head against the wall, mind…), but my implementation is far from perfect and still needs work. Which is ironic really, because I could say exactly the same thing about the entire Audio API. The implementation is currently quite fragmented, and some browsers support features that others don’t. For example, Firefox 4 doesn’t currently support the ‘loop’ property – you have to listen for the ‘ended’ event, set the currentTime to zero, and then set the audio to play.
Matters aren’t helped by the fact that browser vendors can’t agree on a universal audio format. Google, Mozilla and Opera have implemented open source codecs (OGG Vorbis/WebM), and Safari and Microsoft will be sticking with proprietary formats (MPEG, H.264), which means that we currently need at least two source files for each piece of audio we want to put on a web page. Better add Audacity to that ever-growing list of software to learn.
Premature optimisation is the root of all evil. I spent a lot of time just undoing changes that, at the time, made sense; but later on, became performance issues or bugs. For example, doing a left bitwise shift on x/y coordinates of the ball (for pixel snapping purposes – read Seb Lee-Delisle’s Sprite Optimisation post for more details) caused a few problems with collision detection later on. I’ve removed most of these optimisations for the time being, as the game is still in development. The best thing you can do during development is to just follow good coding practices – store references in a variable if you’re using them more than once, don’t set things like fillStyles in a loop if you can do it outside of a loop, etc. A really good book to read on this is High Performance JavaScript
Game development is time consuming. This game was cobbled together over the course of a few months, and it’s not even finished! I think the reason that we haven’t seen anything particularly mind-blowing in the HTML5/WebGL game department yet is that it takes a long time to get a project into a playable state if you build it from the ground up – especially if you’re the only person working on it. (Did you see the production crew on ro.me? The list was a mile long! Wonder what the budget was…) There isn’t a great deal of choice in middleware/game engines yet, and projects that did look promising were snapped up by development studios (Aves by Zynga, Rocketpack by Disney…)
I’m really interested in the future of browser games, and of JavaScript games in particular. I plan to make a whole bunch more of them, but writing them from scratch would prove time consuming. It’s really tempting to fall victim to NIH (Not Invented Here) Syndrome when you’re a developer, but there’s enough work to do in building a game without having to write your own engine first. After all, if you needed a blogging engine, would you write your own, or use WordPress? Look forward to my next project, built with ImpactJS 🙂
Update 31/05/11: HTML5 Breakout now has lasers and marginally less crappy sfx. I also forgot to mention, the graphics and sfx were created by me (can’t you tell? :p) and the music is from AudioJungle. If there are any artists out there who would like to make a game and wouldn’t mind dealing with the artistically challenged, please tweet me!