📚 지식 노트

게임 UI 네 갈래: 디제틱·비디제틱·공간·메타

웹 화면의 UI는 모두 "화면 위"에 있다. 게임은 다르다. 체력이 화면 구석 막대일 수도, 주인공 옷에 붙은 불빛일 수도, 벽 너머 아군의 윤곽선일 수도, 시야가 붉게 물드는 효과일 수도 있다. 이 차이를 두 질문으로 가르는 틀이 널리 쓰인다. 그 정보가 이야기 세계 안에 있어 인물도 볼 수 있는가, 그리고 3D 공간에 놓였는가, 화면 평면에 덧그렸는가다.

이 네 이름은 에릭 파게르홀트와 망누스 로렌손이 EA DICE와 함께 쓴 2009년 석사 논문 Beyond the HUD의 정의로 퍼졌다. Game Developer의 글이 이 정의를 따라 예를 든다. 데드 스페이스의 홀로그램 화면은 디제틱, 대부분의 고전 HUD는 비디제틱, 레프트 4 데드의 아군 윤곽선은 세계의 물건이 아니면서 공간에 그려지는 공간 UI, 맞았을 때 화면에 튀는 피는 세계의 상태를 평면에 나타내는 메타 UI다.

칸마다 값이 다르다. 디제틱은 몰입을 깨지 않지만 카메라 각도와 조명에 따라 가려진다. 비디제틱은 언제나 같은 자리에서 읽히지만 화면을 덮는다. 공간 UI는 "어디에"를 말하는 데 가장 좋고, 메타 UI는 숫자 대신 느낌으로 상태를 전한다. 이 분류의 기본과 데드 스페이스 사례는 게임 개발 › 난이도·접근성·UX에 있으니, 이 글은 그 다음, 실제로 화면에 어떻게 배치하고 조작하게 하는지를 다룬다.

HUD 정보 위계와 배치: 가운데는 비우고 가장자리에 둔다

HUD(heads-up display)는 플레이하는 동안 늘 떠 있는 정보다. 시선은 조준점과 캐릭터가 있는 화면 가운데에 머물고, 가장자리는 주변 시야로만 본다. 주변 시야는 글자를 읽지 못하지만 움직임과 밝기 변화는 잘 잡는다. 그래서 배치의 기본은 이렇다. 읽어야 하는 정보는 모서리에 고정해 두고, 지금 반응해야 하는 신호는 가운데 가까이에서 움직임과 색으로 알린다.

• 순위를 먼저 매긴다: "지금 죽을 수 있다"(낮은 체력, 날아오는 공격)가 1순위, "어디로 가나"(미니맵, 목표)가 2순위, "무슨 일이 있었나"(킬 피드, 획득 알림)가 3순위다. 순위가 크기·대비·위치·움직임을 나눠 받는다.
• 자리를 바꾸지 않는다: 같은 정보는 늘 같은 모서리에 둔다. 눈이 자리를 외우면 보지 않고도 찾는다. 메뉴와 HUD의 자리 규칙이 게임마다 비슷한 것도 플레이어가 이미 외운 자리를 쓰기 위해서다.
• 방향은 방향으로 알린다: 왼쪽에서 맞았다면 글자보다 조준점 왼쪽의 붉은 호 하나가 빠르다. 소리의 방향과 겹쳐 주면 더 빠르다.
• 색만으로 말하지 않는다: 위험을 빨강 하나로만 알리면 색각 이상인 사람은 놓친다. 모양, 깜빡임, 소리를 함께 붙인다. 색각 이상 시뮬레이터로 HUD 스크린숏을 바로 확인할 수 있다.

최소 HUD와 정보 많은 HUD, 그리고 상황형 HUD

HUD의 양은 장르가 정한다. 공포·탐험 게임은 화면을 비워 세계가 정보를 전하게 한다. 빛이 길을, 소리가 위험을 알린다. 반대로 MMO 레이드나 MOBA처럼 숫자로 판단하는 장르에서는 정보가 곧 조작이다. 파티원 체력, 스킬 재사용 대기, 보스 시전 막대를 보지 않고는 할 수 없다. Game Developer의 글은 월드 오브 워크래프트 플레이어들이 기본 화면보다 정보가 빽빽한 애드온 HUD를 더 좋아하는 듯 보인다고 적고, 배치를 스스로 바꿀 수 있으면 붐비는 화면도 받아들여진다고 짚는다.

둘 사이의 흔한 답이 상황형 HUD(contextual HUD)다. 평소에는 숨겨 두고, 그 정보가 필요해지는 사건이 생길 때만 잠깐 띄운다. 같은 글은 파 크라이 2가 비디제틱 HUD를 저절로 나타났다 사라지게 했다는 예를 들면서, 그 대신 플레이어가 언제 볼지를 고를 수 없게 된다는 점도 짚는다. 그래서 상황형 HUD에는 "항상 표시" 설정을 함께 둔다. 규칙은 두 가지로 정리된다. 사건 뒤 몇 초 동안 보일지, 그리고 어느 값 아래면 사건과 상관없이 계속 보일지다.

체력 막대·미니맵·크로스헤어·데미지 숫자

HUD 위젯 하나하나에도 정해진 질문이 있다. 무엇을 한눈에 읽게 할지, 무엇을 고정할지, 무엇을 감출지다.

• 체력 막대: 막대는 숫자보다 빨리 읽힌다. 방금 잃은 양을 연한 잔상으로 남겼다가 잠시 뒤 줄이면, 한 번에 얼마나 맞았는지가 보인다. 칸을 나누면 "두 칸 남았다"처럼 셀 수 있고, 회복 아이템 하나가 한 칸을 채우게 맞추면 계산이 쉬워진다. 정확한 값이 판단에 필요한 장르라면 숫자를 함께 둔다.
• 미니맵: 북쪽 고정은 큰 지도와 방향이 같아 위치를 외우기 좋고, 진행 방향 고정은 화면의 왼쪽이 지도의 왼쪽이라 길 찾기가 쉽다. 둘 다 장단이 있어 설정으로 고르게 하는 게임이 많다. 미니맵을 없애고 나침반 띠만 두면 시선이 세계에 더 머문다.
• 크로스헤어: 조준점은 그 무기가 지금 맞을 범위를 보여 주는 장치다. 달리거나 연사할 때 벌어지게 하면 탄 퍼짐을 배우게 한다. 맞혔는지는 조준점 둘레의 짧은 표시와 소리로 알린다. 반동과 탄 퍼짐의 원리는 게임 개발 › 조작감·확률에 있다.
• 데미지 숫자: 크기와 색이 뜻을 갖게 한다. 작은 타격은 작게, 치명타는 크고 다른 색과 모양으로. 연타가 한 자리에 겹치지 않게 조금씩 흩고, 너무 많으면 합쳐 보이거나 끌 수 있게 한다. 숫자가 화면을 덮어 적의 준비 동작을 가리면 손해다.

메뉴 흐름: 메인 → 설정 → 인게임 일시정지

메뉴는 화면의 스택이다. 열 때마다 한 칸 쌓고, 뒤로 가기(패드의 B, 키보드의 Esc)는 한 칸 내린다. 규칙은 단순하지만 두 가지를 자주 틀린다. 하나는 같은 화면을 여러 곳에서 여는 경우다. 설정은 메인 메뉴에서도, 게임 중 일시정지에서도 열린다. 화면은 하나로 만들고, 뒤로 가기는 "메인 메뉴로"가 아니라 "연 곳으로" 돌아가야 한다. 다른 하나는 깊이다. 원하는 설정까지 서너 단계를 내려가야 하면, 자주 바꾸는 것(자막, 음량, 감도)을 위로 올린다.

• 타이틀 화면은 입력 장치를 알아내는 곳이다. "아무 버튼이나 누르세요"에서 누른 장치를 기억해 두면 이후의 버튼 안내를 그 장치에 맞출 수 있다.
• 되돌릴 수 없는 일은 한 번 더 묻는다: 저장 파일 삭제, 저장하지 않고 나가기. 확인 창의 기본 포커스는 안전한 쪽(취소)에 둔다. 확인 버튼을 연타하다 실수로 지우는 일을 막는다.
• 일시정지가 멈추지 않는 게임: 온라인 게임은 메뉴를 열어도 세계가 돈다. 그 사실을 화면에 알리고, 메뉴 뒤로 게임 화면이 보이게 둔다.
• 설정은 바로 보인다: 밝기, 음량, 자막 크기는 바꾸는 즉시 미리 보여 준다. 적용 버튼을 누르고 나서야 결과를 아는 설정은 몇 번씩 오가게 만든다.

컨트롤러 포커스 내비게이션

마우스는 가리키는 곳을 바로 누르지만 패드는 포커스를 한 칸씩 옮긴다. 그래서 패드 메뉴에는 마우스 메뉴에 없는 세 가지가 필요하다. 지금 포커스가 어디 있는지 늘 보이는 강조, 방향키를 누르면 어디로 갈지 정한 이웃 관계, 화면을 열었을 때 처음 포커스를 둘 곳이다. 포커스 강조가 없거나 흐리면 패드로는 메뉴를 쓸 수 없다.

이웃을 정하는 흔한 방법은 위치로 계산하는 것이다. 아래 그림은 이렇게 계산했다. 누른 방향 쪽 가장자리 너머에 있는 요소만 후보로 두고, 가장자리 사이 거리에 중심이 옆으로 벗어난 거리의 두 배를 더해 가장 작은 것을 고른다. 옆으로 벗어난 거리에 무게를 주면 같은 줄·같은 열의 요소가 먼저 뽑힌다. 자동 계산은 출발점일 뿐이고, 어색하게 이어지는 곳은 손으로 이웃을 지정한다.

• 좌우가 값 바꾸기라면 탭 이동은 다른 버튼으로: 설정 항목에서 ←→가 값을 바꾼다면 왼쪽 탭으로 넘어가는 데 쓸 수 없다. 탭 이동은 숄더 버튼(LB·RB 같은)에 따로 준다.
• 되돌아오면 같은 곳: 아래로 갔다가 위로 오면 출발한 요소로 돌아와야 한다. 기하만 쓰면 이 대칭이 깨지는 경우가 있어 확인한다.
• 끝에서 감쌀지 정한다: 목록 맨 아래에서 ↓를 누르면 맨 위로 돌아갈지(감싸기) 멈출지 정한다. 긴 목록은 감싸기가 편하고, 격자는 멈추는 편이 덜 헷갈린다.
• 포커스를 잃지 않는다: 창을 닫거나 항목이 사라질 때 포커스를 엉뚱한 곳이나 아무 데도 없는 상태로 두지 않는다. 연 버튼으로 되돌린다.
• 모든 기능을 디지털 입력만으로: 스틱 없이 방향키와 버튼만으로도 끝까지 다룰 수 있어야 한다. 인벤토리처럼 칸이 많은 화면을 가볍게 그리는 법은 게임 개발 › 엔진 구조·최적화의 리스트 가상화에 있다.

버튼 프롬프트: 지금 쥔 장치의 글리프로

"A를 눌러 줍기"는 Xbox 패드를 쥔 사람에게만 맞는 말이다. 같은 자리의 버튼이 PlayStation 패드에서는 ×이고, 키보드라면 E 같은 키다. 버튼 프롬프트는 마지막으로 입력이 들어온 장치를 따라 글리프를 바꿔 그린다. 마우스를 잠깐 움직였다고 화면 전체가 키보드 안내로 바뀌었다 되돌아오는 깜빡임을 막으려고, 바꾸는 조건에 약간의 여유를 두기도 한다.

스팀 덱 검증 기준(Steam Deck Compatibility Review)은 이것을 요구 사항으로 둔다. 화면의 글리프는 지금 쓰는 입력(덱, 스팀 컨트롤러, Xbox 패드)과 맞아야 하고, 키보드·마우스가 지금 입력이 아니면 그 글리프를 보이면 안 된다. 같은 기준은 이름을 짓는 등 글자 입력이 필요하면 패드만으로 쓸 수 있는 화면 키보드를 띄우게 하고, 기본 조작 설정만으로 모든 내용에 닿을 수 있어야 한다고 적는다.

기호의 뜻은 문화와도 엮인다. 일본에서는 오랫동안 ○가 확인, ×가 취소였는데, PS5는 2020년에 확인 버튼을 모든 지역에서 ×로 통일했다. 소니는 콘솔 메뉴와 게임의 확인 버튼이 달라지는 것을 피하려는 것이라고 밝혔다(Anime News Network). 여러 플랫폼에 내는 게임은 확인·취소를 고정된 글자가 아니라 "확인 동작", "취소 동작"으로 다루고, 플랫폼마다 글리프와 버튼을 맞춘다. 글리프 안의 글자도 글자다. XAG 101은 아이콘 안의 글자도 최소 글자 크기를 지키고, 글자를 키우면 글리프도 200%까지 함께 커져야 한다고 적는다.

세이프 영역과 해상도·종횡비

TV는 화면 가장자리를 잘라 보여 주는 경우가 있다(오버스캔). 그래서 콘솔 게임은 중요한 UI를 안쪽 영역에만 둔다. Xbox 개발자 문서는 렌더링한 화면의 안쪽 95%를 액션 세이프, 안쪽 90%를 타이틀 세이프로 정한다. 4K 화면이면 액션 세이프가 3648×2052, 타이틀 세이프가 3456×1944이다. 메뉴, 제목, 게임 진행과 이야기에 꼭 필요한 내용은 타이틀 세이프 안에 그린다. 같은 문서는 액션 세이프 안이라도 좌우 32픽셀, 위아래 8픽셀에는 시스템 UI가 뜰 수 있으니 게임 UI를 두지 말라고 적는다.

PC와 휴대 기기는 종횡비가 제각각이다. 흔한 16:9 말고도 21:9 울트라와이드 모니터가 있고, 스팀 덱 검증 기준은 덱의 네이티브 해상도인 1280×800(16:10)을 우선, 1280×720을 다음으로 지원하라고 권한다. HUD를 16:9 화면 좌표에 박아 두면 다른 비율에서 엉뚱한 자리에 가거나 잘린다. 그래서 HUD 요소는 가장 가까운 모서리에 붙이고(앵커), 모서리에서 떨어진 거리로 위치를 정한다. 화면이 넓어지면 모서리가 멀어질 뿐 배치는 깨지지 않는다.

21:9에서는 모서리에 붙인 HUD가 시선에서 너무 멀어진다는 문제가 생긴다. 그래서 HUD만 16:9 폭 안으로 모으는 설정을 두기도 한다. 화면 비율에 따라 무엇이 잘리고 남는지는 화면 비율 미리보기에서 직접 겹쳐 볼 수 있다. 반응형 웹의 브레이크포인트와 같은 문제를 게임에서는 앵커와 세이프 영역으로 푼다(반응형·모바일·접근성).

텍스트 가독성: 거실 TV는 멀다

콘솔 게임은 소파에서 TV를 보며 한다. 화면은 크지만 훨씬 멀어서 같은 픽셀 수의 글자가 눈에는 작게 맺힌다. 글자가 읽히는지는 픽셀이 아니라 눈에 차지하는 각도(시각)로 정해진다. 화면 크기와 해상도로 픽셀 하나의 실제 크기를 구하고, 글자 높이를 거리로 나누면 각도가 나온다.

XAG 101은 게임을 켰을 때의 최소 기본 글자 크기(디센더 아래 끝에서 어센더 위 끝까지의 높이)를 플랫폼별로 둔다. 콘솔은 1080p에서 26px, 4K에서 52px, PC·VR은 1080p에서 18px, 4K에서 36px다. 모바일은 100 DPI에서 18px이고 DPI에 비례해 늘린다(400 DPI면 72px). 스팀 덱 기준은 30cm 거리에서 쉽게 읽혀야 하고, 1280×800에서 가장 작은 글자도 9픽셀 밑으로 내려가면 안 되며, 가능하면 12픽셀을 목표로 하라고 권한다.

그림의 각도로 보면 55인치 TV를 2.5m에서 볼 때 26px는 22.7분, 24인치 모니터를 60cm에서 볼 때 18px는 28.5분이다. 같은 TV에 18px를 띄우면 15.7분으로 줄어, 콘솔 기준이 왜 PC보다 큰지가 보인다. 최소 크기 말고도 XAG 101은 몇 가지를 더 적는다.

• 200%까지 키울 수 있게: 내용과 기능을 잃지 않고 최소 크기의 두 배까지 글자를 키울 수 있어야 한다. 키운 글이 화면을 넘으면 한 방향 스크롤로 읽게 한다.
• 줄 길이: 두 줄이 넘는 글은 한 줄에 80자, 한국어·중국어·일본어는 40자를 넘지 않게 한다. 줄 간격은 1.5배 이상이다.
• 글꼴: 산세리프 글꼴을 하나 이상 고를 수 있게 하고, 장식 글꼴을 쓰면 장식 없는 글꼴도 준다. 지원하는 모든 언어의 글자가 글꼴에 있어야 한다.
• 배경과 떨어뜨리기: 장면 위에 뜨는 글은 외곽선이나 반투명 판을 깔아 어떤 배경에서도 읽히게 한다.

현지화: 글은 늘어나고, 한글은 키가 크다

번역하면 글 길이가 달라진다. W3C 국제화 글(Text size in translation)이 옮긴 IBM 지침은 영어 원문을 유럽 언어로 옮길 때 평균으로 얼마나 늘어나는지를 길이별로 적는다. 10자 이하는 200~300%, 11~20자는 180~200%, 70자를 넘으면 130%다. 짧은 문구일수록 많이 늘어난다는 것이 요지다. 버튼 이름과 메뉴 항목이 바로 그 짧은 문구다.

한국어로 먼저 만든 게임이라면 더 조심해야 한다. 같은 글에 따르면 한글·한자 한 글자는 폭으로 라틴 글자 두 개쯤으로 세고, 실제 번역에서 한국어가 영어보다 짧아지는 예도 있다. 한국어 화면에 맞춰 버튼을 빠듯하게 잡으면 영어·독일어판에서 넘친다. 높이는 반대다. 한중일 글자는 라틴 글자보다 키가 커서 줄 간격을 더 넉넉히 잡아야 한다.

• 칸은 늘어나게: 버튼과 목록은 글자에 맞춰 늘어나거나 두 줄로 내려가게 만든다. 글자를 줄여 우겨넣는 것은 최소 크기를 깨므로 마지막 수단이다.
• 문자열은 표로 빼고 자리 표시자로: "님이" "개를 얻었다"를 코드에서 이어 붙이면 어순이 다른 언어로 옮길 수 없다. 문장 하나를 통째로 번역 표에 두고 이름·개수는 자리 표시자로 넣는다. 한국어의 조사(이/가, 을/를)처럼 앞 낱말에 따라 바뀌는 부분도 처리 규칙이 필요하다.
• 글꼴의 글자 범위: 한글 11,172자를 모두 담지 않은 글꼴이면 플레이어 이름에서 글자가 네모로 깨진다. 날짜·숫자 형식은 문자와 시간 노트에 있다.
• 가짜 번역으로 미리 시험: 개발 중에 모든 문자열을 일부러 길게 늘리고 악센트 글자로 바꾼 가짜 언어(의사 현지화)를 넣어 보면, 번역이 오기 전에 넘치는 곳과 박혀 있는 문자열을 찾을 수 있다.

UI 성능: 그리는 묶음과 다시 계산하는 범위

UI도 그래픽이다. GPU는 같은 텍스처와 재질을 쓰는 것들을 한 번의 명령(드로 콜)으로 묶어 그릴 때 빠르고, 텍스처가 바뀔 때마다 묶음이 끊긴다. 인벤토리처럼 칸과 아이콘이 번갈아 나오는 화면에서 아이콘마다 파일이 따로면, 그리는 순서대로 텍스처가 바뀌어 묶음이 잘게 쪼개진다. 아이콘들을 한 장의 큰 텍스처(아틀라스)에 모으면 같은 텍스처의 다른 영역을 쓰므로 하나로 묶인다.

CPU 쪽 비용도 있다. Unity의 UI 최적화 글은 캔버스 위 요소 하나가 바뀌면 캔버스 전체가 더러워져(dirty) 다시 분석된다고 설명한다. 그래서 다음을 권한다.

• 자주 바뀌는 것과 안 바뀌는 것을 나눈다: 정적인 요소는 한 캔버스에, 함께 갱신되는 동적 요소는 작은 하위 캔버스에 둔다. 매 프레임 바뀌는 타이머 숫자 하나 때문에 인벤토리 전체를 다시 계산하지 않게 한다.
• 숨길 때는 캔버스 컴포넌트를 끈다: 캔버스 컴포넌트를 끄면 그리기는 멈추지만 정점 버퍼는 남아, 다시 켤 때 다시 만들지 않는다.
• 누를 일 없는 요소는 광선 검사에서 뺀다: 정적이거나 상호작용하지 않는 요소의 Raycast Target을 끄면 매 프레임 하는 교차 검사가 줄어든다.
• 레이아웃 그룹을 아낀다: 자동 배치 그룹은 자식이 바뀔 때마다 비용을 더하고, 겹쳐 둘수록 커진다.
• 겹쳐 그리기를 줄인다: 카드 게임의 쌓인 카드처럼 UI를 여러 겹 겹치면 같은 픽셀을 여러 번 칠한다(오버드로).

엔진이 달라도 원리는 같다. 그리는 묶음을 줄이고, 바뀐 것만 다시 계산한다. 프레임 시간을 어떻게 재고 읽는지는 게임 성능 노트, GPU가 장면을 그리는 과정은 컴퓨터 그래픽스 노트에 있다.

흔한 오해

• 디제틱 UI가 언제나 더 몰입감 있고 좋다: 세계 안의 정보는 카메라 각도와 조명에 가려지기 쉽다. 빨리 읽어야 하는 정보는 화면 위가 낫고, 대부분의 게임은 섞어 쓴다.
• HUD는 적을수록 좋다: 전략·MMO처럼 숫자로 판단하는 장르에서는 정보가 곧 조작이다. 줄일 것은 양이 아니라 지금 필요 없는 정보다.
• 마우스로 되는 메뉴면 패드로도 된다: 포커스가 어디에 있는지, 방향키로 어디로 가는지, 뒤로 가기가 어디로 돌아가는지를 따로 설계해야 한다. 포커스가 안 보이면 메뉴를 쓸 수 없다.
• PC에서 읽히는 글자는 TV에서도 읽힌다: 같은 18px도 55인치 TV를 2.5m에서 보면 눈에 15.7분으로, 책상 모니터(28.5분)보다 훨씬 작다. 콘솔 최소 기준이 PC보다 큰 이유다.
• 해상도만 맞추면 종횡비는 저절로 된다: 16:9 좌표로 박아 둔 HUD는 21:9에서 가운데에 몰리거나 16:10에서 잘린다. 모서리 기준으로 붙이고 세이프 영역 안에서 늘린다.
• 번역은 나중에 문자열만 바꾸면 된다: 짧은 영어 문구는 다른 언어로 두세 배 길어질 수 있다. 버튼 폭, 줄 수, 글꼴의 글자 범위, 어순을 처음부터 열어 둬야 한다.

게임 UI가 플레이어의 배움·동기·접근성과 어떻게 이어지는지는 게임 UX: 온보딩·피드백·접근성에, 사람의 지각과 주의의 한계는 HCI와 UX 노트에 있다. 패드의 데드존과 입력 지연은 컨트롤러 노트에서 다룬다.

핵심 자료