Flash - Managing a large project

Question

We are prototyping using Autodesk Scaleform and building our game UI using Flash. We will need to be able to run a large project with a team of 3-4 artists and 10+ programmers. We use Perforce source control system for storage of all code and assets. We need to be able to manage a project with multiple shared resources and multiple people (artists & programmers) working on screens and controls.

Our problem is as follows:

We want to be able to create skinned graphical custom components, such as buttons, sliders, checkboxes as well as more complex controls such as tables and game specific elements. We want to be able to share graphics assets in a single location and allow multiple artists and coders to work on shared components simultaneously. We need all of this to be stored in a Perforce source control repository.

For AS3 code this is all fairly straight forward. It works like any other codebase and we have set up FlashBuilder and FlashDevelop projects.

Now, the options seem to be as follows:

• Create a flash project or projects. The problem here is that all of the assets are copied into AuthortimeSharedAssts.fla. This means that, because FLA is a binary format, our source control cannot allow more than one person to edit any shared resource at the same time.

• Set up manual authortime sharing. This will allow work on multiple shared components because individuals can update a small discrete FLA file and this will automatically update a larger shared librar. The problem is that this does not allow sharing of graphics assets, which means that, if an artist updates a graphic, this does not filter down to individual flash files.

• Use the XFL format. This would allow us to merge files when checking in to source control as they are plain text and it saves out individual assets as separate files, which looks perfect. The problem is that I can't see how to make a project, which entirely uses XFL files (i.e. makes something like AuthortimeSharedAssets.xfl).

At the moment I can't see any obvious, sensible way of running a large project in Flash. We cannot be the first to do this sort of thing though.

Can anyone help or explain how we should do it?

Answer 1

I would say XFL would be the way to go for such a large team, especially when using source control.

As far as I know most symbols for XFL are saved as .xml in the LIBRARY folder. If they are imported jpgs or other bitmaps then the actual image file is saved there as well.

I have not been able to embed fonts and save them under this format however, which can be a big issue depending on what you are doing. A solution to this is to load your fonts dynammically, as discussed here. Which may be a slight inconvenience to you designers but a small price to pay when you consider what you gain using the XFL format when there are so many people involved in the project.

I would also recommend to pre-compile (make components) of certain parts of your project.

I hope that helps.

Answer 2

This may not be an option for your team but I will suggest it, as it has been (in my experience) a very successful project management approach.

When making big, department infrastructure choices like this it pays to get into the weeds and see the problems you're trying to head off. That said, bear with my explanation here.

The main hurdles you have are 1) locking and editing large FLA files that cannot be merged and 2) preventing duplications / version conflicts of MovieClips and classes within those files. The conflicts can be authortime ones (FLAs having out-of-date library symbols from authortime shared libs) or runtime ones (SWFs compiled with conflicting versions of the same classes, causing runtime crashes).

The solution, in my experience, is 1) to put as little code as possible in the binaries (FLAs), 2) bind the class code to the MovieClips as late in the process as possible, and 3) write your application code to do this "late binding" gracefully. This means using runtime libraries instead of authortime ones. I would not bother trying solutions that treat binaries as text for sake of merging; instead minimize and isolate the role FLAs they play in your code. Keep 'em separated.

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

1. In your production (non-library) FLAs, work with "view" MovieClips. "View" clips are all art and animation; they have no class bindings and as little code as possible. For example where your artist may add a BouncingBall symbol to the stage with a linkage to BouncingBall.as, they instead add BouncingBallView with no linkage (generated class name BouncingBallView with base class MovieClip).
2. In your library SWFs (which can be pure AS), write Mediator classes to wrap around these Views. Mediators "wrap" instances of the View clips at run-time, exposing the view object's properties to the rest of the application and effectively acting like a library class linkage. For example you'd write BouncingBallMediator.as instead of BouncingBall.as, and in that Mediator class you put all your app logic for bouncing balls.
3. Set up your application to load SWF libraries at run-time with all your classes (like BouncingBallMediator). Then when a BouncingBallView instance appears on stage, your application creates a new BouncingBallMediator instance and assigns the BouncingBallView object to it. This successfully decouples the view (MovieClip library symbol) from its controlling logic (in the BouncingBall.as class file). In so doing the nettlesome baggage of linking classes to the FLA file is disposed of.

This approach has many benefits, 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 are never working with FLAs that have code and developers have the control they need to minimize the likelihood of duplicate / conflicting class definitions across SWFs. Everyone gets to focus more on what they do best.

Projects I've worked on with this approach tend to go very well, as long as the lead dev at the rudder groks the decoupling strategy that I'm talking about. Apologies for the super verbose response; HTH.

Answer 3

I cannot recommend Authortime Sharing as I have not been able to use all of the components out of the several swc's in my project. The reason is after several day's of investigation rather strange.

At least one component (eg. a dialog) is always throwing Type-Errors when it uses authortime shared components (eg. a button) and the shared component has an instancename. Everything works fine as long as you don't assign any instancenames to the shared components within components you've linked via actionscript and instantiate later in your project.

The goal was to split a massive *fla into several smaller ones, sharing the assets at authortime so changes are shared between the splitted smaller fla's and the compiler (not runtime!) does not duplicate those classes. This works great, even when using actionscript-linking and custom baseclasses massivly. (deactivate automatically declare stage instances though) The compiler successfully excludes all duplicated classes caused by the sharing. You can controll that easily looking into each included swc.

To simply reproduce the problem you have to make 2 fla's. each one with a movieclip (eg. a dialog) and a shared one. (eg. a button; one fla shares the button with the other one). Assign all components actionscript-linkage. Put the button on each of the dialogs and assign each of the buttons an instancename. Compile both fla's to swcs, include them into your project and try to instanciate both of the dialogs. One of them is going to throw a #1034 Type Coercion Error. Remove (one of) the button instancenames and it will work.

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

My guess is that as long as no instancename is set, flash doesn't care what type the button actually is and treats it as a movieclip but when an instancename is set the player trys to typecast the movieclip to the specified type. But for some reason doesn't look into the whole namespace(?) but only in the swc the dialog has been compiled in. I conclude this because when the button has been compiled into swcA but not into swcB, the dialog from swcA works but not the dialog from B and the other way around. You can "force" the button to swap swc by recompiling the fla you want the button to be in.

I also got it running in rare cases involving more than just 2 fla/swc's. But have no idea why. Maybe I investigate a little bit further but I already wasted quite some time on it.

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

---

€: The error (only?) seems to occur if you also updated the shared component once

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

Answer 4

I'm having almost the same problems now as you have! I'm working on a game that has all of graphical assets in one huge FLA file that is exported as SWC library. My problem is that we want to split this huge file into several smaller ones and then creating new FLA file for each new screen.

We are using RSL to share assets between different FLA files. Eg. fonts.fla is having three fonts in library exported for runtime sharing. graphic_hsl.fla contains high score list graphics and having fonts.swc imported for runtime sharing. You should think about RSL as they give you ability to edit graphical assets in one file and it will be automatically updated whereever you used it in other FLA files.

We tried with XFL file format, but at the end we switched back to FLA as version control is not really useful with XFL. It has very complex structure and changing file from two different computers at the same time pretty much breaks things! So no merging with SVN, Git or whatever you are using!

Answer 5

There are few more options. I'm not saying they are better, but, depending on your team and how much you can invest into development of your own development tools... OK, here's a port of SWFMill to Haxe: http://code.google.com/p/hxswfml/ . This allows for graphic assets to be represented as text (XML) files. Maybe it would be possible to add a plugin for Incscape to export the graphics to this format... Then I think these folks had their own format and tools for managing visual stuff. Flex SDK compiler can actually decently translate SVG into flash graphics.

Lastly, and most likely option I would investigate, would I have enough time, is the FXG format. Flex compiler can compile that, however, it still requires some patching to remove all Flex framework related junk from what comes out of FXG. The benefit of FXG however is that programs like Photoshop, Illustrator, Indesign etc can export to this format. Of course, this is mostly untested... and at some place I fear that FXG was designed for the Adobe product that has been suspended recently (Catalyst). Yet there is a chance the format itself will remain the interchange format for Adobe programs - thus you will not need to check in the FLA.

The way I work with graphic artists: we never check in FLA, instead, we check in the SWC and make it a rule that whoever works on a project needs to check it out and import. This isn't really helping when more then one person needs to work on the same symbol, but, at least, they are all in one place and it is possible to work simultaneously, if you are editing different things (which happens most of the time anyway).