Follow the path with your mouse in this easy to pick up casual game. As you progress, Eric’s adventures unfold before your eyes. Can you get through all six scenes? Downloadable rewards await those who can.
Whilst this is a postmortem for the game Adventurous Eric, it focusses mainly on migrating from Flash 8 to CS4. The project was undertaken as a learning exercise, and as an experiment to whether it’s the right time to move production to AS3.
Adventurous Eric was my first proper outing in AS3. I’ve been putting off using AS3 for several years, partly because I keep getting AS2 jobs and partly because of the absurdity of the gotoAndStop issue. Yes, there’s a workaround, but it’s way too ugly to even consider using. With the advent of Flash Player 10 and Flash CS4 however, this disasterous bit of language design has been fixed, so I thought I’d give it another look.
The Adventurous Eric game isn’t complex. It doesn’t really require any of CS4 or AS3′s much touted new features. I could throw the underlying code together in AS2 in just a few hours, and it’d work perfectly. Obviously there’s rather more work in the illustration, animation and animation.
I picked the core mechanic of a mouse maze precisely because of these reasons. I wanted a project where I could discover the new ways of doing the stuff I can already do in Flash 8, but in the new CS4 tools. It needed to be simple so I could do it quickly. It needed to be timeline and animation heavy, because those are essential tools (and an apparent weak point of AS3). It needed to be a complete polished game, so that it had everything a bigger project would need. It had to have sound, game-sync’d music, independent mute buttons, transitions, a sitelock and embed test, tracking, external link buttons and so on.
The idea was to build this simple game in a few days whilst learning the pitfalls of doing a real actual project. It’s all very well learning from a book, but all the examples work already, and they’re deliberately short so they’re focussed on the topic at hand. That’s nothing like a real-world project though, hence my building a full complete game, albeit a short one.
The biggest language issues were all to do with integration with the timeline. Nothing executes in the order you’d expect coming from an AS2 background. For example, early on I was building the equivelent of an onEnterFrame handler. If I put my code in ENTER_FRAME, items that were newly instantiated on-stage in that frame weren’t available yet. If they needed some sort of initialisation (say, hit areas have to be made invisible), you wouldn’t see them in code until the following frame, but they’d appear on stage earlier. Fair enough I thought, I’ll put the code in the new EXIT_FRAME event instead then, which executes after new items have been made available to the code. That was fine for a while, until I did a gotoAndStop from within that event. That caused an infinite recursion, since jumping to another frame caused another EXIT_FRAME within that handler, which cased another gotoAndStop… Then I tried FRAME_CONSTRUCTED, RENDER and so on. I had similar issues with all of them. Eventually I hacked together a sort of frankenstein’s onEnterFrame made from several of the events with flags to say which ones had run already. This is deeply unsatisfying, and I’m going to have to look at this issue further if I do another AS3 project. Ironically, the best emulation of a working onEnterFrame event I’ve thought of so far is two timeline frames running around in a gotoAndPlay loop. Hardly elegant, but it seems to cover all the issues!
Now, issues like that are to be expected, but they cost time. I was hoping I’d solve a few biggies like that in this project, then be fine in the future. This doesn’t seem to be the case though, and I found myself constantly fighting some obscure issue that just wouldn’t have been a problem in AS2. It makes it difficult to imagine taking on a nontrivial commercial AS3 project, with the potential for horriffic weird issues stealing unpredictable chunks of the budget. This can happen on any software project of course, but AS3 seems so prone to this kind of thing.
Then there’s the natural lanaguage strictness to battle. I know some people love strictness in their programming languages, but I don’t. Certainly not for a creative expressive language anyway. The language and tools should flow like a liquid with your imagination. If you find yourself fighting the tools, that’s brain-load that you’re not committing to your project. It’s stifling you. Suffocating you.
Plus, everything in AS3 just takes longer. Classes are more wordy to write. Definitions are longer and more complicated. Want to try out a quick hack to see if something is worth building in properly? Well you can’t, there are no quick hacks. If you don’t do things properly then the compiler will throw a hissy fit and refuse to build your SWF. I’m all for cleanliness in code, but sometimes it’s great to just hack something quick and easy to see what effect it has. This might even be as simple as removing something to test if performance improves. In AS2 we can usually just guide the layer on stage, change the instance name or whatever and it’ll all still run. In AS3 you’ll get a runtime exception and your code will stop executing entirely.
Then there are the bugs with the IDE. CS4 crashes a lot more than Flash 8 did, which is inexcusable. It is slower and less responsive to use too. Plus the windows don’t always redraw properly, and menus sometimes vanish whilst you’re looking at them. Related, timeline scrubbing often just stops updating the stage view. Windows dock to anything and everything except what you want, then appear above or below things and won’t re-order. One particularly annoying one is when the actions window simply refuses to live at a lower depth than the running SWF. You’d think the most basic quality testing at Adobe would have discovered and fixed these issues, but no. Distribute to layers STILL crashes the IDE (which has been true since I started using Flash), and there’s STILL the bug where the IDE will crash if you close your test movie while there’s an outstanding HTTP request. I had weird issues with duplicate-movieclip too, where the screen would show both original and duplicate changing together when edited. Restart Flash however and they actually retained their separation correctly. Most strange. I had another similar issue with dragging frames around, and the contents getting obliterated. These are Flash basics! If these don’t work, frankly the entire tool is worthless.
Even if it were totally bug-free, the whole IDE is less usable now. The repositioning of everything is bad enough (like when they move all the isles around at the supermarket), but some things just can’t be made nice anymore. On my frankly generous sized screen, I can’t get the full properties panel in view at once for textfields. The filters require a scroll to show. The filters themselves are fiddly to configure as well too.
There are improvements as well mind. CS4 is a huge leap beyond CS3. I’m impressed that it’s changed this much and yet my own JSFL hacks still work (and they really are hacks – I never bothered to learn JFSL properly and just bash it with a hammer ’til it kinda works). Library search is nice, and show-in-library is a feature we’ve been hankering after for years.
These little niceties just aren’t anything like enough to make it worth upgrading though. The real torment of it all is that in Flash 8, all this stuff just worked and now it doesn’t.
Imagine Ford came up with a new family car that does 5mpg more than the old one. Sure, given the choice you should use it over the old one, right? Oh, but you do have to manually wind this little handle by the gearstick all the time while you’re driving. And the steering is done with pedals now. Yeah, the big round thing in front of you is the clutch, and we found that headlights are just an inefficient waste of energy so there aren’t any.
There are many good reasons to use AS3. You might want to use one of the amazing free libraries like Box2D, Away3D or JigLib. Uou might be freelancing for a company that has already moved to AS3. Alternatively you might be working on a big app with strict standards and lots of people all coding together. AS3′s stricter environment would make lots more sense then and will likely lead to cleaner code that’s easier to maintain.
End users don’t care about code clenliness though. They don’t care about language structure or how beautiful your core framework is. What they care about is finished products that they can use. AS3 doesn’t deliver finished products at anything like the rate AS2 does. For that reason alone, AS2 shouldn’t be abandoned by anyone who finds AS3 a struggle.
Don’t let anyone make you feel stupid about it. Don’t allow people to tell you that you just don’t get it, or that it’s frustrating to migrate but we all have to do it. Don’t be pursuaded that your old technique that worked a treat just isn’t how it’s done anymore. Demand a demonstration of how the new technique is better. Either it’s less work or it produces better results that are worth the extra effort. If you’re not pursuaded, stick the stuff you know works.
I’m not pursuaded.