Flash - Управление большим проектом

Question

Мы прототипируем с помощью Autodesk Scaleform и создаем пользовательский интерфейс игры с использованием Flash. Нам нужно будет запустить большой проект с командой из 3-4 художников и 10+ программистов. Мы используем систему контроля источников Perforce для хранения всего кода и активов. Мы должны иметь возможность управлять проектом с несколькими совместно используемыми ресурсами и несколькими людьми (художниками & программистами), работающими на экранах и элементах управления.

Наша проблема заключается в следующем:

Мы хотим, чтобы иметь возможность создавать кожурой графические пользовательские компоненты, такие как кнопки, ползунки, флажки, а также более сложные элементы управления, такие как таблицы и игры конкретных элементов. Мы хотим иметь возможность обмениваться графическими ресурсами в одном месте и позволять нескольким художникам и кодерам работать на совместно используемых компонентах одновременно. Нам нужно, чтобы все это хранилось в репозитории управления версиями Perforce.

Для кода AS3 все это довольно прямолинейно. Он работает как любая другая кодовая база, и мы создали проекты FlashBuilder и FlashDevelop.

Теперь варианты кажутся следующим образом:

• Создание флэш-проекта или проектов. Проблема здесь в том, что все активы скопированы в AuthortimeSharedAssts.fla. Это означает, что, поскольку FLA является двоичным форматом, наш источник управления не может позволить нескольким отдельным пользователям редактировать любой общий ресурс одновременно.

• Настройте совместное использование authortime вручную. Это позволит работать с несколькими разделяемыми компонентами, поскольку отдельные пользователи могут обновлять небольшой дискретный FLA-файл, и это автоматически обновит большой общий библиотечный файл. Проблема заключается в том, что это не позволяет использовать графические ресурсы, а это означает, что если художник обновляет графику, это не фильтрует отдельные файлы флеш-памяти.

• Используйте формат XFL. Это позволит нам объединять файлы при проверке исходного элемента управления, поскольку они являются простым текстом, и он сохраняет отдельные активы в виде отдельных файлов, что выглядит идеально. Проблема в том, что я не вижу, как создать проект, который полностью использует файлы XFL (т. Е. Делает что-то вроде AuthortimeSharedAssets.xfl).

В настоящий момент я не вижу ясного и разумного способа запуска большого проекта во Flash. Однако мы не можем первыми делать такие вещи.

Может ли кто-нибудь помочь или объяснить, как мы должны это делать?

Answer 1

Я бы сказал, что XFL - это путь для такой большой команды, особенно при использовании контроля источника.

Насколько я знаю, большинство символов для XFL сохраняются как .xml в папке LIBRARY. Если они импортируются jpg или другие растровые изображения, тогда также сохраняется реальный файл изображения.

Я не смог встроить шрифты и сохранить их в этом формате, но это может быть большой проблемой в зависимости от того, что вы делаете. Решением для этого является загрузка ваших шрифтов динамически, как discussed here. Это может быть небольшим неудобством для вас дизайнеров, но небольшая цена, которую вы заплатите, если учесть, что вы получаете, используя формат XFL, когда в проекте участвует очень много людей.

Я бы также рекомендовал предварительно скомпилировать (изготовить компоненты) определенные части вашего проекта.

Я надеюсь, что это поможет.

Answer 2

Есть еще несколько вариантов. Я не говорю, что они лучше, но, в зависимости от вашей команды, и сколько вы можете инвестировать в разработку собственных инструментов разработки ... Хорошо, вот порт SWFMill на HaXe: http://code.google.com/p/hxswfml/. Это позволяет отображать графические объекты в виде текстовых (XML) файлов. Возможно, можно было бы добавить плагин для Incscape для экспорта графики в этот формат ... Тогда я думаю, что these folks имел свой собственный формат и инструменты для управления визуальными материалами. Компилятор Flex SDK может фактически перевести SVG на флэш-графику.

Наконец, и, скорее всего, вариант, который я бы исследовал, у меня было бы достаточно времени, это формат FXG. Компилятор Flex может скомпилировать его, однако он по-прежнему требует некоторого исправления, чтобы удалить все связанные с инфраструктурой фрейма Flex из того, что выходит из FXG. Преимущество FXG заключается в том, что такие программы, как Photoshop, Illustrator, Indesign и т. Д., Могут экспортироваться в этот формат. Конечно, это в основном непроверено ... и в каком-то месте я опасаюсь, что FXG был разработан для продукта Adobe, который недавно был приостановлен (Catalyst). Тем не менее, есть шанс, что формат сам по себе останется форматом обмена для программ Adobe, поэтому вам не нужно будет проверять FLA.

Как я работаю с художниками-графиками: мы никогда не проверяем FLA, вместо этого мы проверяем SWC и делаем это правило, что кто-нибудь, кто работает над проектом, должен проверить его и импортировать. Это не помогает, когда более одного человека нужно работать над одним и тем же символом, но, по крайней мере, все они находятся в одном месте, и можно работать одновременно, если вы редактируете разные вещи (что происходит в большинстве случаев время в любом случае).

Answer 3

Это может быть не вариант для вашей команды, но я предлагаю, как это было (по моему опыту) очень успешный подход к управлению проектами.

При создании больших инфраструктурных решений отдела, таких как это, он платит, чтобы попасть в сорняки и увидеть проблемы, с которыми вы пытаетесь уйти. Тем не менее, я расскажу здесь свое объяснение.

Основные препятствия, которые у вас есть: 1) блокировка и редактирование больших файлов FLA, которые нельзя объединить, и 2) предотвращение конфликтов дубликатов/версий MovieClips и классов внутри этих файлов. Конфликты могут быть authortime (FLA, имеющие устаревшие библиотечные символы из автономных общих библиотек) или исполняемые файлы (SWF, скомпилированные с конфликтующими версиями одних и тех же классов, что приводит к сбоям во время выполнения).

Решение, по моему опыту, состоит в том, чтобы 1) сделать как можно меньше кода в двоичных файлах (FLA), 2) привязать код класса к MovieClips как можно ближе к процессу и 3) написать код приложения для этого «позднего связывания» изящно. Это означает использование библиотек времени выполнения, а не authortime. Я бы не стал пробовать решения, которые рассматривали бы двоичные файлы как текст для слияния; вместо этого минимизируйте и изолируйте роль FLA, которую они играют в вашем коде. Храните их отдельно.

Если это вообще возможно, я бы рекомендовал вашей команде использовать следующую стратегию:

1. В вашем производстве (не библиотека) FLAS, работа с «видом» MovieClips. «Просмотр» клипов - это все искусство и анимация; у них нет привязок классов и как можно меньше кода. Например, если ваш художник может добавить символ BouncingBall на сцену с привязкой к BouncingBall.as, вместо этого они добавляют BouncingBallView без привязки (сгенерированное имя класса BouncingBallView с базовым классом MovieClip).
2. В вашей библиотеке SWF (которая может быть чистой AS), напишите классы посредников, чтобы обернуть эти Представления. Посредники «обертывают» экземпляры «Просмотр клипов» во время выполнения, выставляя свойства объекта вида остальной части приложения и эффективно действуя подобно привязке класса библиотеки.Например, вы должны писать BouncingBallMediator.as вместо BouncingBall.as, и в этом классе Mediator вы помещаете всю свою логику приложения для прыгающих шаров.
3. Настройте приложение для загрузки библиотек SWF во время выполнения со всеми вашими классами (например, BouncingBallMediator). Затем, когда на сцене появляется экземпляр BouncingBallView, ваше приложение создает новый экземпляр BouncingBallMediator и назначает ему объект BouncingBallView. Это успешно отделяет представление (символ библиотеки MovieClip) от его логики управления (в файле класса BouncingBall.as). При этом уничтожается нетронутый багаж ссылок на классы в файл FLA.

Этот подход имеет много преимуществ, но в двух словах он позволяет вашим разработчикам и вашим художникам работать независимо, с меньшей озабоченностью конфликтами управления версиями между файлами класса и искусства. Художники никогда не работают с FLA, у которых код и разработчики имеют необходимый им контроль, чтобы минимизировать вероятность дублирования/противоречивых определений классов в SWF. Каждый может больше сосредоточиться на том, что они делают лучше всего.

Проекты, над которыми я работал с таким подходом, имеют тенденцию идти очень хорошо, пока ведущий разработчик на руле, анализирует стратегию развязки, о которой я говорю. Извинения за сверхсловный ответ; НТН.

Answer 4

Я не могу рекомендовать совместное использование Authortime, поскольку я не смог использовать все компоненты из нескольких swc в моем проекте. Причина заключается в том, что несколько дней расследования довольно странно.

По крайней мере, один компонент (например, диалог) всегда выбрасывает ошибки типа, когда он использует общие компоненты, связанные с authortime (например, кнопку), а общий компонент имеет имя instancename. Все работает нормально, пока вы не назначаете какие-либо имена для общих компонентов в компонентах, которые вы связали с помощью actionscript, и создавайте их позже в своем проекте.

Цель состоит в том, чтобы разделить массивную * fla на несколько более мелких, разделяя активы на authortime, поэтому изменения распределяются между разделенными меньшими флеками, а компилятор (а не runtime!) Не дублирует эти классы. Это отлично работает, даже при широком использовании actionscript-ссылок и пользовательских базовых классов. (деактивировать автоматически объявлять экземпляры сцены, хотя). Компилятор успешно исключает все дублированные классы, вызванные совместным использованием. Вы можете контролировать, что легко смотреть на каждый включенный swc.

Чтобы просто воспроизвести проблему, вам нужно сделать 2 флакона. каждый из которых имеет мувиклип (например, диалог) и общий. (например, кнопка, одна кнопка разделяет кнопку с другой). Назначьте все компоненты actionscript-linkage. Поместите кнопку в каждое из диалоговых окон и назначьте каждой из кнопок значение instancename. Скомпилируйте fla's для swcs, включите их в свой проект и попытайтесь установить оба диалоговых окна. Один из них собирается бросить # 1034 Type Coercion Error. Удалите (одну из) кнопку instancenames, и она будет работать.

Чтобы получить впечатление - heres a screenshot (полного размера):

Я думаю, что до тех пор, как не имя_экземпляр не установлен, то вспышка не волнует, что типа кнопки на самом деле и обрабатывает его как мувиклип, но когда задано инстанкамену, игрок пытается отобразить мувиклип в указанном типе. Но по какой-то причине не рассматривает все пространство имен (?), Но только в swc диалог был скомпилирован. Я заключаю это, потому что, когда кнопка была скомпилирована в swcA, но не в swcB, диалог из swcA работает, но а не диалог от B и наоборот. Вы можете «принудительно» нажать кнопку «swap swc», перекомпилировав флажок, который вы хотите, чтобы кнопка была нажата.

Я также получил его в редких случаях с участием не более 2 fla/swc. Но понятия не имею, почему.Может быть, я еще немного разобрался, но я уже потратил немало времени на это.

Надеюсь, вы найдете хорошее решение (и опубликуете его: P), потому что у нас та же проблема, что и вы.

---

€: Ошибка (? Только), кажется, происходит, если вы обновили общий компонент раз

€€: и только если вы экспортируете МЖК, а другой Fla с общим компонентом является открытым (?)

Answer 5

У меня сейчас почти такие же проблемы, как и у вас! Я работаю над игрой, которая имеет все графические активы в одном огромном FLA-файле, который экспортируется в виде библиотеки SWC. Моя проблема заключается в том, что мы хотим разбить этот огромный файл на несколько более мелких, а затем создать новый FLA-файл для каждого нового экрана.

Мы используем RSL для обмена активами между различными файлами FLA. Например. fonts.fla имеет три шрифта в библиотеке, экспортированной для совместного использования. graphic_hsl.fla содержит графику с высоким рейтингом и имеет fonts.swc, импортированный для совместного использования во время выполнения. Вы должны думать о RSL, поскольку они дают вам возможность редактировать графические активы в одном файле, и они будут автоматически обновляться, если бы вы использовали его в других файлах FLA.

Мы пробовали с файлом формата XFL, но в конце мы вернулись к FLA, поскольку управление версиями не очень полезно с XFL. Он имеет очень сложную структуру и меняет файл с двух разных компьютеров, в то же время в значительной степени нарушает все! Таким образом, нет слияния с SVN, Git или тем, что вы используете!