[번역] 이전 웹/앱을 다뤘던 UX디자이너에게 게임 UX란? by Jasper Stephenson

Choo Sooa
7 min readMar 17, 2021

--

  • Jasper Stephenson미디움 글 번역으로, 번역에 대한 허락을 맡았습니다.
  • 오역, 의역 있습니다. 오역은 제보해주시면 감사하겠습니다.

지난 10년 동안, GDC 같은 게임 업계의 큰 이벤트의 사이드로 시작했던, 게임 UX 서밋(2017/2018)과 게임 유저 리서치 컨퍼런스 같은 행사들이 게임 UX를 발전시키기 위해 생겨났다.

게임 회사가 UX 직군을 채용하는 숫자 또한 가파르게 상승하고 있다.

2017 게임 UX 서밋의 주 무대 (출처)

하지만 도대체 게임 UX라는 건 뭐지? 그냥 웹이나 앱에 적용하던 원칙을 게임에 똑같이 적용하고 끝내면 안되나?

그에 대한 대답은 “항상 같지는 않다”이다. 나는 이 글을 몇 가지 굉장히 다른 핵심적인 방법들을 이야기하고 싶어서 썼다.

전통적인 UX 접근 방식이 게임 UX에 설 자리가 없다고 말하는 것이 아니다. 사실 새로운 툴과 사고방식을 실험할 땐, 가지고 있는 지식에서 시작하는 것이 중요하다.

게다가 이 글에서 내 목표는 개인 경험 뿐만 아니라 몇 케이스 스터디에서 반복적으로 봤던, 게임-UX의 특정 이론들 강조하기다. 그리고 웹사이트와 앱의 UX 디자인 기본에서 그들이 얼마나 다른지를 분석하기 위함이다.

시작하자!

유저 테스트

우선 먼지 유저 테스트에 대해 생각해보자. 유저 테스트에 있어 게임 VS 웹/앱의 가장 큰 변화는 테스트의 크기와 길이에 있다. 웹/앱의 사용은 보통 목표에 기반한다. 목표를 한번 달성하면, 보통 그 세션은 끝난다. 반대로 게임은 한번에 몇 시간동안 플레이 할 수 있고, (웹/앱에 비해) 좀더 탐사를 하거나 협동을 한다. 이것에 댑을 얻기 위해서 테스트 환경은 확장되고 주기는 엄청나게 길어진다.

예를 들어 헤일로3의 유저 테스트에 대한 기사에서, 마이크로소프트 UX팀은 “헤일로3의 3천 시간 이상을 분석…”이라고 썼다. 이건 대부분의 UX 테스트와 비교해봤을 때 어마어마하게 큰 숫자다. 그러나 메이저 게임 하나에 내재된 다양한 경험과 흐름을 생각했을 때에는 말이 된다. 아마 각각의 테스트 세션들은 몇 시간 정도 지속되었을 것이고, 이런 것은 웹/앱 분야에서 찾아보기 어렵다. 거대한 데이터 분석을 정확히 어떻게 끝낼 수 있는지에 대해선, 잠시 뒤에 다루도록 하겠다.

단일 테스트에 있어선 더욱 많은 수의 플레이어를 동시 접속시키는 경향이 뚜렷하다. 예를 들어, 라이엇 게임즈은 최근 60명 이상의 플레이어가 한번에 참가할 수 있는 새로운 테스트실을 공지했다.

라이엇게임즈가 가진 여섯 유저 테스트실 중 하나 (출처)

또한 분석가들이 게임을 다른 방법으로 측정하는 것은 주목할 만 하다. 웹/앱이 태스크 완료에 쓰이는 시간이나, 디자인 평가를 위해 유저가 실수하는 빈도를 측정할 때, 게임UX분석가는 얼마나 성공적으로 레벨디자인이 되었는지, 인터렉션이 되는지 인사이트를 얻기 위해 다른 것을 측정할 것이다. — 다른 플레이어들과 커뮤니케이션의 톤, X분 간격마다의 진행, 심지어 심장 박동수나 눈동자 움직임 같은 것들 말이다.

그런 측면에서…

데이터 수집과 분석

게임 유저 테스트가 만들어내는 어마어마한 양의 데이터를 생각했을 때, 게임UX팀이 이 산처럼 많은 정보를 쓸만한 것으로 분석하는 것은 어떻게 가능한가?

그 답은 커스텀된 분석과 내장된 데이터 캡쳐-시각화 툴에 있다.

데스티니 가디언즈2 같은 게임을 해보시라. 데스티니2는 모든 월드의 레벨이 꽤 자유롭게 형성되어 있고, 플레이어들은 제한 없이 자유롭게 모이고 상호작용 할 수 있다. 예를 들자면, 플레이어 15명 각각의 3시간 플레이에서 어떻게 유용한 정보를 얻어낼 수 있는가?

Bungie의 지도(데스티니 가디언즈) — 테스트 결과를 매핑하는 시스템 (출처)

Bungie팀은 이곳에 데이터를 모으는 몇번의 시도를 했다. 그 중 내가 강조하고 싶은 것은 이 부분이다. — 팀은 플레이어에게 3개의 기분 버튼(놀라움, 잃어버림, 좌절)이 달린 판을 줬다. 그들은 테스트 도중 해당 기분을 느낄 때 버튼을 누르도록 지시받았다.

Bungie의 개발팀은 게임 안에 실제로 이 버튼 시스템을 만들어두었다. 버튼이 눌리면, 플레이어의 위치가 지도에 기록된다. 이 데이터로 인해 테스트 팀은 (위에 보이는 것처럼) 간단한 플레이어 감정 지도(heat map)를 만들 수 있었다. 이 지도는 레벨 디자인 팀에게 플레이어가 어떻게 느끼는지 쉽게 보여주고 설명해주었기 때문에 문제 있는 지역을 빠르게 반복 개선할 수 있었다.

이런 종류의 (게임에) 내장된 분석툴은 UX분석팀에게 그들이 원하는 정보를 원하는 형태로 분석할 수 있게 했다. 즉, 웹/앱 UX에서 종종 보이는 레벨 이상으로 깊숙하게 UX팀과 개발팀을 연결시킨 것이다. 만약 UX팀이 개발팀에게 주요 데이터 수집에 대해 도움을 요청하지 않았다면? 아마도 로우데이터를 일일히 분석하느라 더 많은 시간을 소비하고, 이해하는데에 시간이 촉박했을 것이다.

재미삼아 레벨디자인을 위한 내장 분석툴의 다른 예시를 보여주겠다.

마이크로소프트의 UX팀이 헤일로3 정글지역의 레벨을 테스트할 때, 개발팀에게 데이터 배분만을 위한 새로운 시스템을 만들었다. 각 테스터의 위치는 지도 위에 5분 단위마다 다른 색으로 표시된다 — 5분은 빨강색, 10분은 분홍색 같은. 같은 지도에 모든 테스터들의 위치가 맵핑되었을 때, 플레이어들이 정확히 어떤 지역(레벨)에서 헤매는지 빠르게 알 수 있었다.

5분마다 플레이어의 위치가 찍힌 점들. 테스트마다 각기 다른 점. 최종적으론 이렇게 보인다. (출처)

위의 그림처럼 모든 점이 잘 정렬된다면, 지역과 지역 사이, 레벨이 좋은 흐름으로 디자인 되었는지 힌트가 된다.

의도적인 도전

(출처)

[사용자를 생각하게 하지 마!] 는 잘 만든 UX 캐치프라이즈다.

이걸 게임UX에 적용시키지 마라.

대신, 게임을 디자인할 때 [사용자를 생각하게 하지 마!]는 [사용자의 노력을 낭비하게 하지 마!]가 되어야 한다.

Witness 속 퍼즐 (출처)

시스템, 메뉴, 컨트롤은 명백하게 직관적으로 동작해야 한다. 그러나 게임은 플레이어에게 생각하고, 배우며 성장하는 도전을 필수적으로 포함하고 있다. 이는 대부분의 웹/앱 프로젝트가 피하려고 하는 방식이다.

Witness의 디렉터 Jonathon Blow의 표현처럼, 게임 디자이너들은 “플레이어가 해답을 생각해낼 수 있고, 찾아내길 원하거나 게임의 시작에서 알았던 것보다 더 이해하길 원하는, 현명한 사람이라는 것을 존중”할 필요가 있다.

UX디자이너는 의도적인 고난(도전)을 잘 디자인하지 않는다. 하지만 과업 달성으로 인한 만족은 한다. 그말인 즉슨 게임의 매커니즘과 세계 형성에 대한 게임디자이너의 안목이 결합될 때, UX디자이너로서 당신의 능력은 게임을 만족하는 동시에 도전하게 만들 것이다. UX디자이너는 어려운 시스템에서 재미와 만족을 최대한 이끌어내기 때문이다.

물론 세상에는 게임에 UX를 적용시키는 숱한 방법들이 있다. (스팀의 얼리억세스 같은) 프로토타입들이나, 같은 씬에서 다중의 다른 유저 인식을 위해 디자인하는 것 같은 것들 말이다. 그러나 그건 다른 기사에서 다룰 것이다. (아마도 파트2?)

또 나는 게임UX에 관한 글와 내역이 실제로 얼마나 적게 쓰여지는지 말하고 싶다. 전세계 게임 회사들이 UX를 지향하고 있는 것은 분명하니 이 분야를 발전시키기 위해 노력하자! 나는 더 많은 게임UX팀이 그들의 일에서 맞닥트린 도전과 해결에 대해 글을 쓰면 좋겠다. 그럼으로서 우리는 더 나은 게임을 만들고, 즐길 수 있을 거다.

읽어줘서 감사합니다!

(원래 이 글은 내 웹사이트에 포스팅되었었다. jasperstephenson.com)

--

--