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

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Надеюсь, это поможет.

Answer 3

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

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

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

Answer 4

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

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

Цель состояла в том, чтобы разбить массивный * fla на несколько меньших, разделяя ресурсы во время разработки, чтобы изменения делились между разделенными меньшими fla и компилятором (не во время выполнения!) Не дублировать эти классы. Это прекрасно работает, даже когда массово используется action-linking и пользовательские базовые классы. (деактивируйте автоматически объявлять экземпляры stage, хотя) Компилятор успешно исключает все дублированные классы, вызванные общим доступом. Вы можете контролировать это, легко просматривая каждый включенный SWC.

Чтобы просто воспроизвести проблему, вы должны сделать 2 флага. каждый с мувиклипом (например, диалогом) и общим. (например, кнопка; один флаг делит кнопку с другим). Назначьте все компоненты actioncript-linkage. Поместите кнопку в каждом из диалогов и назначьте каждой кнопке имя экземпляра. Скомпилируйте оба флага в swcs, включите их в свой проект и попробуйте создать оба диалоговых окна. Один из них выдаст ошибку приведения типа # 1034. Удалите (одно из) имен экземпляров кнопки, и оно будет работать.

Чтобы получить впечатление - Вот скриншот (полный размер):

Я предполагаю, что пока имя экземпляра не установлено, flash не заботится о том, какой тип кнопки на самом деле и обрабатывает ее как мувиклип, но когда имя экземпляра установлено, проигрыватель пытается типизировать мувиклип указанного типа. Но по какой-то причине не смотрит на все пространство имен (?), А только в SWC, в котором был скомпилирован диалог. Я делаю вывод, потому что, когда кнопка была скомпилирована в SWCA, но не в SWCB, диалог из SWCA работает, но не диалог от Б и наоборот. Вы можете «заставить» кнопку поменять местами SWC, перекомпилировав флаг, в котором вы хотите, чтобы кнопка была.

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

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

---

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

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

Answer 5

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

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

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