베르의 프로그래밍 노트

UI 비법서 (7) 

- 

Button 컴포넌트

작성 기준 버전 :: 2019.2

[이 포스트의 내용은 유튜브 영상으로도 시청하실 수 있습니다.]

아마 게임을 하면서 플레이어와 제일 많은 상호작용을 하는 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을 끄는 방법으로 실제 버튼 이미지보다 작은 영역만 클릭 가능하게 만드는 것도 가능하다.

버튼 이미지보다 작은 영역에 터치를 받는 테크닉은 잘 사용되지 않을 것 같지만 버튼 이미지 리소스 외곽에 그림자나 글로우가 들어간 경우에 글로우 영역이나 그림자 영역을 제외하고 실제 버튼 영역에만 클릭을 받기 위해서 사용되는 경우가 종종 있다.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

UI 비법서 (6) 

- 

Image 컴포넌트

작성 기준 버전 :: 2019.2

[이 포스트의 내용은 유튜브 영상으로도 시청하실 수 있습니다]

이번 포스트에서는 유니티 UI의 기본이 되는 Image 컴포넌트에 대해서 알아보자.

2D Sprite 패키지

유니티에서 UI와 관련된 기능을 제대로 사용하기 위해서는 2D Sprite 패키지를 설치해야 한다.

2D Sprite 패키지를 임포트하기 위해서 상단 메뉴바에서 [Window > Package Manager]를 선택하고 패키지 매니저를 연다.

잠시 기다리면 설치 가능한 패키지 전체가 나올 텐데, 만약 곧바로 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로 변경된다.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

UI 비법서 (5) 

- 

캔버스의 분할

작성 기준 버전 :: 2019.2

유니티에서 모든 UI는 캔버스(Canvas) 위에서 그려진다. 아직 유니티 엔진을 이용한 개발에 익숙하지 못한 개발자들은 모든 UI를 한 캔버스에 만드는 경우가 많다.

하지만 모든 UI를 한 캔버스로 몰아넣으면 모든 UI를 그리는 과정에서 불필요한 낭비가 발생하게 된다.

[그림 1]을 보면 하나의 캔버스 안에 여러 개의 이미지가 포함되어 있는 것을 볼 수 있다. Checker 오브젝트는 흰 색과 검은 색으로 이루어진 이미지이고, 그 뒤에 Background Slide라는 이름의 회색 이미지가 크게 배치되어 있다.

우선 이 상태에서 UI는 어떤 과정을 통해서 그려지는지 확인하기 위해서 프레임 디버거(Frame Debugger)를 실행해보자. 프레임 디버거는 게임에서 각 프레임이 그려질 때 어떤 과정을 거쳐서 그려지는지 보여주는 디버깅 툴이다. 이것을 통해서 어떤 렌더링 과정에서 시간을 소모하는지를 확인할 수 있는 좋은 도구이다. 프레임 디버거를 실행하기 위해서는 유니티 상단 메뉴에서 [Windows > Analysis > Frame Debugger]를 선택하면 된다.

그러면 [그림 3]과 같은 프레임 디버거 창이 열린다.

프레임 디버거 창을 띄운 후, 플레이를 시작하고 프레임 디버거 창의 Enable 버튼을 누르면 한 프레임이 그려지는데 어떤 과정으로 몇 단계나 거쳐서 실행되는지 확인할 수 있다.

이 상태에서 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 오브젝트에 위와 같은 코드를 추가해서 이미지가 계속해서 채워졌다가 사라지는 동작을 반복하도록 만들어보자.

코드를 모두 작성했다면 Background Slide 게임 오브젝트에 컴포넌트로 붙여준다.

이것을 실행해보면 [그림 7]와 같이 보여진다. 하지만 단순히 겉으로만 보이는 상황으로는 어떤 낭비가 발생하는지 알 수 없다. 그러면 어떤 낭비가 발생하는지 확인하기 위해서 다시 프레임 디버거로 살펴보자.

프레임마다 분명 7단계였던 렌더링 과정이 회색 이미지가 체커와 겹치게 되면서 8단계로 늘어나는 것을 볼 수 있다.

이 8단계로 늘어난 렌더링 과정을 살펴보면 7단계일 때는 분명 회색 바탕을 먼저 그리고 체크 무늬 이미지를 그렸던 과정이 회색 바탕과 겹치지 않은 체크 무늬 이미지를 그리는 과정, 회색 바탕 이미지를 그리는 과정 그리고 회색 바탕과 겹친 체크 무늬 이미지를 그리는 과정으로 나누어진 것을 볼 수 있다. 이것은 렌더링 과정이 아주 작게 늘어난 예시로, UI 캔버스의 구조가 복잡해지면 복잡해질 수록 어떤 성능의 낭비를 가져올지 알 수 없게 된다.

이것을 해결하기 위한 방법이 바로 이번 글의 주제인 캔버스의 분할이다.

[그림 10]을 보면 매 프레임 변동이 발생하는 Background Slide와 늘 고정되어 있는 Checker를 다른 캔버스로 나누어 배치한 것을 볼 수 있다.

이렇게 캔버스를 분할한 뒤 다시 실행해서 매 프레임의 렌더링 단계를 살펴보면 다시 7단계로 줄어든 것을 확인할 수 있다.

렌더링 단계 역시 살펴보면 회색 바탕을 먼저 그리고 회색 바탕과 체크 무늬 이미지가 겹치는 것과 상관없이 한꺼번에 체크 무늬 이미지를 그리는 것을 볼 수 있다.

이렇게 캔버스를 분할하는 것 역시 렌더링 최적화를 위한 하나의 방법이 될 수 있다. 가능하면 변동되는 타이밍이 비슷한 UI끼리 그룹을 지어서 캔버스로 묶는 것이 좋다.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

UI 비법서 (4) 

- 

UI 개발자라면 제발 Rect Transform 애용합시다!

작성 기준 버전 :: 2019.1-2019.2

[이 포스트의 내용은 유튜브 영상으로도 시청하실 수 있습니다]

유니티 개발을 처음으로 공부하는 개발자들은 기본적으로 게임 오브젝트의 위치를 이동시키는 코드를 작성하려고 할 때, 제일 먼저 떠올리는 코드는 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개발자라면 제발 렉트 트랜스폼을 애용하자. 이상한 문제를 만나기 전에...

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

UI 비법서 (2)

-

하나의 그룹 Canvas Group

작성 기준 버전 :: 2019.1.4f1

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)은 잘 사용되지 않는 옵션이다.

이렇듯이 캔버스 그룹을 사용하면 원래는 간단하지만 계층이 복잡해지면 어려워지는 작업을 간단하게 처리할 수 있다.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

UI 비법서 (1)

당신의 레이아웃에 딱맞는 Content Size Fitter

작성 기준 버전 :: 2018.3 -2019.4

[이 포스트의 내용은 유튜브 영상으로도 시청하실 수 있습니다]

UI를 제작할 때, 보기 좋은 레이아웃을 만들어 내는 일은 매우 어렵다. 어렵사리 보기 좋은 레이아웃을 만들어 냈다고 해도 UI에 들어가는 내용의 크기가 바뀔 수 있는 상황이라면 정해진 텍스트나 이미지 등의 콘텐츠가 정해진 레이아웃을 벗어나는 경우가 쉽게 발생한다.

이러한 유동적인 상황에 대처하는 UI를 만드는 것은 이전까지는 스크립트에서 일일이 처리해야하는 번거로움이 있었다. 그런 번거로움을 해소하기 위한 기능으로 유니티는 콘텐츠 사이즈 피터(Content Size Fitter)라는 컴포넌트를 지원한다. 이 컴포넌트를 이용해서 콘텐츠의 크기에 따라 자유롭게 변화하는 UI를 제작하는 방법에 대해서 알아보도록 하자.

콘텐츠 사이즈 피터(Content Size Fitter)

콘텐츠 사이즈 피터는 단어 그대로 컴포넌트가 붙어있는 오브젝트의 크기를 내용물, 콘텐츠의 크기에 맞게 만들어주는 역할을 한다.

콘텐츠 사이즈 피터 컴포넌트를 게임 오브젝트에 추가하는 방법은 위의 이미지처럼 씬에서 Add Component 버튼을 누르고 "Content"를 검색해서 나오는 Content Size Fitter 컴포넌트를 선택하는 것이다.

콘텐츠 사이즈 피터를 사용하지 않으면 위의 이미지처럼 내용이 UI의 사이즈보다 커지면 옵션에 따라 뒷 부분이 잘리거나 영역을 넘어가서 표시되는 바람에 다른 UI를 침범하는 문제가 발생한다.

콘텐츠 사이즈 피터를 사용하면 전과 다르게 UI의 사이즈가 텍스트의 내용에 따라 자동으로 변하는 것을 확인할 수 있다.

추가된 콘텐츠 사이즈 피터는 인스펙터 뷰에서 위의 이미지와 같은 모습으로 보이며, Horizental Fit과 Vertical Fit라는 두 가지 프로퍼티를 설정할 수 있다.

선택 가능한 옵션으로는 Unconstrained, Min Size, Preferred Size 이렇게 세 가지가 있다. Unconstrained는 UI의 크기를 콘텐츠에 맞추지 않는 옵션으로 UI의 크기를 직접 맞추거나 고정된 크기를 사용해야 하는 경우 사용하면 되는 옵션이다. Min Size는 레이아웃 요소의 최소 크기를 기준으로 UI의 크기를 맞추는 옵션인데, 이 옵션의 경우에는 단독으로 사용되는 경우는 거의 없고 Layout group 계열의 컴포넌트와 함께 주로 사용된다. 마지막으로 Preferred Size 옵션은 기본적인 콘텐츠의 크기에 따라 UI의 크기를 맞추는 옵션으로 위의 예시 이미지처럼 텍스트나 이미지에 단독으로 콘텐츠 사이즈 피터를 사용하는 경우에 주로 사용된다.

콘텐츠 사이즈 피터와 피봇

콘텐츠 사이즈 피터로 인해 Rect Transform의 크기가 변경될 때는 UI의 피벗을 중심으로 조정되기 때문에, 피벗을 사용해서 UI의 크기가 조정되는 방향을 조절할 수 있다. 위의 이미지 중에서 콘텐트 사이즈 피터를 붙인 gif를 보면 피벗이 UI의 중심에 있어서 피벗을 중심으로 양 쪽 방향을 향해서 UI가 커지는 것을 볼 수 있다.

위의 이미지를 보면 X Pivot을 0으로 변경해서 UI의 피봇을 가장 좌측으로 옮긴 결과, UI의 트랜스폼이 왼쪽에서 오른쪽으로 확장되는 것을 볼 수 있다.

콘텐츠 사이즈 피터와 스크롤 뷰(Content Size Fitter & Scroll View)

콘텐츠 사이즈 피터를 가장 잘 응용할 수 있는 부분은 바로 스크롤 뷰이다. 이전에 스크롤 뷰에 대해서 설명했던 글에서는 스크롤 뷰에 들어가는 내용에 따라서 Content 오브젝트의 크기를 맞춰주는 방법을 스크립트로 설명했지만 콘텐츠 사이즈 피터를 사용하면 스크립트를 작성하지 않고도 훨씬 편하게 Content 오브젝트의 크기를 맞출 수 있다.

이제 콘텐츠 사이즈 피터를 사용해서 스크롤 뷰의 Content의 크기를 조절하는 방법을 알아보자.

우선 (200, 200) 사이즈의 스크롤 뷰를 생성한다.

그리고 스크롤 뷰의 Content 오브젝트 아래에 (150, 50) 사이즈의 이미지를 하나 만들어주자.

콘텐츠 사이즈 피터가 없는 상태에서 플레이 버튼을 눌러서 실행해보면 스크롤 뷰의 크기는 이미지의 크기나 갯수에 상관없이 동작하는 것을 확인할 수 있다.

다음에는 이 스크롤 뷰에 콘텐츠 사이즈 피터를 적용해보자.

우선 아이템들이 들어갈 Content 오브젝트를 선택하고 여기에 오브젝트들을 자동으로 정렬해주는 Vertical Layout Group 컴포넌트를 추가한다.

원하는 정렬 방법에 따라 Grid Layout Group이나 Horizontal Layout Group을 사용해도 된다. 각 프로퍼티의 값은 보기 좋아보이는 값을 찾아서 입력하도록 하자. 이 예시에서는 위 아래의 패딩을 10씩 주고 각 아이템 간의 간격을 5로 설정했다. 그리고 아이템의 정렬은 상단 중앙으로 설정했다.

그 다음에 내용물에 따라 오브젝트의 크기를 조정해주는 콘텐츠 사이즈 피터 컴포넌트를 추가한 뒤에 사용한 Layout Group에 맞게 Fit 옵션을 Min Size로 변경한다.

스크롤 뷰에 콘텐츠 사이즈 피터와 레이아웃 그룹을 적용하고 플레이를 해보면 아이템이 추가/제거됨에 따라서 자연스럽게 내부 Content의 크기가 늘어나서 스크롤이 가능하게 되는 것을 확인할 수 있다.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]

ScrollView 사용법

작성 기준 버전 :: 5.4 - 2019.4

게임에서 UI 창보다 크거나 많은 내용이 들어가는 콘텐츠를 UI 안에 담기 위해서 사용하는 방법은 여러가지가 있다. 그 중에 대표적인 방법이 바로 버튼 같은 것을 이용해서 페이지를 넘기는 것이고 또 하나는 스크롤을 이용해 UI 내에서 이동하면서 볼 수 있는 스크롤 뷰이다. 이 두 가지의 방법 중에서 어떤 것을 사용할 것인지 결정하는 차이점은 내 개인적인 생각이지만 바로 '연속성'이라는 것이다.

UI에 들어가는 콘텐츠가 연속적이지 않고 흐름이 끊어져도 상관 없다면 페이지 방식을 사용하는 것이 좋고, 들어가는 콘텐츠가 커다란 하나의 것이거나 연속적인 면이 중요해서 연결되어져야 한다면 스크롤 뷰 방식이 적당할 것이다.

이런 스크롤 뷰 방식은 스스로 직접 구현하려면 상당히 귀찮은 면이 많겠지만 유니티 엔진의 UGUI에서는 이미 스크롤 뷰를 지원하고 있다. 그래서 간단한 클릭 몇 번만으로도 스크롤 뷰를 뚝딱하고 만들 수 있다.

Hierachy 뷰에서 우클릭을 UI 메뉴에서 Scroll View를 선택하면 스크롤 뷰가 생성된다.

스크린샷과 같은 형태로 스크롤 뷰가 생성되는데 내용을 하나씩 살펴보자면.

Scroll View :: 우리가 생성한 스크롤 뷰

Viewport :: 표시하고자 하는 콘텐츠가 보여질 곳

Content :: 표시하고자 하는 내용물

Scrollbar Horizontal :: 수평 스크롤바

Scrollbar Vertical :: 수직 스크롤바

를 나타낸다. 스크롤 뷰를 원하는 형태로 수정하기 위해서는 Hierachy에서 Scroll View를 선택하고 Inspector 창을 보면 스크롤 뷰에 대한 옵션을 볼 수 있다.

스크롤 뷰의 옵션들은 Scroll Rect라는 Component에 대부분 포함되어 있다.

Horizontal :: 스크롤 뷰의 수평 이동을 허용할 것인가?

Vertical :: 스크롤 뷰의 수직 이동을 허용할 것인가?

Movement Type :: 스크롤 이동 타입(세 가지가 있다.)

Unrestricted - 콘텐츠가 스크롤 밖으로 나가도 조금도 제한하지 않는다.

Elastic - 콘텐츠가 스크롤 밖으로 나가면 정해놓은 값(Elasticity)만큼의 속도로 스크롤 뷰 안으로 돌아온다.

Clamped - 콘텐츠가 스크롤 밖으로 나가지 못하게 완전히 제한한다.

Inertia :: 관성. 이 값을 켜두면 스크롤을 끌다가 놓으면 바로 정지하지 않고 끌던 속도가 점점 감소하며 멈춘다.

Scroll Sensitivity :: 스크롤 민감도

Horizontal Scrollbar :: 수평 스크롤바

Visibility - 스크롤바가 보이는 방식(항상 보이는 방식인지 콘텐츠의 크기에 따라 보이는 방식인지를 설정할 수 있다.)

(수직 스크롤바 역시 같은 내용이다.)

이 다음으로 다뤄야하는 내용은 바로 콘텐츠이다.

바로 뷰포트 밑에 있는 Content 라는 게임 오브젝트인데, UI에서 보여주고자 하는 내용들은 모두 이 Content 오브젝트의 자식 오브젝트로 배치해야한다. 그리고 이 Content의 크기에 따라 스크롤 뷰의 크기가 결정된다. 그리고 초기 상태는 top, stretch 상태로 설정되어서 크기 값이 Right, Height로 되어있는데 좀더 직관적인 값인 Width, Height로 보기 위해서 top, left 상태로 바꿔주는 것을 추천한다.

현재 설정된 Width 583, Height 300이라는 크기를 Scene에서 보면 아래와 같은 크기이다.

게임을 제작할때 필요한 스크롤 뷰의 크기에 맞춰서 잘 조절해 주어야 한다. 다만 고정된 크기의 스크롤 뷰라면 Inspector 창에서 크기를 직접 조절해도 상관은 없지만 만약 아이템의 갯수와 같은 요소를 통해서 보여져야하는 스크롤 뷰의 크기가 달라져야 한다면 스크립트를 통해서 Content의 크기를 조절하는 방법도 알아둬야 한다.

우선 스크롤 뷰를 쉽게 가져오기 위해서 스크롤 뷰를 가진 오브젝트에 스크립트를 추가한다.

그리고 추가한 스크립트를 통해 다음과 같은 코드를 작성하면 된다.

ScrollView의 Content 크기를 조절하는 스크립트

using UnityEngine;
using UnityEngine.UI;   // UI와 관련된 스크립트 작업을 위해서 추가해 주어야 한다.
using System.Collections;

public class ScrollViewPractice : MonoBehaviour
{
    // 스크롤 뷰와 관련된 수정을 하기 위해 가지고 있는 변수
    ScrollRect scrollRect;

    // Use this for initialization
    void Start ()
    {
        scrollRect = GetComponent<ScrollRect>();    // 게임 오브젝트가 가지고 있는 ScrollRect를 가져온다.

    }
   
    void SetContentSize()
    {
        float width = 100.0f;
        float height = 100.0f;
        // scrollRect.content를 통해서 Hierachy 뷰에서 봤던 Viewport 밑의 Content 게임 오브젝트에 접근할 수 있다.
        // 그리고 sizeDelta 값을 통해서 Content의 높이와 넓이를 수정할 수 있다.
        scrollRect.content.sizeDelta = new Vector2(width, height);
    }
}

위의 코드를 적절히 응용하면 아이템 개수에 따라, 혹은 원하는 크기로 Content의 크기를 조절할 수 있다.

[유니티 어필리에이트 프로그램]

아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.

[투네이션]

[Patreon]

[디스코드 채널]