Развернутый формат файла Flash CS5 IDE

До CS5-го флеша бинарный формат файла флеша был практически не читаемым. Это приводило ко многим неудобствам. Начиная от хранения этого бинарника в системе контроля версий, до восстановления поломанного файла или внесения массивных однотипных изменений.

И наконец Адоби порадовали — можно сохранять в ИДЕ не бинарный файл FLA а папку с ясными и понятными файлами проекта. Более того, FLA формат CS5 это просто zip такой папки. Ура? Частично да, но в бочке меда оказалась не одна лопата дегтя.

Сначала — какие плюсы мы таки неоспоримо обретаем?

Можно разорхивировать FLA подхачить, поправить все что необходимо, наконец просто посмотреть что-же не так с каким-то конкретным шейпом. Примеры от меня:
— импортировнный векторный рендеринг 3Д модели из Блендера при попытках оптимизировать или превратить линии в заливки превращается в кашу, заливки исчезают. Рассмотрев xml файл этого клипа можем выяснянить в чем кривизна шейпа (двойные точки, например). Можно поравить ручками.
— полученный после рендеринга 3Д модели из Блендера swf с анимацией в векторном виде импортированный во флеш видится в библиотеке с заливками, но при попытке редактирования заливки исчезают. Смотрим что за фигня и правим.
— массированно переименовываем клипы :) — это можно сделать и другим способом, но так тоже удобно
— делаем нетривиальное или массированное изменение на таймлайнах клипов, то что ручками в ИДЕ делать очень муторно и долго. Любые другие массированные действия, в частности просто дублировние клипов фаз юнитов для дальнейшей перекраски и мелкой дорисовки в их бронированные варианты
— написание тулзовины, которая анализирует xml клипа в котором нарисованы кривые безье путей по которым едут юниты и создание соответствующего файла для пропихивания в игру. У меня была тулза встроенная во флеш и это конечно было удобно пользовать — нажал кнопку и увидел анализ путей на ошибки, обводки прямо во флеше, автоматом все уже в игре. Однако это было неудобно и небыстро девелопить — JSFL + swf, ошибки в котором поди догадайся где произошли. swf тулзы перекомпилил — слава богу не надо переоткрывать флеш, но окном тулзы надо открывать-закрывать через меню. Итд. Так что думаю для скорости удобнее будет лезть прямо в xml. Либо использовать его как есть :), правда перед релизом почистить xml, чтобы сэкономить место.

Еще один плюс не плюс — для кого как. Старый FLA все импортированные картинки хранил у себя в своем формате. И конечно помнил пути до оригинала, чтобы можно было нажать update. Новый FLA делает себе копию картинки и работает с ней. Параллельно все равно держит и dat файлы в своем формате, для скорости загрузки. Таким образом можно редактировать прямо в папке эти картинки. При переключении во флеш даже update не надо делать. Однако если вы сделали замену картинки — надо переоткрывать документ. Тут возникает вопрос, что будет если после сделать update — не затрется ли изменение, которое вы делали прямо в папке проекта? Я не стал экпериментировать, поскольку решил жить с бинарным FLA. Почему — ниже.

Сперва вкратце про развернутый формат. Это папка с именем проекта (бывшего имени FLA файла) в которой главное что есть:
— папка bin (здесь лежать dat файлы с картинками/звуками во внутреннем формате флеш + некий кеш)
— папка library (здесь лежат клипы библиотеки — файлы xml, плюс картинки png jpg, звуки/музыка итд)
— DOMDocument.xml — главный файл, здесь в большинстве случаев только список клипов библиотеки плюс возможно два кадра стейджа с прелоадером итд
— PublishSettings.xml

Все эти xml файлы очень понятны, их удобно редактировать — таймлайны, шейпы, клипы итд.

Тем, кто конвертит свои FLA файлы из CS4 формата — картинок в png jpg итд в library папке вы не обнаружите. Сначала надо сохранить в бинарный FLA CS5 формата, потом сделать update всем картинкам/звукам которые вы хотите видеть у себя в library папке. Потом сохранить. Потом сохранить как XFL. Все эти телодвижения нужны потому, что старый FLA вообще не хранит у себя копий картинок итд.

А теперь про лопаты дегтя. Разумные люди ;) пользуются системой контроля версий, даже если работают в одиночку. А для команд и компаний это вообще маст-хэв. Раньше для FLA хорош был SVN, ибо он очень разумно работает с бинарными файлами, репозиторий не разрастается — красота. Однако, имея на руках развернутую структуру папок с тестовыми xml — грешно не поверить что теперь придет суперсчастье. Например, подкорректировал я только шейп одного клипа и коммичу изменения. Раньше перекоммичивался весь FLA, который может занимать мегабайты. Спасибо SVN — по сети едут дифференсы, которые он умудряется выловить в бинарниках. Но в общем случае идет перерасход. Плюс нельзя узнать какие точно изменения произошли. Теперь же, вроде-бы, дифференс это одна строчка шейпа. Он легко весит, любой может сделать дифференс хоть через месяц и увидеть что за изменение было сделано.

Однако! При конкурентной работе, если один художник создаст красный круг слева, а другой зеленый квадрат справа, и первый коммитит свои изменения первым, то второй при коммите получит конфликт, хотя хотелось бы чтобы обе добавки попали в систему вместе, как это работает с кодом. Для того, чтобы этого не происходило Адоби надо было доводить свой xml до ума (либо это вообще невозможно).

Однако! Флеш может писать клипы библиотеки в произвольном порядке. Иногда в одном иногда в другом. На ПС в одном на Маке в другом. В итоге — изменений не было, а контроль версий может зафиксировать глобальные изменения. Недавно вроде это пофиксили, но не без греха. Еще одна засада — флеш ориентируется на даты изменения файлов (для того чтобы быстро загружать проект), а апдейты контроля версий могут даты менять при каждом чекауте. Это вроде можно отключить но муторно. Самое главное не пофиксено — флеш продолжает генерить «случайные» изменения при записи xml. Перемешивает, например. То-есть по сути ничего не поменялось, а контроль версий считает что поменялос вообще все (это не контроль версий такой «плохой», на всякий случай скажу).

Про вышеупомянутые траблы forums.adobe.com/message/2959932

Таким образом, буду хранить в бинарном FLA, при случае разворачивая его и насилуя ручками.

Ссылки по теме:
The XFL File Format Explained — blog.theflashblog.com/?p=1986
XFL: Managing your library assets — blog.mencio.com/?p=121
Flash CS5 and Version Control — www.dz015.com/?p=202