Workflow for large Flash / AS3 projects

Question

I am currently working on a fairly large UI heavy flash game. Our team has been working on this for about 9 months. None of us had previous experience with Flash, so we are constantly improving our workflows during this time. Nevertheless, we still believe that what we are doing now is not optimal, especially the interface between encoders and artists, so I wonder how other teams work.

An ideal workflow must meet the following requirements:

1. Reusable user interface elements are defined only once.

This means that if we want to change the font or style of the button, we do not want to go through all of our menus and change them manually. We want them to be defined in one central place and only sent from there. Bonus points if assets are distributed not only during editing, but also during execution, that is, they are loaded only once.

2. Everything loads on demand

We currently have two different loading steps: first, we load the menu libraries. When this is done, players can already interact with all the menus. Then we start loading the actual gameplay data. The initial loading time is still too long and makes us lose a lot of potential players. We really want to load only the minimum minimum necessary for the main menu, and then download everything else only when the player is trying to actually open the corresponding menu. Zuma Blitz does it really well.

3. Artists may make minor changes without the help of coders.

If the menu needs to be redesigned without changing the actual functionality, artists can do it themselves in Flash CS6. This requires a clear interface between art and code, and artists must also check and debug their changes before sending them to the encoders.

-

Our current workflow looks like this: an artist creates screens in the role of MovieClips in Flash CS6 and exports them as SWF. On the code side, download MovieClips from the SWF screens and use them as View classes on our PureMVC-based system. Mediators gain access to elements, such as text fields in views, by their instance names.

This is error prone because there is no central place to define an interface (i.e. instance names). It takes a lot of communication overhead between the coder and the artist. In addition, it creates a relationship between the code and the internal structure of the movie clip. Artists cannot attach a text box to another submodule when they want to apply some effects to it.

We are experimenting with an event-based interface that requires an artist to add a few lines of code to a movie clip. This is less error prone and interdependent than before, but it still does not fully satisfy (3), unless we write additional tools for testing and debugging. This should be a common problem, and I cannot imagine that there is no simpler way.

For (2) we also began to build a home solution, but again, this is such a common task, there should already be something that we can use.

So, how do experienced Flash developers manage such large projects?

Answer 1

I have some thoughts, but they are based on my coding style, which is unique to me.

1. Reusable user interface elements are defined only once.
Depending on what you reuse, it may be as simple as defining a library symbol and just using it. Fonts can be replaced without searching and replacing, and you can also simply replace the font in the Font Embedding menu.

For sharing via xfls, you can use the Flash Pro project . Keep in mind that there is a certain amount of time (files will be updated when you open or save them, Flash will work more with projects, and it might be a bad idea to try working with two files from the same project at once).

Some people use swcs, but this requires you to instantiate things in it in code, which may not work for your workflow. I use them only for audio, and I believe that the objects in it should be compiled on or in front of the frame that you designate as an AS compilation frame, or the sound cannot be created correctly. I suspect this will be the case for anything created using swc.

2. Everything loads on demand
One of the best secrets of Flash is that it is very easy to do using a timeline and an educated use of compliment. Here's how it works:

If your compiled ActionScript frame is a frame larger than 1, here is how it will be compiled:

• Before frame 1:
  • Any visual objects and embedded sounds used in the frame 1
  • Your main class of documents, as well as any classes directly related to the class of the document (which is a good reason for code on interfaces).
• Before creating the AS (N) cascade:
  • Your AS classes (code, not necessarily visual / audio assets)
  • Visual and audio resources for any library symbols set to export for AS in frame N (even if they are not used in swf)
• Until the asset is first used on the timeline:
  • Visual / audio assets in all library symbols where Export for AS was not exported in frame N.

If you put a graphic using spinner in frame 1, and you selected frame 10 as your export frame, then if you just allow the movie to be shown until it reaches frame 10, here's how it loads:

• If you have any heavy assets on your counter or are directly indicated in your main document class, users will see a blank screen while this file uploads
• The counter will become visible and begin to rotate.
• Once your AS classes have loaded with the library symbols set for export in frame 10 and the assets that are actually in frame 10, you will see these assets, and everything you need to use will be ready.
• The rest of swf will continue to load in the background, updating framesLoaded .

Actually, I am using a setter combination for an object that is on frame 10, plus the ENTER_FRAME handler to check if we are still on frame 10. There are certain things that I have to do that are easier based on one and the others that work better, to make another way.

3. Artists may make minor changes without the help of coders.
If the code is in the base class for the library symbol, the artists do not need to understand it unless they delete or change the name of the required instance. I try to minimize dependency on instance names by observing ADDED_TO_STAGE (capture phase) and observing the display of objects by type. Once I have a reference to an object of the appropriate type, just watching REMOVED_FROM_STAGE on that object is enough to dereference it. This is similar to how features like RobotLegs and Swiz work.

In addition, I use a concept that I call "Semantic Flash", where I do a lot based on tags. I have a base class, FrameLabelCip, which has the built-in functions nextLabel () and previousLabel (), as well as dispatching events FRAME_LABEL_CONSTRUCTED . It’s very easy to go from the name of the storyboard event to the name of the Flash shortcut and just build the bang-bang-bang graphics.

I use Graphic Symbols to synchronize graphics on multiple labels (e.g. with bulleted lists) instead of relying on code. This animator trick makes these things reliable and affordable for less technical teammates.