Flash 개발하면서


지겹도록 쓰는 구문 두개가 바로 다음이 아닐까 합니다.


public class Game
{
     public function Game()
     {
     }
}


var game: Game = new Game();


거의 1+1 수준으로 외워서 쓰고 자주 쓰다보니 그 의미를 이해할 기회가 없었습니다.


하지만 이런 생각 해보신 적 없나요?


왜 초기화 함수에는 리턴 타입을 선언해주지 않는거지?


public function Game()


이라고만 쓰지 


public function Game(): Game


이런식으로 쓰지 않습니다.


왜 일까요?


그 이유는 Virtual Machine이 해주는 일을 숨겨주기 위한 것입니다.


결론부터 간단하게 이야기하자면


이 초기화 함수의 숨겨진 부분은


다음과 같습니다.


public class Game
{
     public function Game()
     {
          // do something
          
          return this;
     }
}


바로 return this 부분이 VM이 몰래 해주는 일입니다.


예를 들기 위해서 알아보기 쉬운 코드로 적은 것입니다. 실제로 저렇게 돌아가진 않아요 ㅋㅋ




그럼 더 깊게 들어가볼까요?


깊게 들어가기 위해서는 다음 구문을 주의 깊게 봐야합니다.


var game: Game = new Game();


자 여기서 실제로 VM이 하는 일은 크게 3가지로 나눌 수 있습니다.


1. 메모리 할당

var game: Game = new Game();


2. 초기화 함수 실행

var game: Game = new Game();


3. 좌항 대입

var game: Game = new Game();


하나씩 살펴보죠.




1. 메모리 할당


new 라는 키워드는 예약어죠.


유저가 변수나 클래스명으로 쓸 수 없다는 것이죠.


이 new 라는 명령어가 하는 역할은


뒤에 오는 클래스를 가져다가


이 클래스의 인스턴스를 만들기 위한 메모리를 할당합니다.


만약 


public class Game
{
     public var name: String = "merong";
     public var id: int;

     public function Game()
     {
          id = 12;
     }
}

이런 클래스가 있다고 하면


new Game 이라고 하면


Game이라는 클래스를 보고


"아 이 클래스는 name이라는 String 변수가 있으니 이곳(메모리주소)에다 값을 적을 준비를 해야겠다.


그리고 id 라는 int 변수가 있으니 이곳(메모리주소)에다가 4바이트(32비트) 공간을 자리 잡아놔야지"


라고 하는 것입니다.


즉, 클래스의 구조를 보고 그대~로 메모리를 비워놓는거죠.




2. 초기화 함수 실행


초기화 함수에서는 이렇게 자리 잡아놓은 메모리에


값을 넣는 역할을 합니다.


위에서


public var name: String = "merong";


이라고 써있는 부분은 마치 초기화하지 않아도 기본으로 값이 들어가 있을 것이라고 생각할 수 있지만


컴파일을 하는 순간에 다음과 같이 코드가 inline 화 됩니다.


public class Game
{
     public var name: String;
     public var id: int;

     public function Game()
     {
          name = "merong";
          id = 12;
     }
}

초기화 함수가 하는 일로 치환된다는 것이죠.


즉 new Class() 에서 () 이 괄호가 하는 일은


초기화 함수를 그저 "실행"만 시켜주는 역할을 합니다.


Q) Flash에서는 new Game; 이라고만 해줘도 된다는데요?


A) Flash는 기본적으로 클래스명과 동일한 함수를 초기화 함수로 인식합니다.


반대로 유추하면 내부에서는 초기화 함수를 내 마음대로 지정할 수도 있다는 뜻입니다. (클래스명은 Game인데 초기화 함수는 createGame 메소드로 한다던가)


하지만 이렇게 되면 VM이 처리해야하는 일이 너무 많아지고


개발자도 소스 분석이 어렵게 되는등 패널티가 많아집니다.


이 약속하나로 얻어지는 이득이 매우 많기 때문에


클래스명과 동일한 메소드명을 초기화 함수로 하자는 "약속"인 것입니다.


이렇게 값이 대입되고 


인스턴스로 쓰일 준비가 되면


마지막에 함수 끝에서 return this 라고 숨겨진 코드가 실행하게 되면서 자기 자신을 넘기게 되죠.




3. 좌항 대입


이렇게 초기화 함수에서 넘어온 객체를


좌항에 대입하게 되는 것입니다.


다들 아시겠지만


리턴 값이 void 인 메소드는 대입하는 구문에 쓰면 에러가 나죠.


function setName( $name: String ): void
{
     _name = $name;
}

// 에러
var currentName: String = setName( "merong" );


하지만 객체를 반환하는 메소드일 경우에는 정상적으로 동작합니다.


function setName( $name: String ): String
{
     _name = $name;

     return _name;
}

// OK
var currentName: String = setName( "merong" );


이해가시죠?


왜 초기화 함수에는 리턴 타입이 없는지?


자기 자신을 반환하기 때문입니다.


엄밀하게 따지면 메모리 주소 즉, 포인터를 넘기기 때문입니다.







var game: Game = new Game();


이 간단한 구문에 이렇게 복잡한게 숨어있었을줄 저도 몰랐습니다.


이제 여러분이 짜는 코드에 조금 더 새로운 눈으로 코딩을 하실지도 모르겠습니다.






For the better.




이상하게 데스크탑에서 Scout가 어느날부터 안돌아가더니 업데이트되도 안돌아가더군요.


그래서 맥북으로 Scout을 띄워서 모바일 게임을 프로파일링하고 있었는데


데스크탑 게임은 어떻게 하나 궁금하더군요.


분명 ip 지정하면 데탑용도 원격으로 프로파일링이 될텐데 말이죠.


방법은 모바일 앱에 telemtry 추가하는것과 동일하더군요.



1. 다음 폴더로 이동합니다.


Windows : C:/Users/사용자 이름/

OS X : ~/



2. ".telemetry.cfg"라는 파일명으로 파일을 하나 만듭니다.




3. 다음 내용을 추가합니다.



TelemetryAddress=[IP]

SamplerEnabled = true

CPUCapture = true

DisplayObjectCapture = false

Stage3DCapture = false



이 후에 Telemetry 추가해서 돌리는건 생략하겠습니다 ㅎㅎ


이렇게 설정하시면 이제 내 컴퓨터에서 돌아가는 모든 SWF 컨텐츠는


TelemetryAddress에 있는 Scout에서 프로파일링 됩니다.




For the better.




부제 : "도전을 해본적 없는 개발자들에게 하는 잔소리"




Starling으로 개발을 하는 곳이 거의 없다보니


나에게 Starling이나 Flash의 전망을 넋두리하는 사람이 꽤 많아졌다.


요약을 하자면 이렇다.


Flash는 망해가는거 같은데 신기술을 보아하니 그럴싸해보이고

내 실력은 하찮은데 잘 만든 것들 보면 또 멋있어보이고

나도 그렇게 되고 싶은데 어떻게 해야할지는 모르겠고


확 도전하기에는 Flash의 전망이 어두워서 꺼려진다.


- ZDNET : 어도비, 플래시 잊고 HTML5로 "새출발"

- ZDNET : 어도비 플래시출구전략?


(이런 제목의 기사들을 보고도 Flash 전망을 밝게 본다면 그것도 이상하긴 하다....)




결과는 하나같이 이렇게 귀결된다.


"포기"


대학생들이 멋도 모르고 영화 감독도 되고 싶고 비행기 조종사도 되고 싶고 소설가도 되고 싶은데 


현실은 편의점 알바에서 벗어나지 못하는 그런 상황이다.


빗대자면 그렇다는 것이다.




왜 그럴까?


가만히 듣다보면 본인들의 주장속에 모순이 종종 발견된다.


Flash의 전망을 비관적으로 보는 이들의 생각의 근거는 이렇다.


"HTML5에 밀리고 Flash 컨텐츠 수요가 확 줄었고 앞으로도 줄어들 것이다."


이 말은 사실이다.


하지만 Flash가 멋있어보인다는 그들의 생각의 근거는 이렇다.


"하드웨어 가속이 되면서 성능 쩔더라 Unity 안해도 되겠더라. 게다가 웹, 모바일까지 다 되지 않느냐"


반은 맞고 반은 틀리다.


성능은 좋아졌다. 확실히.


그리고 모바일, 웹 둘다 된다.


그러나 다 되긴 하지만 다 잘 되진 않는다.


전망은 어두운데 다 되니까 괜찮다? 모순이다.


왜 이런 모순이 생기는 것일까?


그것은 바로 "만들 수 있는"것과 "잘 만드는"것은 다르다는 것이다.


바로 이 부분에서 Flash에 대해 막연히 가졌던 기대감이 꺾이는 부분이다.


간단하고 작은 애플리케이션을 개발하려면


Flash 만한 개발환경이 없다.


이건 사실이다.


(아마 Flash 개발하다가 Objective-C나 Android 개발해보신 분들은 Flash의 무비클립이 얼마나 대단한 기술인지 새삼 깨닫게 되는데 이것이 그 증거가 아닐까)


하지만 완성도 있고 규모있는 애플리케이션을 개발하는 것은 


문제가 달라진다.




오래전부터 Flash 개발자들이라면 누구나 한번쯤 들어봤던 말이 있을 것이다.


"그거 C로도 다 되는건데 왜 Flash로 해? C로 하는게 훨씬 빨라"


당시에는 반박할 수 있는 논리를 가진 사람은 많지 않았다.


그 논리는 생각보다 복잡한게 아니었다.


"구현이 편리하다."


이게 다다.


여기서 Flash 개발자들의 장점이자 약점이 시작된다.


장점은 편리하기 때문에 좋은 아이디어들이 구현물로 나오는 시간이 굉장히 짧다.


게다가 디자인과 협업하기 좋기 때문에 다른 언어들의 개발 환경에 비해 디자인 협업이 쉽다. (고로 같은 노력으로 더 훌륭한 디자인이 가능하다)


단점은 편리하게 개발할 수 있는 환경이기 때문에 CPU나 메모리를 상대적으로 많이 쓰게 되고


결국 "성능"보다는 "비쥬얼"에 집중되어 왔다.


다른 언어 개발자들이 지적했던 부분은 바로 이 "성능"에 있었다.


"float도 없는 언어가 무슨 언어란 말인가?"


그런 뜻이다.




다시 본론으로 돌아가서


바로 위에서 언급한대로 Flash는 "잘 만들"기 위해서라기보다 "편리"하게 만들기 위한 개발 환경이었다.


Macromedia나 Adobe가 업데이트를 통해서 발전해온 과정을 한번 살펴보자.


ActionScript 3.0이 나오면서 int, uint가 생겼고


ByteArray가 생겼으며


Dictionary도 생겼고 소심한 overload 도 가능하게 됐고 (참고 : http://javahwan.tistory.com/45)


BitmapData는 디자이너에게도 충격적인 변화를 이끌게 했다.


최근에는 Stage3D를 지원하면서 AGAL(Adobe Graphics Assemble Language)까지 지원하면서


그래픽 칩셋의 파이프라인까지 사용할 수 있게 되었고


바보같은 멀티 쓰레드인 Worker까지 등장했다.


그렇다면 여기서


왜 Flash는 더 멋진 효과나 더 멋진 필터를 업데이트하지 않았을까?


왜 무비클립의 기능을 더 추가하지 않고


왜 비트맵의 크기 제한을 소심하게 늘릴까? 그냥 무제한으로 하면 왜 안되나?


이런 질문을 한번 해볼 필요가 있다.


내가 내린 결론은 이렇다.


더 멋진 효과나 더 멋진 비쥬얼은 개발자의 몫이지 플랫폼 제공자의 몫은 아니다.


플랫폼 제공자의 몫은 더 많은 환경에서 더 원활하게 같은 코드가 돌아가게 하는 것이다.


새로운 기능을 제공하는 것도 중요하지만 더 성능좋고 더 적은 메모리로 돌아가게 해서 


더 많은 비쥬얼과 실력이 있고 원한다면 그만큼 더 훌륭한 결과물을 만들 수 있는 "가능성"을 제공해야한다.


그렇기 위해서 ByteArray를 제공함으로써 byte를 다룰 수 있게 해주었고


Dictionary를 제공하여 포인터를 사용할 수 있게 했으며


BitmapData를 제공함으로써 메모리의 낭비를 줄이게 해줬다.




다른 언어도 그렇겠지만 Flash Player의 업그레이드 히스토리를 보면 


"쉽게 개발할 수 있지만 실력이 된다면 그에 상응하는 성능을 가능하게 해주는" 업데이트를 한 것이다.




여전히 Flash는 편하다.


내가 자주 드는 예인데 비디오 플레이어 만드는데 


지금까지 나온 그 어떤 언어보다 훨씬 빠르게 만들 수 있다. (Video, NetStream 객체 두개만 만들면 끝이다.)


하지만 "최고"의 애플리케이션을 만들 수는 없었다.


비디오 플레이어를 만들기는 편하지만


곰플레이어와 KMP같은 플레이어는 흉내도 못내었고


차트 프로그램을 만들수는 있지만


은행권에서 쓰이는 대규모 그래픽 차트는 꿈도 못꿨다. (이때문에 금융권에서 Flex를 걷어내는 것이 유행이 되었다)


숫자마추기 게임은 만들 수 있지만


디아블로같은 게임은 ... 굳이 이건 말 안해도 될거 같다.




다시 맨 처음 사람들의 넋두리로 돌아가서 생각해보자.


그들이 자신도 모르게 왠지 Flash가 괜찮아보이는 희망의 실체가 이것이다.


이제는 곰플레이어나 디아블로 같은 게임을 만들 수 있게 된것이다.


물론 아직 더 많은 연구와 더 최적화된 Flash Player가 나와야겠지만


거의 근처까지 온 것이다.


Farmville 2, Cityville 2, Angry Birds Friends, Square Enix Birts


이게임들을 보면 어느정도까지 발전했는지 알 것이다.


이제 원한다면 원하는 수준까지 성능을 낼 수 있게 되었다는 것이다.




이제 슬슬 결론을 이야기할 때가 왔다.


넋두리를 하는 사람들의 망설임의 실체는 이것이다.


"편하게" 개발하는 것은 그동안 해와서 괜찮았는데


"최고"로 개발하는 것이 어려워보이기 때문에 망설여지는 것이다.


Flash의 전망이 어두워서 망설여지는 것이 아니라는 것이다.


비겁하게 HTML5 핑계대지 말길 바란다.


HTML5 때문에 Flash가 "웹 브라우져"시장에서 인기가 없어진 것은 맞다.


하지만 여전히 마이크로 사이트는 풀플래시로 만들어지고 있고


여전히 배너는 플래시로 만들어지고 있으며


여전히 이러닝은 플래시로 만들어지고 있고


네이버의 로그인은 아직도 플래시를 걷어내지 못하고 있다. (네이버의 보안 2단계 로그인은 commonLoginF.swf로 이뤄진다)




눈앞의 밥그릇이 바람에 등뒤로 움직인것이지 밥그릇이 사라진 것이 아니다.


뒤돌아앉는 도전만 한다면 밥그릇을 다시 찾을 수 있다.




페이스북 게임은 앞으로도 계속 Stage3D 기능을 활용하여 Flash 천하를 이어갈 것이고


화려한 홍보를 위한 인터렉티브 사이트는 앞으로도 Flash 로 개발될 것이다.


모바일 앱도 간단한 타이머나 미니게임은 Flash도 한 축을 담당하게 될 것이다.




이 글의 결론은


Flash 개발자가 떠나는 이유는


Flash의 전망이 어두워서가 아니라 "최고"를 만드는 개발자가 되기를 무서워하는 중급 개발자들이 많기 때문이다.


한 가지 악담을 하자면


그 개발자들은 Flash가 아니라 C++이나 Java 개발자가 되었었더라도 디아블로 같은 게임이나 곰플레이어 같은 프로그램은 만들지 못했을 것이다.


그 이유는


최고의 애플리케이션을 만들기 위해서 필요한 알고리즘이나 개념들은


언어에 귀속되지 않기 때문이다.


A Star 알고리즘


Binary Search, 허프만 알고리즘


Matrix 연산


ASE 암호화


SSL 통신 기법


Shader Program


Data Driven Programming


JSON, BSON, AMF


File Format, zlib, deflate, XOR 암호


위 기술한 알고리즘들은 모두 ActionScript로 구현이 가능한 것들이다.


이중에 몇개나 들어봤으며 몇개나 손으로 구현해보았는가?




이제 마지막으로 "최고"의 애플리케이션을 개발할 수 있게 되려면 어떻게 해야되는지


지금 벗어나지 못하는 환경에서 할 수 있는 최선의 방법을 몇가지 제안해보겠다.


"귀찮거나 어렵다고 느껴져도 꼭 도전해보기 바란다~"


이런말 하지 않겠다. 


여기 적는 내용들은 소위 "고급"개발자들이 들으면 코웃음 치는 내용들이다. 당연한거 아니냐고.




 - 한글 레퍼런스, 한글 검색 하지 마라.


무조건 영어로 검색하고 주석도 영어로 달고 영어 레퍼런스 봐라.


개발자가 한글로 검색한다는 건 창피해야 할 일이다.


 - 다른 사람 코드 보기를 힘들어하지 말고 내 코드를 다른 사람 보여주는걸 부끄러워 말아라.


빌게이츠도 남의 코드는 보기 힘들어한다.


고수라고 남의 코드 한번에 훅훅 보는거 아니다.


하지만 남의 코드를 보고 내 코드를 남이 보는 것은 숨쉬는것과 마찬가지로 개발에서는 너무 당연한 과정이다.


보여주기 쪽팔리다? 그러면 잘 짜면 된다. 이건 핑계도 아니다.


 - 다른 개발자들 많이 만나라.


프로그래밍은 예술이 아니다. 


방구석에서 고민하고 혼자서 머리 굴린다고 절대 좋아지지 않는다.


다른 개발자들 만나서 어떻게 개발했는지 뭐가 어려웠는지 물어보고


나도 좀 알려달라고 하고 친해지고 부탁하고 부탁 받아라.


이런 전문가라면 당연히 해야하는 일이다.


 - 다른 언어 공부해라.


C나 Java 하는 사람중에 한 가지 언어만 하는 사람 본적 있는가?


"Flash 밖에 못해요"


개발자라고 어디가서 인정 못 받는다.


이 글에선 일단 ActionScript 개발자가 가장 배우기 쉬운 언어를 몇 개 골라 제안해보겠다.


Node.js - 이거 책보고 따라해서 하루안에 웹서버 못 돌리면 프로그래머 관두고 그냥 장사하는게 낫다.


Javascript - jQuery나 Ajax 하라는게 아니다. 적어도 document나 location.href가 뭔지는 알아야하지 않나? HTML 쓰지 말고 Javascript 만으로 Flash 불러오는거 정도는 해보자.


php - 웹 프로그램 언어중에 가장 유연한 언어다. 대신 메소드들을 거의 다 외워야하고 문법도 좀 특이하지만 타 언어에 비해 시작하기 훨씬 쉽다. php와 mysql은 가장 쉽고 효과적인 게시판 짝꿍이다.


Android Java - 이건 디바이스가 있어야 편하지만 없어도 충분하다. 개발환경 셋팅하고 내 코드가 돌아가기까지 개발 외적인 것들도 중요하구나를 알 수 있게 해주고 Java의 문법은 ActionScript와 똑같다. 하지만 훨씬 강력하고 thread나 synchronized가 무엇인지 정도는 알아야 Java 좀 했구나 한다.


Objective-C - 이건 언어가 C++ 기반이고 문법도 특이해서 코딩 자체에서 벽이 많이 느껴질 것이다. 하지만 만들면 제일 뿌듯하다. 만족감을 맛보고 싶은 매너리즘에 빠진 개발자라면 해보자.


위 언어들이 그나마 가장 대세이면서 시작하기 쉬운 (자료도 많은) 언어들이다.


"당신이 할 줄 아는 언어의 갯수가 당신의 한계입니다."


 - 게임 만들어보기


내가 게임 개발자라 그런게 아니라


게임 개발은 프로그램이라는 것이 무엇인지 가장 잘 나타내주는 분야가 아닌가 싶다.


눈으로 보기에는 너무 당연한 것을 


실제로 구현하려면 얼마나 많은 로직과 얼마나 많은 데이터들이 움직여야하는지 깨닫게 된다.


프로그래밍에 경외를 갖게 된다.


미니 게임이라도 한번 만들어보고 나면


내가 그동안 생각없이 심심해서 켰던 게임들이 얼마나 대단하고 얼마나 어려운 기술들이 접목되었던 것인지


놀라운 세계를 볼 수 있을 것이다.


"와우 세상에 미사일이 맞은 방향으로 폭발을 하다니!"


"헐 몹들이 다리 밑으로도 가고 다리 위로도 가다니!!! 어떤 알고리즘이지?"


"블럭이 없어지기 전에 다른 블럭을 움직일 수 있다니!! 이런 로직은 도대체 어떻게 처리하는거지?"


"물이 찰랑거려!!!! 말도 안돼!!"


아마 무슨 헛소리를 하는건가 싶은 사람도 있을 것이다.


하지만 게임 개발하는 사람이라면 자기도 겪었던 상황과 비슷해서 실소를 하지 않을까 싶다.


어떤 분야건 가장 새로운 기법이나 기술은


게임에서 가장 먼저 적용된다는 유행어가 있다.


그만큼 게임은 가장 유저친화적이면서 그만큼 자연스러운 구현을 위해선 얼마나 어려운 것인지 잘 깨닫게 해줄 것이다.




얼마전 면접 자리에서 


회사에 대해 궁금한거 없냐는 내 질문에


영어로 된 자료나 이런거 참 보기가 힘든데 그런 것들은 어떻게 극복했냐는 구직자의 개인적인 질문을 받았었다.


이때 나는 이렇게 알려주었다.




"지금 모르는 것을 오늘 공부하지 못하면 내일도 모르는 것이 됩니다.


지금 모르는 것을 오늘 공부해서 알게 되면 내일은 아는게 되죠."




For the better.

+ Recent posts