Collaborate in Adobe Animate

Hi.

Yeah, there is.

Lots of studios use Flash/Animate for TV productions and game development that are handled by teams of all sizes.

In addition to distributing responsibilities, as already suggested here, you can rely on version control systems, like Git and Perforce.

You can also save your projects as .xfl instead of .fla for easier versioning control and to be a bit more file corruption proof.

There's also the authortime sharing feature for common symbols between FLAs/XFLs and theres's also shared libraries.

I suggest you to create a very simple prototype/project and test all the possibilities.

Regards,

JC

To expand on @n. tilcheff 's answer: the latest versions do support sharing library items via the online CC Libraries. More info:

https://helpx.adobe.com/animate/using/sharing-symbols.html

Personally I would never rely on such a fragile approach within a team-based animation effort.

Ideally some kind of versioning system would be used, such as SVN or GIT because working with a team on a collaborative animation project becomes much too fragile when no versioning is used to keep track of project files. Furthermore, I would seriously think twice before relying on Adobe's servers for such a team project. Support is difficult to get hold of in case of issues, and as a team (project leader) you'd want full control over the server whether it is by setting up your own online server or relying on a dedicated versioning server option.

As an alternative for Animate, the open source and free OpenToonz supports SVN natively. As a team it is easy to set up a SVN versioning server (https://riouxsvn.com/ provides a free and private SVN server space, for example). OpenToonz's project file management is lightyears ahead in terms of versioning and team-based animation project compatible workflows compared to Animate CC in my opinion.

(Blender's 2D animation capabilities are not to be underestimated either, but not as animator intuitive compared to Animate or OpenToonz. Blender's external file referencing also works fine for collaborative efforts. And free again!)

One more advantage would be that the software is freely available to all team members and the lead (you @Ashley31070466tbs8 ) controls the centralized SVN server. With SVN it is also simple to control which parts of the project files are accessible to specific team members. And SVN is very friendly for binary files (graphics, sounds, music, movie files, etc which tend to be heavily used in an animation project).

But having to work with different software can also be a disadvantage in regard to retraining and learning a different workflow, of course.

It is also possible to work with a GIT based workflow and Animate, of course. You'd have to work with external library files again (NOT CC Libraries! Regular ones!). Team members working on individual parts of the animation(s) should NEVER touch other animators' library files (unless very strict workflows are adhered to). The library files would then be linked in master scene files by the main animation lead(s).

However! GIT is much more confusing and difficult for the average person (animator!) to grasp compared to SVN, which is easily learned and understood. I suppose SVN can work just as well with team members checking out their respective library files (have not tested this myself). I'd have to repeat here once more that the project and file structure of OpenToonz is by far friendlier for team based animation projects. And also much easier to understand: basically, there is no need for library files. Any file can be linked in any other file, and finally linked into a master scene. Thus it becomes a doddle for an animator to check out a specific scene or scene take/part or an animated character or the base character file and update those files. It is not nearly as simple in Animate. And when links between files are lost, the binary nature of Animate files cause additional headaches, while in OpenToonz animation files are plain text files and easily edited to resolve linking/referencing problems.

And that doesn't include dealing with other files such as audio and other media (movie files, backgrounds, static bitmaps, etc.). Audio files may need to be updated during animation. Those are ideally linked externally as well (something easily done in OpenToonz or Blender, for example, because files imported are automatically referenced to their external files - just replace the original-->versioning system is essential!). Works in Animate as well, but again via external library files (I believe - it's been a while).

Anyway... However you plan on setting up  it is important to discuss with the entire team how the collaborative workflow is planned and executed. It is essential to test test test a collaborative workflow and familiarizing yourself with (a) versioning system(s) before deciding how to move forward.

You can't work on the same FLA at the same time with another person.

You can merge changes by replacing Library Items.

For example, one person can work on a background, while another is animating a shot using a placeholder. As long as the background symbol has the same name and dimensions you can later replace it easily with the finished artwork.

The same applies to various rig elements, but conventions have to be created and maintained.

i don't see how 2 people could work on the same fla and then easily merge both edited fla's into one.