유저 인터페이스 시스템 개요

UI System 과 그 함수성은 더이상 지원되지 않습니다. 현재 지원되는 유저 인터페이스 시스템에 대한 정보는 스케일폼 GFx 문서를 참고하시기 바랍니다.

개요

본 문서는 UI 시스템의 주요 기능에 대해 설명합니다. UI 시스템의 디자인은 UI 시스템 자체와 UI 에디터의 2가지 부분으로 나누어져 있습니다.

UI 시스템

UI는 아티스트가 UI 컨트롤의 레이아웃을 만들고, 이러한 컨트롤을 게임 데이터에 바인딩하고, 데이터에서 다양한 작업을 수행하기 위해 Kismet을 통해 스크립트화된 이벤트와 액션을 만드는 아티스트 중심의 시스템입니다. UI 시스템은 데이터 소스, 프리젠테이션, 상호 작용의 3가지 주요 구성 요소로 구성되어 있습니다. 데이터 소스 구성 요소는 UI가 게임 데이터와 어떻게 상호 작용하는지를 나타내고, 프레젠테이션 구성 요소는 UI가 사용자에게 어떻게 데이터를 표시할지를 나타내고, 상호 작용 구성 요소는 UI 시스템이 어떻게 이벤트(사용자에 의해 생성되는 이벤트뿐만 아니라 시스템에 의해 생성되는 이벤트 모두)를 처리하는지를 나타냅니다. 이러한 3가지 구성 요소는 아래에서 좀 더 자세히 설명됩니다.

데이터 저장소

데이터 저장소는 UI가 게임에서 데이터를 가져오고 게임에 데이터 변경 사항을 게시하는 방법을 나타냅니다. 데이터 저장소는 지속적일 수 있으며, 이 경우 UI 컨트롤러 객체에 등록 및 삽입되어 모든 위젯에서 사용할 수 있습니다. 또한 데이터 저장소는 임시적일 수도 있으며, 이 경우 현 장면에 삽입되어 그 장면에 포함된 위젯만이 액세스할 수 있습니다. 비록 데이터 저장소에서 데이터를 바인딩하고 가져오기 위한 인터페이스는 데이터 저장소가 제공하는 데이터의 유형에 관계없이 동일하지만, 데이터 저장소는 모든 유형의 데이터를 UI에 제공할 수 있습니다.

지속적 데이터 저장소는 게임유형, 캐릭터 리소스, 상태 데이터 등의 정보를 추적할 수 있는 반면에, 장면별 데이터 저장소는 장면의 일부 위젯에 입력된 값 또는 접속 대기의 상태에 관한 정보등과 같은 정보를 추적할 수 있습니다. 데이터 저장소는 모든 게임유형의 이름 또는 캐릭터 리소스 데이터와 같은 정적 정보를 제공할뿐만 아니라 현 게임유형의 이름과 같은 동적 정보도 제공할 수 있습니다.

UI에 의해 사용되는 몇 가지 특별한 유형의 데이터 저장소가 있습니다. 현재 활성 상태인 UISkin은 현 장면에서 사용 가능한 스타일의 목록을 포함하고 'Styles' 태그를 사용하는 위젯에 의해 참조될 수 있습니다. 'Attributes' 데이터 저장소는 UIString의 텍스트 스타일(굵게, 기울임꼴 등과 같은)을 수정하는 가상 저장소입니다.

데이터 저장소 기능

• 위젯에 데이터를 제공하고, 위젯의 데이터 변경 사항을 받아들이고, 적용 가능한 경우 해당 데이터를 적절한 위치로 전달합니다.
• 클래스 기반 디자인을 통해 임의의 데이터 유형을 액세스할 수 있습니다.
• 예를 들어, 변경 사항이 발생하자마자 그것을 게임 상태 값에 전달하는 것처럼 근본적인 데이터 소스와 실시간 상호 작용할 수 있습니다.
• 변경 사항을 데이터에 게시할 때 지연, 버퍼된 또는 일괄된 트랜잭션이 가능하다.

데이터 저장소 카테고리

데이터 저장소에는 4개의 주요 카테고리가 있습니다.

1. Game State(게임 상태) - 플레이어, 목표, 남은 시간, 현재 점수 등과 같은 현 게임 상태에 대한 모든 데이터를 추적합니다. 게임 데이터 저장소는 GameState 데이터 저장소가 다른 게임 상태 데이터 저장소에 대한 참조를 포함하는 곳에 내재될 수 있습니다. 예를 들어 이것은 특정 플레이어와 연관된 무기 데이터 저장소를 분리시키는데 유용합니다. 게임 데이터 저장소는 다음 2가지 구성 요소로 추가 분할됩니다.
   • 게임 상태 데이터 제공자: 플레이어, 무기, 주운 아이템(pickup), 또는 게임의 목표와 같은 데이터 소스의 특정 인스턴스에 대한 상태와 정적 데이터를 제공합니다. 데이터 제공자는 일반적으로 UI에 의해 직접 참조되지 않습니다. 그 대신 소유하고 있는 플레이어 또는 현 게임 정보 인스턴스와 관련된 게임 상태 데이터 저장소와 같은 게임 상태 데이터 저장소를 통해 일반적으로 액세스됩니다.
   • 게임 상태 데이터 저장소: 게임과 UI 사이의 첫 번째 레이어의 역할을 합니다. 각각의 데이터 저장소는 게임 객체의 인스턴스에 데이터를 제공하는 게임 상태 데이터 제공자의 모음을 포함합니다.
2. Game Settings(게임 설정) – 게임 고유 또는 전역에서 구성할 수 있는 설정에 대한 액세스를 UI에 제공합니다. Game Settings 데이터 저장소는 게임유형의 구성 가능한 MaxPlayers, GoalScore 등과 같은 데이터로 또는 사용자의 구성 가능한 버튼의 레이아웃과 같은 사용자 고유 데이터로 표시될 수 있습니다. Game Settings 데이터 저장소는 또한 사용자의 선택을 적절한 지속성 장소에 게시하여 게임이 플레이될 경우 이러한 값이 게임플레이 코드에 의해 사용되도록 합니다.
3. Remote Data(원격 데이터) – 네트워크에 걸쳐 원격 컴퓨터에서 받은 데이터에 대한 액세스를 UI에 제공합니다. 이런 유형 데이터 저장소는 인터넷 게임 세션에 대한 게임 및 플레이어 데이터가 마스터 서버에서 검색되는 서버 브라우저에서 사용될 수 있습니다.
4. Game Resources(게임 리소스) - 게임 모드, 무기 선택, 캐릭터 선택, 맵 등과 같은 게임에서 사용 가능한 리소스에 대한 모든 정보를 추적합니다.

데이터 저장조 참조하기

각 데이터 저장소에는 UI가 해당 데이터 저장소를 인식할 수 있는 특정 태그가 있습니다. 데이터 저장소 태그가 실제 데이터 저장소와 어떻게 연관되는지는 일반적으로 데이터 저장소 유형의 필요 또는 목적에 의해 결정됩니다. 데이터 값을 UI에 게시하기 위해 각 데이터 저장소는 위젯에 바인딩할 수 있는 속성에 해당하는 이름의 목록을 제공합니다.

데이터 저장소와 그 값은 마크업 구문을 사용하여 UI에 의해 참조됩니다. 이것의 구문은 <DataStoreName:PropertyName>입니다. 예를 들어 게임 사용자에게 3개의 컨트롤러 레이아웃의 선택이 제공되었고 현 레이아웃의 이름이 구성 화면의 라벨에 표시되길 원한다고 가정합시다. 이 설정을 제어하는 속성에 라벨을 바인딩하려면 라벨의 값을 <Controls:LayoutType>와 같은 값으로 설정합니다(데이터 저장소가 'Controls' 태그를 사용한 이 값의 추적을 담당하고, 이것이 어떤 게임패드 레이아웃이 사용되는지를 제어하는 'LayoutType'이라는 속성을 노출시킨다고 가정합니다).

데이터 저장소는 위젯과 가비지 수집과 연계될 수 데이터 저장소에 의해 나타내지는 근본적인 데이터간에 절대 참조가될 수 없게 수명 관리를 캡슐화하기 때문에 위젯에 바인딩하는 이 방법은 UI가 게임 데이터를 안전하게 참조할 수 있도록 합니다.

상호 작용

각각의 위젯에는 해당 위젯에서 사용 가능한 이벤트 목록을 제공하는 EventProvider 구성 요소가 포함되어 있습니다. EventComponents는 이벤트 클래스의 배열(실제로 이들은 Kismet 시스템의 SequenceEvent 클래스의 자식이지만 UIEvent라고 합니다)을 포함합니다. EventComponent에 의해 포함된 각 UIEvent 인스턴스는 이벤트가 트리거되었을 때 수행되는 액션의 모음을 가지고 있습니다. 특정 이벤트에 지정된 액션의 목록은 이벤트를 구현하는 각 위젯에 따라 달라질 수 있습니다.

입력 이벤트(간단하게 하기 위해 이것을 UIEvent_ProcessInput이라고 함)를 처리하는 특별한 UIEvent 클래스가 있습니다. 위젯이 입력을 처리할 수 있기 위해 해당 EventComponent가 자신의 이벤트 목록에 UIEvent_ProcessInput을 반드시 포함해야 합니다. 내장 위젯 세트의 경우, 입력을 처리하는 모든 위젯은 이미 이벤트 목록에 입력 프로세서를 가지고 있습니다. 디자이너(prefab을 통해) 제작하는 사용자 정의 위젯의 경우, 해당 위젯이 입력을 처리하길 원하면 위젯에 이벤트 프로세서를 추가할 수 있습니다. UIEvent_ProcessInput 클래스는 임의의 입력 키 이벤트 개수를 처리할 수 있습니다. 처리하는 각 입력 이벤트의 경우, 이것은 해당 입력의 발생하는 1개 이상의 액션을 정의할 수 있습니다. 따라서 주어진 장면에서 입력 프로세서를 포함한 위젯만이 입력을 처리할 수 있습니다.

위젯이 어떤 입력 이벤트를 처리할지 위젯의 이벤트 프로세서를 조회하면 알 수 있기 때문에 어떤 주어진 시간에 어떤 위젯이 어떤 입력 키 이벤트에 대응할 수 있는지 알 수 있으므로 그 장면의 다른 모든 위젯을 무시 수 있습니다. 입력을 처리할 수 있는 일련의 위젯의 변경시키는 이벤트가 발생할 때마다 장면의 폴링 가능한 위젯의 목록이 업데이트됩니다. 이것은 입력 키 이름을 위젯의 배열에 매핑하는 구조체인 InputEventSubscription을 사용하여 캡슐화됩니다. InputEventSubscription에 포함된 위젯은 현재 입력을 처리할 수 있는 위젯이고, 해당 입력 키에 대응하는 이벤트의 EventComponent 목록에 UIEvent_ProcessInput 이벤트를 포함하고 있습니다. 일반적으로 위젯은 포커스 체인의 일부일 경우에만 입력을 처리할 수 있지만 포커스 되지 않은 입력을 인식하도록 설정되어 있는 위젯 또한 처리할 수 있는 것으로 간주됩니다. 각 장면은 입력 키 이름에서 InputEventSubscriptions로의 매핑을 갖고 있습니다. 입력 이벤트가 수신되면 장면은 키 이름에 해당하는 InputEventSubscription 구조체를 검색합니다. 이것이 장면이 해당 입력 이벤트를 잠재적으로 처리할 수 있는 모든 위젯을 즉시 액세스할 수 있게 합니다. 배열에서 처리 가능한 위젯이 발생할 수 있는 순서는 위젯에 입력을 처리할 수 있는 기회가 주어진 순서입니다. 따라서 현재 포커스된 컨트롤은 배열의 첫 번째 위젯일 수 있고, 그 다음이 그 위젯의 부모, 그 다음에는 해당 입력을 처리할 수 있는 그 부모의 자식이 있게 됩니다.

장면의 InputSubscribers는 정적 데이터 구조체가 아닙니다. 장면의 지속시간(lifetime) 동안 위젯은 계속해서 장면의 처리 가능한 위젯 목록에 자신을 추가 및 삭제합니다. 위젯이 포커스를 잃을 때, 장면의 처리 가능한 위젯 목록에서 자신을 제거합니다. 위젯이 포커스를 얻게 되면 위젯은 자신을 장면의 InputSubscribers 목록에 추가합니다. 또한 위젯의 상태 또는 일부 내부 논리의 변경(예: 편집박스는 텍스트박스에 입력되는 첫 문자는 숫자이어야 하지만 그 이후는 아무 문자나 괜찮음)에 위젯은 처리하는 이벤트 목록에 새 입력 키를 추가 또는 삭제할 수 있습니다. 이것이 발생하면 해당 위젯은 장면에 통지하고, 해당 장면도 그에 따라 InputSubscribers를 조정합니다. 여기서의 핵심은 장면의 InputSubscribers는 일부 이벤트에 따라서만 변경된다는 것입니다. 폴링이 필요하지는 않습니다. 입력 이벤트가 발생하면 InputSubscribers가 이미 업데이트되었기 때문에, 입력을 어떻게 처리할지를 결정하는데 신뢰할 수 있는 소스로 사용될 수 있습니다.

입력 이벤트가 수신되면 해당 장면은 InputSubscribers 목록에서 적절한 InputEventSubscription을 조회합니다. 이것은 해당 입력 이벤트에 현재 대응할 수 있는 위젯의 목록에 전반에 걸쳐 반복하므로 각 위젯에 이벤트를 처리할 수 있는 기회를 부여합니다. 이러한 위젯은 해당 입력 이벤트에 대응할 수 있는 능력이 있는 것이 보장됩니다(물론 다른 이유로 인해 대응하지 않기로 결정할 수 있지만도). InputEventSubscription의 위젯 중 어떤 위젯도 해당 입력에 대응하고 싶지 않거나 또는 대응했지만 그 입력 이벤트가 계속해서 전달되도록 구성된 것이라면, UI 시스템은 GameViewportClient가 해당 입력 이벤트를 배열의 나머지 상호 작용에 전달하는 것을 허용합니다. (입력 이벤트가 처리되지만 그냥 지나가 버리는 경우, 해당 입력 이벤트를 나타내는 이벤트 객체는 입력이 이미 처리되었다는 것을 나타내기 위해 표시되고, 어떠한 액션이 취해졌는가, 누구에 의해 입력이 처리되었는가의 정보가 아마 포함될 수 있습니다. 이것은 어떤 상호 작업을 수행하기 위해 다른 게임 객체가 위젯과 함께 협력하는 것을 허용하는데 사용됩니다. 이것은 위젯이 대응한 입력 이벤트를 캡쳐하지 않도록 설정되어 있는 경우에만 해당합니다.)

프레젠테이션

프레젠테이션 하위시스템은 UI를 사용자에게 표시하는 것을 담당합니다. 이것은 위젯의 렌더링과 그의 리소스뿐만 아니라 데이터 저장소에 의해 제공된 데이터의 렌더링을 포함합니다.

장면

위젯들의 그룹을 위한 최외각 컨테이너를 UIScene이라고 합니다. 장면은 위젯 모음을 포함하고, 장면과 위젯의 관계는 모든 위젯이 반드시 UIScene에 의해 포함되야 한다는 의미에서 맵과 맵에 배치된 액터와의 관계와 매우 비슷합니다. 위젯은 직접 렌더될 수 없습니다. 항상 위젯의 컨테이너 장면에 의해 렌더되야 합니다. 한 번에 1개 이상의 장면이 활성화될 수 있으며, 일부 장면은 맵 변경에 걸쳐 지속될 수 있습니다. UIScene은 에디터에서 만들어지고 Unreal 패키지 파일에 저장됩니다. UIScene을 여는 방법은 게임 중 다른 Unreal 리소스를 로드하는 것과 정확히 동일합니다. UIScene은 싱글 플레이와 연관될 수 있거나 또는 모든 플레이어에 전역적으로 액세스될 수 있습니다. UIScene은 위젯의 위치 추적 및 업데이트, 입력 이벤트 전송, 위젯의 렌더링을 담당합니다. 장면에서 위젯은 계층적으로(위젯은 다른 위젯을 포함할 수 있음) 조직 구성될 수 있지만, 입력이나 렌더링이 각 위젯에 전달되는 순서가 반드시 장면에 있는 위젯의 조직 구조에 의해 결정되는 것은 아닙니다(대부분의 경우 그래야 하지만도).

위젯

모든 위젯의 기본 클래스는 UIObject라고 합니다(대부분의 경우, 위젯과 UIObject는 상호 교환적으로 사용됩니다).

특징:

• 모든 위젯은 다른 위젯의 컨테이너의 역할을 할 수 있습니다.
• 각 위젯은 고유한 GUID를 갖습니다.
• 각 위젯은 누름, 활성, 포커스됨, 사용 불가됨 등과 같은 제한되지 않은 수의 “상태”를 지정할 수 있습니다.
• 도킹 대상이 같은 장면에 포함되어 있는 경우, 위젯은 다른 위젯에 도킹될 수 있습니다. 위젯은 1개 이상의 위젯에 도킹할 수 있지만, 위젯이 가질 수 있는 도킹 세트의 최대 개수는 그 위젯이 갖고 있는 면의 최대 수와 동일합니다. 2D 위젯은 4개의 도킹 집합만을 가질 수 있습니다(각 면당 1개). 소스 위젯의 2면이 대상 위젯의 동일한 면에 바인딩할 수 없다는 제한(예: 들면, 위젯의 상단과 오른쪽 측면을 모두 대상 위젯의 오른쪽 면에 도킹시킬 수 없음)의 전제하에 단일 위젯은 여러 도킹 집합의 대상이 될 수 있습니다. 서로 수직 관계에 있는 면을 도킹시킬 수 있습니다. 대상 면의 길이가 반으로 나뉘고, 소스 면은 대상 면의 해당 지점에 도킹합니다. 2개의 도킹 집합 사이에 원형 관계를 만들 수 없습니다(WidgetA의 왼쪽 면이 WidgetB의 오른쪽 면에 도킹하고, WidgetB의 오른쪽 면이 WidgetA의 왼쪽 면에 도킹함)을 만들 수 없습니다. 위젯을 자신의 고유 도킹 집합에 포함할 수 없습니다. 그러나 도킹 관계가 원형이 아니라면 WidgetA가 WidgetB에 도킹하고, WidgetB가 WidgetA에 도킹하는 것에는 전혀 문제가 없습니다. 컨테이너와 자식 관계(WidgetA가 컨테이너이고 WidgetB가 WidgetA의 자식임)를 생각해 보십시오. WidgetB의 왼쪽 측면이 WidgetA 왼쪽 측면에 도킹하고, WidgetB의 오른쪽 측면이 WidgetA의 오른쪽 측면에 도킹하는 것을 원할 수 있습니다. 이것은 WidgetA가 WidgetB를 포함하기 위해 확장되거나 수축되고, WidgetB는 WidgetA 왼쪽에 왼쪽 정렬 상태로 유지됩니다. 각 도킹 집합에 여백(패딩) 값을 지정할 수 있습니다.
• 위젯의 위치는 픽셀 또는 백분율로 지정될 수 있습니다. 이 값은 뷰포트 전체, 소유하고 있는 장면, 또는 UIObject의 컨테이너 위젯에 상대적일 수 있습니다.
• 위젯은 모든이벤트(사용자 또는 시스템 모두)에 대응하도록 구성될 수 있습니다. 위젯 클래스의 프로그래머는 특정 클래스가 어떤 이벤트에 대응할 수 있는지를 결정합니다. 디자이너는 그 위젯 클래스의 인스턴스에 어떤 이벤트가 구현되는지를 선택합니다. 또는 위젯의 프로그래머가 위젯이 항상 1개 이상의 이벤트 유형을 구현하도록 만들 수 있습니다.
• 각 위젯은 특정 이벤트에 대응하여 다른 액션을 실행할 수 있습니다.
• 모든 위젯은 잠재적으로 입력을 처리할 수 있습니다. 위젯은 항상 입력을 처리하도록 또는 포커스될 경우에만 처리하도록 구성될 수 있습니다. 위젯은 처리된 및 처리되지 않은 입력을 수용할 수 있는 여부를 선택할 수 있습니다.
• 회전, 스케일, 위치, 색상, 앵커, UV 좌표와 같은 도구의 각 속성에 Matinee를 사용하여 애니메이션 효과를 줄 수 있습니다.
• 계층적 콘텍스 메뉴는 각 위젯에서 지원됩니다.
• 모든 위젯은 적용 가능한 곳에 드래그 앤 드롭을 지원합니다.
• 포함한 위젯이 자동적으로 정렬되고 위치 지정될 수 있도록 구성될 수 있습니다.

(다음은 사용 가능한 모든 내장 위젯 클래스의 참조가 아닙니다. 몇 가지 흥미로운 클래스의 개요일 뿐입니다).

라벨

UI에 텍스트를 표시하기 위한 기본적인 도구입니다.

• 포함한 문자열에 맞추기 위해 자신의 크기를 자동 조절하는 것을 지원합니다.
• 보통(클립), 랩(wrap), 생략(ellipsis: 문자열의 끝에 어떤 문자가 3개의 마침표로 대체되는 것)의 3가지 클립 모드를 지원합니다.
• UIString은 근원적인 기초의 역할을 합니다.

목록

UIList는 UI를 통해 구성될 수 있을 정도로 충분히 추상화되도록 매우 복잡한 형식의 목록을 일반적인 방법으로 지원하도록 디자인되어 있습니다. 목록은 데이터 소스, 컨테이너 위젯, 발표자의 3가지 구성 요소로 구성되어 있습니다.

• Container(컨테이너) - 컨테이너는 UI에 데이터를 전달하는 역할을 합니다. 컨테이너에는 포함하는 데이터 유형에 대한 지식이 없습니다. 컨테이너는 각 셀의 크기, 입력 처리(어떤 요소가 선택되는가를 추적하고,선택된 요소의 변경 등을 포함), 요소를 목록에 추가 및 목록에서 제거하고, 데이터 소스와 발표자 사이에 데이터 교환을 전달하는 등의 컨터이너가 갖고 있는 여러 요소를 추적하는 것을 담당합니다. 컨테이너는 UIList 위젯은에 의해 UI로 표시됩니다.
• Data(데이터) – 데이터 소스는 목록으로 렌더되는 데이터 값을 목록이 가져오는 곳입니다. 어떤 주어진 목록에 여러 데이터 소스가 있을 수 있습니다. 목록은 부모 장면에 의해 액세스될 수 있는 어떤 데이터 저장소에 대한 액세스를 갖습니다. 목록의 데이터 소스는 UIString 클래스에 의해 처리됩니다.
• Presenter(발표자) – 발표자는 목록 컨테이너에서 데이터를 표현하는 방법을 제어하는 것입니다. 발표자는 디자이너에 의해 구성된 레이아웃에 따라 데이터를 포맷합니다. 발표자는 목록 컨테이너의 비동적 제약에 따라 목록 컨테이너에 있는 동적으로 조정 가능한 매개 변수의 값을 조절하는 것을 처리합니다.

UIString

UIString은 UI에 의해 표시되는 모든 데이터를 위한 핵심 렌더링이 가능한 실체입니다. UIStrings는 일반 텍스트 또는 마크업 데이터 중 하나에 해당하는 각 노드인 1개 이상의 UIStringNodes로 나누어집니다. 마크업 데이터는 데이터 저장소로부터 가져오기되는 데이터에 의해 대체되는 텍스트로 정의됩니다. 데이터 저장소의 섹션에서 언급한 것처럼 데이터 저장소는 <<DataStoreName:PropertyName>에 의해 참조됩니다. 마크업은 현 스타일을 변경시킬 수 있고(<Styles:NormalText>), 스타일 속성을 활성 또는 비활성 시킬 수 있고(<Attributes:B> <Attributes:/B>), 또는 마크업에서 지정된 데이터 저장소의 속성 값으로 마크업이 교체되야 한다는 것을 나타낼 수 있습니다(<SomeDataStoreName:PropertyName>). UIStrings는 입력 텍스트를 구문 분석하여 UIStringNodes를 동적으로 생성합니다. 예를 들어 다음 문자열을 UIString으로 구문 분석하면 다음과 같은 7개의 토큰을 생성합니다.
The name specified '<SceneData:EnteredName>' is not available. Press <ButtonImages:IMG_A> to continue or <ButtonImages:IMG_B> to cancel.
생성된 토큰은 다음과 같습니다.

[0] = "The name specified '"
[1] = "<SceneData:EnteredName>"
[2] = "' is not available.  Press "
[3] = "<ButtonImages:IMG_A>"
[4] = " to continue or "
[5] = "<ButtonImage:IMG_B>"
[6] = "to cancel."

이러한 토큰은 UIStringNodes로 변환됩니다. 데이터 저장소에 의해 데이터 저장소를 참조하는 마크업이 처리됩니다. 데이터 저장소는 적절한 값이 이미 기입된 적절한 UIStringNode를 만듭니다. UIStringNodes에는 텍스트 렌더링과 이미지 렌더링의 2가지 유형이 있습니다. UIStringNode_Text 노드는 문자열뿐만 아니라, ints, bools 등과 같이 텍스트로 렌더되는 데이터 값이 사용될 수 있습니다. UIStringNode_Image 노드는 객체와 텍스처와 같은 이미지로만 렌더될 수 있는 데이터를 나타내는 데이터 저장소 마크업에 사용될 수 있습니다. 각 문자열 노드는 후처리된 텍스트 또는 마크업 버전에 따라 자신의 정확한 범위 값(너비와 높이)을 계산하고 추적할 수 있습니다. 이것은 노드 상태의 특정 요소(데이터 자체, 스케일링, 커닝(kerning) 등)가 변경된 경우에만 이루어집니다. 그런 다음 전체 UIString의 범위를 계산하는 것은 매우 간단합니다. 모든 노드 범위의 합계입니다. UIString은 예를 들어 디자이너가 셀의 특정 영역에 특정 폭을 가지는 것을 바라거나 또는 오른쪽 정렬되는 원하는 UIListElementCell에 의해 포함되는 경우 각 UIStringNode 영역을 수동으로 조절하도록 설정될 수도 있습니다.

위젯 스타일

스타일은 위젯이 어떻게 표시되는지를 제어합니다. 스타일에는 텍스처를 렌더(스케일 조절하는, 스트레칭하는, 등)하는 방법에 대한 정보가 포함될 수 있고 문자열을 그리는(글꼴, 색상, 속성 등) 것에 대한 정보 또한 포함될 수 있습니다. UI 에디터에는 스타일 브라우저가 있습니다. 위젯에 스타일을 적용하려면, 사용자는 기존의 스타일 목록에서 1가지를 선택하거나, 새로운 스타일(기존 스타일을 기반으로 하거나 또는 완전히 새로운)을 만들 수 있습니다. 스타일이 만들어지면, 지속성 GUID가 지정됩니다. 특정 위젯 스킨에 대한 모든 스타일은 단일 Unreal 패키지 파일에 저장됩니다. 스타일에 의해 요구되는 리소스는 스킨 파일에 저장될 수 있거나 또는 다른 패키지에 위치될 수 있습니다. 전체 게임 UI는 기본 스타일 패키지로써의 역할을 다하도록 스타일 패키지가 적어도 1개 필요합니다. 추가 스킨 세트는 이 기본 스킨에 기반하고, 사용자 지정 스킨 파일에 저장된 스킨 파일로부터만 변경됩니다. 위젯에 스킨 패키지로부터 스타일이 지정되면 위젯의 GUID와 스타일의 GUID 간의 매핑이 스킨 파일에 배치됩니다. 사용자 지정 스킨 설정의 경우 기본적으로 위젯이 자동으로 사용자 지정 스타일 집합에 포함된 사용자 지정된 스타일 버전으로 매핑하지만, 사용자가 특정 위젯에 전혀 다른 스타일을 지정할 수 있습니다. 이것은 해당 위젯의 스타일을 해당 스킨 집합과 사용자 지정 집합에 기반한 모든 스킨 집합에 대해서만 변경시킵니다. 사용자 지정 집합은 계층적일 수 있고, 해당 사용자 지정 집합은 다른 사용자 지정 스킨 집합에 기반할 수 있습니다.

스킨

애니메이션

UI 편집기

UI Editor의 주요 기능 및 사용 방법을 설명하는 문서는 UIEditorUserGuideKR 에서 찾을 수 있습니다.