Flash - managing a large project

Question

We prototype using Autodesk Scaleform and create a game user interface using Flash. We will need to launch a large project with a team of 3-4 artists and 10+ programmers. We use Perforce's source control system to store all code and assets. We need to be able to manage a project with several shared resources and several people (artists and programmers) working on screens and controls.

Our problem is as follows:

We want to be able to create hidden graphical user components, such as buttons, sliders, check boxes, as well as more complex controls, such as tables and game-related elements. We want to be able to exchange graphic resources in one place and allow several artists and code devices to work on shared components at the same time. We need all this to be stored in the Perforce version control repository.

For AS3 code, all this is pretty straight forward. It works like any other code base, and we created the FlashBuilder and FlashDevelop projects.

Now the parameters are as follows:

• Create a Flash project or projects. The problem here is that all assets are copied to AuthortimeSharedAssts.fla. This means that since FLA is a binary format, our control source cannot allow multiple individual users to edit any shared resource at the same time.

• Set up sharing autorun manually. This will allow you to work with several shared components, as individual users can update a small discrete FLA file, and this will automatically update a large shared library file. The problem is that this does not allow the use of graphic resources, which means that if the artist updates the graphics, it does not filter individual flash files.

• Use the XFL format. This will allow us to merge the files when checking the source control, since they are plain text and it saves individual assets as separate files, which looks perfect. The problem is that I don’t see how to create a project that makes full use of XFL files (i.e. does something like AuthortimeSharedAssets.xfl).

At the moment, I do not see any obvious, reasonable way to launch a large project in Flash. We cannot be the first to do this.

Can someone help or explain how we should do this?

Answer 1

I would say that XFL is the way to such a large team, especially when using source control.

As far as I know, most characters for XFL are saved as .xml in the LIBRARY folder. If they are imported jpg or other bitmap images, then the real image file is also saved.

I could not embed the fonts and save them in this format, but this can be a big problem depending on what you are doing. The solution to this is to dynamically load your fonts, as discussed here . This may be a slight inconvenience for designers, but the small price you pay when you consider what you get using the XFL format when so many people participate in the project.

I also recommend pre-compiling (creating components) specific parts of your project.

I hope this helps.

Answer 2

This may not be an option for your team, but I suggest how it was (in my experience) a very successful approach to project management.

When you make a large selection of department infrastructure like this, it pays to get into the weeds and see the problems you're trying to get away with. However, do not forget about my explanations here.

The main obstacles that you have are: 1) locking and editing large FLA files that cannot be merged, and 2) preventing duplicate / version of MovieClips and classes conflicts inside these files. Conflicts can be authortime (FLAs that have obsolete library symbols from offline shared libraries) or executable files (SWF compiled with conflicting versions of the same classes, which leads to runtime crashes).

The solution, in my experience, is to 1) put as little code as possible in binary files (FLA), 2) associate the class code with MovieClips as late as possible, and 3) write the application code for this “late binding” elegantly. This means using runtime libraries, not authortime. I would not try solutions that consider binary files as text to merge; instead, minimize and isolate the FLA role they play in your code. Keep them separate.

If at all possible, I would recommend your team use the following strategy:

• In your production (non-library) FLA, work with the "view" MovieClips. "Viewing" clips is all art and animation; they do not have class bindings and as little code as possible. For example, if your artist can add a BouncingBall symbol to a scene with a binding to BouncingBall.as, instead they add a BouncingBallView without binding (the generated class name is BouncingBallView with the base class MovieClip).
• In your library's SWF libraries (which may be pure AS), write mediation classes to wrap these views. Intermediaries "wrap" instances of "View Clips" at run time, exposing the properties of the view object for the rest of the application and acting effectively like binding a library class. For example, you should write BouncingBallMediator.as instead of BouncingBall.as, and in this Mediator class you put all your application logic for bouncing balls.
• Configure the application to load SWF libraries at runtime with all your classes (e.g. BouncingBallMediator). Then, when a BouncingBallView instance appears on the scene, your application creates a new BouncingBallMediator instance and assigns it a BouncingBallView object. This successfully separates the view (MovieClip library symbol) from its control logic (in the class file BouncingBall.as). This removes the unnecessary baggage of class references to the FLA file.

This approach has many advantages, but in a nutshell it allows your developers and your artists to work independently, with less concern for version control conflicts between class and art files. Artists never work with FLAs for which code and developers have the control they need to minimize the likelihood of duplicate / conflicting class definitions in SWF. Everyone can focus more on what they do best.

The projects that I worked on with this approach, as a rule, go very well, while the lead developer on the steering wheel analyzes the decoupling strategy I'm talking about. Apologies for the overwhelming answer; NTN.

Answer 3

There are several more options. I'm not saying that they are better, but depending on your team and how much you can invest in developing your own development tools ... OK, here is the SWFMill port on HaXe: http://code.google.com/p/hxswfml / . This allows you to display graphic objects in the form of text (XML) files. Perhaps it would be possible to add a plugin for Incscape to export graphics in this format ... Then I think that these people had their own format and tools for managing visual materials. The Flex SDK compiler can actually convert SVG to flash graphics.

Finally, and most likely the option that I would explore, I would have had enough time, this is the FXG format. The Flex compiler can compile it, however, it still needs some correction to remove all infrastructure-related Flex frames from what comes out of the FXG. The advantage of FXG is that programs such as Photoshop, Illustrator, Indesign, etc., can be exported to this format. Of course, this is mostly untested ... and at some point I fear that FXG was developed for an Adobe product that has recently been suspended (Catalyst). However, there is a chance that the format will remain an exchange format for Adobe programs, so you will not need to check the FLA.

How I work with graphic artists: we never check the FLA, instead we check the SWC and make it a rule that someone who works on a project needs to check it and import it. This does not help when more than one person needs to work on the same symbol, but at least they are all in one place, and you can work at the same time if you are editing different things (which happens in most cases, time anyway )

Answer 4

I cannot recommend sharing Authortime since I was not able to use all components from several swc in my project. The reason is that a few days of research is rather strange.

At least one component (for example, a dialog) always throws Type-Errors when it uses common components for autorun (for example, a button), and the common component has the name instancename. Everything works fine until you assign any names to the common components in the components that you linked using ActionScript and create them later in your project.

The goal was to split the massive * fla into several smaller ones, dividing the resources into authortime, so the changes are split between the fragmented smaller fla and the compiler (rather than runtime!), Not duplicating these classes. This works great, even with widespread use of actionscript links and custom base classes. (deactivate automatically declare instances of the scene, though). The compiler successfully eliminates all duplicate classes caused by sharing. You can control that it is easy to look at every included swc.

To just reproduce the problem, you need to make 2 bottles. each of which has a movie clip (for example, a dialogue) and a common one. (for example, a button, one button shares the button with another). Assign all actionscript-linkage components. Place a button in each of the dialog boxes and set each of the buttons to instancename. Compile both fla and swcs, include them in your project and try installing both dialog boxes. One of them is going to throw # 1034 Type Coercion Error. Remove (one of) the instancenames button and it will work.

To get an impression - heres screenshot (full size):

My guess is that as long as no instancename is installed, flash does not care what type of button it really is, and treats it as a movie clip, but when instancename is installed, the player tries to map the movie clip to the specified type. But for some reason it does not consider the entire namespace (?), But only in swc the dialog was compiled. I conclude this because when the button was compiled in swcA, but not in swcB, the dialog from swcA works, but not the dialogue from B and vice versa. You can force the swap swc button to recompile the fla in which you want the button to be pressed.

I also ran it in rare cases involving no more than 2 fla / swc. But I have no idea why. Maybe I'm investigating a bit, but I have already spent a lot of time on this.

Hope you find a good solution (and post it: P) because we have the same problem as you.

---

€: An error (only?) Occurs if you also updated the common component once

€€: and only if you export swc while another fla with the common component is open (??)

Answer 5

I have almost the same problems as you! I am working on a game that has all the graphic assets in one huge FLA file, which is exported as a SWC library. My problem is that we want to split this huge file into several smaller ones, and then create a new FLA file for each new screen.

We use RSL to exchange assets between different FLA files. For example. fonts.fla has three fonts in the library exported for sharing. graphic_hsl.fla contains highly rated graphics and has fonts.swc imported for sharing at runtime. You should think about RSL as they give you the ability to edit graphic assets in one file, and they will automatically update if you use it in other FLA files.

We tried to use the XFL file format, but in the end we returned to FLA, since version control is not very useful with XFL. It has a very complex structure and changes the file from two different computers, at the same time it violates everything to a large extent! Thus, there is no merging with SVN, Git or what you use!