달력

12

« 2018/12 »

  •  
  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
  •  
  •  
2012.02.07 12:00

라그나로크 GUI 작업기 - 2005.02. dev_logs2012.02.07 12:00

원문 : http://quve.egloos.com/1010508

이미 한참 오래된 게임이 되어버렸긴 했지만, 첫 게임 GUI 기획작이자 실 디자인까지 맡았던 라그나로크 온라인의 작업에 대한 기록을 예전 이글루스에 남겨놓긴 했었는데, 백업을 위해 그대로 옮겨올까 하다가 기억을 더듬어 좀더 수정해 정리.

2000년 어느 날 라그나로크의 개발이 시작되고 난후 액션RPG 타입이 될지 택틱스RPG타입이 될지도 확정하지 못하고 갈등할 무렵, 레벨디자인 작업과 인터페이스 작업을 겸하고 있던 내게 김학규 사장님이 A4 종이에 낙서하듯 그린 인터페이스 레이아웃을 건네 주었다. 그 초기 시안은 그때까지 벤치마킹을 위해 찾고있던 리니지나 디아블로 같은 구성의 레퍼런스들과는 전혀 다른 것이였고, (개인적으로 느끼기엔) 게임에 있어 전에 없이 파격적인 구조와 디자인을 가지고 있는 것으로 보였다. 그 종이에 그려진 것은 바로 winamp 타입의 플로팅 윈도우형 GUI.

당시엔 대부분 리니지, 디아블로, 울티마 같이 이미 고정된 레이아웃의 GUI에 정해진 위치에 띄워지는 프레임 윈도우 방식이 대다수였기 때문에, 지금은 온라인 게임에 있어 일반적이 되어버린 플로팅 윈도우형 인터페이스 자체도 생소했었던 시기였다. 일단 요구 의도 자체는 '게임 화면을 최대한 가리지 않았으면 하기에, 필요할 때 꺼내쓰고 넣는 방식이 되었으면 한다'가 있었기에, 그에 위해 winamp가 다른 미디어플레이어들에 비해 가진 장점들을 찾아보게 되었다.

- 학습을 최소화 한 심플한 기능과 사용성
- 필요한 기능만 호출해 사용 가능
- 모든 기능을 한번에 불러 멀티태스킹 가능
- 작은 형태와 일반 형태로 변형 가능
- 변경 가능한 스킨
- 각 윈도우 간 스냅 달라붙기
- 최종 좌표를 저장하는 플로팅 윈도우

찾아보면 뭐 더 있겠지만 위와 같은 사항들이 우선 정렬되었다. 하지만 이것을 게임에 어떻게 적용해야 할지가 문제였는데, 그때까지는 콘솔 게임처럼 아예 시간을 정지하고 인터페이스를 호출해 보는게 아닌 이상, 온라인 게임은 중지할 수 있는 실시간 환경임을 고려하여 이미 보여지고 있는 UI 화면 내에서 중요한 파라메터값은 기본 표기하면서 하위 기능을 바로 호출할 수 있게 돼있었기 때문이였다.
때문에 이미 이런 낮은 뎁스의 인터페이스 네비게이션에 익숙해진 유저들에게 한단계 뎁스를 추가해 호출하도록 하는 것은 좋지 않은 선택이였기에, 결국 최초로 표기되는 UI 윈도우 패널 자체를 통합형으로 만들지 않고 메인윈도우/채팅윈도우/맵윈도우로 분리해 화면 내 배치하고 서브윈도우를 종속 호출하되 일정한 크기를 유지해 스냅하는 것으로 정리하였다.

하지만 당시 시간적으로 완전한 객체지향적 인터페이스 구조를 구현하기에 할애된 시간은 적었던데다 변경 가능한 스킨이라는 기능 때문에 디자인 자체도 컴포넌트 타입으로 단순 구조화해야 했기에, 기획/디자인/구현을 병행하면서 상당한 시행착오 + 끊이지 않는 버그를 겪게 되었다. 출시 이후 홍보에서는 윈도우즈 방식의 유저지향성 인터페이스를 채용했다고 대놓고 강조하긴 했지만, 일부에 있어서 그 사용성만 차용한 것 뿐이고 기획적으로나 디자인적으로나 구현적으로나 해당 방식의 UX에 대한 본질적인 접근은 하지 못했기에 상당히 애매하면서도 민망한 느낌도 있었다;;

어쨌든 이러한 사항을 바탕으로, 기획이 준비하고 있었던 시스템들과 파라메터들이 하나둘씩 정리되어 카테고리로 묶이기 시작했고, 각 기능 윈도우의 항목들이 시스템맵으로 정리되어갔다. 이렇게 내용을 채워넣다보니 최초의 A4 스케치와는 많은 부분이 달라지게 되었는데, 창의 기본 사이즈가 문제가 되기 시작했다. 애초부터 인벤토리창과 채팅창을 제외하고는 스킨의 디자인적 개입을 최대화하고자 기본적인 컴포넌트의 사이즈를 winamp와 거의 유사하게 고정했었는데, 각 기능마다 내용을 넣다보니 창의 크기가 너무 협소했던 것이다. 물론 좌우나 상하로 움직일 수 있는 스크롤바가 있었지만, 내용 부분을 프레임으로 나눠 include하는 형태로 렌더하는 방식이 아니였기에 불가능한 부분이 더 많았다. 하지만 결국 이 부분은 당시의 일정 상 포기할 수 밖에 없었고, 결국 일부를 제외한 대부분의 윈도우는 각자 렌더해 통째로 뿌리는 방식이 되어 스킨 만들기에 용이하도록 유지되었다.
덕분에 몇몇 윈도우의 경우에는 기능이나 파라메터가 추가될 때마다 레이아웃이 깨지게 되었고, 특정 언어에서는 정해진 영역에 구겨넣다보니 글자 폰트 자체가 너무 작아지거나 뭉게져 가시성을 해치는 결과까지 낳았다. 게다가 요즘 게임들처럼 해상도와 UI 크기를 분리하는 기능 없이 해상도가 변경되어도 UI의 크기는 변하지 않도록 했기 때문에, 고해상도에서는 UI가 모두 작아져 특정 버튼을 조작하기 어렵거나 텍스트 자체를 알아보기 힘들 정도로 불편해지기도 했다.

당시에는 이러한 부분들을 충분히 고려하지 못한 채 디자인만 중시해 접근하다보니 많은 부분을 놓치게 된 것 같다. (그래봤자 스킨 샘플로 급히 추가한 scribbling kids의 디자인 빼면 osx의 aqua 스타일의 흉내내기만;;) 하지만 이러한 나름의 고민과 무식한 결과물이 일본 동인을 중심으로 유저 제작 스킨이라는 측면에서는 큰 반향을 일으켜 짧은 시간 내 정말 많은 변형형을 만들어내자;; 되돌이킬 수 없는 상황- 제작된 유저 스킨이 호환되어야하니, 현 GUI 시스템이나 디자인의 구조 개선은 하지 말자 -이 되어버려 좋으면서도 한편으론 아쉽기도 했던 것 같다.




Posted by JC Shin quvelab