#1 게임 UI 제작에 프로토타이핑 툴 활용해보기
게임 UI 개발 프로세스에 대하여..
최근에 많은 프로토타이핑 툴이 나왔고, 이를 실무에 활용하는 UI 디자이너들이 많아지고 있습니다.
하지만 게임 업계에선 UX실이 따로 있는 곳을 제외하면 이에 대한 관심이 낮은 편입니다.
제가 생각하는 대표적인 이유는 아래와 같습니다.
- 현재 프로토타이핑 툴은 모바일 앱 ui제작 위주로 나와있음
- 개발 프로세스와 협업 방식의 차이
- 개발 스펙에 비해 타이트한 일정
때문에 당장 툴만 보고는 활용성과 필요성이 게임 UI 디자이너에게는 와 닿지 않는 게 사실입니다.(개발에 사용되는 툴과 개발 프로세스가 앱 UI 개발 프로세스 다른 점이 제일 큰 것 같습니다.)
하지만 개인적인 관심으로 툴들을 살펴본 결과, 평소에 느끼던 개발 프로세스 속에서의 불편함과 소모적인 대화를 효율적으로 개선할 수 있다고 생각하게 되었습니다.
그래서 매우 살포시.. 개인적으로 실무에 조용히 활용해보기로 결정했습니다.(주로 설득과 결정 단계에)
시작하기 앞서 : 무엇이 다른가?
게임 UI 제작 시 디자이너가 사용하는 툴은 저희 회사 기준으로는 시안 제작을 위한 툴과 UI 개발을 위한 툴로 나눠집니다.
시안 제작을 위한 툴은 주로 포토샵을 사용합니다.
게임 UI는 사용성 높은 UX를 추구함과 동시에 유저에게 동적인 인터랙션에서 오는 재미 또한 선사해줘야 하는 사명감이 있습니다.
그래서 다른 분야 UI보다 에셋의 그래픽 소스(사진, 텍스쳐, 이펙트 등) 사용률이 높고, 게임 전체의 아트적인 콘셉트도 고려해야 합니다.
시안 제작은 뭘 만드냐가 다른거지, 웹과 앱(과거 포토샵을 쓸때의)의 시안제작과 큰 차이를 없는 것 같습니다. 실제로 스포츠, fps장르에선 웹페이지와 유사한 디자인을 많이 사용합니다.
리그 오브 레전드 : 최근 오픈베타테스트 중인 UX개편(사용성을 고려하며 마법공학이라는 아트 컨셉을 훌륭히 녹여냈다.)
The Witcher3 : Wild hunter포토샵으로 제작된 시안이 통과되면, 컴포넌트별로 에셋을 추출하여 UI 개발을 진행합니다.
UI 개발을 위한 툴은 게임에 쓰이는 엔진에 맞춰 정해집니다.
모바일 앱 UI 제작과 다르게 게임 UI는 이 툴을 통해 디자이너가 직접 화면에 UI를 입히고, 화면을 구성하며, 한 화면에 들어가는 모션을 직접 넣습니다.(때문에 모션 그래픽의 역량도 요구됩니다.)
크게 나누면 현재 모바일 게임에서는 유니티를 점유율이 높은데, 이를 위해 UI 디자이너는 NGUI라는 UI 개발 툴을 사용합니다. PC, 콘솔게임들은 스케일폼이라는 UI 미들웨어를 많이 사용하는데, Flash를 기반으로 UI를 제작하여 C++ 기반의 엔진 위에 올려지는 것이 일반적입니다.(최근에 나온 피파 17 등에도 쓰이고 있습니다.)
웹, 앱에선 호환성 등과 같은 문제로 Flash를 거의 사용하지 않지만, 게임 쪽에선 여전히 활발히 사용되고 있습니다. 큰 이유에는 타임라인 기반의 Flash로 세밀하고 동적인 UI 컨트롤이 가능하고, 디자이너의 접근이 용이하기 때문입니다. 개발 과정에서 빌드에 올리는 화면 속의 UI, 모션 등은 디자이너가 직접 전담할 수 있습니다.
여담이지만, 스케일폼에서 컴포넌트는 Flash의 무비클립으로 만듭니다. 버튼도 버튼 심벌이 아닌 무비클립으로 만듭니다. 무비클립으로 엔지니어 코드가 연결되기 때문입니다.
게임 화면에 GUI, 모션 등을 디자이너가 직접 만들어 빌드에 넣는다.*gif 자료가 브런치 모바일앱에선 끝까지 재생이 안되는데 왜 그럴까요? PC에선 잘 나옵니다~!
저희 회사 기준에서 게임 UI 개발 프로세스는 아래와 같습니다.
1. 콘텐츠 기획서
: 기획자가 이러이러한 피처 혹은 기능을 만들겠다는 내용을 정리하는 단계입니다.
2. 개발 기획서
: 정리된 콘텐츠 내용을 토대로, 화면에 들어가는 정보를 두고 기획자와 UI 디자이너와 엔지니어가 일정 등을 체크하며 개발 가능 여부를 파악하고 결정된 내용들이 정리된 개발 기획서 문서가 나옵니다.
3. UI 시안 작업
: 개발 기획서를 보고 UI 디자이너가 화면에 대한 flow, layout, gui 등을 고려하며 시안을 제작하고, 시안 리뷰를 통해 기획자와 UX에 대한 의논이 이뤄집니다.
4. 코드 스켈레톤
: 완성된 시안 이미지와 flow를 엔지니어에게 전달하면, 엔지니어는 이를 토대로 코드로 화면에 뼈대를 잡습니다. 이때 gui는 엔지니어가 시안을 보고 사각형이나 다른 곳에서 쓰고 있는 컴포넌트를 가져와 대충 위치만 맞추고 코드를 연결시켜둡니다.
5. UI 스키닝
: 이름 그대로 코드로 이뤄진 UI뼈대에 디자이너가 GUI를 입힙니다. 1차적으로 에셋을 뽑아 시안과 동일하게 GUI들을 화면에 배치하고, 그 후 인터랙션 모션 / 게임 화면 연출 등 세밀한 작업을 진행합니다.
이때 모션 때문에 코드 수정이 필요한 경우가 종종 생깁니다. 그래서 엔지니어와 가장 많은 대화가 이뤄지는 과정입니다. 또 개발에 올린 UI를 Flash에서 퍼블리싱하면서 실시간으로 개발 빌드로 구동시켜 테스트를 할 수 있습니다.
앱 UI 개발 과정과의 큰 차이는 개발을 엔지니어와 디자이너가 함께 진행하는 4,5번 과정이라 생각됩니다.
엔지니어는 데이터와 코드에만 집중할 수 있고, 디자이너는 레이아웃/폰트/컬러/모션 등을 디자인 영역을 직접 관리하고 수정하고 테스트할 수 있기 때문입니다.(몇몇 특정 상황에 기획자와 엔지니어의 도움이 필요할 때도 있습니다.)(디자인 버그도 직접 고칩니다.)
어떻게 보면 UI 스키닝 과정에서 동시에 프로토타입을 만들어 빌드로 테스트를 해볼 수도 있습니다.
왜 프로토타이핑이 필요한가?
앞에서 UI 스키닝 과정에서 테스트를 바로 해볼 수 있다고 말했습니다.
하지만 이 과정에서 flow상의 오류를 발견하고 UI 수정 작업이 생기면, 때때로 데이터나 코드상에선 대공수가 일어나면서 일정에 리스크를 주는 상황이 생길 때가 있습니다. UX상 오류를 발견하면서 수정 안 할 순 없고.. 이는 곧 일정이 딜레이 되는 상황을 만들 수 있습니다.
또 UI 시안 리뷰 과정에서 기획자와 UX에 대한 의견이 다른 경우가 생깁니다. 이 경우 주로 flow에 관한 것이 많은데, 항상 멈춰있는 시안 이미지를 가지고 각자의 머리 속으로 생각을 하며 토론을 하기에 소모적인 대화가 많이 지는 경우가 생각보다 많았습니다.
때문에 저는 게임 ui 제작 과정에선 flow에 대한 프로토타이핑의 필요하다고 느꼈습니다.
보고 생각하는 것과, 만져보는 것은 꽤 많은 차이가 있습니다.
제작한 시안으로 만든 프로토타이핑으로 기획자와의 효율적인 토론을 유도할 수 있고, 엔지니어의 스켈레톤 작업이 들어가기 전에 빠르게 전체적인 UX 체크를 해서 수정의 가능성을 낮출 수 있다고 생각했습니다.
다음 글에서 프로토타이핑에 대한 구체적인 이유와 제가 판단한 게임 ui 개발 프로세스 속에선 어떤 프로토타이핑 툴이 적합한지에 대한 글로 찾아뵙겠습니다.
