쑥갓재배기

처음작성 : 2006-06-27

PNG항목 추가 : 2006-07-31

글 다쓰고 마무리 하고 있었는데 노트북 다운되서 대략 orz

다시 쓰쟈..-_-

참고로 개인 블로그에 올리는 용도이므로 말은 편하게 하겠습니다..;;

참고로 각 참고용 이미지는 풍류공작소(http://p.paran.com)..;; 1차 클베버전UI의 스샷이고, 홈페이지에도 많이 공개되어 있으므로, 개발중인 내용을 공개하는게 절대-_- 아니며, 편집기능 같은 경우는 찍을수 있는 사람이 내부 개발자 몇명-_- 밖에 없기는 하지만, 공개되도 별 상관없는 내용이고, 일부러 부분 스샷이 아니라 하단에 로고가 잘 들어가 있는 풀~ 스샷으로 넣었으니까.. 스샷 유출했다고 혼내지 마세요ㅠ.ㅠ

--------------------------

지금 쓰고 있는 UI모듈을 만든게 2004년 2월이니 꽤 오래되었다.

처음 만들때는 새프로젝트를 시작한지 얼마 안됐었지만 기존 프로젝트도 유지보수를 같이 해야 하는 상황이었고, 한참 해외화다 머다 정신 없는 시절이었어서..

작업시간은 퇴근후에 시간을 내어서 할 수 밖에 없었고, 기한은 두달정도라 시간에 쫒겨서 꽤 대충..;; 만들었다.

그래도 몇년간 UI에 대해서 구상해왔던지라 구조적인 부분은 꽤 신경써서 만들어 놨었어서.. 현재까지도 편집의 편의를 위한 몇가지 기능과 lua연동, 이미지매핑을 추가 한것 말고는 별다른 수정없이 잘 쓰고 있다.

꽤 오래쓰다 보니 여러가지 기능 추가나 리펙토링을 하고 싶은게 잔뜩이지만, 항상 다른 스케줄에 밀리는 관계로 아마 회사내에 있는 상태로는 힘들것 같다..;;

혹시 다음에 회사를 옮기게 되면 한 3개월 정도 쉬면서 공개를 할 수 있도록 처음부터 새로 만들고 싶다..;;

어쨋건 처음 게임용 GUI를 만들게 된다면 MFC나 DXUT의 UI를 참고하는게 꽤 도움이 된다..

현재 모듈 만들때는 DXUT가 없었기 때문에 이쪽은 별로 참고를 안했고(사실 참고할것도 별로 없다..)

MFC를 꽤 많이 참고를 했고... 기능적인 부분은 마비노기를 베꼈다..벤치마킹 했다

해외게임까지 통틀어 놓고 봐도 마비노기의 인터페이스는 쵝오다 >_<)=b

기능적인 부분을 빼고 보더라도 UI본연의 기능인 접근성과 0에 가까운 학습시간..은 경이로울 정도다..;

하지만...;; 이건 개인의 취향일 뿐이고, 보통의 MMORPG를 개발한때는 좀 더 게임틱-_-한 UI를 원하므로 너무 마비노기에 집착하는건 좋지 않다..;; ( 난 너무 집착했다-_- )

덕분에 프로그램으로 구현된 그래픽(실제로 마비노기가 이런방식을 사용하는지는 모른다)에 너무 집중했다-_-;;

대부분의 내용을 프로그램으로 그리고 가끔 이미지가 필요한 부분에만 이미지를 넣는다..라고 컨셉을 잡았는데.. 그렇게....되기는 힘들다. _ _;;;

사실 프로그램으로 그릴수 있는건 이미지로 대부분 커버가 되기 때문에 쓸데 없기도 하고..;;

이미지코드노가다-_-;의 시간은 둘째치고(사실은 xml에서 폴리곤이나 line등의 데이터를 읽도록 했기 때문에 그다지 오래걸리지는 않았지만..)

구조를 코드로 그리는 쪽으로 맞춰버린 덕에 지금도 고생하고 있다..;;

이건 잡담이지만 UI용어를 위젯이라고 쓰기도 하고 컨트롤이라고 쓰기도 하고, 다른 용어를 쓰기도 하는데..현재 모듈은 컨트롤이라고 쓰고 있다.

어쨋건 내가 생각하는 게임용 GUI를 만들 때 고려해야할 점은 다음과 같다.

1. 컨트롤의 구조가 Tree형태가 되도록 하쟈

어플리케이션의 UI는 다이얼로그에 각 컨트롤들이 올라가는 형태지만...

게임에서는 창안에 창이 들어가야하는 경우가 비일비재하게 발생한다..

이부분은 사실 그렇게 안만들려면 안만들수도 있다-_-;

사실 전에 전에 만들던 게임같은 경우도 그냥 윈도우는 루트바로 밑에 존재하고, 그 하위에 버튼이나 등등등이 들어가도록 사용했었다.

막상 Tree형태가 필요한걸 생각하려고 하니 생각이 잘 안난다..;;

현재는 구조상에 강제하는 부분은 없는데 Static밑에 Window가 들어간다거나..할 수 있는 형태다.

우훔 장점은 창안에 세부창을 두고 각 창을 hide/visible시킨다던가 enable/disable시킨다던가 하는 그룹형태로 쓸 수 있다...;;

탭기능 같은 경우도 편하다. 탭을 선택하면 각 탭에 연결된 창을 hide/visible시키면 된다.

머 대충 그렇다-_-;;

2. UI편집툴을 만들지 말고 자체 편집이 가능하도록 하쟈...

처음에 상당히 고생한 부분인데 먼가 UI테스트를 하려고 보니 편집관련 UI가 필요해져서 닭이 먼저냐 닭알이 먼저냐의 상황이 되서 상당히 난감했었다-_-;;

결국은 편집UI가 완성될때까지는 xml에서 직접 편집해줬었다..

사실은 여기서 더 중요한건 UI툴이 있어야 한다-_-;

UI툴을 만들지 않고 xml을 직접 편집하는 형태로 작업을 하는 경우도 있는데..

그런형태의 작업에서는 좌표같은걸 맞춘다거나 이미지 매핑을 하는게 수치 바꿔보고 다시 로딩해보고.. 를 반복해야 하기때문에 (물론 포토샵에서 좌표를 가져오는 법도 있지만 번거롭긴 마찬가지다)..

실제 작업시간이 상당히 많이 차이가 난다.

그리고 그 기능이 별도의 툴이 아니라 자체 편집이 필요한 이유는 게임화면을 보면서 실제 작동을 바로 테스트 할 수 있다는 장점이 있다..;;

처음 레이아웃 잡는건 툴에서 한다고 해도..

조금 작업하다보면 게임화면을 보면서 작업을 해야하게 되기 때문에 게임내에서 바로 편집할 수 있도록 만들어 두면 작업효율이 몇배의 차이가 난다.

현재의 UI는 게임중에 Control+Space Bar를 누르면 바로 편집모드로 전환되며(물론 개발용 빌드에서만 이다.. 배포용 빌드에는 막혀있다. )

덕분에 경영진 앞에서 시연하다가도 먼가 UI위치가 이상하다고 하면 바로 편집모드로 들어가서 쓱 끌어다가 옮겨주는 센스를 발휘할 수 있다.(처음보면 다들 신기해한다-_-a)

물론 경영진을 보여주기 위한건 아니고-_-;;

게임 상황에서 보면서 편집하기 위한 용도이며 기획자나 디자이너의 의견을 바로 적용해서 보여줄 수 있다는건 상당한 이득이다..

UI작업은 안그래도노가다성이 짙은데 작업시간마저 길다면 대략 재미없어지므로 가능한 작업시간을 단축시킬 수 있는 방법을 다각도로 연구하는게 좋다...;;

3. 이미지 매핑 기능을 넣쟈..

자체 UI편집기능이 있다면 바로 이미지 매핑을 해서 게임화면에서 볼 수 있도록 하는게 좋다.

꽤 오래전에 N모사의 L게임 2-_-에서 포토샵에서 이미지의 좌표를 보고 xml에 편집하도록 하는 알바-_-를 뽑는걸 보고 경악한적이 있다..

  2D스프라이트 툴을 만들어봤다면 이미지에서 적당한 영역을 체크해서 RECT를 뽑아오는 기능을 만드는게 별로 어렵지 않고 작업기간도 얼마 걸리지 않는 일인데...

이걸 사람이 수동으로 하다니-_-;;;;;;

어쨋건 UI작업의 30%정도는 좌표랑 크기 맞추기이고 50%정도는 이미지 세팅이기 때문에 마비노기나 라그나로크처럼 대부분의 UI를 같은 이미지 형태를 사용하는게 아니라면... 필수적인 기능이다..

게다가 편집기능이 이미 존재하면 별로 어렵지도 않고, 비용대비 효과는 환상적이다..;

4. 프라퍼티를 제어하쟈

똑같은 창이라고 해도 어떤창은 이동이 가능하고 어떤창은 폰트 크기가 다르다거나... 하는 식의 내용들이 많은데.. 자체 편집이 가능하다면 프라퍼티도 실시간으로 바꿀 수 있도록 하면 작동을 바로 확인할 수 있다..

현재 사용하는 속성은 대략 20개가 약간 넘는데.. 컨트롤 이름부터 Text, align, 좌표, 크기, 폰트, 처음에 열려 있을것인가..등등등과 각 컨트롤의 고유속성이 있다.

5. 이벤트 편집 기능을 만들쟈..

이벤트란 머 예를 들면, 메뉴의 한 버튼의 Click(Excute)이벤트가 발생하면 Inventory창에 Toggle(Visible/Hide) 메세지를 던진다.. 라는 내용이다.

타겟 컨트롤을 선택하고, 발생 이벤트를 선택하고 어떤 메세지를 던질지를 편집할 수 있게 하쟈

그리고 UI자체내에서 가능한 내용(Visible, Check등)은 바로 처리해준다..

그리고 클라이언트와의 연동이 필요하다거나 한 경우를 위해 커스텀 메세지를 지원한다.

현재의 모듈은 커스텀 메세지를 처리할 수 있는 C++콜백을 코드에서 수동으로 설정하거나, lua파일에 자동으로 연동되도록 되어 있다.

6. 다른 컨트롤을 포함하쟈.

예를 들어 콤보박스라고 하면(게임에선 DropList만 있으면 된다-_-)

현재 선택되어 있는 항목을 보여주는 Static과 선택창(List), 선택창을 여는 버튼(Button) 세개의 컨트롤로 구성 할 수 있다.

현재 이게 콤보박스라는 하나의 클래스에서 다 처리를 하게끔 되어 있는데 대략 낭패다..;;

현재는 분리가 안되있는 상태여서 쓸데없이 SubList가 열리는 이벤트라던가 하는 쓸데없는 이벤트와 메세지들이 생겨버렸다-_-;;

Static과 List와 Button의 각 이미지를 따로 세팅해야 하는데 물론 콤보박스의 이미지 종류를 늘려서 각각 세팅하도록 할수도 있지만..

이미 만들어져서 Focus처리나 이미지 처리, 속성처리, 이벤트처리까지 다 되는걸 만들어 놓고.. 따로 만들 필요는 없다..;

ComboBox라는 컨트롤을 만들고 위 세개의 컨트롤을 하위로 가지고 있도록 하고, 셀렉트 관련 몇가지 인터페이스만 만들어주면 쉽게 끝난다-_-;

7. Template기능을 만들쟈

이건 워드같은데 있는 문서 템플릿 같은걸 말한다..

일반 창이라고 하면, 적당한 크기에 윈도우용 크기가변 이미지가 세팅되어 있고, RightTop으로 Close버튼이 있고, 버튼에는 X모양의 이미지가 매핑되어 있고, Execute이벤트에 부모윈도우에 Invisible Message를 보내는 이벤트가 설치되어 있는...

형태가 자주 쓰는 창이라고 하면 이 창을 템플릿으로 따로 저장하게 하쟈..

어차피 저장기능은 있을거고 그게 전체 저장이 아니라 컨트롤 하나로 부터 하위로 저장을 하도록 하면 되니까 별로 어렵지는 않다.

응용하면 쉽게 컨트롤의 Copy&Paste기능을 만들 수 있다.

이 기능 하나로 지루한 작업을 꽤 줄여줄 수 있다..

만약 이미지가 같다고 하면 이미지와 이벤트가 모두 설정되어 있는 템플릿을 추가하면 바로 새로운 창하나 뚝딱 완성이다.

8. PixelScroll을 만들쟈..

스크롤 기능을 각 리스트컨트롤이나 콤보박스에 넣고, 따로 스크롤바컨트롤 하나 만들어서 창에서 Draw할때 참고하도록 할 수도 있지만..

PixelScroll이 되면 꽤 할 수 있는게 많다.

각 컨트롤별로 기능따로 만들고 창에 스크롤바 하나 달때마다 고생할거 생각하면 PixelScroll을 만들어서 속편하게 쓰쟈

9. 다국어 IME는 미리 만들쟈..

IME는 미리 만들어 놓는게 좋다. 그리고, 유니코드용으로 만들어서 UniScribe를 사용하도록 하는게 좋다.

나중에 해외화할때는 다른것도 할거 많은데 IME까지 신경쓰려면 대략 정신이 멍해진다..

UniScribe는 윈도우에서 제공해주는 텍스트 파서? 같은 형태인데. DX에서 Rect를 넣고 Text출력을 하면 줄바꿈 처리가 되는게 내부에서 UniScribe를 사용한다..(일반 어플리케이션에서도 사용한다..)

IME는 기본 IME와 Candidate외에 따로 처리해줘야 하는 언어가 몇개 있는데...

한국어, 중국어, 일본어, 태국어, 아랍어-_- 이다..

아랍에 수출할일은 없겠지.. ( __);

GPGStudy자료실을 뒤져보면 zupet님께서 한국어, 중국어, 일본어, 태국어..와 Candidate처리까지 되는 소스를 올려놓으신게 있으니 그쪽을 참고하고.. 혹시나 모자른 내용은 MSDN-_-)=b

IME는 예전에 다 처리해두었는데 블록 설정하고 Copy&Paste기능 따위를 넣다가 현재는 버그가 있는 상황이다ㅠ.ㅠ

10. 이미지 파일 포맷은 PNG를 사용하자.

PNG파일은 무손실 압축 포맷이며, 압축률이 상당히 높은 편이다.

UI의 경우 DXT포맷을 사용하면 이미지가 손상되어 TGA를 사용하는 경우가 많은데

TGA에 비해서 PNG쪽이 훨씬 용량이 적다.

게다가 TGA의 경우는 알파값을 알파채널에 따로 넣는 작업을 디자이너가 해줘야 하지만

PNG의 경우 포토샵의 투명배경(격자로 되어있는..;;)의 투명값을 그대로 가져올 수 있다.

레이어로 편집하고 있던 데이터를 그냥 세이브 해도 된다는 얘기다..;;

TGA의 경우는 레이어를 머지해서 투명도 값을 따로 뽑아서 알파채널에 넣어줘야 해서 상당히 번거롭다..;

디자이너가 편해지면 프로그래머도 편해진다는 점을 명심하자.

-----------------

물론 이외에도 다른 편의성 기능들이라던가 lua연동이라든가 만들면 좋은게 많겠지만.. 대략 이정도의 내용이면 지겨운 UI작업을 빠르고 쉽게 할 수 있으리라 생각된다.

당부를 하는건 vb나 mfc등의 어플리케이션용 UI를 참고하는건 좋지만, 어플리케이션과 게임은 사용목적이 전혀 다르기 때문에 중요하게 생각해야 하는것이 다르므로, 어플리케이션UI에 집착하면 좋지 않다..;