게임 시각적 계층 구조

게임 화면 시각적 계층 구조

핵심 사상

플레이어는 매 순간 화면에 할애할 수 있는 주의력이 한정되어 있습니다. 어떤 '눈에 띔'——더 밝음, 더 어두움, 더 화려함, 더 조밀함, 더 큼, 움직임——은 모두 동일한 예산에서 지출됩니다. 계층 구조란 이 예산을 분배하는 것입니다: 게임플레이에서 더 중요하고 즉각적인 반응이 필요한 정보일수록 더 많은, 독점적인 가시성 수단을 할당받고, 나머지 요소는 자발적으로 양보합니다.

핵심 동작은 상위 계층을 높이는 것이 아니라 하위 계층을 제한하는 것입니다. 중요한 것만 밝게 만들면 다른 모든 에셋도 함께 밝아져 결국 모든 것이 경쟁하게 됩니다. 효과적인 방법은 최하위 캔버스에 좁은 범위를 설정하고, 상위 계층이 사용할 방향에 여백을 남겨두는 것입니다.

이 방법은 Riot의 2014년 블로그 게시물 'Defining the Rift's Visual Style'에서 추출되었습니다. 원문의 주장, 본 스킬의 추론, 그리고 실제 측정 데이터는 references/rift-case-study.md를 참조하세요. 다른 출처는 references/sources.md를 참조하세요.

0. 먼저 프로젝트 자체의 규범 찾기

프로젝트에서 다음 항목을 먼저 찾으세요:

• 아트 방향 및 색상 규범, 팔레트 파일, QA 스크린샷 기록, 리뷰 페이지에 이미 명시된 문제;
• 장치 및 내보내기 도구의 제한 사항(예: LED 디스플레이의 프레임 속도 상한, 밝기 구동 방식);
• 의사 결정 기록: 무엇을 했고 무엇을 거부했는지.

찾았다면 그 용어와 색상 공간을 그대로 사용하고, 해당 숫자를 승인 기준으로 삼으세요. 코드 주석의 가정과 검증된 사실은 분리하여 설명하세요. 규범과 여기서 설명하는 원칙이 충돌할 경우 이를 지적하고, 함부로 다시 작성하지 마세요.

1. 플레이어가 내려야 할 판단부터 시작

먼저 질문하세요: 이 순간 플레이어가 무엇을 읽어야 합니까? 나는 어디에 있는가; 어디로 갈 수 있는가; 누가 적이고 아군인가; 무엇이 곧 나를 타격할 것인가; 지금 무엇을 할 수 있는가; 방금 무슨 일이 일어났는가. 읽힌 정보는 진실해야 합니다: 걸어갈 수 있어 보이고, 피해를 줄 수 있어 보이고, 범위가 있어 보이는 것은 게임플레이 상 실제로 그래야 합니다.

• 우선순위는 두 가지를 기준으로 합니다. 긴급성: 놓쳤을 때의 비용이 얼마나 크고 얼마나 빠르게 반응해야 하는가; 플레이어가 이를 기반으로 회피, 차단, 위치 변경을 할 수 있을 때만 비용이 크며, 대응할 수 없는 효과는 경고처럼 보이게 만들지 마세요. 지속성: 상시적인가 일시적인가. 가장 우선순위가 높은 것은 일반적으로 '일시적이고 치명적인' 신호입니다.
• 주시점: 플레이어가 현재 보고 있는 곳(캐릭터, 조준점, 커서)을 표시하세요. 주시점 근처의 신호는 색상과 모양으로 처리할 수 있습니다. 주시점에서 먼 긴급 신호는 움직임, 면적 또는 화면 가장자리의 전반적인 변화에 의존해야 합니다.
• 단계: 탐색과 전투, 탐색/목표 선택/결산 등 각 단계마다 우선순위를 다시 정하세요. 특정 단계에 진입할 때 관련 없는 레이어는 적극적으로 낮추세요.
• 기능별로 레이어를 나누고, 에셋별로 나누지 마세요: 절벽 가장자리, 획득 가능한 아이템은 게임플레이 정보이므로 환경 레이어의 상단 가장자리에 배치합니다. 장식용 입자는 기술적으로 '이펙트'라도 환경 레이어에 속합니다.
• 그리기 순서는 가시성 우선순위와 같지 않습니다: 타워 디펜스의 탄환은 적 위에 그려지지만, 개수가 많고 개별 정보량이 적으므로 작고 짧아야 합니다.

각 유형의 레이어 시작점은 references/layer-stacks.md를 참조하세요.

2. 눈에 띄는 채널

채널	특징
명암 대비	가장 강력하고 빠르며, 그레이스케일에서도 유효, 계층 설정의 첫 번째 선택.
채도	두 번째로 강함. 작은 영역의 고채도 색상 블록도 눈에 띕니다.
색상과 난색/한색	화면의 주 색상군과 차이가 있을 때 매우 강력함 (예: 용암 장면의 차가운 색상); 동일 색상군 내에서는, 빨강 대 초록은 신뢰할 수 없음. 의미 전달에도 사용됨.
디테일 밀도	고주파 텍스처는 노이즈와 같아 주의력을 분산시킵니다.
형태, 면적, 실루엣	형태 언어는 신호의 종류를 구분합니다; 실루엣은 멀리서도 인식 가능한지 결정합니다.
움직임과 나타나는 방식	주변 시야에 매우 효과적이며, 갑작스러운 출현이 점진적인 것보다 낫습니다. 최우선 신호가 움직임에 의존할 때, 다른 순환 애니메이션은 중지하거나 낮춰야 합니다.
위치와 프레이밍	화면 가장자리, 바닥판, 외곽선, 바닥 원. 상주 UI는 주로 이에 의존합니다.
전체 화면 색조와 총 밝기	멀리서, 한눈에 가장 먼저 읽히며, 전체 상태를 표현하는 데 적합합니다.

명도의 기준: 그레이스케일에서 구분되는지 여부는 지각 명도(L*)를 기준으로 합니다. HSB의 V는 '밝음'과 '화려함'을 혼동합니다: 순수한 파랑의 V는 100이지만 L*는 32에 불과합니다. 숫자가 있는 명도는 어떤 종류인지 명시해야 합니다.

3. 할당 규칙

1. 캔버스를 가장 좁게 하고 상위 계층이 사용할 방향에 여백을 남깁니다. 기본적으로 양쪽 끝에 여백을 둡니다. 어두운 게임과 LED의 캔버스는 어두운 쪽에 밀착할 수 있으며, 이 경우 상위 계층은 밝고 화려한 방향으로만 확장할 수 있으며, 외곽선, 실루엣, 움직임으로 보완해야 합니다.
2. 상위 계층은 하위 계층을 포함하고 그 위로 확장됩니다. 상위 계층은 캔버스의 중간 톤을 사용할 수 있으며, 확장된 부분(더 밝은 하이라이트, 더 깊은 실루엣, 더 화려한 포인트)을 통해 보입니다. 계층 내에서도 1차와 2차를 구분합니다: 경계를 넘는 부분은 게임플레이 정보를 전달하는 작은 부위(방향, 무기, 약점, 준비 동작의 신체)에 사용하고, 나머지는 디테일이 낮은 휴식 영역으로 만듭니다.
3. 가장 강력한 채널은 섹션 1에서 최우선 순위로 지정된 신호에 할당하여 전용 슬롯으로 만듭니다. 전용 슬롯은 다른 모든 계층에서 빼내어 해당 신호의 소유자에게만 귀속됩니다. 하나의 슬롯은 하나의 의미에만 해당해야 플레이어가 학습할 수 있습니다; 다른 것이 침범하면 오경보가 됩니다. 반드시 '가장 밝음'일 필요는 없으며, 특정 색상, 형태, 움직임 또는 단계별 할당일 수 있습니다.
4. 눈에 띄는 정도 × 면적 × 지속 시간 × 개수 = 하나의 예산. 예산은 주 신호와 경쟁하는 요소들을 제한합니다; 주 신호 자체는 먼저 시청 거리에서 볼 수 있도록 보장되어야 합니다.
   • 짧아야 하는 것은 명중 섬광과 결과 피드백입니다. 경고는 반대입니다: 판정보다 먼저 나타나고 반응 시간을 충분히 확보하며, 접근에 따라 점진적으로 강화됩니다.
   • 개수는 화면을 압도합니다: 같은 화면에 수백 개의 탄환 또는 떠다니는 텍스트가 있으면 개수별로 제한해야 합니다. 넓은 범위 표시는 채움을 낮추고 가장자리만 눈에 띄게 하며, 겹칠 때는 합집합을 취합니다.
   • 상주 UI는 먼저 게임플레이(캐릭터 주변, 전진 방향, 다음에 조작할 위치)를 가리지 않아야 하며, 그 다음으로 좁고, 작고, 가장자리에 위치해야 합니다. 체력바, 데미지 숫자와 같은 월드 공간 UI는 해당 레이블이 지정된 레이어의 예산에 포함됩니다.
   • 섬광 안전은 계층보다 우선합니다: '짧음'이 광과민성 위험을 낮추지 않습니다. 넓은 영역의 깜빡임은 초당 3회를 초과하지 않아야 하며, 포화된 빨간색의 깜빡임은 피해야 합니다.
5. 비교는 국소적으로 합니다. 요소와 실제로 접촉하는, 가장 불리한 배경을 기준으로 비교합니다. 밝고 어두운 배경을 모두 지나는 요소는 한 쌍의(어둡고 밝은) 이중 외곽선을 사용합니다.
6. 문제 수정 순서: 먼저 낮추고, 그 다음 채널을 바꾸고, 마지막으로 높입니다. 먼저 경계를 넘은 하위 계층을 되돌립니다; 그런 다음 신호에 하위 계층이 점유하지 않은 다른 채널(색상, 형태, 나타나는 방식, 위치)을 고려합니다; 마지막으로 상위 계층을 강화합니다. 하위 계층을 압축한 후 재측정합니다: 원래 '배경보다 어두움'으로 구분되던 요소가 오히려 붙어버릴 수 있습니다.
7. 업그레이드 인플레이션을 경계하십시오. 만렙, 높은 희귀도는 실루엣, 부품, 애니메이션으로 표현하고 원래 범위 내에 유지합니다.

4. 환경: 물러서고 길을 안내하라

• 물러서기는 부드럽게 하는 것이 아니라 단순화하는 데 의존합니다: 미세한 고대비 텍스처 대신 큰 덩어리의 형태와 명암을 사용합니다. 전체를 흐리게 하면 지표는 낮출 수 있지만 재질을 알아보지 못하게 됩니다. 일반적인 변경 사항은 채도 낮추기, 지면 텍스처 대비 낮추기, 환경 광원 줄이기이며, 종종 캐릭터를 먼저 건드릴 필요가 없습니다.
• 길 안내: 이동 가능한 곳은 더 평탄하고 조용하며, 경계와 안정적인 명도 차이를 유지합니다; 경계는 더 어둡고 조밀합니다. 이는 조용한 힌트일 뿐 화살표가 아닙니다.
• 환경 내부에서도 계층이 있습니다: 게임플레이와 관련된 지형은 범위의 상단 가장자리에, 순수 장식은 중간에 배치합니다. 환경 광원은 전용 슬롯과 위치를 경쟁하므로 축소, 압축하거나 게임플레이 의미를 부여해야 합니다.

5. 통일성과 기술적 흔적

• 모든 에셋은 동일한 비전으로 돌아가며, 규모는 캐릭터에 적합해야 합니다. 캐릭터 스타일 범위가 넓을수록 환경은 더 중립적이어야 합니다; 새 에산을 평가할 때 범위 양 끝의 캐릭터 옆에 배치하여 확인하세요.
• 스타일 식별력은 의도적인 형태 대비(부드러움 대 날카로움)에서 비롯될 수 있으며, 현실 참조와 환상 요소의 비율을 제어합니다.
• 딱딱한 폴리곤 가장자리, 이음새, 타일 반복, 깜빡임, 과도하게 사실적인 거친 텍스처는 주의를 끌지만 정보를 전달하지 않으므로 숨기거나 의도적인 스타일로 변경해야 합니다. 그리드, 픽셀 블록, 외곽선과 같이 의도적으로 유지된 구조는 예외입니다.

6. 프로젝트별 조정

• 어두운 / 공포: '밝음'은 희소 채널입니다. 여러 신호가 어둠 속의 밝은 점이 되므로 형태, 높이, 움직임으로 구분해야 합니다; 중요한 정보를 가장 어두운 단독 슬롯에만 두지 마세요.
• 밝은 만화 스타일: 양쪽 끝이 스타일에 의해 점유된 경우, 캔버스를 중간 구간으로 되돌리거나 캐릭터 분리를 위해 어두운 외곽선을 사용합니다.
• 3D / 사실적 / 동적 조명: 최종 명도는 재질, 조명 및 카메라에 의해 공동 결정됩니다. 먼저 조명을 추정한 다음 범위를 설정하고, 후처리 이후의 화면에서 측정합니다. references/3d-lighting.md를 참조하세요.
• 픽셀 아트, 제한된 팔레트, LED 도트 매트릭스, 소형 화면: references/limited-palette.md를 참조하세요.
• 색각 차이: 계층은 주로 명암에 의존하며, 의미 색상은 형태 및 아이콘과 함께 사용합니다. 색상 전용 슬롯을 사용하는 경우 적색 및 녹색맹 시뮬레이션 이미지를 확인하세요.

7. 검사 방법

먼저 추론하고, 그 다음 측정합니다. 먼저 위의 규칙과 해당 유형의 상식을 사용하여 판단을 내리세요: 조명이 어떻게 감쇠하는지, 장치에 어떤 제한이 있는지, 플레이어가 언제 판단을 내리는지. 측정은 구체적인 질문에 답하는 데만 사용하며, 퍼즐 맞추기와 숫자 세기가 추론을 대체하지 않도록 하세요.

• 먼저 증거 확인: 스크린샷이 현재 버전보다 앞선 것인지, 디버그 오버레이가 있는지, 촬영 시 조명 및 후처리가 활성화되었는지 확인합니다. 방법은 references/evidence-and-measurement.md를 참조하세요.

• 최악의 경우 선택: 가장 혼잡한 순간, 플레이어가 중요한 판단을 내리는 순간을 선택합니다. 순간 신호는 완전히 밝아진 피크 프레임이 아닌 시작 프레임을 봅니다. 상태 변화는 동일한 카메라 위치의 두 프레임을 비교합니다.

• 세 가지 빠른 테스트: 그레이스케일에서 계층이 유지되는가; 흐리게 했을 때 눈이 가장 먼저 어디에 떨어지는가; 특정 레이어를 단색으로 칠했을 때 자세와 방향을 여전히 인식할 수 있는가.

• 핵심 신호를 채널별로 확인: 최우선 순위 신호와 실제로 인접한 경쟁자를 섹션 2의 채널별로 하나씩 비교합니다.

• 측정: 본 스킬 디렉토리의 scripts/sv_profile.py는 레이어별 면적, 채도 및 명도 범위, 지각 명도, 디테일 밀도, 전용 슬롯 소속 및 국소 대비를 보고합니다. 프로젝트의 색상 공간, 두 프레임 비교 및 멀티 프레임 GIF를 지원합니다. scripts/palette_check.py는 그림을 그리기 전에 계층형 팔레트를 확인합니다. 매개변수는 -h를 참조하고, 판독 방법은 위의 참조 파일을 참조하세요. 출력은 임시 디렉토리에 기록하고 프로젝트에 쓰지 마세요.

  python <스킬 디렉토리>/scripts/sv_profile.py shot.png -o <임시 디렉토리> -r "!environment:0,0,1,1" -r "player:0.42,0.40,0.50,0.55" -r "hud:0,0.88,1,1"
  

• 예시 프레임은 대조 실험으로만 사용: 스크린샷이 없을 때는 색상 블록으로 프레임을 구성할 수 있지만, 한 번에 하나의 변수만 변경하고 조명은 대략 실제와 일치해야 합니다. 직접 구성한 이미지에서 측정한 숫자는 '현재 상태'로 간주될 수 없으며, 자신의 솔루션이 규정을 준수함을 증명하는 데 사용할 수도 없습니다.

• 숫자는 증거일 뿐: 결론은 궁극적으로 '플레이어가 읽어야 할 것을 읽을 수 있는가'로 돌아갑니다. 승인이 필요한 경우 플레이어 재테스트 지표를 작성하세요.

8. 출력

검토는 기본적으로 읽기 전용입니다: 에셋, 코드 및 프로젝트 문서를 수정하지 않고 변경 사항을 제안으로만 작성합니다. 사용자가 묻는 질문에 먼저 직접 답변하고, 동일한 판단은 한 번만 말합니다.

• 스크린샷 검토: 먼저 한 줄 결론을 제공합니다. 발견 사항을 게임플레이 영향 순으로 정렬합니다: 먼저 '내 위치, 적 위치, 나를 타격할 것' 및 UI 가림, 그 다음 환경과 캐릭터의 주의력 경쟁, 마지막으로 스타일 및 기술적 흔적. 각 항목에 위치, 현상, 위반된 원칙, 최소 변경 사항을 작성합니다.

• 전후 비교: '플레이어가 읽어야 할 것'이 좋아졌는지 나빠졌는지 항목별로 답변합니다; 이 스크린샷 세트에 대한 판단과 현재 버전에 대해 무엇을 해야 하는지 분리하여 작성합니다.

• 텍스트 설명만 있는 진단: 가장 가능성 있는 원인과 조사 순서를 제공하고, 사용자가 직접 실행할 수 있는 검사와 엔진 내 구체적인 방법을 알려주며, 화면 이외의 가능한 원인(지속 시간, 판정 범위, 카메라, 사운드 효과)을 나열합니다.

• 규범 작성: 먼저 섹션 1의 우선순위를 완료한 다음, 각 레이어의 범위, 전용 슬롯 소속, 면적/지속 시간/개수 제약 조건을 작성하고, 규정 준수 및 위반 사례의 대조를 첨부합니다. 규범은 직접 실행할 수 있어야 합니다:

  • 사용자가 지명한 모든 요소 유형을 다룹니다;
  • 숫자는 실행자의 단위(그리드, 픽셀, 초, 엔진 필드)로 시작 값을 제공하고 '실측 필요'라고 표시하며, 스크린샷이 없어도 숫자를 제공하지 않는 일이 없도록 합니다;
  • 렌더링 순서 및 스케줄링 규칙을 작성합니다: 누가 누구를 압도하는지, 겹침 상한, 언제 지우는지;
  • 마지막으로 몇 가지 레드라인과 구현 순서를 나열합니다.

  이미 아트가 있지만 스크린샷이 없는 경우, 동시에 사용자에게 스크린샷을 제공하여 보정하도록 요청합니다.

공통 규칙:

• 증거가 부족하면 결론을 축소하고, 마지막에만 언급하지 마십시오; 스크린샷에 없는 것에 대해 숫자를 추정하지 마십시오.
• 용도를 설명할 수 없는 요소는 먼저 프로젝트에서 확인하십시오; 찾을 수 없으면 두 가지 가능성에 대해 각각 결론을 내리고 사용자에게 질문하십시오.
• 원인이 여러 가지 가능성이 있는 경우, 먼저 빠르게 검증할 수 있는 진단을 제공한 다음, 경우에 따라 수정 방법을 제공하십시오.
• 수정 방법을 제공하기 전에 프로젝트에서 이미 수행한 것과 거부한 것을 확인하십시오. 비교 기준은 프로젝트 규범 또는 프로젝트 자체의 규정 준수 프레임만 사용하고, 참조 사례의 숫자를 표준으로 사용하지 마십시오.
• 프로젝트의 기존 아트 스타일을 함부로 변경하지 말고, 제안에 이점과 비용을 명시하십시오.