The Software Purist |

TAG | FLA

Nov/09

16

Flash and FLA Structure

So, recently I have been working with Adobe Flash, working on my first multiplayer Flash game. I normally have been focusing on the server-side of these sorts of games, but this time I get to work on both sides of the puzzle, which I am very excited about. I can’t provide any particular details about the project, but it is an interesting project, nonetheless. With that said, I ran into some caveats with the design of Flash FLAs, that I would like to talk about.

Introduction to the Problem

The first thing to note is that I made a branch from a single player version of this game, which still also has some changes which occur from time to time. When I made my code changes, I hadn’t realized how the art was embedded in the FLAs. Artists sometimes have the habit of directly embedding images in the FLA and not providing the actual source image. Furthermore, all of the UI changes that you would normally find in some sort of an external resource file is embedded directly in the FLA structure. Finally, the FLA format is binary and not published.

Because of these facts that I mentioned, when I went to merge my FLA with the one from the trunk, they were conflicted, with no mechanism for resolution. I had a discussion with some people and everyone lamented that Adobe had intentionally decided not to open up the FLA format.

Alleviating the Problem

After some more discussions, it became clear that there are a few things to help out the problem. The first is better communication between programmers and artists about what is actually being changed. Oftentimes, people make changes and don’t really communicate with each other well enough, and so each cog knows their piece, but perhaps not what other people’s pieces are. This is just a general thing and not limited to Flash, but certainly is worsened by the unfortunate design of Flash FLAs.

Another idea has to do with Flash SWC modules. Flash SWC modules are analogous to your typical C++ style static library (e.g.: .lib on Windows compilers or .a on Unix). Flash SWC modules give you a means to distribute both your compiled code and your GUI code into different modules. This makes a lot of sense to me. It’s more work upfront, but by using the Flash SWC modules, you can distribute different UI screens and panels to having owners, which I think is much more reasonable and makes the merging much easier. Of course, it doesn’t fix the problem, but it certainly turns a disaster of a problem into a more managable one.

If you have any more tips about how to streamline this process or any information about whether this may become more maintainable in CS5, I think that would be very interesting. Please let me know your thoughts.

Sources:
http://www.communitymx.com/content/article.cfm?cid=dc2c0

· · · ·

Theme Design by devolux.nh2.me