Рабочий процесс для больших проектов Flash/AS3

Question

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

Идеальный рабочий процесс должен удовлетворять следующим требованиям:

1. Повторно используемые элементы интерфейса определяются только один раз

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

2. Все загружается по требованию

В настоящее время у нас есть два разных шага загрузки: во-первых, мы загружаем библиотеки меню. Когда это будет сделано, игроки уже смогут взаимодействовать со всеми меню. Затем мы начинаем загружать фактические данные игрового процесса. Начальное время загрузки все еще слишком велико и заставляет нас терять много потенциальных игроков. Что мы действительно хотим сделать, так это загрузить только необходимый минимум для главного меню, а затем загружать все остальное только тогда, когда игрок пытается открыть соответствующие меню. Зума Блиц делает это очень хорошо.

3. Художники могут вносить незначительные изменения без помощи программистов

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

-

Наш текущий рабочий процесс выглядит следующим образом: художник создает экраны в виде видеороликов в Flash CS6 и экспортирует их в виде SWF-файлов. На стороне кода загрузите мувиклипы из SWF-файлов экрана и используйте их в качестве классов View в нашей системе на основе PureMVC. Посредники получают доступ к таким элементам, как текстовые поля в представлениях, по именам их экземпляров.

Это подвержено ошибкам, потому что нет централизованного места для определения интерфейса (т. Е. Имен экземпляров). Требуется много коммуникационных накладных расходов между кодером и исполнителем. Кроме того, он создает зависимость между кодом и внутренней структурой мувиклипа. Художники не могут прикрепить текстовое поле к другому фрагменту фрагмента ролика, если они хотят применить к нему некоторые эффекты.

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

Для (2) мы также начали создавать решение для домашнего приготовления, но опять же, это такая распространенная задача, уже должно быть что-то, что мы могли бы использовать.

Итак, как опытные разработчики Flash управляют такими большими проектами?

Answer 1

У меня есть некоторые мысли, но они основаны на моем стиле кодирования, который уникален для меня.

1. Повторно используемые элементы интерфейса определяются только один раз
В зависимости от того, что вы используете повторно, это может быть так же просто, как определить символ библиотеки и просто использовать его. Шрифты можно заменить, не копаясь с поиском и заменой, а также вы можете просто поменять шрифт в меню "Внедрение шрифтов".

Для обмена между XFL, вы можете использовать проект Flash Pro. Имейте в виду, что на это уходит определенное количество времени (файлы будут обновляться при их открытии или сохранении, Flash больше аварийно завершает работу с проектами, и может быть плохой идеей попытаться поработать над двумя файлами из тот же проект сразу).

Некоторые люди используют swcs, но для этого требуется, чтобы вы создали в нем вещи в коде, что может не сработать для вашего рабочего процесса. Я использую их только для аудио и обнаруживаю, что объекты в нем должны быть скомпилированы в кадре, который вы определили как кадр компиляции AS, или перед ним, иначе звук не может быть должным образом создан. Я подозреваю, что это будет иметь место для всего, что было создано от SWC.

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

Если ваш кадр компиляции ActionScript - это кадр больше 1, то вот как все будет компилироваться:

• Перед кадром 1:
  • Любые визуальные активы и встроенные звуки, используемые на кадре 1
  • Ваш основной класс документа, а также любые классы, на которые непосредственно ссылается класс документа (что является хорошей причиной для кодирования интерфейсов)
• Перед компиляцией фрейма AS (N):
  • Ваши AS Классы (код, не обязательно визуальные / аудио активы)
  • Визуальные и звуковые ресурсы для любых символов библиотеки установлены на Экспорт для AS в кадре N (даже если они не используются в SWF)
• Перед кадром, где актив впервые используется на временной шкале:
  • Визуальные / аудио активы во всех символах библиотеки, где Экспорт для AS в кадре N не проверен.

Если вы поместили рисунок загрузки счетчика на кадр 1 и выбрали кадр 10 в качестве кадра экспорта, то если вы просто дадите фильму воспроизводиться до тех пор, пока он не достигнет кадра 10, вот как он будет загружаться:

• Если у вас есть какие-то тяжелые ресурсы в вашем бланке или они прямо указаны в вашем основном классе документов, пользователи увидят пустой экран, пока загружается этот материал
• Блесна станет видимой и закрутится
• После того, как ваши классы AS будут загружены вместе с установленными в "Рамка 10" символами библиотеки "Экспортировать" и активами, которые фактически находятся в кадре 10, вы увидите эти активы, и все, что вам нужно для их использования, будет готово.
• Остальная часть SWF будет продолжать загружаться в фоновом режиме, обновляя framesLoaded,

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

3. Художники могут вносить незначительные изменения без помощи программистов
Если весь код находится в базовом классе для символа библиотеки, художникам не нужно его понимать, если он не удаляет или не изменяет нужное имя экземпляра. Я стараюсь минимизировать зависимость от имен экземпляров, наблюдая ADDED_TO_STAGE (фаза захвата) и отслеживание отображения объектов по типу. Если у меня есть ссылка на объект соответствующего типа, достаточно просто наблюдать за REMOVED_FROM_STAGE на этот объект разыменовать его. Это похоже на работу фреймворков, таких как RobotLegs и Swiz.

Кроме того, я использую концепцию, которую я называю "Semantic Flash", где я много делаю на основе меток. У меня есть базовый класс, FrameLabelCip, который имеет встроенную функциональность nextLabel() и previousLabel(), а также диспетчеризацию FRAME_LABEL_CONSTRUCTED События. Очень просто перейти от названия события раскадровки к имени метки Flash и просто создать графическую схему.

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