алгоритм взаимодействия дизайнера с кодером (SWC+FD)
 

К примеру делаем мы игру крестики-нолики.

Дизайнер нарисовал внешний вид приложения, всякие там крестики, нолики, поле, фон и тд.

это все експортируется в SWC. т.е. у нас голые графические ассеты, и отдельным классом некий общий вид интерфейса, как его видит дизайнер.

Теперь Кодер должен со всем этим работать как то.

я вижу несколько кривоватый способ построения интерфейса :(

я должен из "общего вида" выдрать координаты всех элементов, и потом заново собрать это все, но уже на AS.

я в правильном направлении двигаюсь?

Не обязательно. Следует просто назначить каким-то переменным getChildByName'ом нужные элементы, другие оставить статическими. С этими переменными уже и работать. Часть может быть придется и выдрать, если, например, где-то сбоку есть три вида стейтов кнопки "close".

В данном случае задаются не только координаты, но еще и глубина и, возможно, масштаб.
И раз оно уже всё задано, то руками выдирать, на мой взгляд, не обязательно.

Тоже интересует эта проблема, тоже не могу найти просветления. Но что-то мне подсказывает, что использование getChildByName-ов не совсем кашерно, учитывая концепцию ООП и типизацию. С нетерпением жду разоблачения или других подходов.

ок. а "кошерный" способ задания к примеру координат ячеек в которых потом разместятся эти самые крестики/нолики?

дизайнер в этих местах просто повставлял крестики например с названиями(p_1_1,p_2_1.... итд) , я получаю их координаты, пихаю в масив. далее мне их надо удалять все, или просто воссаздать заново.

еще есть анимация появления этой элементов интерфейса в данном примере рисование "#".

на ее месте в "исходном" классе сейчас просто нарисованный спрайт, мувик с ее проявлением в библиотеке.

Ну вот варианты:
1. Мы вытаскиваем из swc наш клип со всем барахлом, пробегаемся по динамическим элементам (заранее зная их имена), даем ссылки на них переменным. С этими переменными работаем. Статические элементы - фоны и прочее у нас остается нетронутым. Вроде бы самое простое.
2. Мы слезно умоляем дизайнера выдать нам swc с уже распарсенными элементами и текстовики с координатами вкупе с ТЗ. Все это формируем динамически в каком-нибудь классе.
3. Ругаемся на ленивого дизайнера, просим fla, парсим все элементы сами и возвращаемся ко второй части пункта 2.
4. Получаем грамотно составленный swc, где динамические части отдельно от статического контейнера, текстовик с ТЗ и координатами (по сути, пункт 2).
Все, я иссяк.

может быть парсер написать который бы проходил по дереву визуальных объектов и выводил лог со всеми необходимыми параметрами, а далее уже с помощью собранной информации вывести все свойства интерфейса в xml и уже с него позиционировать объекты в конечном приложении, тогда любые возможные изменения можно будет вносить в xml не меняя код ?!

КорДум браво!

Как работаем мы.
Обычно у swc которая линкуется к FD уже настроены все export, имена и т.д. К примеру у нас есть сцена с крестиками/ноликами. Это значит что есть экспортируемый символ-сцена, в котором уже лежат экземпляры экспортируемого символа с 2 кадрами(крестик/нолик).
Обычно после этого я наследуюсь от сцены, и пишу там логику. Экземпляры крестиков и ноликов в виде переменных у меня уже автоматом есть. Но это - естественно не обязательно.

Естественно, что бы получить такую swc, fla должны делать программисты. Соотвественно, какие тут есть варианты:
1) Художники все рисуют в photoshop. Затем передают psd программистам. Они сами импортят во flash и настраивают.
2)Художники делают fla, на основе ТЗ и своих способностей. Затем программист дотачивает fla напильником.

Если надо, уже нормальную FLA можно вернуть художникам, с подробным описанием, где и как сделать какую нибудь анимацию... Как то так...

При любом раскладе допиливать во Flash программисту придется. Автоматизировать сей процесс в любом случае не удастся, художники все равно где нибудь набокапорят:)

Добавлено через 4 минуты
Опять же, тут много зависит от задачи. К примеру я делал игру про рыбок, с видом сверху, с программным скелетом и анимацией. Как не странно, мне вполне удалось научить художников делать правильную структуру объекта для рыбок и экспорт рыбки. А так же я сделал им класс, который они прописывали его в качестве класса - документа. Они ложили свою рыбку на сцену, и могли поуправлять рыбкой с помощью мышки, посмотреть как-что, если надо, что-то подправить.(класс содержал логику анимации рыбки, а так же брал первый символ на сцене, если таковой был, и пытался сделать из него рыбку, а затем управлял ею)...
В результате получился вполне нормальный pipline.

Не очень удобный вариант - наследовать графику от логики. Любые изменения в таком коде, будут порождать необходимость пересборки swc. Лучше композицию использовать.