Over the last few weeks at work I have been head down involved with building a fun HTML5 game for EMI titled ‘Way Out Wars’.
Way Out Wars is a fun game for casual gamers, and provides the much sought after challenge for veterans of the ‘space chicken music discovery typing shoot ‘em up’ genre. The game was built in pure HTML5, with some heavily modified impactjs as the core engine. Lots of long hours spent tuning nanoseconds off particle render times.
My best is 75 tracks back to back for around 44 million. Go play it at http://www.wayoutwars.com … preferably before reading the rest of this post to give insight.
Some things achieved in HTML5 that were pretty cool:
- Real time usable particle effects engine we had to dumb down because it was just looking too busy (yet awesome). At one stage we had smoke, jets, trails, explosions, musical notes, and swarms. Unfortunately you couldn’t see the game.
- Infinite playlist – Depending on your browser, since Chrome mysteriously dies
- Music discovery that’s fun – Songs you hate, songs you like and songs you don’t know, that you can review and purchase.
Some pleasant discoveries:
- HTML5 rocks. It’s definitely a platform for the future, however it’s not necessarily the be all and end all. But the game has no browser dependent coding. It does however have code that checks for issues that may occur in some browsers, there isn’t any code that goes ‘if IE do this, if FF do that’.
NOTE: This does happen for audio however since Firefox hates MP3.
- Impactjs rocks! In the end we probably didn’t need it as much as we thought, but it did so much heavy lifting in the beginning it allowed us to experiment and play around with ideas. We simply wouldn’t have had a product as far advanced without it.
- HTML5 benchmarks don’t coincide with real world scenarios. Simply ignore them until real world tests turn up. Every benchmark I do IE9 doesn’t come out on top, but all of our experience with the game has been IE9 is way out on front, with no IE9 specific tuning in sight. Someone who is familiar with graphics pipelines who understands the concepts behind draw calls, fill rate etc. needs to give HTML5 the same treatment.
- As such, IE9 rocked, and we were pleasantly surprised.
- Opera is amazing, although I’ll probably still never use it. It came in 2nd performance and stability wise.
- Firefox and Safari were stable, however their performance lacked.
- Chrome was fast, however it’s stability lacked.
- Hardware acceleration rocks. Browsers without it will die slowly as user experience becomes encumbered by poor performance.
- The iPad did load it once, but it got too big for it. This however is promising for HTML5 moving forward when the processing power of these devices steps up.
Some discoveries that were as fun as being jettisoned into the sun by space chickens:
- Having lots of <audio> elements on a page can cause issues. Clean them up, delete them, and do everything you can to remove any trace of them. This was common for all browsers, with the impact having different results in each. But cleaning up the audio elements makes all the browsers behave. And whilst Chrome will still go silent after about 100 songs, without doing this it will crash after 57.
- Oh, and be careful deleting i.e. ‘delete obj;’ audio objects in Chrome, you can crash the browser and all open Chrome windows will stop working. I think Chrome tries to do garbage collection on audio elements no longer in use. A quick check ‘if(obj != null) delete obj;’ tends to be stable.
- Any browser that doesn’t support MP3 needs to fix that. It is a bug, not a feature. If every music site in the world has to re-encode their audio to OGG, they will ignore browsers that require it, or simply be ignorant to it. Firefox needs to wake up. Media companies are going to be staring at mobile devices, and Firefox is the last thing their IE and Safari based offices will test in.
- Firefox 3 is antique, Firefox 4 feels like a classic, that still goes well, but won’t keep up for long. A shame. This feels like a Firefox bash, but it has just been the reality we’ve been dealing with.
- Chromes instability. Chrome is fast, yet buggy. We discovered a critical error that would happen on the 57th track crashing Chrome. After writing a universal piece of code that wouldn’t crash Chrome, we found that at some point, chrome refuses to play audio, and kills audio across all chrome tabs and windows, with no error message. This came as a surprise to me, and over the coarse of 3 weeks Chrome has been superseded by IE9 now as my default.
- Safari underperformed. Of the big names it was the worst performer.