아마 게임을 하면서 플레이어와 제일 많은 상호작용을 하는 UI 요소는 바로 버튼일 것이다. 버튼은 마우스의 클릭에 반응해서 지정해둔 기능을 동작하게 하는 UI이다. 이렇게 설명만 들어도 간단해보이는 Button 컴포넌트가 이렇게 영상까지 만들어서 이야기할 필요가 있을까 싶을 것이다.
버튼 게임 오브젝트 생성하기
하지만 이렇게 간단해보이는 Button 컴포넌트에도 유용하게 사용할 수 있는 팁들이 꽤 있다.
하이어라키 뷰에 우클릭하고 [UI > Button]을 선택하면 버튼 게임 오브젝트를 생성할 수 있다.
생성된 버튼 게임 오브젝트에는 Image 컴포넌트와 Button 컴포넌트가 부착되어 있는 것을 볼 수 있다. 거기에 기본적으로 버튼 게임 오브젝트 아래에는 버튼에 글자도 표시되게 Text 컴포넌트가 붙어있는 게임 오브젝트도 자식으로 있는 것을 알 수 있다. 이게 버튼의 제일 기본적인 상태이다.
Button 컴포넌트의 프로퍼티
그럼 Button 컴포넌트의 프로퍼티들을 하나씩 알아보도록 하자.
Interactable
첫 번째 프로퍼티는 Interactable이다. Interactable은 버튼이 상호작용 가능한지를 정하는 프로퍼티입니다.
먼저 Interactabla이 체크된 상태에서 클릭해보면 클릭할 때마다 버튼이 깜빡깜빡하며 버튼과 마우스 사이의 상호작용이 일어나고 있는 것을 확인할 수 있다.
Interactable을 끄면 먼저 버튼의 색깔이 약간 어두워지고 반투명해지는 것을 볼 수 있다. 그 상태에서 버튼을 클릭해보면 아까와는 다르게 상호작용하면서 발생하는 깜빡임이 나타나지 않는 것을 알 수 있다.
이 프로퍼티는 특정한 조건에 따라서 버튼을 활성화/비활성화 하는 기능으로 응용할 수 있다.
Transition
그다음 프로퍼티는 Transition이다. Transition은 버튼이 각 상호작용 상태에서 어떤 모습으로 보일 것인지를 결정한다.
버튼의 상호작용 상태로는 먼저 아무런 상호작용도 일어나고 있지 않은 Normal, 마우스가 버튼 위에서 호버링되고 있는 상태인 Highlighted, 버튼을 클릭하고 손을 떼지 않은 상태인 Pressed, 버튼에 클릭을 하고 손을 뗀 상태인 Selected, 버튼이 비활성화된 Disabled.
이렇게 총 5가지가 있다.
그리고 선택 가능한 Transition의 종류로는 None, Color Tint, Sprite Swap, Animation이 있다.
None
None 타입의 트랜지션은 버튼과의 상호작용이 일어나도 아무런 표현을 하지 않는 타입이다.
Color Tint
버튼을 생성하면 기본 트랜지션으로 설정되는 Color Tint는 버튼에 상호작용을 했을 떄 상태변화를 생상으로 표현하는 것이다.
위에서 버튼을 클릭할 때마다 버튼이 깜빡깜빡하던 것을 기억할 것이다. 여기 Pressed를 보면 색깔이 약간 어두운 색으로 되어 있다. 이 Pressed에 설정된 색상이 버튼 이미지에 합쳐져서 버튼을 클릭할 때마다 깜빡거렸던 것이다.
Sprite Swap
Sprite Swap은 버튼의 상호작용 상태에 따라서 버튼 게임 오브젝트의 Image를 완전히 교체하는 방식이다.
Transition을 Sprite Swap으로 바꾸면 각 버튼 상호작용 상태에 따라서 색깔을 바꾸던 프로퍼티들이 스프라이트를 넣도록 바뀐 것을 볼 수 있다.
Sprite Swap 타입에서는 Normal 상태가 없는 것을 볼 수 있는데 Sprite Swap의 기본 상태는 버튼에 붙은 기본 이미지의 Image Source여서 바꿔넣을 필요가 없기 때문이다.
버튼 이미지에 기본 이미지를 넣고 Pressed에 버튼이 눌린 이미지를 넣으면 위의 그림과 같이 버튼이 눌리는 듯한 연출이 가능하다.
Animation
Animation 타입은 버튼의 색깔만 바뀌는 Color Tint나 이미지만 바뀌는 Sprite Swap에 비해서 좀 더 복잡하고 다양한 연출이 필요할 때 사용한다.
Animation 타입에서 Transition의 하위 프로퍼티는 각 상태에 맞는 이름으로 되어있는데 버튼 애니메이션에 추가될 스테이트와 파라미터의 이름을 지정하는 부분입니다. 이 부분은 따로 손댈 필요가 없다.
아래에 있는 Auto Generate Animation 버튼을 누르면 버튼에 대한 애니메이터 컨트롤러를 생성하는 대화상자가 뜬다. 여기서 애니메이터를 생성하면 하면 자동으로 버튼 게임 오브젝트에 애니메이터 컴포넌트가 추가되고 애니메이터에서 필요한 스테이트와 파라미터들이 자동으로 생성된다.
버튼 게임 오브젝트를 선택한 상태로 [Ctrl +6] 단축키를 누르면 애니메이션 뷰가 열리는데 개발자는 여기서 각 상태의 애니메이션 키만 잡아주면 된다.
이미지 하나를 버튼의 자식 게임 오브젝트로 만들고 버튼 위에 마우스를 올렸을 때, 이미지를 활성화 시키면서 360도 회전시키는 애니메이션을 만들어보자.
그 다음 플레이시킨 뒤 버튼에 마우스를 올려보면 버튼 앞에서 사각형이 나타나서 회전하는 것을 볼 수 있다.
이런 연출은 확실히 Color Tint나 Sprite Swap으로는 할 수 없는 연출이다. 일반적으로는 Color Tint나 Sprite Swap을 사용하지만 버튼과의 상호작용 연출에서 이런 다양한 연출을 사용하려면 Animation 타입의 Transition을 사용하는 것이 좋다.
Navigation
그 다음 프로퍼티인 Navigation은 모든 UI 컴포넌트에 있는 것으로 키보드나 패드로 UI를 선택할 때 어떤 순서로 포커스가 넘어갈 것인지를 결정하는 옵션dl다.
On Click 이벤트
On Click()은 버튼을 눌렀을 때 실행될 기능을 넣을 수 있는 On Click 이벤트 리스트이다.
public class ButtonTester : MonoBehaviour
{
public void OnClickButton()
{
Debug.Log("Button Click!");
}
}
On Click에 실행될 함수를 이벤트로 등록해주기 위해서는 스크립트에서 public으로 된 함수를 만들면 된다.
그리고 버튼에 스크립트로 작성한 컴포넌트를 추가하고 On Click 항목의 [+] 버튼을 누른 뒤 비어있는 오브젝트 란에 호출할 함수를 가진 컴포넌트를 넣어주고 호출해야할 함수를 선택해주면 된다.
이렇게 함수를 선택해주면 이 버튼이 클릭되었을 때, 이 함수가 실행되게 된다.
스크립트에서 On Click 이벤트 등록하기
버튼의 응용 기술로는 이렇게 에디터에서 고정으로 이벤트를 등록하지 않고 스크립트에서 동적으로 등록해주는 방법이 있다.
using UnityEngine.UI;
public class ButtonTester : MonoBehaviour
{
Button button;
public void OnClickButton()
{
Debug.Log("Button Click!");
}
void Start()
{
button = GetComponent<Button>();
button.onClick.AddListener(OnClickButton);
}
}
스크립트에서 Button 컴포넌트와 같은 UI의 기능을 사용하기 위해서는 UI 네임 스페이스를 using 선언해줘야 한다.
그 다음에는 Button 변수를 선언하고 Start 함수에서 GetComponent로 게임 오브젝트에 부착된 Button 컴포넌트를 가져온다. 그리고 button.onClick.AddListener에 함수를 넣어주면 이 함수가 이 버튼을 클릭했을 때 호출되는 이벤트로 등록된다.
게임을 플레이해보면 Button 컴포넌트의 On Click에서는 아무런 이벤트가 등록되지 않은 것처럼 보이지만 게임 뷰에서 버튼을 클릭해보면 스크립트에서 버튼의 이벤트로 등록해준 ButtonTester의 OnClickButton 함수가 정상적으로 호출되어 로그를 출력하는 것을 볼 수 있다.
버튼 터치 영역 키우기
모바일 기기에서 작은 버튼은 터치가 잘 안되거나 잘못 터치할 확률이 높다. 이런 문제를 해결하기 위해서 그냥 버튼의 크기를 키워버릴 수도 있지만 그렇게 하면 디자이너가 지정해준 전체적인 UI 레이아웃이 깨지게 될 것이다. 그러니 실제로 보이는 버튼의 크기는 키우지 않고 버튼의 터치 영역만 키워야 한다.
우선 버튼의 자식 컴포넌트로 이미지를 하나 추가하고 적당히 버튼을 덮도록 세팅한 다음 투명하게 만들어주면 된다.
그러면 눈에 보이는 버튼 이미지보다 바깥을 클릭해도 버튼이 무사히 동작하는 것을 볼 수 있다.
이것을 응용해서 버튼보다 작은 투명 이미지를 만들고 그 투명 이미지를 제외한 나머지의 Raycast Target을 끄는 방법으로 실제 버튼 이미지보다 작은 영역만 클릭 가능하게 만드는 것도 가능하다.
버튼 이미지보다 작은 영역에 터치를 받는 테크닉은 잘 사용되지 않을 것 같지만 버튼 이미지 리소스 외곽에 그림자나 글로우가 들어간 경우에 글로우 영역이나 그림자 영역을 제외하고 실제 버튼 영역에만 클릭을 받기 위해서 사용되는 경우가 종종 있다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
잠시 기다리면 설치 가능한 패키지 전체가 나올 텐데, 만약 곧바로 2D Sprite 패키지가 보이지 않으면 왼쪽 상단의 Packages 탭 아래의 [+] 버튼 옆에 있는 버튼을 클릭해서 All Packages를 선택하면 설치가능한 모든 패키지가 나온다.
그 중에서 2D Sprite를 선택하고 오른쪽 아래의 Install 버튼을 클릭한다.
Sprite
유니티 엔진에서 사용되는 이미지 리소스를 텍스쳐(Texture)라고 부른다. 이 텍스쳐 중에서도 Image 컴포넌트나 2D 게임의 오브젝트로 그려지는 스프라이트 렌더러에서 사용되는 리소스들을 스프라이트(Sprite)라고 한다.
보통 유니티 프로젝트에 임포트되는 텍스쳐들은 자동으로 Texture Type이 Default로 정해진다. Default는 주로 3D 모델 오브젝트의 텍스쳐로 사용되는 타입이다.
UI에 사용하기 위해서는 이 Texture Type을 Sprite로 변경해주어야 한다. 임포트한 텍스쳐들을 선택하고 Texture Type을 Sprite로 변경해주자.
이미지 게임 오브젝트 생성하기
이미지 게임 오브젝트를 생성하기 위해서는 하이어라키 뷰에 우클릭하고 [UI > Image] 항목을 선택하면 된다.
이미지 게임 오브젝트를 만들 때 씬 안에 캔버스 게임 오브젝트가 없으면 자동으로 캔버스 게임 오브젝트를 생성하고 그 아래에 이미지 게임 오브젝트가 만들어진다. 이미 캔버스 게임 오브젝트가 있다면 그 캔버스 오브젝트 아래에 이미지 게임 오브젝트가 생긴다.
Image 컴포넌트
유니티 엔진에서 화면에 그림을 표현하기 위해 사용되는 것이 바로 이 Image 컴포넌트다. 기본 Image 컴포넌트는 화면에 그림을 보여주기만 하고 클릭한다던가 하는 상호작용이 불가능하다.
UI 작업을 좀 더 편하게 하기 위해서는 단축키 [2]를 눌러서 2D 작업모드로 변경하면 된다.
Image 컴포넌트의 프로퍼티들
이미지 게임 오브젝트를 선택하고 게임 오브젝트에 부착되어 있는 Image 컴포넌트를 보면 Source Image, Color, Material, Raycast Target과 같은 프로퍼티를 볼 수 있다.
Source Image
우선 Source Image는 이 Image 컴포넌트가 화면에 보여줄 그림을 설정할 수 있는 프로퍼티이다. 이 프로퍼티가 비어있으면 위의 이미지처럼 그냥 하얀 이미지로 화면에 표시된다.
Source Image에 다른 스프라이트를 넣어주면 하얀 이미지가 넣어준 스프라이트로 바뀌게 된다.
using UnityEngine.UI;
public class ImageChanger : MonoBehaviour
{
private Image image;
[SerializeField]
private Sprite sprite;
void Start()
{
image = GetComponent<Image>();
// image.sprite로 Image 컴포넌트의 Source Image에 접근
image.sprite = sprite;
}
}
스크립트에서는 image.sprite를 통해서 Source Image에 접근해서 화면에 그리는 이미지를 바꿀 수 있다.
Color
Color 프로퍼티는 이미지의 색상을 바꿀 때 사용된다.
하얗게 표시된 색상 부분을 클릭해보면 색을 바꿀 수 있는 Color 대화상자가 표시된다. R값은 빨간 색 계열, G값은 초록 색 계열, B값은 파란 색 계열을 의미한다.
그리고 A는 알파(Alpha) 값으로 투명도를 의미한다. 수정하면 이미지를 투명하게 만들 수 있다.
Material
Material 프로퍼티는 이미지에 머티리얼을 넣어서 흐리게 보이게 만든다거나 왜곡되어 보이게 하는 것처럼 특별한 효과를 넣고자 할 때 사용된다.
Raycast Target
Raycast Target 프로퍼티는 이 이미지를 Raycast의 타깃으로 삼을 것인가를 결정하는 것이다.
이 프로퍼티의 기능을 이해하려면 Raycast가 무엇인지 이해해야하는데 간단하게 설명하면 클릭한 위치에 일종의 광선을 쏴서 그 광선에 맞은 오브젝트를 검출해내는 것이다.
한마디로 Raycast의 타깃으로 삼는다는 것은 이 오브젝트를 클릭했을 때 Raycast에 검출이 되게 한다는 의미이다.
이것을 확인해보려면 Image 컴포넌트가 붙어 있는 게임 오브젝트에 Button 컴포넌트를 붙여보면 된다.
Button 컴포넌트를 붙인 다음 게임을 플레이시키고 이미지를 클릭해보면 이미지가 깜빡거리면서 상호작용이 일어나고 있는 것을 알 수 있다. 하지만 Raycast Target을 끄고 버튼을 클릭해보면 더 이상 클릭이 되지 않는다.
이렇게 Raycast Target 옵션은 이미지가 클릭을 받아들이게 만들지 말지를 설정하는데 사용된다.
Image Type
Source Image를 넣으면 비어있을 때는 없던 프로퍼티들이 새로 생긴 것을 볼 수 있다.
Image Type은 이미지가 그려지는 방식을 결정하는 프로퍼티이다.
Simple
Simple은 보이는 그대로 이미지를 바로 보여주는 타입이다.
Use Sprite Mesh
Use Sprite Mesh는 이미지를 그리는 영역을 지정할 때, 그냥 사각형 영역으로 그릴지 아니면 이미지의 알파 영역을 무시하고 최대한 그림의 형태에 맞는 영역으로 그릴지를 결정한다.
화면에 그려지고 있는 초록색 이미지를 보면 그림에 투명한 부분이 많은 것을 알 수 있다.
씬 뷰의 왼쪽 상단에 Shaded라고 표시된 부분을 클릭해서 Overdraw를 선택한다.
그러면 씬 뷰가 까맣게 변하고 UI가 있는 부분은 갈색으로, UI가 겹쳐진 부분은 옅은 갈색으로 표시되는 것을 볼 수 있다.
이렇게 UI가 겹쳐진 것을 Overdraw라고 부르며, 이렇게 겹쳐진 부분의 픽셀을 화면이 갱신될 때마다 겹쳐진 횟수만큼 다시 그리기 때문에 반드시 필요한 경우가 아니라면 이미지가 겹쳐서 그려지는 것을 피해야 한다. 그런 의미에서 이런 쓸데없는 알파값 부분을 제외하고 그림의 형태 대로만 다시 그리도록 하는게 좋을 것이다.
Use Sprite Mesh를 체크하면 사각형으로 잡혀있던 이미지의 영역이 최대한 이미지의 영역에 가깝게 바뀐것을 볼 수 있다.
Preserve Aspect
Preserve Aspect는 Source Image의 원본 비율을 지켜서 그릴 것인지를 정하는 프로퍼티이다. 보통은 Image 컴포넌트가 부착된 UI 게임 오브젝트의 너비와 높이에 따라서 그림의 비율이 변형되어서 화면에 그려지지만 Preserve Aspect를 체크하면 비율을 지킨 상태로 화면에 그려지게 할 수 있다.
Sliced
Sliced 타입은 9슬라이싱이라는 기능을 사용하기 위한 것으로 작은 크기의 이미지를 모서리 부분의 해상도를 유지하고 가운데 부분을 늘어뜨려서 채워주는 방식으로 UI의 크기를 자유자재로 사용할 수 있게 도와주는 타입이다.
우선 이미지를 9슬라이싱 하기 위해서는 프로젝트 뷰에서 9슬라이싱을 적용할 스프라이트를 선택하고 인스펙터 뷰에서 Sprite Editor 버튼을 클릭하면 된다.
그리고 스프라이트 에디터에서 모서리 부분과 중간에 반복될 부분을 적당히 나눠주고 Apply 시키면 9슬라이싱이 적용된다.
이렇게 슬라이싱된 이미지를 넣은 Image 컴포넌트의 Image Type을 Sliced로 적용하면 이미지가 크기에 따라 늘어지지 않는 것을 볼 수 있다.
Fill Center
Fill Center 프로퍼티는 Sliced로 늘어난 이미지의 가운데를 채울 것인가를 결정한다.
Pixel Per Unit
Pixel Per Unit 프로퍼티는 이미지의 1픽셀을 유니티에서 어떤 크기로 화면에 그릴 것인가를 결정한다.
Tiled
Tiled 타입은 이미지를 반복으로 그려주는 타입이다.
Filled
Filled는 차오르는 게이지 같은 연출을 표현할 때 주로 사용된다.
하위 프로퍼티로는 Fill Method, Fill Origin, Fill Amount가 있다.
Fill Method는 Radial 360, Radial 180, Radial 90, Vertical, Horizontal이 있다.
Fill Origin은 채우기를 시작하는 지점을 정하는 프로퍼티인데, Fill Method마다 조금씩 다른 값을 가지고 있다.
그리고 Clockwise는 Radial 타입 메소드에서 사용되는 프로퍼티로 이미지를 시계방향으로 차오르게 할 지, 반시계 방향으로 차오르게 할 지를 설정하는 데 쓰인다.
Radial 360
Radial 360은 중심을 기준으로 360도 회전하며 이미지가 차오르게 만드는 방식이다.
Fill Origin은 Top, Bottom, Left, Right로 바꿀 수 있다.
이 형태는 원형 스킬 UI에서 쿨타임이 줄어드는 연출을 하고자 할때 주로 사용된다.
Radial 180
Radial 180은 한 쪽 변을 기준으로 180도 회전하며 이미지가 차오르게 만드는 방식이다.
Fill Origin은 Top, Bottom, Left, Right로 바꿀 수 있다.
Radial 90
Radial 90은 한 쪽 꼭지점을 기준으로 90도 회전하며 이미지가 차오르게 만드는 방식이다.
Fill Origin은 Bottom Left, Bottom Right, Top Left, Top Right로 바꿀 수 있다.
Vertical
Vertical은 이미지를 위/아래로 차오르게 만드는 방식이다.
Fill Origin은 Top, Bottom으로 바꿀 수 있다.
사각형 스킬 UI에서 스킬 쿨다운 연출이나 과열된 장비의 냉각을 연출하는데 쓰면 좋다.
Horizontal
Horizontal은 이미지를 좌/우로 차오르게 만드는 방식이다.
Fill Origin은 Left, Right로 바꿀 수 있다.
로딩 바나 경험치 바처럼 차오르는 연출을 보여주는데 자주 사용한다.
스크립트에서 Fill Amount 값 조절하기
using UnityEngine;
using UnityEngine.UI;
public class ImageFiller : MonoBehaviour
{
private Image image;
void Start()
{
image = GetComponent<Image>();
}
float timer = 0f;
void Update()
{
timer += Time.deltaTime;
image.fillAmount = Mathf.Sin(timer) * 0.5f + 0.5f;
}
}
스크립트에서는 image.fillAmount를 통해서 Image 컴포넌트의 Fill Amount 값을 조절할 수 있다.
Set Native Size
Set Native Size 버튼은 Image 컴포넌트가 부착된 UI 게임 오브젝트의 Width와 Height를 Source Image로 넣은 스프라이트의 해상도와 같게 만들어주는 버튼이다.
예를 들어 Source Image로 512x512 해상도의 스프라이트를 넣고 Set Native Size 버튼을 누르면 이미지 게임 오브젝트의 Width와 Height도 512x512로 변경된다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
게임에서 플레이어에게 게임 내의 정보를 전달하는 매개체를 유저 인터페이스, 줄여서 UI라고 부른다.
GUI
CUI
그리고 이 UI는 크게 문자로 보여주고 사용자 역시 문자를 입력해서 상호작용해야하는 Character User Interface, CUI와 이미지와 문자의 혼합된 형태로 보여지고 마우스를 이용해서 상호작용할 수 있는 Graphic User Interface, GUI로 나누어진다.
문자나 글자로만 상호작용하는 CUI는 컴퓨터의 성능이 모자라서 그래픽으로 UI를 보여주기 힘들던 옛날 게임에서나 볼 수 있는 방식의 UI다. 최근에 와서는 옛날 게임의 감성을 되살리고자 하는 게임에서 이 CUI 방식을 일부 차용하기도 한다.
하지만 컴퓨터의 성능이 충분히 올라온 지금은 대부분의 게임에서 GUI를 사용한다.
유니티 엔진의 GUI 시스템, UGUI
캔버스
유니티 엔진에서 사용되는 GUI 시스템을 유니티 GUI 줄여서 UGUI라고 부른다. 그럼 이제 에디터에서 UGUI의 기본부터 차근차근 살펴보자.
하이어라키 뷰에 우클릭 해보면 생성할 수 있는 게임 오브젝트의 종류를 볼 수 있는데 그 중에 UI 항목이 있다.
글자를 표현하는 Text, 그림을 표현하는 Image, 클릭할 수 있는 Button 등 UI로 사용할 수 있는 여러가지 형태의 게임 오브젝트들을 볼 수 있다.
우선 UI 게임 오브젝트 중에서 Canvas를 생성해보자. Canvas를 생성하면 씬 뷰에 하얀 선으로 직사각형이 표시되는 것을 볼 수 있다.
Canvas는 유니티 엔진에서 UI를 배치하기 위한 영억으로 모든 UI가 화면에 표시되기 위해서는 이 Canvas 컴포넌트가 부착된 게임 오브젝트의 자식 게임 오브젝트여야 한다.
Canvas의 설정은 용도에 따라서 여러가지가 있지만, 방금 생성한 Canvas처럼 Render Mode를 [Screen Space - Overlay]로 된 것을 기본적으로 많이 사용한다. 이 설정은 게임 해상도로 표현되는 스크린 스페이스에 UI를 그리는 설정이다.
이 설정에서 Canvas의 해상도는 게임의 해상도를 따른다.
게임 뷰를 보면 지금 해상도가 1920x1080으로 설정되어 있는 것을 볼 수 있는데 거기에 맞춰서 Canvas의 width와 height도 1920x1080인 것을 볼 수 있다. 게임 뷰의 해상도를 바꿔보면 Canvas의 해상도 역시 자동으로 바뀌는 것을 볼 수 있다.
[Screen Space - Overlay]는 일반적인 평면 UI에서 주로 사용되는 설정입니다.
Rect Transform 컴포넌트
일반 게임 오브젝트의 Transform
UI 게임 오브젝트의 Rect Transform
일반 게임 오브젝트와 UI 게임 오브젝트의 차이점으로는 일반 게임 오브젝트의 경우에는 Transform 컴포넌트로 씬 안에서의 위치를 표현하지만, UI 게임 오브젝트들은 Rect Transform 컴포넌트로 위치를 표현한다.
메인 메뉴 만들어 보기
간단하게 게임의 메인 메뉴 형태로 UI들을 만들어 보자.
2D 작업 모드
그 전에 씬 뷰에서 이렇게 원근감이 있는 상태로는 이동도 어렵고 UI 작업이 불편하기 때문에 키보드의 숫자 '2' 버튼을 눌러서 씬 뷰를 2D 모드로 만든다. 2D 모드는 UI 작업이나 2D 게임 작업을 위한 모드로 마우스 휠을 돌려서 확대/축소하고 휠 클릭으로 화면의 위치를 이동시킬 수 있다.
캔버스에 Button과 Text, Image를 이용해서 위의 이미지와 같이 UI를 구성해보자.
중간의 꾸미는 모양이 이미지는 이 그림을 다운로드 받아서 사용하면 된다.
늘 강조하던 내용이지만, 하이어라키 뷰에서 게임 오브젝트의 이름이 생성된 초기 이름 그대로이면 나중에 필요한 오브젝트를 찾기가 어려워지기 때문에 버튼 이름도 적절하게 바꿔주도록 한다.
참고로 유니티 엔진에서 어떤 UI가 더 위에 그려지느냐 하는 우선 순위는 하이어라키 뷰에서의 순서로 결정된다. 지금 하이어라키 뷰를 보면 "Background" Image가 다른 Text나 Button보다 하이어라키 뷰에서 상단에 있는 것을 볼 수 있다. 하지만 씬 뷰나 게임 뷰에서는 제일 뒤에 그려지고 있다.
이 "Background" 이미지를 조금씩 아래로 내려보면 다른 버튼과 텍스트를 하이어라키 뷰의 순서에 따라서 가리기 시작하는 것을 볼 수 있다.
이렇게 다른 UI 보다 앞에 나오길 바라는 UI는 하이어라키 뷰에서 아래로 옮기고, 뒤에 나오길 바라는 UI는 하이어라키 뷰에서 위로 옮겨서 UI의 순서를 조정할 수 있다.
이번에는 간단하게 방금 만든 메인 메뉴에 기능을 추가해보도록 하자. 먼저 MainMenu라는 이름으로 C# 스크립트를 생성한다.
public class MainMenu : MonoBehaviour
{
// 새 게임 버튼을 눌렀을 때 버튼이 호출할 함수
public void OnClickNewGame()
{
Debug.Log("새 게임");
}
// 불러오기 버튼을 눌렀을 때 버튼이 호출할 함수
public void OnClickLoad()
{
Debug.Log("불러오기");
}
// 옵션 버튼을 눌렀을 때 버튼이 호출할 함수
public void OnClickOption()
{
Debug.Log("옵션");
}
// 종료 버튼을 눌렀을 때 버튼이 호출할 함수
public void OnClickQuit()
{
#if UNITY_EDITOR // 에디터에서만 실행되는 코드
UnityEditor.EditorApplication.isPlaying = false; // 에디터의 플레이 모드를 중단
#else // 빌드된 게임에서 실행되는 코드
Application.Quit(); // 실행되고 있는 게임 프로그램을 종료
#endif
}
}
코드를 저장하고 에디터로 돌아와서 "Main Menu Canvas"에 MainMenu 컴포넌트를 추가해준다.
그 다음에 각 버튼의 On Click 이벤트에 [+] 버튼을 누른 뒤, MainMenu 컴포넌트를 붙인 게임 오브젝트를 할당하고 각 버튼에 맞는 함수를 호출하도록 만든다.
그리고 플레이 버튼을 눌러 게임을 실행하고 각 버튼을 눌러보면 함수에 넣어둔 로그가 출력되고 마지막으로 종료 버튼을 누르면 플레이 상태가 종료되는 것을 알 수 있다.
이렇게 유니티에서 제공하는 UI 관련 컴포넌트들을 잘 응용하면 거의 모든 UI 기능들을 구현할 수 있다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
유니티에서 모든 UI는 캔버스(Canvas) 위에서 그려진다. 아직 유니티 엔진을 이용한 개발에 익숙하지 못한 개발자들은 모든 UI를 한 캔버스에 만드는 경우가 많다.
하지만 모든 UI를 한 캔버스로 몰아넣으면 모든 UI를 그리는 과정에서 불필요한 낭비가 발생하게 된다.
[그림 1]
[그림 1]을 보면 하나의 캔버스 안에 여러 개의 이미지가 포함되어 있는 것을 볼 수 있다. Checker 오브젝트는 흰 색과 검은 색으로 이루어진 이미지이고, 그 뒤에 Background Slide라는 이름의 회색 이미지가 크게 배치되어 있다.
[그림 2]
우선 이 상태에서 UI는 어떤 과정을 통해서 그려지는지 확인하기 위해서 프레임 디버거(Frame Debugger)를 실행해보자. 프레임 디버거는 게임에서 각 프레임이 그려질 때 어떤 과정을 거쳐서 그려지는지 보여주는 디버깅 툴이다. 이것을 통해서 어떤 렌더링 과정에서 시간을 소모하는지를 확인할 수 있는 좋은 도구이다. 프레임 디버거를 실행하기 위해서는 유니티 상단 메뉴에서 [Windows > Analysis > Frame Debugger]를 선택하면 된다.
[그림 3]
그러면 [그림 3]과 같은 프레임 디버거 창이 열린다.
[그림 4]
프레임 디버거 창을 띄운 후, 플레이를 시작하고 프레임 디버거 창의 Enable 버튼을 누르면 한 프레임이 그려지는데 어떤 과정으로 몇 단계나 거쳐서 실행되는지 확인할 수 있다.
[그림 5]
이 상태에서 7 of 7 옆에 있는 넘기기 버튼을 눌러서 확인해보면 총 7단계를 거쳐서 화면이 그려지고 있고 그 중에 UI는 6, 7단계 두 단계를 거쳐서 먼저 회색 바탕이 그려지고 그 위에 체크 무늬 이미지가 그려지는 것을 볼 수 있다.
using UnityEngine;
using UnityEngine.UI;
public class FillingImage : MonoBehaviour
{
private Image image;
void Start()
{
image = GetComponent<Image>();
}
bool isFill = false;
float timer = 0f;
void Update()
{
if(timer >= 1f)
{
timer = 0f;
isFill = !isFill;
}
timer += Time.deltaTime;
image.fillAmount = isFill ? timer : 1f - timer;
}
}
그렇다면 이번에는 회색 바탕의 이미지인 Background Slide 오브젝트에 위와 같은 코드를 추가해서 이미지가 계속해서 채워졌다가 사라지는 동작을 반복하도록 만들어보자.
[그림 6]
코드를 모두 작성했다면 Background Slide 게임 오브젝트에 컴포넌트로 붙여준다.
[그림 7]
이것을 실행해보면 [그림 7]와 같이 보여진다. 하지만 단순히 겉으로만 보이는 상황으로는 어떤 낭비가 발생하는지 알 수 없다. 그러면 어떤 낭비가 발생하는지 확인하기 위해서 다시 프레임 디버거로 살펴보자.
[그림 8]
프레임마다 분명 7단계였던 렌더링 과정이 회색 이미지가 체커와 겹치게 되면서 8단계로 늘어나는 것을 볼 수 있다.
[그림 9]
이 8단계로 늘어난 렌더링 과정을 살펴보면 7단계일 때는 분명 회색 바탕을 먼저 그리고 체크 무늬 이미지를 그렸던 과정이 회색 바탕과 겹치지 않은 체크 무늬 이미지를 그리는 과정, 회색 바탕 이미지를 그리는 과정 그리고 회색 바탕과 겹친 체크 무늬 이미지를 그리는 과정으로 나누어진 것을 볼 수 있다. 이것은 렌더링 과정이 아주 작게 늘어난 예시로, UI 캔버스의 구조가 복잡해지면 복잡해질 수록 어떤 성능의 낭비를 가져올지 알 수 없게 된다.
이것을 해결하기 위한 방법이 바로 이번 글의 주제인 캔버스의 분할이다.
[그림 10]
[그림 10]을 보면 매 프레임 변동이 발생하는 Background Slide와 늘 고정되어 있는 Checker를 다른 캔버스로 나누어 배치한 것을 볼 수 있다.
[그림 11]
이렇게 캔버스를 분할한 뒤 다시 실행해서 매 프레임의 렌더링 단계를 살펴보면 다시 7단계로 줄어든 것을 확인할 수 있다.
[그림 12]
렌더링 단계 역시 살펴보면 회색 바탕을 먼저 그리고 회색 바탕과 체크 무늬 이미지가 겹치는 것과 상관없이 한꺼번에 체크 무늬 이미지를 그리는 것을 볼 수 있다.
이렇게 캔버스를 분할하는 것 역시 렌더링 최적화를 위한 하나의 방법이 될 수 있다. 가능하면 변동되는 타이밍이 비슷한 UI끼리 그룹을 지어서 캔버스로 묶는 것이 좋다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
유니티 개발을 처음으로 공부하는 개발자들은 기본적으로 게임 오브젝트의 위치를 이동시키는 코드를 작성하려고 할 때, 제일 먼저 떠올리는 코드는 transform.position일 것이다.
public class UIController : MonoBehaviour
{
private void Update()
{
if(Input.GetMouseButtonDown(0) || Input.GetMouseButton(0))
{
transform.position = Input.mousePosition;
}
}
}
그래서 UI 게임 오브젝트를 이동시키는 코드를 작성하면 보통은 위의 예시 코드와 같이 작성하게 된다.
물론 에디터에서는 UI가 마우스 클릭을 따라서 잘 움직인다. transform.position으로 위치를 이동시키는 코드를 만들어도 UI 오브젝트를 잘 움직일 수는 있다.
Rect Transform
하지만 캔버스(Canvas) 밑에 속하는 UI 게임 오브젝트를 인스펙터 창에서 보면 트랜스폼(Transform) 대신에 렉트 트랜스폼(Rect Transform, 사각 트랜스폼)이 표시되는 것을 볼 수 있다. 유니티 엔진에서는 UI 오브젝트의 위치를 다룰 때, 트랜스폼 컴포넌트보다는 렉트 트랜스폼 컴포넌트를 사용하는 것을 권장한다는 의미로 볼 수 있다.
앵커(Anchor)
트랜스폼 컴포넌트와는 다르게 렉트 트랜스폼 컴포넌트는 앵커(Anchor)라고 하는 기준점을 가진다.
기본적으로는 앵커의 기준점이 middle, center로 설정되어 있는데, 이 기준점은 부모 UI 게임 오브젝트를 영역을 대상으로 한다.
이것을 씬 뷰에서 보면 제일 바깥의 하얀 사각형이 부모 UI 게임 오브젝트의 영역이며, 빨간색 이미지 중간에 4개의 삼각형이 짚고 있는 지점이 middle, center이다. 캔버스 바로 아래에 있는 UI 오브젝트의 부모 UI 영역은 일반적으로 스크린 전체를 의미한다.
노란 이미지의 자식 UI인 초록 이미지를 선택해보면 부모 UI 영역인 하얀 사각형이 노란 이미지를 크기만큼 지정되어 있고 앵커 역시 노란 이미지의 중심에 있는 것을 볼 수 있다. 즉, 자식 UI 오브젝트의 위치는 부모 UI 오브젝트의 영역을 대상으로 잡은 앵커를 중심으로 계산된다.
빨간색 십자선이 그려진 사각형 이미지를 선택하면 이 앵커의 위치를 정할 수 있는 몇 가지 프리셋을 보여주는데, 너비 앵커에는 left, center, right, stretch를 제공하고 높이 앵커에는 top, middle, bottom, stretch를 제공하며. 너비 앵커의 left, center, right나 높이 앵커의 top, middle, bottom 옵션은 부모 UI 영역의 왼쪽, 가운데, 오른쪽, 상단, 중단, 하단, 같은 특정한 위치를 의미한다. 그리고 너비 앵커와 높이 앵커 둘 다에 stretch 옵션이 있는데, 이것은 앞선 옵션들의 위치와는 조금 다른 의미를 가진다.
너비 앵커와 높이 앵커의 프리셋을 둘 다 stretch로 변경하면 원래는 Pos X, Pos Y, Width, Height이던 렉트 트랜스폼의 프로퍼티가 Left, Top, Right, Bottom으로 변경되는 것을 볼 수 있다.
각각의 프로퍼티는 부모 UI 영역의 경계선으로부터의 거리를 의미하며, 부모 UI의 영역의 너비와 높이의 변화에 영향을 받는다는 것이다.
단순한 예시로 부모 UI 영역의 너비가 늘어나면 위의 이미지처럼 Left와 Right의 간격을 유지하기 위해 빨간색 이미지 역시 늘어나게 된다. 하지만 노란색 이미지의 앵커는 middle, center로 부모 UI 영역의 너비와 높이로부터 영향을 받지 않기 때문에 여전히 정사각형 형태를 유지한다.
앵커의 간단한 활용
이러한 앵커의 활용법은 굉장히 간단하고도 유용하다. 만약 빨간 이미지의 UI를 항상 화면 왼쪽 상단에 위치 시키고 싶다고 가정해보자. 지금 해상도는 1920x1200으로 설정되어 있는데 해상도가 바뀐다면? 그리고 빨간 이미지의 앵커가 기본인 middle, center라면?
두 말할 것 없이 해상도가 바뀌는 순간 바로 이미지가 원하는 위치를 벗어나 버린다.
이 문제를 해결하기 위해서는 앵커를 top, left로 설정해주고 위치값을 적절하게 잡아주면 된다.
이렇게 해주면 어떤 해상도로 바뀌어도 빨간 이미지는 항상 화면 왼쪽 상단에 위치하게 된다.
두 번째 예시로는 화면 상단에 항상 저런 상단 바를 띄우고 싶을 때이다. 이런 상단 바는 모바일 게임에서 자주 사용되는 것으로 많은 개발자들이 알고 있듯이 모바일 기기는 신비하고 기괴한 해상도의 디바이스가 아주 많다. 그래서 반드시 모바일 디바이스별 해상도 대응에 신경을 써야한다.
이것 역시 UI의 앵커를 middle center로 두면 해상도가 바뀔 때마다 UI가 원하는 위치를 벗어나 버린다.
이때는 UI의 앵커를 top stretch로 설정해주고 위치를 잡아주면 된다.
이 다음에는 해상도가 변경되어도 상단바가 이상한 위치로 벗어나버리는 문제가 해결되는 것을 볼 수 있다.
스크립트에서의 렉트 트랜스폼
그럼 이제 다시 처음의 이야기로 돌아가보자. 일반적인 3D 공간에서의 게임 오브젝트의 위치를 이동시킬 때는 트랜스폼(Transform)을 이용한다. 그럼 UI 게임 오브젝트를 움직일 때는 무엇을 쓰면 좋겠는가? 그렇다! 렉트 트랜스폼(Rect Transform)이다!
using UnityEngine;
public class UIController : MonoBehaviour
{
private RectTransform rectTransform;
private void Start()
{
rectTransform = GetComponent<RectTransform>();
}
private void Update()
{
if (Input.GetMouseButtonDown(0) || Input.GetMouseButton(0))
{
rectTransform.position = Input.mousePosition;
}
}
}
UI 오브젝트에 붙어서 UI 오브젝트의 위치를 수정할 스크립트에서는 렉트 트랜스폼을 이용해야 한다. 모노비헤이비어(MonoBehaviour)를 상속받은 게임 오브젝트에는 렉트 트랜스폼 멤버 변수가 없다. 그렇기 때문에 새로운 멤버 변수를 선언하고 GetComponent<RectTransform>()으로 자신이 가진 렉트 트랜스폼 컴포넌트를 가지고 와서 사용해야 한다.
위 코드를 작성한 뒤 저장하고 에디터에서 플레이해보면 이렇게 rectTransform.position을 사용해서 UI 오브젝트를 정상적으로 움직이는 것을 볼 수 있다.
using UnityEngine;
public class UIController : MonoBehaviour
{
private RectTransform rectTransform;
private void Start()
{
rectTransform = GetComponent<RectTransform>();
}
private void Update()
{
if (Input.GetMouseButtonDown(0) || Input.GetMouseButton(0))
{
rectTransform.anchoredPosition = Input.mousePosition;
}
}
}
이 rectTransform.position 외에도 anchoredPosition을 사용해서도 UI의 위치를 옮길 수도 있다.
다만 이 경우에는 앵커의 위치에 영향을 받기 때문에 마우스의 위치를 따라가기를 원한다면 화면 좌측 하단 구석으로 앵커를 잡아주어야만 한다.
무엇이 문제인가?
사실 결과를 놓고 보면 transform.position을 이용해서 UI 오브젝트를 이동시킨 것과 rectTransfrom.postion을 이용해서 UI 오브젝트를 이동시킨 것이 결과가 똑같으니 뭘 쓰든지 상관없다고 여길 수도 있다.
사실 본인도 그런 생각이었지만, 이런 생각이 바뀐 계기가 있다. 전에 어떤 게임을 만든 적이 있는데, 그 때는 모든 UI 오브젝트를 transform.position 코드로 위치를 이동시켰다. 이것이 에디터, PC버전, 안드로이드 버전에서는 모두 정상적으로 동작했는데, 단 하나. iOS 버전 빌드에서 위치를 이동시키는 UI들이 정상적인 위치가 아닌 화면 좌측 하단 구석에 고정되는 문제가 발생했다. 당연히 이 문제로 며칠을 골머리를 앓았다. 그렇게 고통 받으며 문제를 해결하기 위해서 여러 가지 시도를 해보던 중에 rectTransform.position으로 UI 이동시키는 방법을 찾았고 그제서야 iOS 버전에서도 UI들이 정상적으로 움직이기 시작했다.
그러니 UI개발자라면 제발 렉트 트랜스폼을 애용하자. 이상한 문제를 만나기 전에...
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
UI를 구성할 때, 아무 위치에나 배치되는 경우는 거의 없다. 대부분의 UI는 미리 설계된 레이아웃에 따라서 배치된다. 대부분의 UI 혹은 메인 메뉴 같은 UI는 고정된 위치에 배치되고 그것이 추가/삭제되는 등의 변동이 실시간으로 일어나지는 않는다.
하지만 카드 수집형 게임(TCG) 같은 게임에서 자신이 보유한 카드를 보여주는 형식의 카드 인벤토리 UI를 예시로 들자면, 보유하고 있는 카드의 숫자에 따라서 보여주는 카드 UI의 숫자가 달라질 것이다. 카드를 새로 얻으면 가지고 있는 카드 UI들 끝에 새로 얻은 카드 UI가 바로 앞 카드 UI와 일정한 간격을 두고 생성되어야 한다. 그리고 카드를 이름이나 카드의 성능 등 사용자가 원하는 기준에 따라서 정렬하고자 하면 현재 보여주고 있는 카드 UI들을 기준에 맞춰 재정렬한 뒤에 보여주는 줘야한다. 이렇듯이 고정된 UI와 달리 실시간으로 UI를 추가/삭제하고 순서를 변동하는 작업을 필요로 한다.
실시간 카드 추가/제거 및 정렬을 위한 기능을 수동으로 직접 구현 한다면 상당히 많은 작업을 해야하고 시간 역시 많이 소모될 것이다. 이런 UI의 위치를 자동으로 맞춰주는 기능을 구현하는데 소모되는 시간을 줄여주기 위해서 유니티 엔진에서 제공하는 기능이 바로 레이아웃 그룹(Layout Group)이다.
『성능 최적화를 위해서는 사실 해당 기능을 직접 구현하는 것이 좋다. 레이아웃 그룹의 성능 문제는 본 포스트의 제일 하단에 언급되어 있다.』
레이아웃 그룹(Layout Group)
레이아웃 그룹은 UI를 자동으로 정렬하는 컴포넌트이다. 이 컴포넌트의 종류로는 수직 레이아웃 그룹(Vertical Layout Group), 수평 레이아웃 그룹(Horizontal Layout Group), 그리드 레이아웃 그룹(Grid Layout Group)이 있다.
수직 레이아웃 그룹(Vertical Layout Group)
수직 레이아웃 그룹은 주로 리스트 형식으로 UI들을 보여줄 때 사용된다.
수직 레이아웃 그룹 컴포넌트를 사용하면 위의 이미지와 같이 하이어라키에서 자식 게임오브젝트로 들어온 UI들이 수직으로 자동 정렬된다. 이 때 캔버스에 표시되는 순서는 하이어라키에 표시된 순서와 같다.
하이어라키 창에서 Vertical Layout Group 게임오브젝트 아래에 있는 Image 게임오브젝트를 복사하면 복사/생성된 이미지 UI 게임오브젝트들이 자동으로 정렬되는 것을 확인할 수 있다.
수직 레이아웃 그룹의 프로퍼티는 위의 이미지에서 볼 수 있듯이 패딩(Padding), 스페이싱(Spacing, 간격), 차일드 얼라인먼트(Child Alignment, 자식 정렬), 컨트롤 차일드 사이즈(Control Child Size, 자식 크기 조절), 유즈 차일드 스케일(Use Child Scale, 자식 크기 사용), 차일드 포스 익스팬드(Child Force Expand, 자식 강제 확장)가 있다.
패딩(Padding)
콘텐츠 사이즈 피터를 사용하면 패딩 프로퍼티에 대해서 더 잘 이해할 수 있다. 좌 우 위 아래의 패딩 값을 조절을 하면 Vertical Layout Group 게임 오브젝트의 넓이와 높이가 늘어나며 Vertical Layout Group 게임오브젝트 아래에 있는 자식 게임오브젝트들을 감싸는 공간이 생기는 것을 확인할 수 있다.
스페이싱(Spacing)
스페이싱 프로퍼티는 자식 게임오브젝트 사이의 간격을 의미한다.
차일드 얼라인먼트(Child Alignment)
차일드 얼라인먼트는 수직 레이아웃 그룹 컴포넌트가 부착된 게임오브젝트 내부에서 어느 위치를 중심으로 콘텐츠들을 정렬할 것인가를 의미한다. 위의 이미지에서도 볼 수 있듯이 회색 사각형은 Vertical Layout Group 게임오브젝트의 영역인데, 차일드 얼라인먼트의 값에 따라서 차일드 게임 오브젝트들의 위치가 변하는 것을 확인할 수 있다.
컨트롤 차일드 사이즈(Control Child Size)
컨트롤 차일드 사이즈 프로퍼티는 단독으로는 큰 의미를 가지지 않는다.
하지만 위의 움직이는 이미지에서 볼 수 있듯이 컨트롤 차일드 사이즈 프로퍼티만 단독으로 사용할 때는 아무런 반응이 없었지만 차일드 포스 익스팬드 프로퍼티와 함께 사용하면 레이아웃 그룹 컴포넌트가 부착된 게임오브젝트의 사이즈만큼 하위 UI들의 크기가 커지는 것을 확인할 수 있다.
혹은 레이아웃 그룹의 하위에 속하는 요소들이 레이아웃 엘리먼트(Layout Element, 레이아웃 요소) 컴포넌트를 가지는 경우에도 의미를 가지고 동작한다.
위의 움직이는 이미지에서 레이아웃 엘리먼트와 레이아웃 그룹의 상호작용을 볼 수 있는데 컨트롤 차일드 사이즈를 넓이 옵션만 활성화 한 뒤, 레이아웃 엘리먼트의 Preferred Width와 Preferred Height를 둘 다 활성화하고 변경했지만, 넓이만 변경되는 것을 확인할 수 있다.
차일드 스케일 사용(Use Child Scale)
차일드 스케일 사용 프로퍼티는 하위의 UI들을 정렬할 때, 차일드 게임 오브젝트의 스케일 값을 사용할 것인가를 정한다.
위의 예시 이미지를 보면 차일드 스케일 사용 프로퍼티를 켜기 전에는 자식 오브젝트의 크기가 바뀌어도 정렬 위치 자체는 그대로인 반면에 차일드 스케일 사용 프로퍼티를 켜면 자식 오브젝트의 크기에 따라서 정렬 위치가 바뀌는 것을 확인할 수 있다.
차일드 강제 확장(Child Force Expand)
차일드 강제 확장 프로퍼티는 컨트롤 차일드 사이즈 프로퍼티 설명에서 봤듯이 자식 오브젝트의 크기를 레이아웃 그룹 컴포넌트가 부착된 게임 오브젝트의 크기에 맞춰서 강제로 늘어나게 만드는 옵션이다.
수평 레이아웃 그룹(Horizontal Layout Group)
수평 레이아웃 그룹은 자기 밑에 속한 자식 UI 오브젝트들을 수평으로 정렬한다. 그리고 수평 레이아웃 그룹 컴포넌트가 가진 프로퍼티는 수직 레이아웃 프로퍼티가 가진 것과 동일하며 그 기능 역시 같다.
그리드 레이아웃 그룹(Grid Layout Group)
그리드 레이아웃 그룹은 하이어라키 뷰에서 자식으로 속한 UI 게임 오브젝트들을 바둑판식으로 정렬한다. 그리드 레이아웃이 가지는 프로퍼티는 패딩(Padding), 셀 크기(Cell Size), 시작 코너(Start Corner), 시작 축(Start Axis), 차일드 얼라인먼트(Child Alignment), 제약(Constraint, 콘스트래인트)가 있다.
우선 패딩과 차일드 얼라인먼트 프로퍼티는 위의 수직/수평 레이아웃 그룹이 가지는 프로퍼티와 같은 기능이다.
셀 크기(Cell Size)
셀 크기 프로퍼티는 그리드 레이아웃 그룹에 속하는 UI들의 크기를 지정해주는데 사용된다.
시작 코너(Start Corner)
시작 코너 프로퍼티는 자식 UI를 정렬될 때 시작 위치를 정하는 기능이다. 왼쪽 위(Upper Left), 오른쪽 위(Upper Right), 왼쪽 아래(Lower Left), 오른쪽 아래(Lower Right)로 설정할 수 있으며 위치를 제대로 잡기 위해서는 차일드 얼라인먼트와 함께 사용하는 것이 좋다.
시작 축(Start Axis)
시작 축은 자식 UI를 정렬할 때, 수직으로 먼저 정렬할 것인지, 수평으로 먼저 정렬할 것인지를 정하는 옵션이다. 기본 설정은 수평이며, 수직으로 변경하면 새로 생겨난 UI는 아래쪽 행으로 추가 되며 레이아웃 그룹 컴포넌트가 부착된 게임 오브젝트의 가장 아래쪽 행까지 채우고 나면 그 다음 옆에 열을 추가하는 방식으로 정렬된다.
제약(Constraint)
그리드 레이아웃의 제약 프로퍼티는 기본적으로 플랙시블, 즉 유연성있는 상태로 설정되어 있는데 이것은 위의 이미지와 같이 2x2, 3x3, 4x4 형태로 정사각형의 정렬된다. 그리고 해당 NxN의 레이아웃이 수용할 수 있는 UI의 갯수를 넘어가면 N+1xN+1 행렬로 자동으로 확장된다.
이렇게 자동으로 행렬 모두가 확장되는 방식은 일반적인 UI에서는 쉽게 사용되지 않는다. 대부분의 경우에는 행이나 열 중 하나는 갯수를 고정시켜두고 추가하는 방식을 사용한다.
제약 프로퍼티를 Fixed Column Count로 선택하면 첫 번째 이미지처럼 열의 갯수를 고정시킨 채로 행을 추가해 나갈 수 있고, Fixed Row Count로 설정하면 두 번째 이미지처럼 행의 갯수를 고정시킨 채로 열을 추가해 나갈 수 있다.
정리
레이아웃 그룹은 이렇게 동적으로 추가/제거되는 UI를 정렬하기에 좋은 컴포넌트이다. 하지만 동적이지 않은 UI더라도 일정한 간격을 두고 배치되는 UI라면 번거롭게 위치를 일일이 계산해서 배치하는 것보다 빠르게 작업할 수 있게 도와준다.
조금 늦게 알게된 사실이지만 최적화를 위해서는 레이아웃 그룹의 사용을 자제해야 된다는 유니티 최적화 팁이 있다. 해당 내용은 레이아웃 그룹 내에서 하나 이상의 자식 요소가 변경되면 레이아웃 시스템이 변경된 것으로 인식해서 레이아웃 그룹 내의 각 UI 요소 1개마다 최소 1회의 GetComponents 호출을 수행한다고 한다. 단순 GetComponents 호출이 아닌 연속적인 GetComponents 호출이 성능에 얼마나 악영향을 끼치는지는 대부분의 개발자들 역시 인지하고 있을 것이다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
UI를 만들 때, 한 UI 창에 텍스트, 이미지, 버튼, 체크박스 등 수많은 구성요소들이 들어간다. 하나의 UI 창을 컨트롤 한다는 것은 이 UI 창 아래에 들어가는 구성요소들을 한꺼번에 통제해야 한다는 것을 의미한다.
위 이미지와 같은 UI 창이 있고, 이 창이 열리거나 닫힐 때, 투명도를 사용해서 투명해지는 연출을 사용한다고 가정했을 때, 일반적으로는 UI에서 이미지나 텍스트를 표현하는 모든 컴포넌트의 색상 값 중에 알파 값을 일일이 수정해주어야 한다. 이 작업은 UI 창의 구성이 복잡해질 수록 더욱 귀찮고 힘든 작업이 되며 이런 작업을 해놓은 다음에 UI의 구성이 바뀌기라도 하면 더 큰 문제가 발생한다.
이러한 문제를 해결해 주는 것이 바로 캔버스 그룹(Canvas Group) 컴포넌트다.
캔버스 그룹(Canvas Group)
캔버스 그룹 컴포넌트를 사용하기 위해서는 하나의 그룹으로 하고자하는 UI의 최상단 게임 오브젝트를 선택하고 인스펙터 창의 [Add Component] 버튼을 눌러 Canvas Group를 검색하여 추가하면 된다.
그렇게 캔버스 그룹을 추가하면 위의 이미지와 같은 캔버스 그룹 컴포넌트가 생성된다. 캔버스 그룹 컴포넌트는 많은 기능을 가지고 있지 않고 간단한 기능 몇 가지만 제공한다. 하지만 이것들만으로도 원래라면 손이 많이 가는 작업들을 크게 줄여준다.
알파 값 조정
캔버스 그룹의 첫 번째 주요 기능은 하위 그룹의 UI들의 알파 값을 한꺼번에 조절할 수 있게 해주는 것이다.
위 이미지를 보면 아까 전의 예시에서는 UI 구성요소들의 알파 값을 일일이 수정해주던 것에서 캔버스 그룹의 알파 값만 수정해주면 되는 것으로 바뀌었다.
캔버스 그룹으로 알파 값을 조정하는 방법의 최대의 장점은 그룹 아래의 UI 구조가 어떤 식으로 바뀌어도 그 밑에 있는 모든 UI에 자동으로 적용이 된다는 것이다.
상호작용가능함(Interactable)
두 번째 옵션은 상호작용에 관한 것이다. UI에는 상호작용이 가능한 종류의 컴포넌트인 버튼(Button), 토글(Toggle), 슬라이더(Slider) 등이 있는데, 이런 컴포넌트들은 기본적으로 상호작용에 대한 옵션을 가진다. 그 옵션이 바로 상호작용가능함(Interactable)이다.
이것들 역시 캔버스 그룹 없이 한꺼번에 제어하고자 한다면, 각각의 컴포넌트에 일일이 접근하여서 값을 수정해주어야 한다.
하지만 캔버스 그룹의 상호작용가능함 옵션을 사용하면 하위에 있는 모든 상호작용가능한 컴포넌트들이 제어되는 것을 확인할 수 있다.
레이캐스트 블록(Blocks Raycasts)
레이캐스트는 일종의 광선을 의미하는데, 일반적으로 마우스를 클릭한 화면 위치에서 게임 속 공간에 레이저를 쏴서 클릭한 위치를 찾아내는 역할을 하는 데에 주로 사용되며, 이를 응용해서 주로 RPG 게임에서 클릭한 위치로 캐릭터를 이동시키는데 사용하게 된다.
UI에서 레이캐스트를 블록, 즉 레이캐스트를 막는다는 것의 의미는 첫 번째로, UI가 입력을 받아들인다는 뜻이다.
위의 gif 이미지를 보면, 입력을 받아들인다는 뜻을 이해할 수 있다. Blocks Raycasts를 켰을 때는 레이캐스트가 UI에 막혀서 입력을 받을 수 있게 되고, 반대로 꺼졌을 때는 입력을 받아들이지 못한다.
그렇다면 여기서 위의 상호작용가능함 옵션과 관련해서 어떤 차이가 있느냐는 질문을 할 수가 있다. 둘 다 똑같이 입력을 못받게 되는데 다른게 없지 않은가? 물론 이 두 개의 옵션은 완전히 다른 옵션이다.
상호작용가능함 옵션의 예시 gif에서는 상호작용가능함 옵션이 꺼지면서 버튼, 토글, 슬라이드가 회색으로 변하고 버튼, 토글, 슬라이드와의 상호작용이 불가능하게 바뀌었지만 레이캐스트, 즉 마우스가 클릭될 때 발사되는 눈에 보이지 않는 광선은 그대로 UI에 충돌하는 상태였다.
하지만 레이캐스트 블록 옵션의 예시 gif에서는 마우스가 클릭될 때 발사되는 광선이 UI를 무시하고 지나간 것이다.
레이캐스트 블록 옵션의 꺼진 상태와 켜진 상태의 차이점과 활용에 대한 예시는 디아블로 3로 들 수 있다. 디아블로 3에서는 탭(tab) 키를 누르면 미니맵이 열리는데 미니맵 UI가 화면 전체에 가득 차서 흐릿하게 보일 것이다. 하지만 이 미니맵은 화면 전체를 덮는 UI임에도 불구하고 클릭한 위치로 캐릭터를 이동할 수 있게 마우스의 클릭에서 발사되는 레이캐스트를 막지 않는다.
하지만 인벤토리 창의 경우에는 인벤토리 찾 어느 위치를 클릭해도 캐릭터가 인벤토리 창 너머로 클릭된 지형의 위치로 이동하지 않는다. 즉, 마우스 클릭에서 발사된 레이캐스트가 인벤토리라는 UI에 막혀서 이동할 위치를 찾지 못한 것이다.
마지막 옵션인 부모 그룹 무시(Ignore Parent Group)은 잘 사용되지 않는 옵션이다.
이렇듯이 캔버스 그룹을 사용하면 원래는 간단하지만 계층이 복잡해지면 어려워지는 작업을 간단하게 처리할 수 있다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
