베르의 프로그래밍 노트

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]

[디스코드 채널]

싱글플레이 게임을 멀티플레이 게임으로 

발전시켰을 때 적 AI가 플레이어를 

인식하지 못하는 문제

UNet Tutorial (13) - 네트워크 애니메이터(Network Animator) 글에 달아주신 myouzing님의 질문 댓글에 대한 답변입니다. 질문의 내용은 다음과 같습니다.

질문의 내용으로는 싱글플레이 FPS 게임을 만드시다가, UNet을 이용해서 그 게임을 멀티플레이로 발전시켰을 때, 적 AI가 플레이어를 인식하지 못하는 것으로 보입니다. 

질문 댓글의 내용이 간략하고 자세한 정황과 멀티플레이 설계가 어떻게 되어있는지 알 수 없기 때문에 완전한 해결책은 알려드리기 어려울 것 같습니다. 하지만 증상을 미루어보아 짐작했을 때, 의심이되는 상황이 있습니다.

의심이 되는 부분은 서버와 클라이언트에서 양 측에 적 AI 오브젝트와 플레이어 오브젝트가 둘 다 정상적으로 네트워크 오브젝트로서 생성되어 있는가 하는 부분입니다. 예를 들어 서버와 클라이언트에 적 AI가 생성되어 동기화 되고 있는데 플레이어 오브젝트가 클라이언트에서만 생성되서 서버에서는 생성되지 않은 경우라면, 클라이언트의 플레이어가 적 AI에게 다가가도 서버 측의 적 AI가 보았을 때는 주변에 아무도 없기 때문에 플레이어를 인식하지 못하는 경우가 발생할 수 있습니다.

그 외에도 기본적인 문제로 신텍스 에러가 발생하지 않더라도 플레이하는 도중에 Null Reference나 Missing Reference 같은 오류가 발생한다면 코드가 진행하다가 멈추기 때문에 로그를 잘 확인해보셔야 할 것 같습니다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Tutorial (7)

애니메이션

작성 기준 버전 :: 2018.3.2f1

[튜토리얼의 내용을 유튜브 영상을 통해서도 확인하실 수 있습니다.]

게임에서 캐릭터가 어떠한 동작도 하지 않고 가만히 멈춘 채로 플레이어가 입력하는 대로 움직이가만 한다면 그 게임은 과연 어떤 느낌일까? 아마 그것은 굉장히 기괴한 모습이거나, 게임이 완성되지 못한 느낌일 것이다. 이렇듯이 애니메이션은 게임에 생동감을 불어넣는 중요한 요소이다.

메카님(Mecanim)

유니티에서 지원하는 애니메이션 시스템을 유니티 측에서는 메카님이라고 이름을 붙였다. 이 메카님 시스템은 기본적인 애니메이션 기능은 물론 애니메이션 레이어, 애니메이션 블렌드, 애니메이션 리타게팅 등의 다양한 기능을 제공한다. 애니메이션과 관련된 고급 기능들은 이후에 다른 섹션을 통해서 알아보도록 하고 이번 섹션에는 메카님 시스템의 기초적인 애니메이션 기능을 알아보도록 하자.

애니메이션 클립과 애니메이터 컨트롤러(Animation Clip & Animator Controller)

유니티의 애니메이션 시스템은 해당 오브젝트가 어떻게 움직여야 하는지에 대한 정보들이 포함된 애니메이션 클립과 플로우 차트와 같은 방식으로 애니메이션 클립들을 구조화하여 현재 어떤 클립이 재생되어야 하고 언제 애니메이션이 변경되어야 하는지 등을 추적하는 상태머신 형태의 애니메이터 컨트롤러로 이루어진다.

애니메이터 컨트롤러와 애니메이션 클립의 아이콘 형태는 다음과 같다.

애니메이션 클립을 만드는 방법은 크게 두 가지가 있다. 첫 번째는 3ds Max나 Maya 같은 외부의 프로그램으로 애니메이션을 만들어서 임포트 하는 것이고, 다른 하나는 유니티에서 직접 애니메이션 키를 잡아서 클립을 만드는 것이다.

3ds Max 같은 외부 프로그램에서 애니메이션을 만들어서 임포트하는 방식은 3D 모델링의 애니메이션을 만들고자 할 때 주로 사용하며 유니티 엔진에서 직접 키를 잡아서 애니메이션 클립을 만드는 것은 비교적 간단한 애니메이션이나 UI 애니메이션을 만들고자 할 때 사용하는 빈도가 높다.

외부에서 만든 애니메이션 임포트하기

우선은 외부에서 만들어진 애니메이션을 임포트하는 방법을 배워보자. 연습용 애니메이션은 위의 첨부파일을 다운로드 받으면 된다. 다운 받은 압축파일의 압축을 해제하면 BoxMan@Run.FBX, BoxMan@Stand.FBX, BoxMan@Walk.FBX, BoxMan@Attack.FBX 네 개의 FBX 파일이 나올 것이다. 일반적으로 외부의 3D 모델링 프로그램을 통해 만들어진 애니메이션들은 FBX 확장자를 가진 것을 사용한다.

이렇게 받은 네 개의 파일을 유니티 엔진의 프로젝트 뷰로 드래그&드롭 한다. 그렇게 하면 네 개의 파일이 우리의 프로젝트에 포함되는 것을 확인할 수 있다.

임포트된 FBX 파일은 프로젝트 뷰에서 파란 직육면체에 종이가 붙은 아이콘으로 표현되며, 그 앞의 작은 삼각형을 클릭해서 접힌 부분을 열면 그 아래에 애니메이션 클립이 포함되어 있는 것을 확인할 수 있다.

이 FBX 파일을 선택한 상태로 인스펙터 창에서 애니메이션의 이름이나 길이, 반복 여부 등을 수정할 수 있다.

유니티 엔진에서 직접 애니메이션 클립 만들기

유니티 엔진에서 직접 애니메이션 클립을 만드는 방법을 배우기 위해서는 우선 씬에 애니메이션 클립을 만들 게임오브젝트 하나를 생성한다.

그리고 생성된 오브젝트를 선택한다. 

그 다음에 상단 메뉴바에서 Window>Animation>Animation을 선택하거나 Ctrl+6 단축키를 누르면 애니메이션을 수정할 수 있는 애니메이션 패널이 열린다.

아직 큐브에는 다른 애니메이션이 없기 때문에 애니메이션 클립을 생성하게 도와주는 Create 버튼만 보인다. 유니티 엔진에서 애니메이션 클립을 직접 만들기 위해서는 이 버튼을 사용하면 된다. 이 버튼을 클릭한다.

그러면 애니메이션 클립 생성 및 저장을 위한 대화상자가 뜨는데 CubeRotating.anim 이라는 이름으로 애니메이션 클립을 하나 생성하자.

애니메이션 클립이 생성되면 애니메이션 창에 타임라인이 표시된다.

이제 큐브가 회전하는 애니메이션을 추가하기 위해서 Add Property 버튼을 누르고 Transform 항목의 Rotation의 + 버튼을 눌러준다.

로테이션 프로퍼티가 추가되면 타임라인의 1초 지점을 클릭하고 Rotation.y 값을 360으로 설정한다.

그 다음 애니메이션 창의 재생 버튼을 눌러보면 화면에 배치된 큐브가 회전하는 것을 확인할 수 있다.

유니티 엔진에서 직접 만들어지는 애니메이션 클립은 대부분 이런 과정을 통해서 만들어지며 일반적으로 간단한 애니메이션이나 UI 애니메이션을 만들 때 사용되는 경우가 많다.

애니메이터 컨트롤러

애니메이션 클립에 대해서 설명했으니 이제 애니메이터 컨트롤러에 대해서 이야기할 차례이다. 앞서 이야기 했듯이 애니메이션 클립이 한 동작에 대한 애니메이션이라면 애니메이터 컨트롤러는 여러 애니메이션 클립을 모아서 오브젝트가 어느 시점에 어떤 애니메이션을 어떻게 재생할지 결정하는 역할을 한다.

애니메이터의 기본적인 구성요소는 스테이트(State), 트랜지션(Transition), 파라미터(Parameter) 이렇게 세 가지이다.

스테이트(State)

스테이트는 일반적으로 애니메이터에서 애니메이션 클립을 담고 있는 하나의 상태로, 지금 어느 애니메이션 클립이 재생되어야 하는가를 표현한다.

스테이트 중 하나를 클릭하여 선택하면 인스펙터 창에서 현재 선택된 스테이트의 정보를 확인하고 수정할 수 있다. 스테이트의 이름을 바꿀 수 있는 것은 물론이고 Motion 프로퍼티에는 현재 스테이트가 재생할 애니메이션 클립을 설정할 수 있고 Speed 프로퍼티를 통해서 애니메이션이 재생될 속도 역시 설정할 수 있다.

또한 위 예시 이미지에서 배치된 스테이트들은 애니메이터의 가장 기본적인 스테이트들로 스테이트당 하나의 애니메이션 클립을 담는다. 애니메이션 클립 하나를 담는 스테이트 이외에도 파라미터 값에 따라서 여러 애니메이션을 블랜딩해주는 블랜드 트리나, 여러 스테이트들을 담을 수 있는 서브-스테이트 머신이 있다. 추가적인 내용은 다른 파트에서 다루도록 하겠다.

특수한 스테이트

예시로 보여진 애니메이터 컨트롤러의 그래프를 보면 일반적인 노드는 회색의 사각형으로 표시되고 있는데, 그 외에 특별한 형태의 노드를 볼 수 있다. 

첫 번째는 엔트리(Entry)다. 엔트리는 애니메이션이 처음 시작될 때의 진입점을 의미한다.

이 엔트리에서 제일 처음으로 연결된 노드는 주황색으로 표시되며, 게임오브젝트가 활성화되어 애니메이션이 시작되면 이 주황색으로 표시된 애니메이션부터 재생이 시작된다.

노드를 기본 스테이트로 만들기 위해서는 기본 스테이트로 만들고자 하는 노드를 우클릭하고 [Set as Layer Default State] 항목을 선택하면 된다.

두 번째는 모든 스테이트(Any State) 노드이다. 이 노드는 애니메이터가 어떤 애니메이션을 재생하고 있는 상태이던 간에 트랜지션의 조건이 만족되면 무조건 다음 스테이트로 넘어가서 애니메이션을 재생하게 만든다.

예를 들어 캐릭터가 걷는 중이든, 가만히 서있는 중이든, 아니면 포션을 마시는 중이었든, 큰 데미지를 입어서 죽으면, 바로 Die 스테이트로 넘어가도록 하는 것이다.

마지막으로 엑시트(Exit) 노드이다. 엑시트 노드는 애니메이터의 흐름이 한 번 끝났음을 의미하고, 엑시트 노드를 통과하면 엔트리 노드로부터 다시 애니메이터의 흐름이 다시 시작된다.

파라미터(Parameter)

애니메이터의 파라미터는 한 애니메이션에서 다른 애니메이션으로 전환되는 조건이 되는 변수의 역할을 한다. Parameters에서 + 버튼을 누르면 추가할 파라미터의 종류를 선택할 수 있다. 파라미터의 종류로는 Float, Int, Bool, Trigger가 있으며 Float는 소수점을 나타낼 수 있는 실수, Int는 정수, Bool는 참/거짓을 표현하는 논리 변수이며, Trigger는 Set되면 True가 되고 해당 Trigger가 걸린 트랜지션을 통과하면 자동으로 False로 바뀌는 타입이다.

트랜지션(Transition)

트랜지션은 애니메이터에서 스테이트와 스테이트 사이를 이어주는 것이다. 스테이트 사이를 이어줄 때, 애니메이션이 어느 방향으로 흘러갈지 방향을 정할 수 있다. 그 외에도 트랜지션을 선택하면 인스펙터 창을 통해서 선택된 트랜지션이 실행될 조건이나, 한 스테이트에서 다른 스테이트로 넘어갈 때 애니메이션을 어떻게 블랜딩해줄 것인지 등을 설정할 수 있다.

이 외의 애니메이션과 관련된 포스트는 애니메이션 카테고리에서 확인할 수 있다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Q&A ::  일반 클래스 내부에

MonoBehaviour 상속 클래스

멤버 변수 저장하기

유니티에서 JSON 사용하기(Unity JSON Utility) 글에 달아주신 psj님의 질문 댓글에 대한 답변입니다. 질문의 내용은 다음과 같습니다.

안녕하세요 올려주신 글 보고 잘 공부하고 갑니다.
궁금한 게 하나 있는데요

 

public class Aclass : MonoBehaviour {}

 

public class Bclass
{
    Aclass a;
}

이런 식으로 MonoBahaviour를 상속 받지 않은 순수 클래스 안에 멤버 변수로 MonoBehaviour를 상속 받은 클래스가 있을 경우에는
Bclass안에 Aclass를 어떤 식으로 저장해야하나요??

안녕하세요 올려주신 글 보고 잘 공부하고 갑니다.
궁금한 게 하나 있는데요
public Class Aclass : MonoBehaviour {}
public Class Bclass
{
Aclass a;
}
이런 식으로 MonoBahaviour를 상속 받지 않은 순수 클래스 안에 멤버 변수로 MonoBehaviour를 상속 받은 클래스가 있을 경우에는
Bclass안에 Aclass를 어떤 식으로 저장해야하나요??

출처: https://wergia.tistory.com/164#comment15327425 [베르의 프로그래밍 노트]

모노비헤이비어 클래스를 상속받지 않은 일반 클래스인 Bclass가 모노비헤이비어 클래스를 상속받은 Aclass를 멤버 변수로서 가질 때, 이 Bclass의 멤버 변수인 a에 어떻게 Aclass의 객체를 대입/할당 할 수 있는지에 대한 질문입니다.

우선 여기서 알아두어야 할 점은, Bclass는 앞서 말했듯이 모노비헤이비어 클래스를 상속받지 않았기 때문에 Awake(), Start(), Update() 등의 함수를 가지지 못했고, 유니티 엔진에 의해서 코드가 실행되지 않는다는 것입니다. 이 클래스에 속한 함수 등의 코드를 실행시키기 위해서는 유니티 엔진에 의해서 작동하는 모노비헤이비어 클래스를 상속받는 클래스의 동작을 통해서 간접적으로 실행되어야 할 것입니다.

이렇게 Bclass를 가지고 함수를 실행하기 위한 클래스를 다음과 같이 Cclass라고 정의하겠습니다.

public class Cclass : MonoBehaviour

{

    private Bclass b;

 

    private void Awake()

    {

        b = new Bclass();

    }

}

그리고 다시 Bclass를 살펴보면 Bclass의 멤버 변수인 a는 private로 선언되어 있어서 접근 방법이 없음을 알 수 있습니다. 외부에서 이 a에 값을 저장하거나 볼 수 있는 경로를 제공해주어야 합니다. 이를 위한 방법은 여러가지가 있습니다.

첫 번째로는 멤버변수의 접근지정자를 public으로 선언하는 것입니다.

public class Bclass
{
    public Aclass a;
}

접근지정자를 public으로 선언하면 아래의 예시와 같이 b아래의 a에 곧바로 접근하여 값을 대입할 수 있게 됩니다.

public class Cclass : MonoBehaviour

{

    private Bclass b;

 

    private void Awake()

    {

        b = new Bclass();

    }

 

    private void Start()

    {

        b.a = FindOfObject<Aclass>();

    }

}

두 번째 방법은 private인 멤버 변수에 접근해서 값을 넣도록 해주는 기능을 가진 함수를 만드는 것입니다.

public class Bclass
{
    private Aclass a;

 

    public void SetA(Aclass a)

    {

        this.a = a;

    }

 

    public Aclass GetA()

    {

        return a;

    }

}

private인 멤버 변수에 접근해서 값을 넣도록 해주는 함수를 만듬으로써 함수를 통해서 b안에 있는 a의 값을 수정할 수 있게 됩니다.

public class Cclass : MonoBehaviour

{

    private Bclass b;

 

    private void Awake()

    {

        b = new Bclass();

    }

 

    private void Start()

    {

        b.SetA(FindOfObject<Aclass>());

    }

}

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Camera.main에서 Null Reference가 발생하는 문제

작성 기준 버전 :: 2018.3.2f1

유니티 스크립트 작업 중에 Camera.main을 호출하면 해당 씬에서의 주 카메라가 반환된다. Camera.main으로 반환받는 주 카메라를 통해서 스크린의 좌표를 월드의 좌표로 변경하거나 월드 좌표를 스크린의 좌표로 변경하는 증의 작업을 주로 하게 된다.

하지만 가끔 이 Camera.main이 제대로된 주 카메라를 반환하지 않고 null 값을 반환하는 문제가 발생하는 경우가 발생한다.

이런 문제는 새로 생성한 씬에 자동으로 들어있는 기본 카메라를 지우고 새 카메라를 만들었을 때 주로 발생한다.

위의 이미지는 새로운 SampleScene을 만들고, 기본적으로 들어 있던 Main Camera를 지우고 New Camera를 만든 상황이다.

public class MainCameraTest : MonoBehaviour
{
    void Start()
    {
        Debug.Log(Camera.main);
    }
}

이 상황에서 위와 같이 Start() 시점에 Camera.main을 호출하는 스크립트를 만들고 게임 오브젝트에 이 스크립트를 컴포넌트로 붙여서 실행해보자.

그렇게 하면 위 이미지처럼 Camera.main이 null 값을 반환하는 것을 확인할 수 있다.

이런 문제가 발생하는 이유는 스크립트에서 Camera.main을 호출해서 메인 카메라를 찾아낼 때, "MainCamera" 태그가 붙어있는 카메라를 찾아내는 방식을 사용하기 때문이다. 그렇기 때문에 기존에 있는 메인 카메라를 지우고 새로운 카메라를 만들었다면 새로 만든 카메라의 Tag를 "MainCamera"로 바꿔줘야 한다.

새로 만들어진 카메라에 MainCamera 태그를 달고 다시 플레이를 해보면 새로 만든 카메라가 Camera.main으로 반환되는 것을 확인할 수 있다.

카메라에 메인 카메라 태그를 붙일 때도 주의해야 하는 점은, 만약 여러 개의 카메라에 메인 카메라 태그를 붙이면 Camera.main으로 호출했을 때 어떤 카메라가 반환될지 확정할 수 없기 때문에 문제가 발생할 수 있다는 점이다.

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

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

[투네이션]

[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]

[디스코드 채널]

당신을 고통에 빠뜨릴 문제 (1)

코루틴과 Instantiate 그리고 Start

게임을 개발하면서 생겨나는 많은 버그들은 개발자들을 고통에 빠뜨리지만, 그 중에서도 엔진의 특성과 맞물려서 발생하는 버그는 깊이가 다른 고통을 느끼게 해준다. 이런 종류의 버그는 개발자가 생각한 로직으로는 완벽하지만 엔진의 특성으로 인해서 그 로직이 완벽하게 동작하지 않는 것이기 때문에 해당 엔진의 동작과 특성을 확실하게 알고 있지 않으면 어디서 버그가 발생했는지, 원인이 무엇인지 알기 어렵다.

이제부터 이러한 버그들에 대해서 알아보도록 하자. 첫 번째 내용은 코루틴과 Instantiate 그리고 Start에 얽힌 문제에 관한 내용이다.

코루틴(Coroutine)의 특성

코루틴은 유니티로 게임을 개발할 때, 자주 사용되는 기능 중에 하나다. 주로 비동기 처리나, 프로그램을 멈추지 않고 다른 동작을 기다리거나, 메인 로직 뒤에서 돌아가는 서브 루틴을 구현할 때 사용된다.

using System.Collections;
using UnityEngine;

public class B : MonoBehaviour
{
    public void CallCoroutine()
    {
        StartCoroutine(SomeCoroutine());
    }

    private IEnumerator SomeCoroutine()
    {
        Debug.Log("Start Coroutine");
        yield return null;
        Debug.Log("End Coroutine");
    }
}

using UnityEngine;

public class A : MonoBehaviour
{
    public B b;

    void Start()
    {
        b.CallCoroutine();
    }
}

위의 코드를 보면 A라는 클래스가 B라는 클래스의 CallCoroutine() 함수를 호출하여 B 클래스의 SomeCoroutine()을 동작하게 만들고 있다.

이 코드는 만약 B 오브젝트가 활성화(enabled)되어 있다면 정상적으로 동작하겠지만, 비활성화(disabled)된 상태라면 위의 이미지처럼 오브젝트가 활성화되지 않은 상태에서 코루틴을 호출했다는 에러 로그가 발생하고 해당 코루틴의 코드가 하나도 실행되지 않는다.

이것은 코루틴을 사용할 때 기본적인 주의 사항으로 해당 오브젝트가 활성화(Enabled)된 상태에서 코루틴을 호출해야 한다는 것을 의미한다.

이런 문제는 에러 로그가 명확하기 때문에 코루틴을 호출하기 전에 게임 오브젝트의 액티브를 확인해주거나 게임 오브젝트가 활성화된 이후에만 코루틴을 호출하도록 수정하면 간단하게 해결된다.

진짜 문제

이전의 예시처럼 이미 생성되어 있는 게임 오브젝트의 코루틴을 호출하는 문제는 활성화 상태만 잘 체크하면 된다. 진짜 문제는 이 코루틴과 Start, Instantiate가 엮였을 때부터 발생한다.

using UnityEngine;

public class A : MonoBehaviour
{
    public GameObject bPrefab;

    void Start()
    {
        var b = Instantiate(bPrefab).GetComponent<B>();
        b.CallCoroutine();
    }
}

이미 생성되어 있는 B 오브젝트를 참조하는 이전의 예시와 다르게 이번에는 B 오브젝트의 프리팹을 소유하고 있다가 A 오브젝트가 Start() 되면 B 오브젝트를 새로 생성해서 B 오브젝트의 코루틴을 호출하는 상황을 가정해보자.

using System.Collections;
using UnityEngine;

public class B : MonoBehaviour
{
    private void Start()
    {
        Debug.Log("Start");
    }

    public void CallCoroutine()
    {
        StartCoroutine(SomeCoroutine());
    }

    private IEnumerator SomeCoroutine()
    {
        // yield return null;
        Debug.Log("Start Coroutine");
      
        Debug.Log("Ing Coroutine");
       
        Debug.Log("End Coroutine");
    }
}

그리고 B 클래스는 Start() 함수가 호출되면 "Start"라는 로그를 띄우고 SomeCoroutine()에서 각 과정에 맞는 로그를 띄울 것이다.

자, 그러면 아래와 같이 여러 상황의 코루틴들을 가정해보자.

private IEnumerator SomeCoroutine()
{
    yield return null;
    Debug.Log("Start Coroutine");
      
    Debug.Log("Ing Coroutine");
       
    Debug.Log("End Coroutine");

}

 

private IEnumerator SomeCoroutine()
{
   
    Debug.Log("Start Coroutine");
    yield return null;
    Debug.Log("Ing Coroutine");
       
    Debug.Log("End Coroutine");

}

 

private IEnumerator SomeCoroutine()
{

    Debug.Log("Start Coroutine");
      
    Debug.Log("Ing Coroutine");
    yield return null;
    Debug.Log("End Coroutine");

}

 

private IEnumerator SomeCoroutine()
{

    Debug.Log("Start Coroutine");
      
    Debug.Log("Ing Coroutine");
       
    Debug.Log("End Coroutine");

    yield return null;
}

여러 상황의 코루틴에서 과연 Start() 함수는 같은 시점에 호출될까? 아니다. 유니티에서 게임 오브젝트의 Start() 함수는 게임 오브젝트가 Instantiate()로 생성되고 한 프레임 뒤에 호출되기 때문에 코루틴이 돌다가 만난 첫 번째, yield return 시점에 Start() 함수가 호출되게 된다. 만약 Start() 함수가 별다른 역할을 하지 않는다거나, 호출순서에 상관없는 일을 처리한다면 큰 문제는 없겠지만, 만약 코루틴의 동작과 연관된 중요한 작업을 Start()가 처리하고 있다면, 이 yield return의 위치에 따라서 심각하고도 감지하기 어려운 난감한 문제를 만나게 될 확률이 높아진다.

그리고 이것보다 심각한 문제로, Instantiate() 직후에 코루틴을 호출한 경우, 희박한 확률로 코루틴의 앞 부분 코드는 정상 동작을 하다가 첫 번째 yield return을 만나는 순간, 그 이후의 코드를 실행하지 않는 문제도 발생한다. 게다가 이 경우에는 어떠한 에러나 경고 로그도 발생하지 않기 때문에, 이 문제의 원인이나 해결법을 찾아내기가 아주 어렵다.

using System.Collections;
using UnityEngine;

public class B : MonoBehaviour
{
    private void Start()
    {
        Debug.Log("Start");
        StartCoroutine(SomeCoroutine());
    }

    private IEnumerator SomeCoroutine()
    {
        Debug.Log("Start Coroutine");
        yield return null;
        Debug.Log("Ing Coroutine");
       
        Debug.Log("End Coroutine");
    }
}

그렇기 때문에 만약 Instantiate()와 Start() 그리고 코루틴이 긴밀하게 엮여있거나, Instantiate()로 게임 오브젝트를 생성한 직후에 코루틴을 호출해서 어떤 작업을 처리해야 하는 경우라면, 별도로 코루틴을 호출하는 것보다는, 위의 코드처럼 Start() 함수에서 코루틴을 실행하는 것을 권장한다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Tutorial (6)

게임 오브젝트와 컴포넌트

작성 기준 버전 :: 2018.3.2f1

이번 섹션에서는 게임 오브젝트와 컴포넌트에 대해서 알아보자.

게임 오브젝트(Game Object)

게임 오브젝트는 유니티 엔진에서 가장 기본이 되는 개념으로 캐릭터와 바닥에 떨어진 아이템, 배경으로 배치된 건물이나 소품, 폭발하면서 발생하는 이펙트, 빛을 밝히는 광원, 모든 장면을 찍는 카메라까지 씬에 배치되는 모든 것은 게임 오브젝트이다.

기본적인 게임 오브젝트에 나중에 설명할 컴포넌트를 추가로 붙임으로써 게임 오브젝트가 캐릭터가 되느냐, 아이템이 되느냐, 아니면 간단한 배경이 되느냐를 결정하게 된다.

게임 오브젝트는 기본적으로 이름(Name - "GameObject"), 태그(Tag - "Untagged"), 레이어(Layer - "Default")를 가지고 있다. 이를 응용해서 나중에 원하는 오브젝트를 찾거나 할 수 있다.

컴포넌트(Component)

컴포넌트는 게임 오브젝트에 붙일 수 있는 다양한 기능을 가진 구성요소들로, 비어있는 게임 오브젝트에 어떤 컴포넌트를 붙이느냐에 따라서 그 게임 오브젝트의 역할이 달라진다.

트랜스폼 컴포넌트(Transform Component)

모든 컴포넌트 중에서 트랜스폼(Transform) 컴포넌트는 모든 게임 오브젝트에 기본으로 부착되며 제거할 수 없다.

이 트랜스폼 컴포넌트는 해당 게임 오브젝트가 씬에 어느 위치에, 얼마나 회전되어서, 어떤 크기로 배치되어 있는지를 정하는 컴포넌트이다.

기타 컴포넌트

게임 오브젝트에는 여러 컴포넌트를 붙일 수 있고 어떤 컴포넌트를 붙이느냐에 따라서 게임 오브젝트의 역할이 달라진다.

게임 오브젝트에 Light 컴포넌트를 붙이면 광원이 되고 Camera 컴포넌트를 붙이면 게임 내에서 씬을 보여주는 카메라가 된다. 이렇게 유니티에서 기본적으로 제공하는 컴포넌트 이외에도 개발자가 유니티 스크립트 API를 이용해서 직접 컴포넌트를 만들어서 게임 오브젝트에 붙일 수도 있다.

컴포넌트 추가하기

컴포넌트를 추가할 게임 오브젝트를 선택하고 인스펙터 창에서 Add Component 버튼을 누르면 게임 오브젝트에 추가할 수 있는 컴포넌트들이 보여진다. 이 중에서 게임 오브젝트에 추가할 컴포넌트를 선택하면 된다.

커스텀 컴포넌트

유니티에서 기본적으로 제공하는 기본적인 컴포넌트 이외에도 개발자가 직접 컴포넌트를 만들어서 게임 오브젝트에 붙일 수도 있는데 대부분의 실제적인 게임 기능을 하는 시스템들은 커스텀 컴포넌트로 만들어지고 게임 오브젝트에 추가될 것이다.

커스텀 컴포넌트를 만드는 방법은 프로젝트 뷰에서 우클릭한 뒤 Create>C# Script 항목을 선택하면 된다.

그러면 NewBehaviourScript라는 이름으로 C# 스크립트 파일이 생성된다.

이렇게 생성한 컴포넌트는 다른 컴포넌트와 마찬가지로 컴포넌트를 붙일 게임 오브젝트를 선택하고 Add Component 버튼을 누른 뒤 추가한 컴포넌트의 이름을 검색해서 붙일 수 있다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]