As I look ahead to this year, I have several posts planned around game development in ActionScript 3 (Flash). So, I thought I should post a brief explanation about why I’m STILL developing games in AS3. After all, isn’t Flash dead? Aren’t we all living in a brave, new HTML5 world? Here are a few of the reasons why I’m developing in AS3:
As of this post, HTML5 <canvas> support is still inconsistent across major browsers. Admittedly, the main issue is Internet Explorer, but they still have a HUGE market share and can’t be completely ignored. For most of our <canvas> projects at work, we still end up building a Flash backup. If you’re targeting desktop devices for your games, publishing to Flash gives you a bigger market share than HTML5 <canvas>.
HTML5 <audio> support is pitiful. In some browsers (*cough* Mobile Safari *cough*), it barely works at all. Then there are issues with preloading sounds so they are actually available when you need them. A lot of game developers spend a lot of time working around HTML5 <audio> issues and a lot of “HTML5” games actually use a small Flash movie to handle the sound. If I need Flash anyway, I’d rather build everything in AS3. There are several good JavaScript libraries to help with this stuff. I recommend Grant Skinner’s SoundJS.
Even if you aren’t using <canvas> or <audio> elements, you’re still relying on JavaScript for all of your game code. JavaScript implementation is also inconsistent across browsers. Technically, Internet Explorer doesn’t use JavaScript – it uses a dialect called JScript, which is supposedly the same thing, but it isn’t. The primary goal of jQuery, after all, is to help developers iron out those inconsistencies. If you need to use a function that isn’t fully supported in all browsers, like requestAnimationFrame(), you’ll have to use a polyfill to make it work across all browsers. Polyfills are inherently slower than native functions, so they can create performance issues.
Speaking of performance, JavaScript is slower than ActionScript. I’m sure that this point is debatable, but properly optimized AS3 will generally run faster than optimized JavaScript. AS3 is compiled into bytecode, which is run in the Flash Player (a virtual machine, like Java). JavaScript is directly interpreted directly by the browser at runtime, so it is simply slower. A lot of smart people are finding ways around this issue (Google’s V8 JS engine for example), but it’s still a problem for most browsers.
Flash has been the industry leader for nearly a decade, so there are a lot of very mature open-source libraries to make coding in Actionscript easier. For animation, there are several tweening libraries. For game development, there are some really solid game engines. Very little of this exists for JavaScript. Again, people are working on it, but I have seen very little that wows me so far. Having said that, here are 2 projects That I’m pretty excited about:
- CreateJS – a large set of JavaScript libraries to aid you with asset loading, <canvas> animation, and <audio> handling. EaselJS actually mimics the ActionScript display list, making <canvas> a whole lot easier to deal with. If you are dipping your toe into <canvas>, this is a great place to start.
- Kiwi.js – This one hasn’t been publicly released yet, but it’s being developed by a top-notch game developer and it’s based on the amazing Flixel Actionscript game engine. I’ve been unimpressed with the other JavaScript game engines I’ve seen, but I can’t wait to dig into this one.
Last, developing in AS3 is easier for me right now. I’m very familiar with the language and the structure. JavaScript makes me nuts with it’s dynamic typing (or lack of typing, depending on how you look at it), lack of class structure, weird variable scoping, and other quirks. I prefer a strongly-typed language with classes.
So, for now, I am still building games in ActionScript. I look forward to the day when I can dive head-first into JavaScript game development, but the tools and implementation need to improve a bit more. This way, I can spend more time refining game mechanics and less time fighting with the shortcomings of bleeding edge tech.
Aristo
There is simply no way Javascript is ready to broach flash on game dev.
Adobe has decided that ALL their resources on flash are going into game dev – the latest iteration of flash 11.6 is basically c++ in the browser via flascc – (Alchemy).
In other words – javascript is to flash what dirt is graphene.
Google – along with everyone else – has realised that Javascript is completely dead end, without classes and strong types etc it can never work – ever – hence Native Clients etc –
Think about it for minute – why do we even NEED the browser anymore ?
We don’t.
erik
I’m still LOL’ing at Aristo’s comments.
wow.
Simon
To me the thing that sums up how much of a bad joke HTML5 is for games, is the sound support. The fact that all but the newest iOS devices will not play 2 sounds at once (so you have to stop any background music to play the sound, then restart the background music) is nothing short of laughable. Then you’ve got the problem of only being able to play sounds on touch events. So if you have some sort of shooting game for instance, there can be a sound when you release the projectile (touch event) but your impact/explosion has to be silent!! These things are fundamental to how it’s implemented on mobile devices, so I doubt they’ll ever change.
Exposure of assets is a huge issue as well. This “open web” nonsense is ridiculous. Do these people not realise how music licensing works for instance? You license music for a project only, under strict conditions. With HTML5 you’re effectively freely distributing that music, not just using it in a single project. This is either going land a lot of developers in legal trouble, or send licensing fees through the roof.
This is without taking into account the fact that all browser developers are pulling in completely different directions (as they have been for well over a decade). So getting anything to work even remotely consistently becomes one big ugly hack after another.
Then you’ve got the shortcomings of the underlying platform itself. Everyone’s touting it as “state-of-the-art” and the future, when it’s actually firmly rooted in the past. All they’ve done is add a layer of (broken) audio and graphics support on top of a positively antiquated (in tech terms) platform. For this to be even remotely viable they needed to design it from scratch, from the ground up, not just add a few bits of extra functionality to the quite frankly awful and already broken HTML+CSS+Javascript combo. The words polish and turd spring to mind.
In 20 years of developing games on various platforms, going right back to the Commodore Amiga, I can honestly say HTML5 is by an aboslute mile the worst, most glitchy, worst supported platform I’ve ever worked with.
And finally, I’m not seeing any conclusive proof that people are even interested in playing (glitchy) games on their mobile devices via their browser. Why would anyone, when native apps have none of these issues? Many average users don’t even know it’s possible to play browser games on a mobile device.
You have to respect Steve Jobs sales skills. How he managed to get so many to buy into the notion that they should be ditching Flash (a great platform for complex multimedia applications such as games for desktop browsers), in favour of a horrible platform that’s not even ready and likely never will be. At this point, it’s not even as good as Flash was 10 years ago!
HTML5’s slogan should be “take twice as long and spend twice as much to do something half as good”.