Monday, September 21, 2009

Flash CS4 and Large Projects

Over on Jobe Makar's blog, he posted about a bug with Flash CS3 and CS4 which prevents the Flash IDE from being able to compile large projects. Adobe spent a lot of time and effort working with him to resolve the issue, and for them it's fixed, but unfortunately the problem is not completely gone.

Background

Here at Gabob, we've had a long history with this bug (the "invisible ceiling"), which has existed since at least Flash 8, when we first started using Flash in the Spring of 2007. After running into it with our first non-game project, we decided to reevaluate our company's direction and go a different route (which was good).

In July of 2008 we hit the ceiling again during the final stages of development for our first big Flash game, Now Boarding. After scouring the internet and finding nothing, we called Adobe, and their official answer was to split the project into more than one swf.

After a week of completely restructuring our project, I split it into 3 swfs, and we were able to move forward from there. Because the game's original design was not particularly suited to splitting the code up, one of the swfs had most of the game's code in it. But I had removed enough code and assets for it to build.

Following the split, we finished the game, shipped it, added a bunch more content for our 1.1 release, shipped that, and then wanted to add some more later.

By now it was January 2009 (after Adobe's 11/17 CS4 update), and we finally decided to buy CS4. I bought it, downloaded it, downloaded the updates, installed everything, and I couldn't build the big swf of the 3 Now Boarding swfs. I could still build it in CS3, so I just continued using CS3 for NB work.

We added more content, then CS3 stopped building it. This time, I scoured the internet again and finally found other people with this problem. Using the java heap trick, CS3 and CS4 both built the game. We added more content, a new map, some new little features, some bug fixes, etc. and then we hit the ceiling again. This was using Flash CS4 with the 11/17 update.

Experiments with Flex

All the posts and blogs I could find on the internet about this issue were about the Flash authoring tool. Flex didn't seem to have this problem, or at least no one had run into it that I could find. I figured if I could put all the code into one swf and use Flex Builder to compile it, then I might not have to deal with this problem ever again.

So I downloaded FB3, started up the trial, made a couple test projects to test how I could use Flash CS4 for all the library symbols we had created and keep all the code in a FB3 ActionScript project. I won't go into all the gory details, but the plan was roughly to decouple all library symbols from .as files by renaming all exported symbols in the fla's (I just appended "MC" to the symbol's class name) and then change all the .as files to instantiate the corresponding *MC object and add it as a child. The fla's would be compiled into swc's which FB3 would import and compile into the code project.

After 2 days of tedious code restructuring, I had a final, single swf built by FB3 that had all kinds of problems. I ended up solving most of them, but some inexplicable problems remained. I then spent another day getting rid of the swcs and just loading the swfs built from the fla's dynamically using the Loader object. Loaded dynamically like that, everything worked correctly.

Our game is still 3 swfs, but ALL code is in one, and that one is built by FB3. One of the original 3 swfs contained only trivial symbols (no timeline code, not even multiple frames, just music, sounds, and images), and those worked fine as a swc, so that one is combined with the FB3 AS project as one swf.

Conclusion

While the journey has been extremely painful, I am very happy with how things are working now. Here are some benefits:

- FB3's compiler is so much faster. Since they contain no code, I don't have to rebuild the fla's very often, so now instead of waiting 2 minutes for Flash to compile in order to try out the changes I just made, it only takes a few seconds (literally just a few seconds).

- FB3 is designed for coding. Flash CS4 is not. I still use gvim for most of my work, but FB3 has nice refactoring tools and a profiler (but the profiler does work on any swf, not just FB projects, so I benefited from it even before this last restructuring).

Remaining Issues

1. There is definitely a problem with library symbols imported from swcs. The symbols that don't work when in a swc but DO work when loaded from an external swf have animations and timeline code. Some of them work, some of them don't. Symbols with no animations or timeline code work fine in a swc.

2. Flash CS4 is targeted (I assume) at movie-makers and developers of small games and other small interactive projects. Flex Builder 3 is targeted at developers of RIA's. Both cost $699 (the profiler is in the pro FB version, and that's essential for large projects). The majority (I assume) of developers who target the Flash player only need one of them and just buy the one they need. Developers of large games need both, so we have to spend twice as much. It'd be nice to have both CS4 and FB3 licensed together in a cheaper package. As it stands, CS4 and FB3 together are only $100 less than Unity Pro, which by many (but not all) standards is better for larger-scale game development...and which now has a Windows IDE.

No comments:

Post a Comment