게임 UI 화면
모든 화면이 동일한 게임의 일부처럼 느껴지도록 만듭니다. 일반적인 웹 스타일링 대신 게임 자체의 가장 완성된 화면을 기준으로 작업하고, 네비게이션을 게임처럼 유지하며, 플레이어가 사용하는 모든 크기에서 각 화면을 확인합니다. UI 기술(DOM 오버 캔버스, 엔진 UI, 또는 인-씬 UI)에 적응합니다. 가능하다면 화면 흐름 자체에는 game-foundation을 사용하세요; 이 스킬은 화면의 모양과 동작 방식을 다룹니다.
1. 인벤토리
모든 화면과 오버레이를 나열합니다. 잊기 쉬운 것들도 포함합니다: 타이틀, 메인 메뉴, 각 모드 메뉴, 차고 또는 로드아웃, 설정, 로비 또는 방 화면, 참여 및 초대 흐름, 로딩, 일시 중지, 결과, 에러, 빈 상태, HUD, 그리고 개발자 전용 화면. 각각에 대해 파일, 접근 방법, 종료 방법, 표시에 서버 또는 저장된 데이터가 필요한지 여부를 기록합니다. 게임 서버가 필요한 화면은 서버와 함께 실행하거나, 검증되지 않은 상태로 보고해야 합니다.
2. 스타일 계약 추출
앵커를 선택합니다: 이미 게임처럼 보이는 화면(보통 타이틀이나 메인 메뉴)을 선택합니다. 다른 화면을 건드리기 전에 그 규칙을 기록합니다: 타입페이스와 타이틀 처리, 색상 토큰, 배경(라이브 3D 씬, 흐린 배경, 아트), 패널 모양, 버튼 상태(기본, 호버, 포커스, 눌림, 비활성화), 간격 척도, 모션, 사운드 큐. 공유되는 부분을 토큰이나 공유 클래스로 만들어 화면이 서로 어긋나지 않도록 합니다. 템플릿과 게임 내 규칙은 style-contract.md를 참조하세요.
3. 적용
- 전체 화면 게임 레이아웃, 웹 카드가 아님. 데스크탑에서 문서 스크롤이 없어야 합니다; 모달은 뷰포트에 맞춥니다; 긴 목록은 자체 패널 내에서 스크롤됩니다.
- 게임 네비게이션. Esc 또는 뒤로 가기 컨트롤이 모든 화면을 종료합니다; 키보드와 게임패드 포커스가 예측 가능하게 이동하고 표시 가능한 포커스 상태가 있어야 합니다; 기본 동작이 명확해야 합니다.
- 온보딩 게이트를 흐름으로. 일부 모드 전에 이름이나 프로필이 필요한 경우, 잠긴 버튼으로 가득 찬 메뉴를 보여주는 대신 짧은 시작 단계(이름 필드 + 플레이)에서 요청합니다. 설정에서도 동일한 검증을 유지하여 나중에 수정해도 깨지지 않도록 합니다.
- 하나로 충분한 경우 하나의 항목. 플레이어에게 같은 곳으로 이어지는 옵션(예: 하나의 맵에 세 개의 스폰 지점) 중에서 선택하도록 요청하지 마십시오; 하나의 기본 동작을 제공하고 변형은 게임 내에서 제공합니다.
- HUD 계층 구조. hud-and-loading.md를 참조하세요. 모든 숫자에 레이블이 지정되고, 디버그 출력처럼 읽히는 것이 없으며, 상황에 맞는 요소만 관련될 때 표시됩니다.
- 로딩 화면은 게임과 일치하는 모션, 가능한 경우 실제 진행 상황, 짧은 로드 시 깜빡임이 없어야 합니다.
- 간격은 뷰포트 높이에 따라 조정됩니다(
clamp()또는 뷰포트 단위 사용) 키가 큰 메뉴가 좁은 화면에서 뭉치거나 넓은 화면에서 퍼지지 않도록 합니다.
4. 플레이어용 이름 변경
게임, 모드, 장소 또는 아이템 이름을 변경할 때: UI 문자열, HTML 제목, 매니페스트, 문서, 패키지 이름, 스토리지 키에서 모든 철자 변형(대소문자, 공백, 하이픈, 오타)을 검색합니다. 스토리지 키가 변경되면 저장된 데이터를 마이그레이션하여 기존 플레이어가 프로필을 유지하도록 합니다. 작업에 변경이 필요한 경우가 아니라면 내부 ID는 안정적으로 유지합니다.
5. 검증
1440×900, 1280×720, 1024×600, 휴대폰 크기(375×812) 및 프로젝트 자체 목표에서 터치한 모든 화면을 확인합니다. 스크린샷을 사용하고, playtest의 __pt.layout()(또는 이에 상응하는 바운딩 박스 검사)을 사용하여 페이지 스크롤, 화면 밖 컨트롤, 겹침을 확인합니다. 각 화면의 진입 및 종료를 살펴봅니다. 열 수 없었던 화면과 그 이유를 보고합니다.