Tag Archive for 'Flash'

Unity & Flash – Friends

얼마전 San Francisco 에서 열린 Flash Gaming Summit 에서 Adode 가 Beta 버전의  Flash Player 인 Molehill 이 발표되었다.

이에 맞춰 Unity 가 Build platform 으로  Flash Player (Molehill) 를 지원하게 될거라는 충격적인 소식을 전했다. Flash Player 도 본격적으로 GPU 가속을 지원하기 때문에 Unity 가 Flash 를 지원할 수도 있을거란 생각을 가졌지만 실제로 이렇게 공식적인 지원을 발표할 줄을 몰랐다.

Unity 의  Web 3D 쪽에서 최대 약점인 낮은 플러그인 형태의 Player 배포율이 이 발표로 인해 한번에 해결될 수 있다는 의미이다. Unity 에서 제작하고 배포는 Flash Player 로 가능하다는 것이다. Flash 를 지원하는 만큼 개발언어도 ActionScript 를 지원한다. Unity 에서 제공하는 ActionScript API 를 이용하면 Flash 개발자도 Unity 에서 개발이 가능하다.

Flash 도 Molehill 로 인해 3D 컨텐츠를 개발가능할 수 있게 되었지만 아직은 low-level Shader 수준의 API 지원이라서 3D 개발에 있어 통합 IDE 가 없는 상태이다. 이 부족한 부분을 Unity 의 직관적인 tool 로 대체하여 개발한다면 Unity 와 Flash 양측다 득이 되는 제휴인것이다.

하지만 미래는 누구도 알 수 없다. 이 전략적 제휴로 인해 서로에게 기술이 흡수될 수도 있는 여지가 충분이 남아있다고 생각한다. Adobe 가 과연 3D IDE 를 어떤식으로 내놓을지 상당히 궁금해진다.

관련기사 : http://blogs.unity3d.com/2011/02/27/unity-flash-3d-on-the-web/

Online 3D Platform & Flash Developer

점점 온라인 플랫폼 시장이 3D 컨텐츠 중심으로 재편되어가는 것 같다. 사용자들은 기존에 경험하지 못했던 새로운 것을 원하고 시장은 늘 그 요구에 충족 시켜주는 구도로 볼때  어쩌면 자연스런 흐름이고 예정된 수순이였다.

온라인 3D 플랫폼은 크게 오픈소스 진영을 대표하는 WebGL 과  플러그인 기반의 Unity 3D 나 Adobe Flash 와 같은 기술이 대표적이다.

물론 Flash 는 현재 버전의 Flash Player 에서는 공식적으로 3D 게임과 같은 하드웨어 가속을 지원하지는 않지만 2011년도 전반기 내에 Molehill 이라는 low-level 의 GPU 가속 3D API 을 내놓을 것이라고 발표했다.
벌써 Alternativa3D 나 Away3D, Flare3D 같은  Flash 3D Framework 에서 도입하여 데모영상을 공개하였다. 영상만 가지고 속단할 수 없지만 기술문서에 따르면 기존의 Flash Player 10.1 에서의 렌더링 속도가 Z-buffer 가 없는 폴리곤 수천개를 30 fps 의 속도로 연산할 수 있었지만 새로운 API 에서는 Z-buffer 가 있는 폴리곤 수백만개를 full-hd 해상도에서 60 fps 의 속도로 연산가능하다고 한다.

이런 기술을 바탕으로 앞으로 Flash 를 이용하여 온라인 3D 게임을 개발 할 수 있는 환경이 점차 갖춰질 것으로 생각이 든다. 2D 개발에서의 개발편의성을 바탕으로 그동안 취약점으로 여겨졌던 3D 개발까지 본격적으로 지원된다면 Flash 기술은 다른 어떠한 플랫폼보다도 향후 시장을 선점할 수 있는 좋은 발판을 마련할 수 있을 것이다.

하지만 Flash 는 여전히 Flash Player 의 안정성 및 플러그인 기반에 따른 문제점을 드러내고 있다. 물론 Flash Player 가 플러그인이긴 하지만 보급율에 있어서 다른 플랫폼과는 거의 비교가 불가할 정도로 높기 때문에 사용자가 설치에 대한 거부감을 가질 수 있는 문제는 그렇게 많지는 않다.  그러나 점점 별도의 플러그인 없이 브라우저내에서 동작가능한 기술들이 속속 등장하면서 Flash 의 가장 큰 장점인 설치 보급률이 어찌 보면 의미없는 숫자가 될 가능성이 있다는 것이다.

Unity 3D 는  현재 나와있는 모든 플랫폼을 지원하는 유일한 엔진이다. Web,Standalone,Mobile(iOS,Android) 뿐만 아니라 Xbox,PS,Wii 와 같은 Console 게임도 지원이 가능하다. 또한 기존의 게임엔진과는 다르게 손쉬운 사용과 직관적인 툴로 인해 개발 생산성이 상당히 높다는 점이 장점이다.  이런한 무기들을 바탕으로 관련 개발자들이 전세계적으로 폭발적으로 늘어나는 추세이다. 실제로 Unity 제작사가 북미게임 웹진인 gamasutra 에서 세계 5대 게임 회사로 선정되었을 만큼 앞으로가 기대되는 엔진이다.

현재 Flash 가 점유하고 있는 수많이 온라인 캐쥬얼 게임이 Unity 3D 의 잠재시장이며 이미 많은 모바일 게임들이 Unity 를 이용하여 개발하고 있는 추세이다.

하지만 Unity 는 플러그인 방식으로서 사용하려면 사용자가 직접 설치과정을 거쳐야한다. 보급률이 아직까지는 웹에 사용할 만큼 높지 않은 관계로 어떤식으로 플레이어를 확산시키는가에 대한 문제를 가지고 있다. 반가운 소식은 google 크롬브라우저에 플러그인이 직접 임베드된다는 이야기가 있었다.

만약 그렇게 된다면 Unity 의 발목을 잡고 있었던 플레이어 보급률 확장에 있어 상당한 힘을 실어줄거라고 판단이 든다. 이 부분은 좀더 지켜봐야할 부분이다.

얼마전 Google Chrome 9 에서는 WebGL 을 기본적으로 지원한다고 발표했다. WebGL 은 그래픽카드의 하드웨어 가속기술을 사용하여 웹 브라우저 내에서 특별히 플러그인 없이 3D 컨텐츠를 원할하게 작동시킬 수 있는 기술이다. 이 기술을 활용하면 Web 에서 Flash Player 나 Unity Player 없이도 3D 컨텐츠를 사용할 수 있다는 의미이다. 어떻게 보면 가장 진일보하고 웹표준에 가장 근접한 기술이다. 하지만 이또한 모든 브라우저에서 WebGL 을 지원하는 않으며 기술 또한 표준화가 이루어질려면 적어도 몇년은 지나야 제대로된 컨텐츠를 제작할 수 있을것이다. 그리고 브라우저내에서 작동하는 방법으로 모든소스코드가 공개되는 문제가 들어나 얼마나 상용컨텐츠 제작회사들이 이를 이용할지 미지수이다.

그야말로 현재 온라인 3D 플랫폼은 춘추적국시대이다. 어떠한 플랫폼이 표준으로 자리잡을지 누구도 알 수 없다. 기술 변화속도가 워낙 빨라 현재의 유망기술이 한순간에 쓸모없는 기술로 변할 수 있다. 더욱이 어느 한개의 기술에 종속되어 개발하는 개발자라면 그 결과에 울고 웃을 수 있다라는 점은 자명한 사실이다. 물론 모든 유망한 기술들을 다 익히면 해결되는 문제이지만 그렇게 기술들이 호락호락하지 않다.

분명한 점이 현재의 흐름은 3D 라는 점이다. 그 기술이 Flash 가 되었건 Unity 가 되었건간에 중심은 3D 기술이다. 이 사실은 아마 변하지 않을 것으로 생각이 든다. 우선 3D 기술의 원리, OpenGL , Shader 등등 3D 에 기본적인 기술을 갖추어 준비한다면 앞으로 도래하는 3D 기술을 사용하는데 있어 상당한 우위를 점할 수 있을 것이다.

Flash Player 의 3D 가속지원으로 앞으로 누구나 공개된 영상처럼 3D 컨텐츠를 개발할 수 있다고 생각하는 플래시 개발자가 많을 것이다. 앞으로 공개되는 Flash 3D API 는 정말 Low-level 수준의 Shader API 이어서 전문적인 3D 개발자가 아니라면 쉽게 퀄리티 있는 3D 컨텐츠를 개발한다는 것이 생각보다 쉬운것이 아니다. 물론 Alternativa3D 나 Away3D, Flare3D 같은  Flash 3D Framework 가 이를 이용하여 좀더 쉽게 사용할 수 있도록 High-level 수준의 API 를 제공할 것이다. 하지만 기술적인 이해를 바탕으로 접근한 전문개발자들이 보다 기술대처에 빠르게 대응할것이고  제대로된  GPU 기능을 활용하여 멋진  3D 컨텐츠들을 만들어 낼것이다. 점점 개발자들 사이에서의 기술편차가 커질것이 분명하다.

플래시 … 상당한 매력적인 기술이다. 디자인 툴에서 출발해 현재는 개발툴로서 변화하였고 인터랙티브 컨텐츠에 있어서 어떠한 툴보다 경쟁력이 있는것은 사실이다. 또한 이런툴을 사용하는 플래시 개발자들도 Unity 나 HTML5 와 같은 향후 등장하는 기술들을 활용하여 인터랙티브한 컨텐츠 개발할 수 있는  상당한 경쟁력을 가지고 있다고 생각한다. 혹시나 미래에 Flash 기술이 사라진다고 해도 그걸 대체하는 기술들을 활용하는 사람들은 분명 플래시 개발자들이 한 축을 형성할 것이다.

플래시개발자들….새로운 기술에 대해 너무 두려워말자.

앞으로의 3D 기술들을 차근히 준비하면 분명 자신도 모르는 사이에 Gears of War 와 같은 컨텐츠를 Flash 에서 제작할 수 있을지도 모를일이다.

URL Encoding

escape 함수
escape(expression:String) : String
매개 변수를 문자열로 변환하거나 영숫자가 아닌 모든 문자를 % 16진수 시퀀스로 바꾸는
URL 인코딩 형식으로 인코딩합니다. URL 인코딩 문자열에서 사용되면 퍼센트 부호(%)는
이스케이프 문자를 시작하는 데 사용되고 이는 모듈러스 연산자(%)와 동일하지 않습니다.

URL인코딩은 웹에서 흔히 볼수 있는 것으로
“kimkijeung%20vkimone”를  “kimkijeung%vkimone” 이런식으로 인코딩을 하는 것을 말한다.


외부 데이터와 연동을 시킬 때는 꼭 사용해야 에러를 막을 수 있다. 반대로 바꿔 주는 함수로는 unescape 가 있다.


예) a=escape(“김기정”);
    trace(a);


/* 이 구문을  실행하면 output 창에


%EA%B9%80%EA%B8%B0%EC%A0%95


과 같이 나온다. */


다른 나라 사람의 언어 환경을 고려하지 않는다면 별 해당사항이 없겠다.
하지만 각 나라마다 고유의 언어 셋이 있어 나라 별로 컴퓨터에서 사용하는 언어가 다르다.
플래시에서 그냥 static field 를 사용하여 작성한다면 그냥 적은 그대로 보이겠지만
외부 데이타를 가져 와서 보여 줘야 한다면 반드시 주의할 점이 있다.

플래시에서의 정보는 유니코드(utf-8) 로 입출력된다. 플래시가 기본적으로 외부 텍스트를 해석할테
System.useCodePage 값을 true 로 설정하지 않느다면 말이다.

useCodePage  는 Flash Player가 외부 텍스트 파일을 해석할 때 유니코드를 사용할 것인지 현재 운영 체제의 기존 코드 페이지를 사용할 것인지 여부를 지정하는 부울 값이다
간혹가다 유니코드로 인코딩 되지 않은 외부데이타를 불러올때 플래시에서 깨져서 보이는 경우가 있다. 이럴때 useCodePage 값을 true 로 설정하면 현재 운영체제에 맞는 코드 페이지를 사용하여 텍스트가  재대로 보이게 된다.

하지만, System.useCodepage를 true로 설정하는 경우, 현재 운영 체제의 기존 코드 페이지에 외부 텍스트 파일에 사용된 문자가 포함되어 있어야만  텍스트를 표시할 수 있습니다. 예를 들어, 중국
어 문자가 포함된 외부 텍스트 파일을 로드하는 경우, CP1252 코드 페이지에는 중국어 문자
가 들어 있지 않기 때문에 이 페이지를 사용하는 시스템에서 이 문자들이 표시되지 않는다.

모든 운영 체제 사용자가 SWF 파일에 사용된 외부 텍스트 파일을 볼 수 있게 보장하려면 모
든 외부 텍스트 파일을 유니코드로 인코딩하고 System.useCodepage를 기본값인 false로 설
정해야 한다.

하지만 이걸로 모든 문자가 표시되는 것이 아니다. 플래시에서 데이타를 저장하고 그걸 다시 불러올때 이런 방식으로 해도 데이타는 원하는 값을 표시할수 없다.
반드시 특수문자나 다른 나라 언어를 저장할때는 텍스트 정보를 URL 인코딩 방식으로 변환하여 보내야 한다.

여기서 escape, 와 unescape 를 사용하면 된다.
그리고 반드시 URL 인코딩을 사용하려면  System.useCodepage 는 기본값인 false 로 놓아두어야 한다. 그렇지 않으면 각 나라의 운영체제의 코드 체계의 문자들의 바뀌어져 인코딩 되어 다른 결과가 보여질 것이다.

Classes in As and Java or C++

[퍼온글] 출처 : <Flex 2 language Reference 36 page>

Programmers familiar with object-oriented programming (OOP) in Java or C++ may think of objects as modules that contain two kinds of members: data stored in member variables or properties, and behavior accessible through methods. The ECMAScript edition 4 draft, the standard upon which ActionScript 3.0 is based, defines objects in a similar but slightly different way. In the ECMAScript draft, objects are simply collections of properties. These properties are containers that can hold not only data, but also functions or other objects. If a function is attached to an object in this way, it is called a method.
While the ECMAScript draft definition may seem a little odd to programmers with a Java or C++ background, in practice, defining object types with ActionScript 3.0 classes is very similar to the way classes are defined in Java or C++. The distinction between the two definitions of object is important when discussing the ActionScript object model and other advanced topics, but in most other situations the term properties means class member variables as opposed to methods. The Flex 2 Language Reference, for example, uses the term properties to mean variables or getter-setter properties. It uses the term methods to mean functions that arepart of a class.

One subtle difference between classes in ActionScript and classes in Java or C++ is that in ActionScript, classes are not just abstract entities. ActionScript classes are represented by class objects that store the class’s properties and methods. This allows for techniques that may seem alien to Java and C++ programmers, such as including statements or executable code at the top level of a class or package.

Another difference between ActionScript classes and Java or C++ classes is that every ActionScript class has something called a prototype object. In previous versions of ActionScript, prototype objects, linked together into prototype chains, served collectively as the foundation of the entire class inheritance hierarchy. In ActionScript 3.0, however, prototype objects play only a small role in the inheritance system. The prototype object can still be useful, however, as an alternative to static properties and methods if you want to share a property and its value among all the instances of a class.

In the past, advanced ActionScript programmers could directly manipulate the prototype chain with special built-in language elements. Now that the language provides a more mature implementation of a class-based programming interface, many of these special language elements, such as __proto__ and __resolve, are no longer part of the language.

Moreover, optimizations of the internal inheritance mechanism that provide significant Flash Player performance improvements preclude direct access to the inheritance mechanism.
actionscript 와 java or c++ 의 class 간의 개념이 약간 다르다.
어찌보면 다아나믹한 움직임을 구현하기 위해선 필요한 차이점인지 모른다.
그래도 ECMAScript 기반의 언어라 그런지 java 와는 외향이 거의 흡사해진다는 느낌이다.

prototype 은 뭔가 꺼림직해서 이전부터 건드리지 않은 부분이지만 아니나 다를까 성능에 문제가 있을 수 있다고 하니 protoype object 는 터치하지 말아야 겠다…

The delete Keyword

The delete keyword in Flash is used to remove variable definitions. It doesn’t delete objects from memory (this happens behind the scenes using something called the “Garbage Collector”), it just takes a variable you’ve created and gets rid of it so that it is no longer accessible and is no longer present through iteration (for..in loops, etc.).

Internally, the Garbage Collector, or GC for short, knows when to physicially delete objects in memory when they no longer have any variables that reference them. So, for example, if you have two variables A and B and they both reference ObjectX, deleting variable A will not cause ObjectX to be removed from memory by the GC because variable B still references it. However, if you delete both variables A and B, there will be no more references to ObjectX and the GC will recognize that it needs to be removed from memory

ActionScript Code:

var a:Object = new Object();

var b:Object = a; // reference same new Object();

delete a;

trace(b); // [object Object] – still exists in memory

delete b; // GC will mark object for deletion from memory

This works practically the same way for Flash 8 and Flash 9 (ActionScript 1, 2, and 3), though some changes were made in 8 to improve the GC. (Note: GC deletion from memory is not immediate.)

Though the GC has not really changed much with ActionScript 3 and the new virtual machine that runs it, what has changed is the behavior of the delete keyword. Now, the delete keyword only works for dynamic properties of a class instance and not declared class memebers (variables or methods). With ActionScript 1 and 2, delete could be used for anything. ActionScript 3 only lets you delete dynamic variables and locks those which are not.

// ActionScript 2

class DeleteVarClass {

public var myVar:Number;

function DeleteVarClass() {

myVar = 1;

trace(myVar); // 1

delete myVar;

trace(myVar); // undefined

}

}

// ActionScript 3

package {

public class DeleteVarClass {

public var myVar:Number;

public function DeleteVarClass() {

myVar = 1;

trace(myVar); // 1

delete myVar;

trace(myVar); // 1

}

}

}

Because myVar in the above example was declared as part of the class definition, it cannot be deleted using delete in ActionScript 3.

Since you cannot delete class members in ActionScript 3, if you want to cause a variable to no longer reference an object or value in memory you should set your variable’s value to null instead of deleting it.

Garbage Collectors는 참조값이 없는한 사용되지 않는 변수에 대한 메모리를 자동으로 찾아서 소거해주는 메모리 소거 프로세스이다. 기능상으로는 AS2.0 이나 AS3.0 이나 크게  달라진 부분은 없지만 한가지, AS3.0 에서는 클래스 맴버변수로 선언된 변수는 제거할수 없게 바뀌었다.

ZenDoc 1.0 Released

ZenDoc 1.0 has been released.

ZenDoc is a free, open source ActionScript documentation utility for converting AS 2 class files commented with JavaDoc style comments into HTML documentation.

JavaDoc 형식으로 작성한 AS2.0 파일을 Html 형식의 문서로 전환해 준다.

로컬에서 작동하는 Application이 아니라 웹서버(PHP)에서 실행되는 형식이다.

개인적으로 작성한 클래스 파일을 이런형식으로 만들어 보는건 큰 의미는 없겠지만 제작한 클래스를 배포하거나 공동작업에 필요한 클래스를 공유할때 다른사용자에게 유용할듯 싶다.

주석을 JavaDoc형식으로 작성하긴 하지만 빠쁠땐 그냥 넘어가는 경우도 있는데 나중을 위해 좀더 부지런해져야 할 것같다.

Actionscript initialization

flash에서 어느정도 actionscript 를 다룰줄 아는 사람이라면 output 창을 통해 출력되는 에러메시지나 오류를 해석해서 문제를 해결할 수 있다. 하지만 정말정말 코딩 자체에 사소한 실수가 없다는 생각이 들때,…..

왜 생각한대로 작동안하는걸까?…이건 분명 프로그램 버그일거야….

라는 생각이 들때가 있다…..하지만 컴퓨터는 거짓말을 하지 않는다. 분명 어떤 문제로 인해 생각한대로 작동하지 않을뿐이다.
이런 문제의 상당부분은 바로 플래시의 초기화 문제이다.(많은 경우가 이런 상황에 부딪힐수 있다는 의미) 즉 무비클립을 attach 하거나 컴포넌트(component) 를 사용했을경우…..특히 자주 발생하는 듯 싶다.

무비클립의 초기화 과정은 타임라인 이후에 일어난다. 따라서 제아무리 처리속도가 빠르다 하더라도 덩치가 큰 프로그램일경우 초기화하는  과정에 어느정도  딜레이가 발생하게 된다.

특히 웹에서 실행할경우 로딩을 고려하지 않고 제작할 경우 문제가 심각해진다. 또한 클래스로 제작할경우 즉 좀 복잡한 로직에 의해 구현되는 어플리케이션이나 사이트일 경우 연결한 무비클립이나 컴포넌트와 같은 프레임 상에 클래스를 사용하여 코딩을 했을 경우 초기화 타임으로 인한 오류가 발생할수 있다는 것이다.

플래시에서 제공하는 컴포넌트는 특히 덩치가 더 커서 상대적으로 프레임에 나타났을때 인식하는 속도가 느리다.(사람이 체감하지 못하겠지만 컴퓨터처리속도는 아마도…)

따라서 컴포넌트를 사용할경우 그것에 해당하는 클래스의 처리순서를 똑 어느정도 딜레이를 주어 처리한다면 초기화 문제를 해결할수 있을 것이다. 1frame 정도 후에 처리한다면 초기화하고도 충분한(?) 시간…..^^

/*----------------------------------------------------------------------------------
  @description 프레임 딜레이 함수
  @param scope : Object, 실행할 함수의 스코프
  @param callback : Function, 콜백함수
  @param delayFrame : Number, 딜레이프레임
*---------------------------------------------------------------------------------/
 
  public static function frameDelay():Void{
    var obj = arguments.shift();
    var func = arguments.shift();
    var delayFrame=arguments.shift();
 
   var p:Array=arguments;
   var mc:MovieClip=_root.createEmptyMovieClip("frameDelay",_root.getNextHighestDepth());
 
   mc.onEnterFrame=function(){
    trace(delayFrame);
    delayFrame--;
    if(delayFrame&lt;1){
 
     delete  this.onEnterFrame;
     func.apply(obj,p);
        this.removeMovieClip();
     }
   }
 
  }

Singleton pattern 에서 유의사항

Singleton pattern 으로 객체를 생성했을경우 플래시에서 뜻하지 않은 상황이 발생한다.

플래시에서 Export 한 후 Download simulate 를 하면 알수 없는 이유로 프로그램이 진행이 되질 않는다. 이것은 프로그램의 오류가 아니라 Singleton pattern 에서 인스턴스 참조값을 저장하기 위해 사용한 전역변수가 문제다.

다시말해, 플래시에서 simulate 를 하기 위해서는 Export 한 상태에서 한번 더 Ctrl+ Enter 을 눌러야된다. 이 상황에서 플래시는 메모리에서  전역변수를 소거하지 않고 그대로 남아있는 상태가 된다.

Singleton pattern 에서는 반드시 인스턴스는 단 한번 밖에 생성되지 않는다.

따라서 한번 Export 해서 생성된 인스턴스로 인해 simulate 할경우 원하지 않은 상황이 발생한다.

private static var sInstance:FramePulse = null;
public static function getInstance () : FramePulse {
    if (sInstance == null) {
      sInstance = new FramePulse();
    }
    return sInstance;
}

–> Download 테스트 시 메모리가 소거 되지 않아 전역속성인 sInstance 로 인해 인스턴스를 생성할 수 없다.

Event Programming

플래시 자체가 이벤트 기반의 프로그램이다 보니 발생하는 이벤트 중심으로 코딩하는 방법이 로직상이나 가독성 측면에서 좋은 코딩 방법이라는 생각이 든다.

하지만 이벤트 별로 패턴을 나누다 보니 코드길이가 자연스레 길어지고 이벤트 리스너(addEventListener) 를 연결하는 시간과 인스턴스를 초기화하는 시간과의 차이로 인해 적지않은 문제점이 발생한다.

var myLoader:XmlLoader=new XmlLoader(this,UrlSet.xmlUrl+"navigation.xml",100,100);
 
myLoader.setXmlAttribute(["label","src","loadingPos"]);
myLoader.addEventListener(XmlLoaderEvent.ON_START,this);
 
function onStart(evt:XmlLoaderEvent){
      myLoader.removeEventListener(XmlLoaderEvent.ON_START); 
   //파싱완료후 실행함수
 
}

간혹가다 인스턴스(myLoader ) 초기화보다 인스턴스 메소드가 먼저 실행되는 이상한 일이 발생할 경우가 있다.

Runtime Exceptions And Types

In ActionScript 2.0, type annotations were primarily a developer aid; at runtime, all values were dynamically typed. In ActionScript 3.0, type information is preserved at runtime, and utilized for a number of purposes. The Flash Player performs runtime type checking, improving the system’s type safety. Type information is also used to represent variables in native machine representations, improving performance and reducing memory usage.

단순히 개발자의 코드 가독성을 위한 도구였던 데이타 타입 설정이 As3.0 에서는 진정한 데이타 타입으로서 기능하게 되었다. 컴파일 타임에서의 데이타 타입의 체크에서 끝났던 것이 이제는 런타임에서도 타입체크가 가능하다.

이로써 실시간 예외처리도 가능해졌다. 플래시에서 가능 취약했던 부분인 런타임 디버깅이 비약적으로 발전했다. 이제보니 플래시가 스크립트 언어라고 하기엔 너무 커진것 같다는 생각이 든다..^^