Чудеса автогенеренных классов во Flash CS4/CS5.

JackFromChaos · 21.12.2010, 19:16

Может кто сталкивался, даже не знаю, можно ли как то с этим бороться... Кроме как отказаться от автогенеренных классов...

Суть проблемы такая.
У нас есть наш простой класс:

Код AS3:

package  
{
	import flash.display.MovieClip;
	public class BaseMyGroup extends MovieClip
	{
 
		public function MyGroup() 
		{
 
		}
 
	}
 
}

Создаем во Flash символ со следующими свойствами:
Export for Action Script – включаем
Class: MyGroup
Base Class: BaseMyGroup

Внутри ложем какой ни будь другой символ с именем. Например Символ Element, с именем “_element”. Путь Element будет компонентом, в котором мы через ComponentDefinition добавили свойство «varName».
Компилируем. Затем декомпилируем чем нибудь вроде Flash Decompiler Trillix, и смотрим что получилось:

Код AS3:

//ActionScript 3.0
//  class BaseMyGroup
package 
{
    import flash.display.*;
 
    public class BaseMyGroup extends flash.display.MovieClip
    {
        public function BaseMyGroup()
        {
            super();
            return;
        }
 
        public var _element:Element;
    }
}
 
 
//  class Element
package 
{
    import flash.display.*;
 
    public dynamic class Element extends flash.display.MovieClip
    {
        public function Element()
        {
            super();
            return;
        }
    }
}
 
 
//  class MyGroup
package 
{
    import adobe.utils.*;
    import flash.accessibility.*;
    import flash.desktop.*;
    import flash.display.*;
    import flash.errors.*;
    import flash.events.*;
    import flash.external.*;
    import flash.filters.*;
    import flash.geom.*;
    import flash.globalization.*;
    import flash.media.*;
    import flash.net.*;
    import flash.net.drm.*;
    import flash.printing.*;
    import flash.profiler.*;
    import flash.sampler.*;
    import flash.sensors.*;
    import flash.system.*;
    import flash.text.*;
    import flash.text.engine.*;
    import flash.text.ime.*;
    import flash.ui.*;
    import flash.utils.*;
    import flash.xml.*;
 
    public dynamic class MyGroup extends BaseMyGroup
    {
        public function MyGroup()
        {
            super();
            this.__setProp__element_MyGroup_Layer1_0();
            return;
        }
 
        function __setProp__element_MyGroup_Layer1_0():*
        {
            var loc1:*;
            try
            {
                _element["componentInspectorSetting"] = true;
            }
            catch (e:Error)
            {
            };
            _element.varName = "test";
            try
            {
                _element["componentInspectorSetting"] = false;
            }
            catch (e:Error)
            {
            };
            return;
        }
    }
}

И результат шокирует. Flash вместо того, что бы добавить переменную

Код AS3:

        public var _element:Element;

в класс MyGroup, добавляет ее в базовый класс BaseMyGroup.
При работе в одной флэшке это конечно не сильно заментно, разве что неприятно, что если у нас много символов наследников BaseMyGroup, то в конечном счете в нем будет очень много переменных. Так как если сделать MyGroup2, с экземпляром внутри _element2, в классе BaseMyGroup после декмпиляции будет уже 2 переменные:

Код AS3:

        public var _element:Element;
        public var _element2:Element;

А если мы компонуем на том же FlashDevelop проект в котором подключено несколько swc в каждом из которых присутвуют наследники BaseMyGroup, то столкнемся с тем, что что-то перестанет работать. Так как в результирующем проекте будет только один экземпляр BaseMyGroup выбранный из одной из подключенных swc, а то и вовсе оригинальный, в котором нет вообще переменных. И тогда приложение будет падать в конструкторе, в строчках подобных этой:

Код AS3:

            _element.varName = "test";

С ошибкой, что переменная «_element» не оепределенна, ведь она действительно не определенна...

Глюк проверен в Flash cs3 и Flash c4. Кто нибудь сталкивался с этим? Есть ли какой нибудь способ адекватно с этим бороться, не делая для каждого символа реальный класс, вроде:

Код AS3:

package  {
 
	import flash.display.MovieClip;
 
 
	public class MyGroup extends BaseMyGroup {
 
 
		public function MyGroup() {
			// constructor code
		}
	}
 
}

?

Искренне Ваш, Джек.

etc · 22.12.2010, 13:27

Моё кунг-фу подсказывает мне, что графические ассеты не надо ни от чего наследовать и вообще не должны содержать логику.

JackFromChaos · 22.12.2010, 21:06

Не согласен. Раньше я тоже так думал. Но в жизни бывает всякое...

Например, есть такой замечательный компонент, partigen, который позволяет редактировать системы части непосредственно в Flash. Что очень хорошо и правильно(как минимум потому, что графикой и анимацией должны заниматься художники, а не программисты). Собственно после покупки этого замечательно продукта я впервые столкнулся с описанной выше проблемой.

Другой вариант. В данный момент я делаю flash версию казуалки – quest/hidden object. На данном этапе программа написана таким образом, что конечные игровые сцены и т.д. можно собирать чисто во flash, причем «скриптовик» совершенно не обязаны знать программирование вообще и ActionScript в частности. Он лишь импортят сцену из psd, настраивают типы для символов(что тоже автоматизировано – написание специальной панели с кучей кнопочек для Flash), и кое где настраивают параметры, что можно сделать либо через код в кадре, либо через параметры компонента(правда с компонентами получилась накладочка. Во первых с ними мешает работать описанная выше ошибка, во вторых я не смог автоматизировать создание компонентов через jsfl).
Затем это экспортится, и подгружается в мое скопиленное во FlashDevelop приложение. Конечно без магии не обошлось, но в целом подход очень даже ничего, имхо.

Работая по такой схеме я пришел к выводу, что использование некоторой, пусть, минимальной логики на уровне Flash IDE все таки скорее хорошо, чем плохо. Почему не использовать Flash как редактор игровых уровней или еще чего то в таком роде? Почему, в конце концов, не сделать класс кнопочки «закрыть»?

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

В общем можно привести довольно много примеров, в которых, пусть не логика, но параметризация Ассетов на уровне Flash, намного лучше чем хардкодинг, и менее геморойно, чем разделение – параметры в excel, графика во flash и т.д.

Добавлено через 13 минут
Кстати, в проекте при подгрузки swf файлов со сценами используется ваша функция getDefinitions

etc · 23.12.2010, 16:40

hidden object я писал и обошелся написанием редактором комнат (с использованием View от игры это несложно и очень быстро), которую дизайнеры же и собирали, из их же либ с простыми граф. ресурсами без какой-либо логики. Опять же, использовался getDefinitionNames для оного.

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

JackFromChaos · 23.12.2010, 17:10

Ну, не совсем харкодинг... Есть набор достаточно умных классов- кубиков из которых строится игра. Дизайн игры – лишь настройка типов, имен и некоторых параметров(по необходимости).
Пример, для создания мини игры Hidden Object, нужно во Flash сцену с ХО, назначить определенный тип(HiddenScene), затем для символа-объекта участвующего в поиске, тоже назначить свой тип(HiddenObject). Ну для объекта может еще потребоваться специфичный коллизион, тогда делаем внутри векторное изображение с именем hit, которое в результате не будет отображаться, но по нему будет делаться HitTest. Публикуем, и все. Есть сцена с мини игрой в отдельной swf/swc(можно и так и этак). Если надо подправить логику самих классов, мы просто ее правим во Flash Develop в основном проекте, пересобирать swf со сценой не нужно(если классы задекларированы в основном проекте, то после загрузки ну или при статической линковке базовые классы сцены подменяются на основные из проекта).
Назначение типов делается 2 кликами – выбрать символ/символы в библиотеке, нажать нужную кнопку на специальной панели. Быстро, дешево, сердито.

Можно было бы и вовсе отказаться от логики в ассетах, но оставив типы HiddenScene, HiddenObject которые содержат в себе только необходимые для настройки свойства. А логику отделить. Для объектов вроде HiddenObject даже параметры не нужны, достаточно типа(интерфейса), по которому можно будет определить что данный ассет именно HiddenObject, а не скажем UseObject(применить один объект на другой). Имена экземпляров так же можно не задавать, а в качестве имен по умолчанию использовать имя класса(символа) в библиотеке.

Более простого варианта я не вижу. Дополнительные редакторы и внешние данные о сцене, вот это уже реально геморрой, по крайней мере для данного жанра. И шагов в производственном процессе куда больше.

(В данном случае я исключаю возможность импорта игровых данных из оригинальной игры, что было бы идеальным. Но по факту, в некоторых случаях, вроде моего, не реальном. На реализация на Flash движка самой игры уйдет больше времени, чем на самый жесткий хардкодинг, после этого оно еще и тормозит будет жутко. Но это конкретно в данном случае, могут быть исключения. Тем более, все равно, из игры 1024/768 сделать игру 640*480 нельзя не меняя логику самого прохождения и ручного изменения некоторых элементов графики.)

P.S.
http://www.alawar.ru/game/mystery-of-mortlake-mansion/

http://flash.porti.ru/flash/7824
А вот этот проект, кстати, как раз делался путем импорта данных из движка. Угрохали кучу времени, все равно пришлось много харкодить, и игровые уровни пришлось пересобирать, только не во Flash, а на desctop редакторе игры...

etc · 23.12.2010, 17:40

Такие вещи решаются (поведение объектов, в том числе и hit area) композицией. В целом, зависит от того, есть уже отработанная платформа или нет.

JackFromChaos · 23.12.2010, 19:06

Если под платформой понимается игровой движек обычной версии, то там разработка проходит похожим образом.
Создается PSD, со слоями, каждый из которых на выходе будет неким объектом. Тип объекта задается посредством специального синтаксиса в названии слоев. После импорта сцены в игровой редактор(возможен многократный реимпорт) на объекты вешаются скрипты и делаются настройки. По сути, приблизительно тот же процесс и та-же архитектура что и у меня во Flash.
Только у меня нет скриптов, а есть чуть менее универсальные объекты. На текущий момент моя flash платформа кажется более удобной, если уж на то пошло

etc · 23.12.2010, 22:45

Угу, это возврат к коду на кнопках и мувиках а-ля Flash 5. И возникшая проблема — следствие.

JackFromChaos · 24.12.2010, 14:26

Возникшая проблема – это ошибка Flash, а не результат неправильного использования или подхода. Она решаема как минимум одним способом, а вопрос был в том, можно ли ее решить еще как-то.
При этом я не увидел никаких убедительных аргументов в пользу того, что мой подход не правильный.
Задача программиста – это организовать удобную систему разработки, а не построение неудобной но «правильной» архитекторы MVC.
Бывают разные задачи, и к ним есть разные подходы, и далеко не всегда жесткое разделение логики и графики – оправданное решение.

etc · 24.12.2010, 14:32

JackFromChaos, даже Adobe, внедрив AS3, ушла от симбиоза графики с кодом. Ну это так, к слову. Как проблему решить, я не знаю, потому что предпочитаю указанный подход.