쌀밥망가 대왕

Chaebol 이라는 단어가 영어사전에 있는데....

쌀밥 — Tue, 19 Aug 2008 20:48:20 GMT

인터넷에서 영문 기사를 읽는데 Chaebol 이라는 단어가 있어서 뭔가 하고 사전을 찾아봤더니 '재벌' 이더군요.

근데 이게 제가 가지고 있는 사전에만 있는건가 하고 찾아봤더니 Wikipedia에도 있군요.

*그림을 클릭하면 커집니다.

창피한 노릇입니다.

*PS: 몰랐던 사실인데 조중동 신문사들이 재벌 가족에 다 엮여 있는 언론사더군요... 이런건 신문사가 아니라 재벌 홍보 브로셔 출판사지요...

ShaderX 5 를 공부하는 중입니다.

쌀밥 — Sun, 17 Aug 2008 03:48:25 GMT

요즘 ShaderX 의 5판을 읽는 중입니다.

생각했던것 보다는 꽤 재미있습니다.

ShaderX 5

Shader X 시리즈 책은 꽤 유명한 책인데, 저는 이번이 처음으로 접하는 책입니다.
왜 5판부터 보고 있냐고 하면, 저희 학교 도서관에 이 책밖에없더라구요 Shader 로 검색되는 책은...

사실 저는 별로 기대는 안했습니다. 왜냐하면 표지가 구렸기 때문만은 아니고 GPU Gems 가 유명한 것만큼은 그다지 이름을 자주 듣지 못했던 책이었고, 언젠가 한번 기회가 되어서 다른 시리즈를 살짝 살펴본적이 있는것 같은데 그때 별로 느낌이 좋지 않았던것 같습니다.

아무튼 꽤 꼼꼼히 읽고 있는데, 생각보다 재미있습니다.
특히 저는 pixel shader 를 사용해서 area light 를 구현한 부분은 정말 인상적이었습니다. 내용도 겨우 3장 밖에 안되는 부분이고 개념만 보면 상당히 단순한데, 저는 예전에 ray-tracing 프로그램 만들때 area light 를 구현하려고 쩔쩔 매다가 결국 아무 정보도 못찾아서 표기 했었거든요... 교수님께 여쭤봐도 그것 까지는 하지 말라고 말리셔서 정보를 얻지 못했었구요...

첫장인 n patch 개선하는거는 저는 별로 관심이 없어서 넘어가줬구요.
모서리부분을 부드럽게 처리해주는 두번째 주제는 상당히 단순하면서도 인상적이었습니다.
세번째는 옷감의 구겨짐을 표현하는 것인데,
한 세시간 정도 한 페이지를 열심히 읽고, 그 아래에 있는 수학 공식도 열심히 머리 싸쥐고 고민해봤는데, 난이도가 무지 높아서 결국은 표기 했습니다. 나름대로 암호 같은 수학 공식을 보는 법을 알아낸것 같기는 한데, 설명이 너무 조악하게 되어있어서 이해하기가 너무 어렵더군요. 옷감 구겨짐 부분은 개인적으로 상당히 관심이 있어서 유심히 봤는데 결국 포기하게 되어서 아쉬어요.

아직까지는 재미있게 잘 보고 있는 중인데 뒤로 가면 주제가 점점 더 흥미로운것들이 나오더군요. 마지막 장에는 무려 '3D Engine design' 에 대한 것이 나오니.... 기대하는 중입니다.

Flash ActionScript 3.0의 Component 에 대해...

쌀밥 — Fri, 15 Aug 2008 18:06:21 GMT

여전히 Flash9 을 공부하는 중입니다.

이번에는 Component 에 대해 적어보겠습니다.

Component 분석...

Component 라는 것은 흔히 말하는 Ui 컨트롤들입니다. 콤보박스, 리스트 박스, 스크롤바, 이런것들을 통칭합니다.

1. 스타일
2. 스킨
3. Class 상속 구조

1. 스타일

우선 스타일이라는 개념이 등장하는데요.
저는 요게 단어 선택이 좀 부적절하다고 생각합니다.
Flash에서 말하는 스타일이라는 것은 해당 인스턴스 각각이 갖을 수 있는 속성값들을 말합니다.
말하자면 Class 구성으로 생각하면 member variable 같은 것입니다.
다만 그 변수들을 정적으로 고정하지 않고, 사용자가 동적으로 추가하거나 제거 할수 있도록 만들어 둔것입니다.
간단히 생각하면 이런식입니다.

public class MyButton {
public map< string, void * > style;
};

그래서 각각의 Component들의 instance들이 각기 다른 값의 속성 값을 동적으로 갖을수 있게 됩니다.

화면 상의 Ui 는 이런식입니다.

위의 스크린 샷에서 '매개 변수' 탭 아래에 우측에 보이는 리스트 박스가 스타일입니다. 현재 5개의 스타일이 한개의 버튼 Component instance 에 (기본값으로) 저장되어있는 화면입니다.
*PS: 여기에서 한가지 주의해서 볼점은, 우측의 리스트 박스는 동적으로 추가 삭제가 가능한 스타일들인 반면에, 좌측 화면에 보이는 몇가지 요소(인스턴스 이름, 너비, 높이, X 좌표, Y 좌표)는 정적으로 항상 고정되어있는 값들입니다. 이렇게 구현된 이유는 아마도 클래스 상속과 관련해서 polymorphism 기능을 사용하기 위해서, 필수적인 몇몇 항목에 대해서 정적으로 고정한것 같습니다.

한가지 흥미로운 점은 내부 구현과 관련된 스타일들이 더 있는데, 화면 Ui에는 보여지지 않고 있다는 점입니다.
이때문에 Component와 관련된 style은 다시 Component Manager Panel 을 열어서 거기에서 추가적인 것들을 설정할수가 있습니다.

위의 스크린샷을 보시면 그 앞의 것에 비해 2개의 스타일이 더 보여지고 있음을 확인할수 있습니다.
왜 이렇게 번거롭고 중복되게 만들었는지는 이해가 안됩니다만 아무튼 그렇게 되어있네요.

근데 더 복잡해지는 느낌이 드는 것은, 이것 말고도 숨겨져 있는 스타일이 더 많다는 점입니다.
예를 들어, 버튼이 화면상에 그려질때 어떤 '스킨'을 사용할 것인지를 기억하고 있어야 하는데 그 정보들이 스타일의 형태로 저장되어있고, 화면상에서는 감춰져서 보이지 않는 다는 점입니다. 이것은 ActionScript 를 사용해서 확인하거나 변경할수 있습니다.

결국 스타일에 대한 정보는 3가지 방법을 통해서 접근할수 있는 것인데요. 제가 Ui툴을 다시 만들게 되면 이것들은 그냥 깔끔하게 한가지로 통일 시킬것 같습니다.

2. 스킨

스킨은 화면상에 보여질때 어떤 그림을 사용할것인지를 따로 모아둔 것입니다.
해당 Component를 더블클릭하면 '스킨 편집기'라는 것이 열린다는데, 보기에는 심볼 편집기와 구분이 잘 안갑니다.

화면 구성은 직관적으로 따로 설명이 필요없을듯 합니다. 디자이너가 바꾸기를 원하는 그림을 선택해서 더블클릭하면 해당 버튼을 편집할수 있게 됩니다.

한가지 개인적으로 인상적이었던 것은
스킨에 대한 정보를 스타일 형태로 저장한다는 점입니다.

예를 들어, 버튼의 경우, 버튼의 일반 모양은 "upSkin"이라는 이름으로 "Button_upSkin"이라는 값이 스타일에 저장됩니다.
마찬가지로 버튼이 눌렸을때의 모양은 "downSkin"이라는 이름으로 "Button_downSkin"이라는 값이 저장됩니다.

여기에서 Button_upSkin 이라는 값과 Button_downSkin 이라는 값은 '라이브러리' 상에 실제 존재하는 '무비클립'의 이름입니다.
그래서 디자이너가 버튼의 모양을 바꾸고 싶은 경우에, 새 버튼 이미지를 그린 다음에 (예를 들어) Button_upSkin_new 라는 이름의 무비 클립으로 저장한뒤에, 해당 버튼의 스타일 값들중 upSkin 정보를 Button_upSkin에서 Button_upSkin_new 로 바꾸면, 그때부터는 그 버튼의 보통 상태 그림이 Button_upSkin 이 아니라 Button_upSkin_new 가 되는 것입니다.

설명이 좀 복잡하군요... 죄송.

아무튼 이렇게 스타일을 잘 활용해서 구현되면 Ui 디자이너가 마음대로 스킨을 수정하는게 가능해집니다. 제가 예전에 Ui툴 만들때는 이런 방식은 미처 생각을 못했는데, 정말 좋은 방법인것 같습니다.

3. Class 상속 구조

Class 상속 구조는 도움말 파일에 자세히 잘 설명되어있습니다.
( ActionScript 3.0 언어 및 구성 요소 참조 설명서 > 모든 패키지 > fl.controls. 패키지 )
여기에서는 Button과 Combo box 두가지만 간단히 살펴보겠습니다.
보다 자세한 설명은 도움말 페이지를 반듯이 참고하시기 바랍니다.
도움말 파일에는 MSDN만큼이나 자세하게 member attribute 와 member methods 그리고 event 와 스타일까지 자세하게 잘 설명되어있습니다.

이것은 Button의 상속 구조입니다.

보시는 것과 같이 최상위 클래스인 Object 부터 Sprite 까지는 지난번에 DisplayObject를 살펴 볼때 살펴본 것입니다.
그 아래로 모든 Component 들은 UIComponent 라는 클래스를 상속 받아서 구현됩니다.
버튼의 경우 BaseButton을 상속 받고 LabelButton을 상속 받는 다는 점은 CheckBox와 같습니다. 왜 BaseButton과 LabelButton의 두개가 구분되어있는지는 이해가 안됩니다. BaseButton을 상속 하는 클래스는 LabelButton 뿐인것 같은데 말입니다.

LabelButton 은 도움말에 따르면 Grid에도 사용되고 스크롤바의 버튼에도 사용되고 체크박스, 라디오 버튼등에 사용된다고 합니다.

ComboBox를 살펴보겠습니다.

콤보 박스는 버튼 보다 좀 더 복잡한데요.
아시다 시피 콤보 박스는 리스트 박스와 텍스트 입력 부분, 그리고 버튼으로 구성됩니다.
도움말에 있는 member variable 들을 살펴 보면 그 안에 list 와 textInput 이 Composite 구성으로 들어있는것을 확인할수 있습니다. 다시 말해 상속 관계로 구현된게 아닌것이죠. 그래서 상속 구조는 간단한데 소유 관계로 구성 요소들을 가지고 있어서, 이걸 구현하는 부분이 상당히 복잡할걸로 예상됩니다. (개인적으로는 상속을 별로 안좋아하고 Composite구성을 선호하기 때문에 이런식이 좋아보입니다.)

이 글은 여기서 끝입니다.

한가지 개인적으로 덧붙이고 싶은 것은 스크롤바에 대한 것입니다. 저는 왜 스크롤바가 독립적으로 다루어질 필요가 있는지 모르겠습니다. 스크롤바가 사용되는 곳은 거의 한정적인데, Flash의 경우를 보면 스크롤바가 따로 사용되는 경우는 TextArea 우측이나 하단에 가져다 붙여 넣고 그걸 ActionScript를 사용해서 두개를 엮어주는 것입니다. 왜 이렇게 따로 구성되어있어서 수작업으로 두개를 붙여줘야하는지 모르겠습니다.
왜냐하면 언제나 TextArea는 내부 공간이 부족하게되면 ScrollBar를 항상 필요로 하는데, 아에 ScrollBar를 TextArea의 기본 속성으로 갖어도 될것 같다는 생각입니다.
그리고 저는 TextArea이외에는 ScrollBar가 어디 따로 사용될 일이 있을까 의심스럽습니다.

Flash 내부 Class 구조 분석.

쌀밥 — Thu, 14 Aug 2008 19:43:47 GMT

요즘 Flash를 공부하는 중입니다.
그중에서도 오늘은 Flash 가 어떻게 동작되도록 설계되었는지 정리해볼 생각입니다.

이 내용은 모두 Flash9 도움말 파일에서 파악된 정보입니다.
원문은 도움말 파일 중에서 ActionScript 3.0 프로그래밍 > 디스플레이 프로그래밍 을 보시면 있습니다.

Class 관계 분석

세가지로 나누어서 정리하겠습니다.

상속 구조
소유 구조
이벤트 흐름

이 세가지가 매우 밀접하게 들러붙어 있는 녀석들이기 때문에 따로 떼어 놓을수가 없습니다.

상속 구조

우선 상속 구조 그림은 도움말 파일 내부에 들어있었습니다.

그림을 설명하겠습니다.
DisplayObject라는 것은 추상 클레스 입니다. 화면상에 보여지는 모든 클레스들의 최상위 클레스입니다.
DisplayObjectContainer는 DisplayObject를 소요 할수 있는 녀석입니다. 말 그대로 컨테이너이지요. 이 소유 개념은 상속 관계와는 완전히 별개이미로 잘 구분해야합니다.

AVM1Movie는 Flash 구버전과의 호환성을 위해 남아있는 동영상 플레이 클레스입니다. (저는 요거는 그냥 무시하고 싶군요)
Bitmap 은 말 그대로 bitmap 그림 파일들을 화면에 출력하는 클레스입니다.
Shape 는 Bitmap과 상대대는 클레스입니다, Flash는 기본적으로 Bitmap방식이 아니라 vector 방식입니다. 그래서 여기서 그려진 Vector 이미지 들을 Shape라는 클래스가 화면에 그려주는 일을 하는 것 같습니다.
StaticText 는 화면상에 고정된 텍스트를 출력합니다. 고정된이라는 의미는, 실행중에 사용자가 바꿀수 없고, ActionScript등을 동원해 내용을 바꿀수도 없다는 의미입니다.
Video 는 말그대로 동영상 파일을 플레이 해줍니다.
SimpleButton 은 '심볼'에서 '버튼'을 선택했을때 만들어지는 것을 관리합니다. (저는 요것도 그냥 무시하고 싶군요)
TextField 는 동적 텍스트(텍스트 파일이나 서버로 부터 값을 읽어와서 표시하는 기능)와 입력 텍스트(사용자로 부터 입력을 받는 텍스트 박스) 두가지를 관리합니다.
Loader는 해당 플레쉬 파일 외부에 따로 저장되어있는 그림파일을 동적으로 읽어오는데 사용되는 듯 합니다.
Spite는 잘 모르겠습니다. 아마도 '심볼'에서 '그래픽'에 해당하는 녀석인듯 합니다.
Stage는 전체 Canvas를 말합니다. 뒤에서 살펴볼 소유 관계에서 root에 해당하는 녀석입니다.
MovieClip은 말 그대로 '심볼'에서 만들수 있는 무비 클립을 관리합니다.

제가 게임 Ui 에디터를 다시 만든다면 이런 모양이 될지도 모르겠습니다. 다만 AVM1Movie랑 SimpleButton은 빼겠지요.
*PS: 레이어는 아마도 DisplayContainer인것 같습니다.

소유 구조

이 이미지 파일도 역시 도움말 파일에서 가져온것입니다.

보시면 소유 관계는 Stage라는 최상위 노드로 부터 시작합니다.
이건 일종의 파일과 디렉토리 구조 같은 것으로 생각하시면 될것 같습니다.
DisplayContainer 는 디렉토리에 해당하고 DisplayObject는 파일에 해당합니다.
Stage는 DisplayContainer를 상속받아서 만들어진 특별한 Root 노드입니다.
각각의 DisplayObject는 다른 DisplayObject를 참조할수 있는데 부모 노드를 경유하는 경우에는 디렉토리 이동하듯이 점 두개(../filename)를 사용하는게 아니라 _parent라는 예약어를 사용합니다.

그리고 DisplayContainer에 집어 넣는 순서가 의미가 있습니다. 먼저 집어 넣는 녀석이 아랫쪽에 깔린 모양으로 표시됩니다.
아래 그림의 경우 A가 먼저 집어넣어져서 (인덱스 번호는 0 이 됩니다) 맨 아랫쪽에 깔렸습니다.

이벤트 흐름

이벤트 흐름이라는 개념은 저는 여기서 처음 봤는데 예전에 제가 이벤트 관련 구현할때는 GoF의 Design Pattern을 참고 했었습니다. 거기에 보면 transparent enclosure 혹은 decoration 패턴이 User Interface 구현에 좋다고 강조되어서 설명되어있기 때문에 그것들을 사용했었는데요. 지금 Flash에서 하고 있는 방식을 보니까 이쪽이 더 좋은것 같습니다.

우선 그림을 보면 (역시 help 에서 가지고 왔습니다.) 이런 모양입니다.

이게 저는 제 식대로 대충 이해하고 넘어갔었는데, 뒷쪽의 도움말 내용을 읽다가 보니까 의문이 많이 생겨서 좀 더 시간을 투자해서 자세히 읽어보니까 상당히 특이한 방법이더라구요. 저는 Java Swing 프로그래밍 할때도 이런식으로는 안될것 같다는 생각입니다. 상당히 좋은 방법 같아요. 설명을 하면 이렇습니다.

그림을 얼핏 보면, stage (말하자면 root) 노드에서 부터 깊이 우선 방식으로 순자척으로 이벤트 받을 녀석을 검색해나가는것 처럼 보입니다. 하지만 그게 아니고, 이벤트 받을 녀석이 어느 노드인지는 이미 알고 있는 상태에서 3가지 단계에 걸처서 이벤트를 사용하는 것입니다.

1단계는 최상위 노드부터 이벤트를 받을 노드의 부모까지 모두에게 순서대로 해당 이벤트를 처리하도록 이벤트 핸들러를 호출 합니다.
2단계는 이벤트를 받을 녀석의 이벤트 헨들러를 호출합니다.
3단계는 역으로 거슬러 올라가면서 이벤트 헨들러를 호출합니다.

우선 어느 노드가 어떤 이벤트를 받을 껀지 어떻게 결정할 수 있는가?
그건 해당 이벤트의 특성에 따르는것 같습니다.
예를 들어 '마우스 이벤트'라고 한다면, 화면상에 마우스 커서가 놓여 있는 좌표값을 기준으로 해당 위치에 있는 노드들이 이벤트 받을 노드들이 됩니다. (테스트 해본 바로는 겹쳐있는 경우에는 겹친것에 관계없이 모두 다 받습니다)
다른 예로 마이크 입력 이벤트나 발생하면, 마이크 입력 이벤트를 처리할 수 있는 노드(화면상의 좌표나 부모 자식간의 위치에 무관하게)를 검색해내서 해당 노드들 전부가 이벤트 받을 대상이 되는 것입니다.

순서가 이렇게 되는 것입니다.

이벤트가 발생하면
해당 이벤트를 누가 받을 것인지를 정한다. 이때 이벤트의 특성을 고려해서 누가 이벤트를 받을 것인지 모두 검색해 낸다.
해당 노드의 부모 노드들을 모두 순차적으로 찾아내서 (켑쳐단계, 1단계) 이벤트 처리를 실행한다.
해당 노드에게 이벤트 처리(대상단계, 2단계)를 실행한다.
해당 노드의 부모 노드 부터 최상위 노드까지 역순으로(버블링단계, 3단계) 이벤트 처리를 실행한다.

이 과정에서 이벤트 버블링은 옵션으로 해당 이벤트 인스턴스안에 수행 여부를 기록해둘수 있습니다.
그리고 이벤트를 처리하는 중간에 이벤트 흐름을 다음단계로 넘기지 않고 끝내는 것도 가능하구요.

이렇게 구현되어있는 이유는 도움말 파일에 설명되어있는데
예를 들어 하나의 버튼이 있고, 그 버튼위에 텍스트 문자열 인스턴스가 겹쳐져있다고 했을때, 사용자가 마우스 클릭을 버튼에 했건 텍스트 문자열 위에 했건 동일한 처리가 가능하도록 하기 위해서라고 합니다.

*PS: 적어놓고 보니까 이게 원래 transparent enclosure 패턴 구현인건가? 하는 생각도 드는군요.

바퀴 벌레 먹을수 있나???

쌀밥 — Wed, 13 Aug 2008 17:15:29 GMT

문득 궁금해져서 찾아봤는데
먹을수 있나봅니다.
인도 어딘가에서는 남녀를 가리지 않고 튀겨서 맛있게 먹는다고 하네요.
1번에 36마리까지 먹은 세계 기네스도 있뎁니다.
기네스야 원래 이상한 기록들이 많아서 그렇다 쳐도
일상적으로 바퀴벌레를 먹는 사람들이 있다는게 인상적....

*PS:사진은 올리지 않겠습니다만 구글에서 바퀴벌레 튀김으로 검색하면 왕창 뜨는군요.

Flash 의 Button Component 를 살펴보고...

쌀밥 — Wed, 13 Aug 2008 01:22:50 GMT

오늘 또 Flash9을 열심히 공부했습니다.
오늘은 Component 들 (특히 버튼)을 중점적으로 살펴 봤는데요.
결론부터 말하면, 전반적으로 잘 만들어져있는것은 사실이지만
Component쪽의 구성은 좀 복잡하다는 느낌이 들었습니다.

오늘은 특별히 버튼 Component를 살펴 봤습니다.

Flash의 버튼(Component) 구현에 대해...

예를 들어 버튼 같은 경우에, 하나의 버튼을 완성시키기 위해서는
버튼의 '보통때 그림'이랑,
마우스가 올라가 있을때의 모양이랑,
버튼에 클릭했을때 눌려있는 모양이랑,
버튼이 확실히 눌렸을때 모양등의 그림이 필요합니다.
그밖에도 버튼이 눌렸던것이 취소되었을때의 반응이나
강조표시가 되어있을때의 모양, 비활성화 되어있을때의 모양등
생각해보면 상당히 많은 추가 모양들이 있습니다.
이런 복잡한 관계에 대해 각각의 그림들을 연결시키는 방법이
제가 예전에 Ui툴 만들었을때도 꽤 깔끔하지 못했었는데
여기 Flash에서도 마찬가지로 상당히 복잡했습니다.

예를 들어 버튼을 하나 라이브러리에 추가 시키면,
Component Assets이라는 폴더가 강제로 추가되는데
여기에 모든 그림 정보등이 들어가 있는 것입니다.
(Component라는 용어는 '버튼', '체크박스', '리스트 박스', '스크롤바', '텍스트 입력 박스', '리스트' 등등을 통칭하는 용어입니다.)
근데 그 안을 열어보면 알수 없는 용어들이 마구 등장해서
말하자면 "이 폴더는 열어보지 마시오" 같은 느낌입니다.

스샷을 보시면 _private이라는 폴더는 느낌부터가 '건드리지 마시오'라는 느낌이고,
avatar라든지 Shim이라는 단어는 어디에서 쌩뚱맞게 튀어나온 개념인지 알수 없습니다.
ButtonSkins안을 열어보면 매우 긴 이름의 이미지 파일들이 있고
'무비 탐색기'를 열어서 보면 내부적으로는 더욱 복잡하다는 것을 확인 할수 있습니다.

스샷을 보면 버튼 Component 안에 assets 라는 폴더가 있고 asset names라는 것이 있고, avatar, compoentShim등의 알수 없는 것들이 잔뜩 있습니다. 게다가 Frame1와 Frame2가 나뉘어있는 것은 지금도 왜 이렇게 되어있는지 알수가 없습니다. (제가 봤을때는 Frame1 한개만으로 충분히 될것같은데 말입니다.)
스샷에서 보여지는 "My Button" 왼쪽에 있는 아이콘 그림이 주는 느낌도 역시 "이건 건드리지 마시오" 라는 느낌입니다.

내부 구성은 제가 봤을때는
가장 높은 단위로 Asset이라는 개념이 있고 (일종의 추상 클레스),
그 아래에 'Symbol', "Folder', 'Text', 'Sound', 'Movie' 그리고 'Component' 정도가 상속되고 있는것 같습니다.
그리고 여기에 Symbol은 다시 세가지로 상속되는데 Movie, Graphic, Button입니다.

복잡해지는 것은 Symbol에서 말하는 Button과 Component에서 말하는 Button이 다른 개념이라는 점입니다. 아마도 후자의 것이 나중에 추가된 개념인것 같습니다.

(나중에 추가된 것으로 짐작되는) Component의 버튼 쪽을 좀 더 자세히 살펴보면
요런 모양의 버튼(여러 Component들중의 하나)입니다.

이것을 더블 클릭하면 안으로 들어가서 버튼에 대한 여러 그림들을 편집할수 있는데 이런 화면입니다.

버튼 하나를 표현하는데 10가지의 그림이 필요하다는 것이지요.
근데 이 각각의 이미지들을 더블 클릭하면 각각의 그림을 편집할수 있는데 이것입니다.

그림에서도 보여지는 것과 같이 하나의 이미지가 9 등분되어있습니다. 이유는 간단합니다. 버튼 안에 들어가는 텍스트의 크기에 따라 버튼이 늘어날 것을 고려한 것입니다. 그래서 각 테두리에 표현된 라운딩이 찌그러지지 않도록 보호하는 것이지요. (저도 요렇게 9등분하는 버튼을 구현했었습니다.)

여기까지가 제가 오늘 조사한 Flash안의 버튼 구현입니다.

제 생각을 좀 더 덧붙이면, 버튼 속성을 편집하는게 너무 난잡하다는 느낌입니다.
속성 편집을 하는 panel 이 '속성'이라는 것이 있는데,

여기에서는 버튼에 대한 속성 편집은 사실상 불가능합니다.
그래서 Component Manager 라는 특별한 panel 이 등장합니다.

근데 문제는 여기에서도 버튼에 대한 그림 정보는 편집이 안되는 것입니다.
그래서 '심볼 편집' 화면으로 넘어가야 하는데
여기에 사용되는 인터페이스는 다른 심볼 편집 방법들과는 완전히 다른 방식이기 때문에 인터페이스의 통일성을 잃어버립니다.
원래 심볼 편집 화면에서 편집한 화면은 나중에 심볼을 사용할때 화면상에 그대로 똑같이 나타나는게 일반적인데
Component편집시에만 별개의 인터페이스로 동작하는 것입니다.
나중에 버전이 올라가면서 땜빵해 넣었다는 증거이지요.

그래서 결론은
Component 관련 구현은 (기대를 많이 했으나) 역시 Flash라도 간단하게 구현 못했구나 하는 느낌입니다.
그리고 최소한 좀 더 간단하게 간소화 하는 개선의 여지는 있다고 보여집니다.

ScaleForm

쌀밥 — Mon, 11 Aug 2008 20:48:08 GMT

Bluwind님이 알려주신 ScaleForm이라는 게임 Ui용 백터 그래픽 툴이 있어서 간단히 살펴봤습니다.

홈페이지에 설명이 장황히 있습니다. 이것만 봐서는 정말 훌륭해 보입니다.
Mass Effect와 문명4등의 유명한 게임에서도 사용되고 언리얼 같은 엔진에도 곧 호환이 될꺼라는 등의 글이 보입니다.

SDK에 대한 링크가 있길레 다운 받으려고 눌러봤더니
가입을 하라고 하더라구요.
그래서 가입 신청을 했는데,
분위기로 봐서는 일반인이나 학생 대상으로는 커뮤니티를 열어주지 않을 눈치입니다.
그래서 저는 이걸 다운 받아보기 어렵겠다는 생각을 하고 있습니다.

그래서 스크린샷을 좀 살펴 보려고 했더니 그것도 가입을 해야한다고 하고,
메인 페이지에 상품광고 페이지에 올라와 있는 7장의 스샷이 제가 접근 할수 있는 모든 사진입니다.

근데 그중의 한장이 상당히 제 마음을 불편하게 합니다.

이 사진인데요.
아마도 편집 툴이 우측에 슬쩍 보여지고 있는것 같습니다. 근데 이건 제가 생각한 수준에 미치지 못하는 조악한 수준입니다.

제가 기대하는 것은 Flash의 인터페이스 같은것인데 사진을 인용하면 이정도 되겠습니다.

상단에 레이어 편집창이 있고 우측 상단에 이벤트 편집 창이 있고 우측 하단에 심볼에 대한 라이브러리가 보여지고 있습니다. 하단에는 속성 창이 있고, 좌측에는 포토샵 처럼 기본적인 그리기 툴들이 보여지고 있습니다.
제가 기대하는 건 이정도인데, ScaleForm에서 얼핏 보여지는 인터페이스는 이에 한참 못 미쳐보입니다.

가입 여부가 결정되는데로 좀 더 많은 스샷을 살펴 보고 싶은데, 지금까지의 정보로 보건데 아직 개선의 여지가 많아보이는 초기 버전 정도로 짐작되고 있습니다. 부디 기우이기를...

Gem Craft

쌀밥 — Mon, 11 Aug 2008 20:30:26 GMT

Gem Craft라는 게임을 한 5일동안 몰아서 했습니다. Flash로 만들어진 Tower Defense 게임입니다. RPG 요소랑 타워 방어 요소가 잘 조합된 명작이라고 생각합니다. 중독성도 매우 심하고요...

Gem Craft

정말 재미있게 몰입해서 잘 했는데
나중에 가니 대부분의 RPG게임들이 그렇듯이 노가다를 요구하더라구요.
그래서 노가다 안하고 저레벨인 상태로 깨려고 하니 난이도가 무지 높아지는 느낌을 받았는데
그래도 깰수 있는데까지 깨다가 결국에는 34레벨에서 포기 했습니다. 맵 8개 남겨두고 더는 못하겠더라구요.

근데 요즘 플레쉬 만드는거 공부하다가 문뜩 해킹하는 방법이 생각이 나서
스킬 좀 해킹해주고 간단히 엔딩을 봤습니다.
엔딩은 거의 10 초 정도 됩니다;;; 플레쉬 게임이다보니...

그냥 인증샷 올려둡니다.

자원은 희소해서 가치가 있나? 가치가 있어서 희소한가?

쌀밥 — Mon, 11 Aug 2008 12:56:54 GMT

오래전부터 자원배분과 희소성문제에 대해 간략히 적어보려고 했었는데
마땅한 예를 찾지 못하고 있다가 오늘 부동산 문제를 보니 한번 써볼만 하겠다는 생각이 들었습니다.

뿌리 깊어라, 부동산 6계급

한겨례 신문 내용을 보니 한국에서 상위 10명이 소유하고 있는 집을 모두 합하면 5508채에 이른다고 합니다.
아니 이게 전체의 몇퍼센트나 되는거야? 엄청나잖아? 하고 생각했습니다.

자원의 희소성

작년에 BB와 대화하던 중에 알게 된 사실인데,
금은 왜 화폐로 사용되기 시작한것인가? 하는 질문에서
금이 희소하기 때문에 화폐의 가치를 갖게 되었다는 대답은 틀린 답이라는 사실을 알게 되었습니다.
금이 화폐로 사용되기 시작한 이유는 금이 쉽게 자를수 있고 오래 보관해도 변하지 않고 가치와 무계가 비례한다는 등의 특징이 있기 때문이라고 합니다.

금이 희소하다는 특징은 원인이 아니라 결과입니다.
금을 화폐로 사용하기 시작하면서 사람들이 금을 박박 긁어서 사용하기 시작했고, 그래서 결과적으로 희소한 자원이 되어버린것입니다.
"그래도 금이 희소한것은 맞지 않나?" 하고 말하면 맞다고 밖에는 말할 수 없겠습니다.
하지만 한 예를 살펴 봅시다.
15C와 16C 대항해시대가 시작되면서, 미국 땅으로 부터 엄청난 량의 금이 발굴 되었습니다.
그리고 그 금은 거의 모두 스페인이나 포르투갈 같은 쪽으로 유입되었습니다.
그랬더니 어떤 현상이 벌어졌나하면, 스페인과 포르투갈의 물가가 폭등하였습니다.
물가를 폭등시킬만큼의 엄청난 량의 금이 유입되고나서도 금은 여전히 희소성을 가지고 있었습니다.
저는 이 예가 아무리 금의 량이 늘어나도 금은 여전히 희소하다는 것을 보여준다고 생각합니다.

상상력을 조금 동원해서
우리가 화폐로 금이 아니라 조개 껍데기를 화폐로 사용하기로 했다고 합시다.
그러면 조개 껍데기가 귀한 물건이 될것입니다. 조개가 많이 사는 어장은 갑자기 금광이 되어버리는 것입니다.
처음에는 희소하지 않던 것도 화폐로 사용되기 시작하면 금방 희소한 것이 되어버립니다.
화폐가 희소한것은 원인이 아니라 결과라는 것이지요.
이 조개 껍데기 예는 여기 George Mason 경제학 교수들중의 한분이 사용한 예라고 합니다.

간단한 다른 예를 들어봅시다.
의자가 10개가 있고 앉고 싶어하는 사람은 11명입니다.
흔히 사회주의를 비판하는 사람들은 이 예를 사용합니다.
어떻게 11명의 욕구를 사회주의에서 만족시킬 것이냐? 하는 것입니다.
여기에 전제 되어있는 것은 자원은 항상 부족하다는 전제입니다.
사회주의는 이 문제를 풀수 없습니다.
이거는 사회주의냐 자본주의냐의 문제가 아니라 수학의 문제입니다. 11 빼기 10은 1이니까 당연히 한명은 못 앉는 겁니다.
이 문제를 해결할수 없다고 해서 자본주의가 더 낳다고는 할수 없습니다.

말하고 싶은 것은 자본주의가 이 의자 문제를 해결하는 방식입니다.
10개의 의자가 있고 앉고 싶은 사람이 11명입니다.
사회주의 비판자들은 자본주의가 이 문제를 해결한다고 합니다.
돈을 맍이 지불할 의사가 있는 사람, 즉 수요가 높은 사람이 의자를 차지하게 될것이다라고 합니다.
말은 그럴듯 합니다. 하지만 여기에는 문제가 있는데 여전히 1명은 앉지 못한다는 사회주의가 가지고 있는 문제가 똑같이 남아버립니다.
다른 문제는 앉고자 하는 욕구는 엄청난데도 돈을 소유하고 있지 못한 가난뱅이들은 의자를 차지할수 없습니다.
그래서 자본주의에서는 돈이 없는 수요는 수요가 아닌걸로 봅니다. 여기서 유효수요라는 새로운 용어가 등장하게 되는 것입니다.

사실상 자본주의 상황에서 이 의자 문제는 더욱 심각해질수 있습니다.
자본주의 경제학이 전제하는 것은
사람의 욕구는 끝이 없기 때문에 더 많은 것을 끊임 없이 갖으려 한다는 것입니다.
그리고 시스템은 이런 욕구를 제한하려 하지 말고 더욱 자극 시켜서 사회발전을 끌어내겠다는 것입니다.
그러면 돈 많은 부자 1명이 (무궁한 욕구 때문에) 10개의 의자를 모두 차지하고 (11명중에서) 1명만 앉고 10명은 서 있는 경우도 생길수 있는 것입니다.

이런 문제는 심지어 자원이 충분히 많은 상황에서도 똑같이 발생할수 있습니다.
예를 들어 의자가 20개이고 앉으려는 사람이 11명인 경우에,
1명의 부자가 자신의 끊임 없는 욕구를 충족시키기 위해 20개의 의자를 다 독차지하고 10명은 여전히 서 있는 경우도 가능한것입니다.
(자원이 희소하지 않았는데도 결과적으로는 여전히 희소한 상태가 되어버립니다.)

저는 여기서 모든 자원이 항상 충분하다고는 하지 않습니다.
자원은 충분할때도 있고 부족할때도 있습니다.
하지만 자본주의 경제학의 첫번째 대전제는 모든 자원이 항상 부족하다는 것입니다.
그래서 부족한 자원을 분배할 방법이 필요한데 그게 자본주의라고 합니다.
결국 자본주의는 자원이 충분한 경우는 없다고 말하면서 그냥 무시하고,
충분한 자원이 존재하더라도 결과적으로는 그걸 부족한 상태로 만들어버립니다.

저는 한겨례의 부동산 기사를 읽으면서
정말로 집이 부족하긴 부족한가?
이게 집이라는 자원이 부족해서 가격이 자꾸 오르는 걸까?
아니면 가격이 오를껄 기대하기 때문에 집이 자꾸만 부족해지는 걸까?
하는 생각을 하게 됩니다.

이 기사에 따르면 한국에는 총 6 계층이 있는데
4%의 인구가 2채 이상(평균5채)을 소유하고 있는 1 계층이고
49%의 인구가 1채를 소유하면서 거기서 사는 2 계층이고
4%의 인구가 1채를 소유하지만 거기서 살지는 못하고 세를 내주고 사는 3 계층이라고 합니다.
나머지 3개의 계층은 집을 소유하고 있지 못하다고 합니다.

이 예를 봐도 소수의 부자들이 다수의 의자를 쓸데 없이 차지하고 있어서 정작 앉아야 할 사람들이 앉지 못하고 있는 상황이 보이지 않습니까?
이게 소위 자본주의의 자원분배 방식이지요.

게임 UI 에디터는 Flash를 필히 참고해야...

쌀밥 — Mon, 11 Aug 2008 00:27:28 GMT

아.. 요즘 Flash를 공부하는 중인데요.
웹디자이너도 아닌 게임 프로그래머가 Flash 공부를 하고 있는 이유는
Flash가 Ui 개발툴의 일종이기 때문에
어떤식으로 만들어져 있는지 알아보려고 공부하는 중입니다.
근데 몇일 공부해보니 정말 정말 좋군요.
이걸로 만든 데이터가 XML로 추출만 될수 있으면 정말 금상첨화일텐데.....

저는 2005년에 NC에서 게임 Ui툴은 만든적이있습니다.
그때 상당히 멋진 프로그램을 만들어냈다고 자부하고 있었는데
Flash를 보니까 제가 만든것을 훨씬 훨씬 능가하더군요.

특히 가장 감탄했던 것은 Layer와 Symbol을 구분해 놓았다는 점입니다.
예전에 EverQuest2의 XML 데이터를 봤을때도 요런 비슷한 구조를 본적이 있지만
얼마나 실용적일지에 의문이 있었는데
자주 사용하는 컴포넌트를 Symbol로 구분해서 재사용성을 높아지고
복잡해지기 쉬운 Layer부분을 매우 간략하게 표현할수 있게 되어서 좋더라구요.
정말 놀랐습니다.

Event처리 방식은 제가 만들었던거랑 거의 비슷한데,
Flash쪽에서 보여주는 방식이 좀 더 쉽고 간략해 보여서 더 좋아보이더군요.

에니메이션 작업하는 방법이나 효과음 처리하는 것등은
저는 아직 시도도 못해봤는데,
Flash에서 하는 방법 이상으로 더 간단하고 좋은 방법은 없을것 같습니다.

다음에 게임 Ui툴 만들일 있으면 필히 Flash랑 비슷한 형태로 만들어야겠습니다.
그러면 따로 메뉴얼 만들 필요도 없이 Flash책 읽어보라고 하면 되고,
이미 Flash쓸줄 아는 게임 디자이너들은 따로 배울 필요도 없고...
쓸줄 모르면 그참에 배워두면 좋고... 등등..