|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
алгоритм взаимодействия дизайнера с кодером (SWC+FD)
К примеру делаем мы игру крестики-нолики.
Дизайнер нарисовал внешний вид приложения, всякие там крестики, нолики, поле, фон и тд. это все експортируется в SWC. т.е. у нас голые графические ассеты, и отдельным классом некий общий вид интерфейса, как его видит дизайнер. Теперь Кодер должен со всем этим работать как то. я вижу несколько кривоватый способ построения интерфейса я должен из "общего вида" выдрать координаты всех элементов, и потом заново собрать это все, но уже на AS. я в правильном направлении двигаюсь? |
|
|||||
...
модератор форума
Регистрация: Sep 2006
Адрес: Minsk
Сообщений: 4,286
|
Цитата:
И раз оно уже всё задано, то руками выдирать, на мой взгляд, не обязательно. |
|
|||||
Тоже интересует эта проблема, тоже не могу найти просветления. Но что-то мне подсказывает, что использование getChildByName-ов не совсем кашерно, учитывая концепцию ООП и типизацию. С нетерпением жду разоблачения или других подходов.
__________________
Ну все, теперь Забава м-о-я. Гы-гы, а корабль мой! |
|
|||||
ок. а "кошерный" способ задания к примеру координат ячеек в которых потом разместятся эти самые крестики/нолики?
дизайнер в этих местах просто повставлял крестики например с названиями(p_1_1,p_2_1.... итд) , я получаю их координаты, пихаю в масив. далее мне их надо удалять все, или просто воссаздать заново. еще есть анимация появления этой элементов интерфейса в данном примере рисование "#". на ее месте в "исходном" классе сейчас просто нарисованный спрайт, мувик с ее проявлением в библиотеке. |
|
|||||
Ну вот варианты:
1. Мы вытаскиваем из swc наш клип со всем барахлом, пробегаемся по динамическим элементам (заранее зная их имена), даем ссылки на них переменным. С этими переменными работаем. Статические элементы - фоны и прочее у нас остается нетронутым. Вроде бы самое простое. 2. Мы слезно умоляем дизайнера выдать нам swc с уже распарсенными элементами и текстовики с координатами вкупе с ТЗ. Все это формируем динамически в каком-нибудь классе. 3. Ругаемся на ленивого дизайнера, просим fla, парсим все элементы сами и возвращаемся ко второй части пункта 2. 4. Получаем грамотно составленный swc, где динамические части отдельно от статического контейнера, текстовик с ТЗ и координатами (по сути, пункт 2). Все, я иссяк.
__________________
тут я |
|
|||||
[+ 1.0 08.10.14]
блогер
Регистрация: Mar 2010
Адрес: x = stage.stageWidth/2 y= stage.stageHeight/2
Сообщений: 293
Записей в блоге: 2
|
может быть парсер написать который бы проходил по дереву визуальных объектов и выводил лог со всеми необходимыми параметрами, а далее уже с помощью собранной информации вывести все свойства интерфейса в xml и уже с него позиционировать объекты в конечном приложении, тогда любые возможные изменения можно будет вносить в xml не меняя код ?!
|
|
|||||
Как работаем мы.
Обычно у swc которая линкуется к FD уже настроены все export, имена и т.д. К примеру у нас есть сцена с крестиками/ноликами. Это значит что есть экспортируемый символ-сцена, в котором уже лежат экземпляры экспортируемого символа с 2 кадрами(крестик/нолик). Обычно после этого я наследуюсь от сцены, и пишу там логику. Экземпляры крестиков и ноликов в виде переменных у меня уже автоматом есть. Но это - естественно не обязательно. Естественно, что бы получить такую swc, fla должны делать программисты. Соотвественно, какие тут есть варианты: 1) Художники все рисуют в photoshop. Затем передают psd программистам. Они сами импортят во flash и настраивают. 2)Художники делают fla, на основе ТЗ и своих способностей. Затем программист дотачивает fla напильником. Если надо, уже нормальную FLA можно вернуть художникам, с подробным описанием, где и как сделать какую нибудь анимацию... Как то так... При любом раскладе допиливать во Flash программисту придется. Автоматизировать сей процесс в любом случае не удастся, художники все равно где нибудь набокапорят Добавлено через 4 минуты Опять же, тут много зависит от задачи. К примеру я делал игру про рыбок, с видом сверху, с программным скелетом и анимацией. Как не странно, мне вполне удалось научить художников делать правильную структуру объекта для рыбок и экспорт рыбки. А так же я сделал им класс, который они прописывали его в качестве класса - документа. Они ложили свою рыбку на сцену, и могли поуправлять рыбкой с помощью мышки, посмотреть как-что, если надо, что-то подправить.(класс содержал логику анимации рыбки, а так же брал первый символ на сцене, если таковой был, и пытался сделать из него рыбку, а затем управлял ею)... В результате получился вполне нормальный pipline.
__________________
Искренне Ваш, Джек. |
|
|||||
...
модератор форума
Регистрация: Sep 2006
Адрес: Minsk
Сообщений: 4,286
|
Не очень удобный вариант - наследовать графику от логики. Любые изменения в таком коде, будут порождать необходимость пересборки swc. Лучше композицию использовать.
|
Часовой пояс GMT +4, время: 04:22. |
|
« Предыдущая тема | Следующая тема » |
|
|