잠시 기다리면 설치 가능한 패키지 전체가 나올 텐데, 만약 곧바로 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로 변경된다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
우선 트랜스폼 컴포넌트는 게임 오브젝트에 필수로 부착되는 컴포넌트로, 인스펙터 뷰에서 보면 [그림 1]과 같이 Vector3 형식의 포지션(Position), 로테이션(Rotation), 스케일(Scale) 프로퍼티를 사용자에게 공개하고 있다.
프로퍼티의 이름에 맞게 포지션 프로퍼티는 게임 오브젝트의 위치 정보를 수정할 수 있다.
로테이션 프로퍼티는 회전 정보를 가지고 이를 수정할 수 있다.
스케일 프로퍼티는 크기 정보에 관여한다.
이렇게 인스펙터 뷰에서 보이는 트랜스폼 컴포넌트로 씬 안에 있는 게임 오브젝트의 위치를 옮기거나, 회전시키고, 그 크기를 바꿀 수 있다. 하지만 인스펙터 뷰에서 트랜스폼 컴포넌트의 내용을 변경하는 것은 게임 중에는 불가능한 일로 고정된 건물이나 물건같은 오브젝트에나 사용할 수 있는 방법이다.
플레이어, 몬스터와 같은 캐릭터, 총알, 화살 같은 투사체, 말, 자동차 같은 탈 것처럼 게임 안에서 플레이어의 조작이나 AI의 조작을 따라서 움직일 게임 오브젝트들은 스크립트를 이용해서 이동시켜야 한다.
스크립트로 트랜스폼 컴포넌트 다루기
트랜스폼 컴포넌트 접근하기
public class TransformController : MonoBehaviour
{
void Start()
{
Transform myTransformComponent = transform;
}
}
커스텀 컴포넌트가 부착된 게임 오브젝트의 트랜스폼 컴포넌트를 가져오기 위해서는 모노비헤이비어(MonoBehaviour) 클래스를 통해서 상속받은 transform 프로퍼티를 호출하면 된다.
transform 프로퍼티를 어디서 상속받는지 궁금할 수도 있다. 그럴 때는 트랜스폼 컨트롤러 클래스가 상속받는 모노비헤이비어 클래스를 클릭하고 F12키를 눌러서 모노비헤이비어 클래스 파일로 이동한 다음, 같은 과정을 컴포넌트(Component) 클래스가 나올 때까지 반복하면 된다. 그러면 컴포넌트 클래스에 정의된 transform 프로퍼티를 확인할 수 있다.
위치 이동시키기
position으로 직접 이동시키기
그럼 제일 먼저 트랜스폼 컴포넌트를 이용해서 게임 오브젝트를 이동시켜보자.
public void MovePosition(Vector3 newPosition)
{
transform.position = newPosition;
}
게임 오브젝트의 위치 정보를 다루는 포지션 프로퍼티에 접근하기 위해서는 위의 예시 코드와 같이 transform.position을 이용하면 된다.
public void MovePositionUseTranslate(Vector3 moveDirection)
{
transform.Translate(moveDirection);
}
Translate() 함수는 position 프로퍼티에 직접 위치를 집어넣어서 이동시키는 것과는 달리 게임 오브젝트가 이동하고자 하는 방향과 속력인 벡터를 매개변수로 받아 그 벡터의 방향과 길이만큼 게임 오브젝트를 이동시키는 함수이다.
위 코드를 저장하고 플레이해보면 position을 이용한 오브젝트 이동에서는 1 ~ -1 사이에서만 움직이던 것과는 달리 Translate() 함수를 이용한 이동에서는 훨씬 큰 폭으로 움직이는 것을 볼 수 있다. 이것은 이동 방향 벡터가 코사인 그래프를 따라서 바뀌는 동안에 0보다 값이 커지면 위로, 0보다 작아지면 아래로 움직이기 때문이다.
두 이동 방식을 비교하기 위해서 TransformController를 상속받는 두 클래스를 만들어보았다. PositionMover 클래스는 매 프레임 MovePosition() 함수를 호출해서 (0, 0.1, 0) 벡터를 넣어주고, TranslateMover 클래스는 매 프레임 MovePositionUseTranslate() 함수를 호출해서 역시 같은 벡터를 넣어주고 있다.
에디터로 돌아가서 게임 오브젝트 두 개를 만들고 이 두 컴포넌트를 각각 붙여주고 플레이하면 TranslateMover 컴포넌트를 붙인 게임 오브젝트만 저 멀리 올라가버리는 것을 볼 수 있다. 하지만 PositionMover 컴포넌트를 붙인 게임 오브젝트는 시작되는 순간에 (0, 0.1, 0) 좌표로만 이동한 다음에 그대로 움직이지 않는 것을 보면, 두 방법의 차이를 이해할 수 있다.
회전시키기
rotation으로 회전시키기
void Start()
{
transform.rotation = new Quaternion();
}
게임 오브젝트를 회전시키기 위해서는 transform.rotation 프로퍼티를 사용하면 된다. 다만, 인스펙터 뷰에서 공개된 Rotation 프로퍼티가 Vector3 형식인 것과 달리 스크립트에서는 쿼터니언(Quaternion) 구조체를 사용한다.
Quaternion rotation = new Quaternion();
rotation.w
rotation.x
rotation.y
rotation.z
쿼터니언 구조체는 벡터와는 다른 사원수라는 체계를 사용해서 오브젝트의 회전을 표현한다. 이 사원수라는 체계는 상당히 난해한 체계이기 때문에 유니티의 공식 문서에서는 사원수에 대한 지식을 충분히 가지고 있지 않다면 쿼터니언을 직접 수정하지 않도록 권장하고 있다.
그럼 사원수를 제대로 알지 못하면 게임 오브젝트를 회전시키지 못하게 되는가? 그렇지는 않다. 인스펙터 뷰에서처럼 3차원 벡터를 이용해서 회전을 다루는 방법을 오일러 각 체계(Euler angle system)라고 부른다. 오일러 각 체계 이용하면 xyz 각 축을 기준으로 오브젝트가 얼마나 회전한 상태인지 직관적으로 알 수 있다. 그래서 쿼터니언 구조체에는 이 오일러 각 체계의 회전을 사원수 체계의 회전으로 전환해주는 Euler() 함수가 포함되어 있다. 이 함수를 이용하면 Vector3로 표현된 각을 Quaternion으로 변환할 수 있다.
그리고 회전 역시 이동과 마찬가지로 rotation 프로퍼티를 직접 수정하는 방법과 Rotate() 함수를 사용하는 방법 두 가지가 있다. 그리고 그 차이점 역시 이동시키기에서의 position 직접 이동과 Translate() 함수를 이용한 이동과 비슷하다.
우선 커스텀 컴포넌트를 만들기 위해서 C# 스크립트를 하나 생성해보자. 프로젝트 뷰에 우클릭하여 [Create > C# Script] 항목을 선택한다.
그렇게하면 NewBehaviourScript라는 이름으로 C# 스크립트 파일이 하나 생성된다.
바로 엔터 키를 누르지 말고 파일의 이름을 ScriptingTest로 변경하고 엔터 키를 누르도록 하자. C# 스크립트 파일은 제일 처음 이름이 정해질 때, 스크립트 파일 내부의 클래스 이름이 정해지며, 스크립트 파일의 이름과 클래스의 이름이 일치하는 것을 권장하기 때문에 클래스의 이름을 처음에 제대로 정하는 것이 나중에 수정하는 것보다 좋다. 특히 나중에 파일의 이름을 바꾸면 내부의 클래스의 이름도 수동으로 바꿔야하므로 굉장히 번거롭다.
그리고 생성된 스크립트 파일을 더블클릭하면 비주얼 스튜디오가 열립니다.
모노비헤이비어 클래스 상속
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class ScriptingTest : MonoBehaviour
{
// Start is called before the first frame update
void Start()
{
}
// Update is called once per frame
void Update()
{
}
}
최초로 생성된 기본 코드는 위와 같다. 먼저 생성된 ScriptingTest 클래스가 모노비헤이비어(MonoBehaviour) 클래스를 상속받고 있는 것을 볼 수 있다. 이 유니티로 게임을 제작할 때 사용되는 C# 클래스는 이 모노비헤이비어를 상속받는 클래스과 상속받지 않는 클래스로 크게 나누어진다.
모노비헤이비어 상속 여부에 따른 차이는, 모노비헤이비어를 상속받지 않은 클래스는 게임 오브젝트에 컴포넌트로써 부착되지 못한다는 것에 있다. 때문에 컴포넌트로써 게임 오브젝트에 부착되어서 씬 내부에 존재해야하는 클래스는 모노비헤이비어를 상속받는게 필수이고, 씬에 컴포넌트로 배치되지 않고 코드 내부에서 개념적으로만 존재할 클래스는 모노비헤이비어를 상속받지 않아야 한다.
모노비헤이비어의 라이프 사이클
모노비헤이비어를 상속받아서 게임 오브젝트에 부착되어 동작하는 스크립트를 잘 활용하려면 모노비헤이비어의 라이프 사이클에 대해서 잘 알아두는 것이 좋다. 모노비헤이비어를 상속받는 컴포넌트는 생성되어 게임 오브젝트에 부착되는 순간부터 위의 이미지와 같은 과정을 거친다.
그리고 위의 모노비헤이비어 상속 파트에서 본 코드 블럭을 보면 Start() 함수와 Update() 함수가 구현되어 있는 것을 볼 수 있다. 이와 같이 거치는 과정의 이름으로 함수를 만들어두면 해당 과정을 거칠 때, 그 함수가 실행되는 구조이다.
그럼 각 과정이 언제 호출되는지 어떻게 구현하면 되는지에 대해서 하나씩 알아보자.
Awake
private void Awake()
{
Debug.Log("Awake");
}
Awake 과정은 스크립트 인스턴스가 로딩될 때 단 한 번 호출되는 함수이다. 컴포넌트에 대한 초기화가 필요한 경우에 사용된다. 참고로 모노비헤이비어를 상속받는 클래스는 생성자 대신에 Awake() 함수를 구현해서 사용해야 한다.
OnEnable 과정은 모노비헤이비어를 상속받은 컴포넌트가 부착된 게임 오브젝트가 활성화될 때마다 호출되는 함수이다.
에디터의 씬에서 게임 오브젝트를 선택하면 인스펙터 뷰에서 선택한 게임 오브젝트에 대한 정보를 볼 수 있는데, 이 중에 게임 오브젝트 이름 앞에 체크박스가 있다. 이 체크박스를 클릭해보면 체크박스 상태에 따라서 게임 오브젝트가 활성화되었다 비활성화되었다하는 것을 볼 수 있다. 이렇게 게임 오브젝트가 활성화될 때마다 OnEnable() 콜백 함수가 호출되는 것이다. 참고로 게임 오브젝트가 비활성화된 상태에서는 해당 게임 오브젝트에 부착된 모든 컴포넌트가 동작을 멈춘다.
Start
private void Start()
{
Debug.Log("Start");
}
Start 과정은 Update 과정이 실행되기 직전에 단 한 번 호출된다. 모노비헤이비어의 라이프 사이클 중에 단 한 번 호출된다는 점이 Awake와 같지만 Start는 게임 오브젝트가 활성화된 경우에만 호출된다는 차이점이 있다.
Update 과정은 모노비헤이비어가 활성화된 상태에서 매 프레임마다 호출된다. 대부분의 게임의 동작 처리는 이 Update() 함수에서 수행되는 경우가 많다. 다만, 이 Update() 함수는 프레임마다 호출되기 때문에 프레임 드랍이 발생하는 경우에는 호출 횟수가 줄어든다. 프레임과 상관 없이 코드가 작동하기 원한다면 FixedUpdate() 함수를 사용해야 한다.
Update() 함수는 OnEnable() 함수를 설명하면서 이야기했듯이 게임 오브젝트가 비활성화된 상태에서는 동작하지 않는다.
위의 코드를 모두 ScriptingTest 클래스에 작성하고 플레이시켜보면 위의 이미지와 같은 순서로 로그가 발생하는 것을 볼 수 있다.
변수
우리가 게임을 만들면서 사용될 값, 공격력, 방어력, 공격속도, 이동속도, HP 등의 데이터나 정보를 담아둘 것을 변수라고 부른다. 유니티 엔진에서 스크립트를 작성하는 C#은 담고자하는 값의 종류에 따라서 변수의 종류가 나누어진다. 그럼 이 변수의 종류에 대해서 알아보도록 하자.
정수(int)
int i = 10;
첫 번째 변수 유형은 정수형이다. 정수형 변수 int는 0과 양의 정수, 음의 정수를 담기 위한 변수로, -2,147,483,648부터 2,147,483,647까지 담을 수 있다.
남아있는 라이프의 갯수, 현재 생산된 인구 수 등의 정수로 딱 떨어지는 곳에서 사용될 수 있다.
실수(float)
float f = 3.14159f;
두 번째 변수 유형은 실수형이다. 실수형 변수 float은 소수를 담기 위한 변수로 일반적으로 소수점 다섯 번째자리 0.00001까지 정확도를 표현할 수 있다.
주로 1.2초 같은 시간이나 20.25%와 같은 확률 등을 표현할 때, 주로 사용된다.
문자열(string)
string str = "hello";
세 번째 변수 유형은 문자열입니다. 문자열 변수 string은 말그대로 문자들의 집합인 문자열을 담는 변수이다.
주로 캐릭터나 아이템의 이름, 설명, 게임에서 사용되는 대사 자막 등의 데이터를 담는데 사용된다.
논리값(bool)
bool isMoveable = true;
네 번째 변수 유형은 논리값이다. 논리값 변수 bool은 참(true) 혹은 거짓(false)의 상태를 가지는 변수로 주로 조건을 처리할 때 사용된다.
이 외에도 각 종류의 변수를 묶음 단위로 취급하는 배열 등이 있고, 일반 C# 클래스나 모노비헤이비어를 상속받은 클래스 역시 변수가 될 수 있다.
함수
함수는 게임 기능을 수행하기 위한 작업을 하나의 블록으로 묶은 것을 의미한다. 모노비헤이비어의 라이프 사이클에 대해서 설명하면서 본 Awake, OnEnable, Start, Update, OnDisable, OnDestroy 역시 함수이다. 일반적으로 함수는 하나의 기능 단위로 작성되는 경우가 많다.
int attackDamage = 10;
public bool Attack(Monster monster)
{
monster.hp -= attackDamage;
return monster.hp <= 0;
}
위의 예시 코드는 몬스터를 공격해서 체력을 공격력만큼 깎고, 몬스터의 체력이 0 이하가 되면 true를 반환하도록 코드가 작성되어 있다. 이렇게 하면 Attack() 함수를 호출하여 몬스터의 체력을 깎고 공격한 몬스터가 죽었는가에 따라서 여러가지 처리를 할 수 있게 된다.
공개 수준 결정
개발자는 코드를 작성하면서 변수나 함수에 대해서 공개 수준을 결정할 수 있다.
public int i;
protected float f;
private string str;
public void Function1() { }
protected void Function2() { }
private void Function3() { }
변수와 함수의 공개 수준은 앞에 표시된 public, protected, private 키워드를 통해서 결정된다. 이러한 공개 수준은 일반적인 C# 프로그래밍에서와 같이 public은 클래스 외부에서 접근이 가능하고 protected는 해당 클래스를 상속받은 클래스에서만 접근이 가능하다. 그리고 private는 해당 클래스의 내부에서만 사용 가능하다.
public class ScriptingTest : MonoBehaviour
{
public int attackDamage = 10;
}
그리고 유니티 엔진만의 특징으로는 모노비헤이비어 클래스를 상속받은 클래스에서 public으로 설정된 변수는 에디터의 인스펙터 뷰에서 바로 보고 수정할 수 있다는 장점이 있다.
이러한 방식의 장점은 매번 게임의 수치가 바뀔 때마다 프로그래머가 코드를 수정하고 새로 빌드 과정을 거칠 필요없이 게임 디자이너가 에디터에서 즉석으로 값을 바꿀 수 있다는 것이다.
하지만 인스펙터 뷰에서 보이게 하고자 하는 모든 변수를 public으로 설정하면 코드 내부에서 어떤 클래스에서던지 접근이 가능해진다. 이런 경우를 방지하고자 protected나 private로 설정한 채로 인스펙터 뷰에 공개하고 싶을 수도 있다.
[SerializeField]
private int attackDamage = 10;
그럴 때는 SerializeField라는 어트리뷰트를 해당 변수 앞에 명시해주면 private나 protected로 둔 상태로도 인스펙터 뷰에 변수를 공개할 수 있다.
[HideInInspector]
public int attackDamage = 10;
그와 반대로 변수를 public으로 둔 상태로 인스펙터 뷰에 공개하고 싶지 않다면 HideInInspector 어트리뷰트를 붙여주면 된다.
모노비헤이비어 클래스를 상속받아서 만들어진 컴포넌트는 클래스를 기반으로 변수를 어떻게 구성하고 함수를 어떻게 구현하느냐에 따라서 그 컴포넌트의 기능과 역할이 정해진다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
기본적인 하이어라키 뷰(Hierarchy View) 상태는 스타트 씬과 비슷하지만 게임이 진행되는 씬이기 때문에 플레이어와 연관된 에셋인 Player Assets 파트와 레벨을 구성하고 있는 Level Assets 파트가 추가되어 있는 것을 알 수 있다.
시스템(System)
시스템으로 분류된 게임 오브젝트는 씬 컨트롤러(Scene Controller), 트랜지션 스타트(Transition Start), 트랜지션 데스티네이션(Transition Destination), VFX 컨트롤러(VFX Controller), 백그라운드 뮤직 플레이어(Background Music Player), 피직스 헬퍼(Physics Helper)가 있다.
이 중에서 씬 컨트롤러와 그리고 백그라운드 뮤직 플레이어는 지난 섹션에서 다루었으니 넘어가도록 하고, 지난 섹션에서 다루기는 했으나 트랜지션 포인트(Transition Point) 컴포넌트를 부착하고 있는 트랜지션 스타트 게임 오브젝트는 약간의 차이가 있으나 가볍게 다루고 넘어가도록 한다.
트랜지션 스타트 게임 오브젝트(Transition Start Game Object)
그림 3
지난 섹션에서 다루었다시피 트랜지션 스타트 게임 오브젝트는 트랜지션 포인트 컴포넌트가 부착되어 있으며 플레이어의 캐릭터가 콜라이더에 닿으면 플레이어를 다른 씬으로 보내는 역할을 한다.
다만, 스타트 씬에서의 트랜지션 포인트와 다른 점은, 스타트 씬에서는 콜라이더에 닿은 캐릭터가 존재하지 않기 때문에 외부에서 트랜지션 포인트를 호출해서 씬을 전환하는 방식을 사용했다면, 이제부터는 본래의 방식에 맞게 캐릭터가 콜라이더에 닿으면 다른 씬을 보내도록 구성되어 있다는 점이다.
그림 4
실제로 씬에서 트랜지션 스타트 게임 오브젝트를 선택해서 보면 발판에서 캐릭터가 뛰어내리면 콜라이더에 닿을 수 있게 배치되어 있는 것을 확인할 수 있다.
그리고 원래의 스타트 씬에서는 Trasitioning Game Object 프로퍼티가 비어있었는데 지금은 Ellen이라는 게임 오브젝트가 할당되어 있는 것을 알 수 있다. 이 게임 오브젝트는 씬에 배치 되어있는 플레이어의 캐릭터로, 다른 물체나 몬스터 등의 다른 캐릭터가 아닌 플레이어의 캐릭터만 닿았을 때, 씬을 이동시키기 위해서 할당해둔 것이다.
void OnTriggerEnter2D (Collider2D other)
{
if (other.gameObject == transitioningGameObject)
{
m_TransitioningGameObjectPresent = true;
if (ScreenFader.IsFading || SceneController.Transitioning)
return;
if (transitionWhen == TransitionWhen.OnTriggerEnter)
TransitionInternal ();
}
}
트리거 설정된 콜라이더에 충돌이 발생했을 때 호출되는 OnTriggerEnter2D 콜백 함수를 보면 확실히 알 수 있다. 매개변수로 넘어온 충돌체의 게임 오브젝트와 미리 할당해둔 transitioningGameObject와 비교하여 같을 경우에만, 다른 씬으로 이동시키는 구조이다.
이렇게 하지 않으면 트랜지션 포인트의 콜라이더에 플레이어의 캐릭터가 아닌 총알이나 몬스터가 닿기만 해도 씬이 이동되는 상황을 보게 될 것이다.
유니티 콘텐츠 팀에서 선택한 방법에도 약간의 단점이 있다. 그것은 트랜지션 스타트에 미리 캐릭터를 할당해두는 방식이기 때문에 나중에 캐릭터를 선택할 수 있는 기능을 넣게 된다면, 다른 캐릭터로 시작하면 그 캐릭터는 이 콜라이더에 닿아도 다른 씬으로 이동하지 못할 수도 있다.
이것은 간단하게 만들어진 예시이기 때문에 발생한 문제로, 플레이어 캐릭터에 태그나 레이어를 설정하고, 태그나 레이어로 비교해서 통과시키는 방법으로 해결할 수 있다.
트랜지션 데스티네이션 게임 오브젝트(Transition Destination Game Object)
그림 5
트랜지션 데스티네이션 게임 오브젝트는 씬 트랜지션 데스티네이션 컴포넌트(Scene Transition Destination Component)와 캐릭터 스테이트 세터 컴포넌트(Character State Setter Component)로 구성되어 있다. 이 게임 오브젝트는 플레이어의 캐릭터가 씬 이동을 할 때 목적지 역할을 한다. 첫 번째 게임 플레이 씬인 Zone1에 두 개가 배치되어 있는데, 처음 게임이 시작되었을 때 배치되는 위치인 트랜지션 데스티네이션 스타트(Transition Destination Start)와 두 번째 게임 씬인 Zone2로부터 넘어왔을 때의 도착 지점인 트랜지션 데스티네이션 프롬 Zone2(Transition Destination From Zone2)가 그것이다.
public class SceneTransitionDestination : MonoBehaviour
{
public enum DestinationTag
{
A, B, C, D, E, F, G,
}
public DestinationTag destinationTag;
[Tooltip("This is the gameobject that has transitioned. For example, the player.")]
public GameObject transitioningGameObject;
public UnityEvent OnReachDestination;
}
씬 트랜지션 데스티네이션 컴포넌트에는 사실상 큰 기능 자체는 존재하지 않고, 씬 컨트롤러(Scene Controller)에서 씬이 전환된 직후에 씬 안에 존재하는 씬 트랜지션 데스티네이션 컴포넌트가 부착된 모든 게임 오브젝트를 가지고 와서 데스티네이션 태그(Destination Tag)를 비교해 일치하는 트랜지션 데스티네이션 게임 오브젝트의 위치에 플레이어의 캐릭터를 이동시키기 위한 표지판 역할을 한다.
캐릭터 스테이트 세터 컴포넌트(Character State Setter Component)
캐릭터 스테이트 세터 컴포넌트는 씬 트랜지션 테스티네이션 컴포넌트와 함께 트랜지션 데스티네이션 게임 오브젝트에 부착된 컴포넌트로, 씬 트랜지션 데스티네이션 컴포넌트가 도착 위치를 지정하는 역할을 한다면 캐릭터 스테이트 세터 컴포넌트는 씬에 도착한 직후의 캐릭터의 상태를 설정하는 역할을 한다.
기본적으로 공개되어 있는 프로퍼티는 Set Character Velocity, Set Character Facing Contents, Set State, Set Parameter가 있으며 Set Character Velocity는 씬에 진입했을 때의 캐릭터의 속도를 설정할 수 있고, Set Character Facing Contents는 캐릭터가 바라볼 방향, Set State는 캐릭터의 애니메이션, Set Parameter는 캐릭터 애니메이터의 매개변수 값을 설정하는 옵션이다.
그림 6
캐릭터 스테이트 세터 컴포넌트에서 눈여겨 볼 점은 [그림 5]에서와 같이 프로퍼티가 선택되지 않았을 때는 해당 프로퍼티에 연관된 옵션이 보이지 않다가 프로퍼티 값이 true로 설정되면 [그림 6]과 같이 프로퍼티와 연관된 옵션이 보이도록 에디터가 커스터마이징되어 있다는 점이다. 프로젝트 뷰에서 CharacterStateSetterEditor를 검색해서 CharacterStateSetterEditor.cs 파일을 확인해보면 어떤 식으로 프로퍼티 값에 따라서 보여줄 옵션을 설정할 수 있는지 배울 수 있다.
이렇게 유니티 에디터에서 필요하거나 사용되는 옵션만 보여주는 것 만으로도 에디터에서 작업하는 디자이너 개발자의 작업 효율을 크게 상승시킬 수 있다.
[Header("Character Velocity")]
public bool setCharacterVelocity;
public Vector2 characterVelocity;
[Header("Character Facing")]
public bool setCharacterFacing;
public bool faceLeft;
public Animator animator;
[Header("Character Animation State")]
public bool setState;
public string animatorStateName;
[Header("Character Animation Parameter")]
public bool setParameters;
public ParameterSetter[] parameterSetters;
그림 7
여기에 더불어 Header 어트리뷰트를 사용하면 [그림 7]과 같이 프로퍼티의 분류를 훨씬 명확하게 인지하도록 만들 수 있다.
VFX 컨트롤러 게임 오브젝트(VFX Controller Game Object)
그림 8
VFX 컨트롤러 게임 오브젝트는 VFX 컨트롤러 컴포넌트(VFX Controller Component)가 부착되어 있다. 이 게임 오브젝트의 목적은 캐릭터가 점프하거나 달릴 때 먼지가 일너나는 들의 이팩트를 관리하는 것이다.
VFX 컨트롤러 컴포넌트(VFX Controller Component)
VFX 컨트롤러 컴포넌트는 이펙트를 관리하는 역할의 컴포넌트이다. 이것은 다른 시스템 컴포넌트와 마찬가지로 싱글톤 패턴으로 만들어졌으며, 같은 이펙트 게임 오브젝트들이 계속해서 생성되고 파괴됨으로써 발생하는 성능 저하를 막기 위해서 오브젝트 풀링 기법을 사용하고 있다. 오브젝트 풀링 기법은 기초적인 최적화 기법으로 오브젝트가 생성/파괴될 때 발생하는 오버헤드를 막기 위해서 오브젝트를 재사용하는 기법을 말한다.
그림 9
VFX 컨트롤러 컴포넌트에서는 게임에서 사용될 VFX 프리팹들을 리스트에 담아서 관리하는데, 만약 같은 방식으로 생성되어야 하는 VFX지만 상황에 따라서 다른 VFX를 생성해야 경우, 예를 들어 캐릭터가 달릴 때 풀 바닥에서는 풀이 날리는 VFX가 발생해야 하지만, 흙 바닥에서 달릴 때는 흙 먼지가 날리는 VFX가 생성되도록 하기 위해서, Vfx Override로 특별한 경우를 정의하고 있다.
피직스 헬퍼 게임 오브젝트(Physics Helper Game Object)
피직스 헬퍼 게임 오브젝트는 피직스 헬퍼 컴포넌트(Physics Helper Component)를 가진 게임 오브젝트로서 게임 내에서 불리적인 처리에 도움을 주는 역할을 한다.
피직스 헬퍼 컴포넌트(Physics Helper Component)
피직스 헬퍼 컴포넌트는 게임이 플레이되는 상황에서 어디서든지 호출될 수 있기 때문에 싱글톤 패턴으로 작성되어 있으며, 캐릭터가 밟고 서는 플랫폼이나 타일맵에 관련된 물리적인 처리를 담당하고 있다.
사실 피직스 헬퍼 같은 컴포넌트는 개발자가 편의에 따라서 작성하기 나름인 스크립트이다. 게임마다 필요한 물리 연산이나 처리는 모두 다르기 마련이라, 필요한 물리 작업에 따라서 피직스 헬퍼의 내용은 천차만별로 달라질 수 있다. 다만, 이렇게 자주 사용되는 기능을 분류 별로 묶어서 어디서든지 호출할 수 있게 헬퍼 클래스로 만드는 작업은 관련된 기능을 이리저리 흩뜨려 놓는 것보다 확실히 더 나은 효율적인 작업을 보장한다.
이런 식으로 각각의 콜라이더가 따로 충돌을 감지하는 것이 아니라 두 콜라이더가 하나로 취급되어 충돌을 감지하고자 할 때, 컴포지트 콜라이더 2D를 사용하게 된다.
그림 6
컴포지트 콜라이더 2D 컴포넌트를 사용하는 방법은 위와 같이 통합하고자하는 콜라이더들의 상위에 컴포지트 콜라이더를 추가해주고,
그림 7
[그림 7]과 같이 하위에 속하는 콜라이더 컴포넌트들의 Used By Composite 프로퍼티를 true로 설정해주면 된다.
그림 8
그렇게 하면 상위 오브젝트를 선택했을때, [그림 8]과 같이 하위의 콜라이더들이 하나로 통합되어서 보이는 것을 볼 수 있다.
그림 9
로그에서도 상위 오브젝트에서의 충돌 체크만 발생하는 것을 알 수 있다.
리지드바디 2D(Rigidbody 2D)
그림 10
컴포지트 콜라이더 2D 컴포넌트를 게임 오브젝트에 부착하면 자동으로 리지드바디 2D 컴포넌트 역시 게임 오브젝트에 부착된다. 때문에 지형지물의 요소에 컴포지트 콜라이더 2D를 사용할 때는 이 리지드바디 2D 컴포넌트의 옵션에 신경써야 한다.
그림 11
옵션에 신경쓰지 않을 경우, [그림 11]처럼 캐릭터가 지형에 닿자마자 지형이 떨어지거나, 게임이 시작하자마자 지형이 추락해서 지형이 사라지는 모습을 보게 될 수도 있다.
그림 12
이렇게 컴포지트 콜라이더 2D 컴포넌트를 적용한 게임 오브젝트를 고정된 지형요소로 사용하고자 한다면 리지드바디2D의 바디타입을 Static으로 설정해야한다.
그림 13
생성 타입(Generation Type)
그림 14
컴포지트 콜라이더 2D 컴포넌트에는 생성 타입이라는 프로퍼티가 존재하는데 Synchronous와 Manual 옵션이 존재한다.
그림 15
Synchronous는 [그림 15]처럼 하위 콜라이더들이 변동되는 때마다 바로 통합된 콜라이더를 새로 만드는 옵션이고,
그림 16
Manual은 컴포지트 콜라이더 2D 컴포넌트가 처음 부착되는 시점 호은 콜라이더 재생성(Regenerate Collider) 버튼을 누른 시점에만 콜라이더를 만드는 옵션이다.
그림 17
[그림 17]과 같이 아래에 있는 노란 원이 애니메이션에 의해서 위치가 바뀌어도 콜라이더는 따라서 움직이지 않기 때문에 빈 공간에 충돌하는 것을 알 수 있다.
위의 설명에서 알 수 있듯이 Synchronous 옵션은 통합된 콜라이더가 변경되는 애니메이션에 따라서 지속적으로 업데이트가 되어야하는 경우에 사용하고, 반대로 Manual은 통합된 콜라이더가 일반 지형과 같이 변경되는 경우가 없는 경우에 사용된다.
지오메트리 타입(Geometry Type)
그림 18
그 다음 중요한 옵션은 지오메트리 타입이다. 이 프로퍼티는 콜라이더를 생성할 때 어떤 형태로 생성할 것인가를 결정한다. 옵션 값은 Outlines와 Polygons가 있다.
그림 19
그림 20
Outlines로 콜라이더를 생성하면 [그림 19]와 같이 내부에 아무선 선이 없이 생성되고, Polygons로 콜라이더를 생성하면 [그림 20]과 같이 내부에 선이 그어져서 나온다. 이 차이가 의미하는 것은 Outlines 옵션의 경우에는 콜라이더가 외부에 선만 그어져 있고 속은 비어있다는 뜻이고, Polygons 옵션은 내부가 꽉 차있다는 뜻이다.
콜라이더의 내부를 굳이 채울 필요가 있냐고 생각할 수도 있지만, 이것은 확실히 필요한 개념이다. 게임 내에서의 발생하는 충돌 감지나 레이캐스트는 주로 옆에서 날아오기 때문에 Outlines 옵션 만으로도 충분하지만 화면 밖에서 들어오는 터치나 사용자의 클릭 같은 이벤트는 개념적으로 위에서 들어오기 때문에 콜라이더의 내부가 차있는 것이 좋다.
public class Picker : MonoBehaviour
{
private void Update()
{
if (Input.GetMouseButtonDown(0))
{
var hitResult2D = Physics2D.Raycast(Camera.main.ScreenToWorldPoint(Input.mousePosition), transform.up, 0.1f);
Debug.Log("2D Raycast Result :: " + hitResult2D.collider.name);
}
}
}
위와 같이 마우스를 클릭한 지점에서 레이캐스트를 발사해서 콜라이더를 검출하는 코드를 작성해서 Outlines 옵션으로 만들어진 컴포지트 콜라이더와 Polygons 옵션으로 만들어진 컴포지트 콜라이더를 클릭하는 테스트를 진행해보면 그 차이를 명확하게 인지할 수 있다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
이제까지 타일맵에 사용될 타일 이미지를 만들고 가져오는 방법, 타일맵을 만들고 사용하는 방법들을 배웠다. 이제 만들어낸 타일맵을 이용해서 맵을 그려내면 게임 레벨이 될 것이다. 하지만 여기에 아직 부족한 점이 있다.
지금까지 배운 것들로는 맵을 그리기만 할 수 있다. 무슨 말인가 하면, 2D RPG 류의 게임에서는 어떤 타일은 벽이 되서 캐릭터가 이동하는 것을 막는 장애물이 되어야 하고, 플랫폼 게임(Platform Game)에서는 타일이 캐릭터가 딪고 설 바닥이 되어주어야 한다. 즉, 타일에 콜라이더를 추가해서 물리적인 작용이 가능하게 만들어야 한다는 뜻이다.
그림 1
플랫폼 게임을 만드는데 노란 공이 떨어져서 바닥에 닿으면 튕기게 만들고 싶다고 가정해보자.
그림 2
노란 공에 물리효과를 주기 위해서 Circle Collider 2D 컴포넌트와 Rigidbody 2D 컴포넌트를 부착해주었다. 그리고 꽤 그럴듯하게 공처럼 튀기게 만들기 위해서 물리 머티리얼(Physics Material)까지 넣어주었다.
그림 3
그림 4
하지만 타일맵에 물리적인 컴포넌트가 아무것도 없는 상태이기 때문에 플레이를 시작하면 떨어지는 공은 타일맵을 그냥 통과해버린다.
그림 5
타일맵 콜라이더 2D 컴포넌트(Tilemap Collider 2D Component)
이전 섹션을 진행해왔다면 하이어라키 뷰에 존재하는 타일맵은 게임 오브젝트하나로 존재하기 때문에 어떻게 콜라이더를 배치해야할지 난감할 수도 있다.
그림 6
타일맵을 위한 콜라이더를 유니티에서는 이미 제공하고 있다. 타일맵 콜라이더 2D 컴포넌트(Tilemap Collider 2D Component)가 바로 그것이다.
그림 7
타일맵 컴포넌트가 붙어있는 게임 오브젝트에 타일맵 콜라이더 2D 컴포넌트를 부착하면 씬에서 위의 이미지와 같이 각 타일마다 콜라이더가 생겼음을 알 수 있다.
그림 8
타일맵에 콜라이더 컴포넌트를 붙인 상태로 다시 게임을 플레이해보면 떨어진 공이 바닥에 맞고 튕기는 것을 볼 수 있다.
[그림 8]을 보면 타일맵 컴포넌트 2D를 이용해서 생성된 콜라이더가 각 타일마다 따로 생성되어 있는 것을 볼 수 있다. 이렇게 분할된 콜라이더는 퍼포먼스 상의 문제와 가끔 이동하는 캐릭터가 콜라이더에 끼어서 움직이지 못하게 되는 등의 문제가 발생할 수 있다.
그런 문제를 해결하기 위해서 제공되는 것이 컴포지트 콜라이더 2D 컴포넌트이다. 이 컴포넌트는 해당 컴포넌트가 붙어있는 게임 오브젝트의 하위에 존재하는 콜라이더들을 하나로 묶어주는 역할을 한다.
그림 9
컴포지트 콜라이더 2D 컴포넌트를 사용하기 위해서는 타일맵 콜라이더 2D 컴포넌트를 부착한 컴포넌트에 컴포지트 콜라이더 2D 컴포넌트를 부착하고 타일맵 콜라이더 2D 컴포넌트의 Used By Composite 프로퍼티를 체크해주면 된다.
그림 10
그렇게 하고 나서 씬 뷰에서 타일맵 게임 오브젝트를 선택해보면 초록색 콜라이더 박스가 타일마다 나누어지지 않고 하나로 합쳐져 있는 것을 확인할 수 있다.
그림 11
하지만 아직 설정이 다 끝나지 않았다. 플레이를 눌러보면 타일맵이 공과 함께 떨어지는 어이없는 상황이 발생한다. [그림 9]를 보면 그 이유를 조금 짐작할 수 있는데 컴포지트 콜라이더 2D 컴포넌트를 추가할 때, 리지드바디 2D 컴포넌트(Rigidbody 2D 컴포넌트)가 자동으로 추가된 것을 알 수 있는데, 리지드바디 컴포넌트는 게임 오브젝트가 외부의 힘이나 토크를 받아 사실적인 물리적인 운동을 보이도록 도와주는 컴포넌트이다.
그림 12
자동으로 추가된 리지드바디 2D 컴포넌트를 보면 바디 타입(Body Type)이 다이나믹(Dynamic)으로 설정있는 것을 알 수 있다. 즉 타일맵의 리지드바디가 고정된 것이 아니기 때문에 공과 함께 떨어지는 것이다.
그림 13
그림 14
바디 타입을 고정(Static)으로 변경하고 실행해보면 [그림 14]와 같이 타일맵이 떨어지지 않고 정상적으로 동작하는 것을 확인할 수 있다.
다만 컴포지트 콜라이더 2D를 사용하는 경우에 주의할 점은 하위에 있는 모든 콜라이더를 하나로 통합하기 때문에, 플랫폼 게임을 만들 때 벽 타일의 콜라이더와 바닥 타일의 콜라이더가 플레이어와 충돌 시 다른 동작을 하게 만들고 싶다면 벽 타일의 타일맵과 바닥 타일의 타일맵을 분리하거나, 캐릭터가 충돌한 방향을 검출해서 벽인지 바닥인지를 검출하는 등의 추가 작업이 필요하다.
지난 섹션에서는 간단하게 타일맵을 만들고 사용하는 방법에 대해서 알아보았다. 이번 섹션에서는 룰 타일 기능을 이용한 동일 타일을 연달아 놓았을 때, 자동으로 연결되는 기능을 구현하는 방법을 알아보자.
타일의 자동 연결은 어떻게?
같은 타일을 놓으면 오른쪽 십자가처럼 자동으로 연결되기를 바랄 수 있다. 하지만 유니티 타일맵 기본 기능 만으로는 같은 타일을 옆에 놓아봤자 왼쪽 십자가처럼 끊어진 십자가만 놓아지고 오른쪽 십자가처럼 만들려면 직접 일일이 배치를 해야한다.
유니티 2D 엑스트라(Unity 2D Extra)
타일을 자동으로 연결해주는 기능은 기본 타일맵에서는 제공하지 않고, 유니티 테크놀러지에서 만들어서 깃허브에 올려둔 별도의 기능인 2D 엑스트라를 임포트해서 사용해야 한다(링크에서 2D Extra를 다운로드 받으면 된다).
그리고 다운로드 받은 파일의 압축을 풀고 2d-extra-master 폴더를 프로젝트 뷰의 Assets 폴더 안에 넣어주면 된다.
룰 타일(Rule Tile)
유니티에서 같은 룰 타일을 근접 배치했을 때, 정해둔 규칙에 따라서 다른 스프라이트를 표시하도록 하는 것을 룰 타일(Rule Tile)이라고 부른다.
프로젝트 뷰에서 Create 버튼을 눌러보면 드롭다운 메뉴 최상단에 Tiles라는 새로운 항목이 생긴 것을 볼 수 있다. 이것은 방금 추가한 2D Extra 기능을 임포트하면서 생긴 것으로, Tiles 중에서 Rule Tile을 선택하면 새로운 룰 타일을 만들 수 있다.
룰 타일을 생성하고 선택해보면 위와 같은 화면이 표시된다.
룰 타일을 설정하는 순서로 먼저 디폴트 스프라이트와 디폴트 게임을 설정한다. 예제에서는 닫힌 타일을 기본 스프라이트로 정했고, 디폴트 게임 오브젝트로는 앞에서 만든 Wall 타일 팔레트를 설정했다.
아래의 Tiling Rule을 + 버튼을 클릭해서 추가하고 연결되어야 하는 경우의 수를 모두 정의해주면 된다. 약간은 반복성이 짙은 작업이지만, 모든 타일을 일일이 선택해서 작업하는 것보다는 한 번 타일 규칙을 설정하고 편하게 작업하는 것이다 좋다.
적절하게 타일링 규칙을 모두 설정했다면 설정한 룰 타일을 사용하고자 하는 타일 팔레트의 빈 칸에 드래그한다. 그러면 직접 만든 룰 타일이 팔레트에 포함된다.
그리고 씬 뷰에서 일반 타일과 룰 타일을 사용해서 타일을 그려보면 직접 정한 룰에 따라서 자동으로 타일이 연결되는 것을 확인할 수 있다.
타일링 규칙
타일 규칙
간단하게 룰 타일의 기능을 맛보았으니 이제 실제로 타일링 규칙들이 무엇을 의미하는지를 알아보자.
첫 번째 규칙은 초록색 화살표이다. 초록색 화살표는 해당 방향에 같은 룰 타일이 놓여져 있는 경우를 의미한다.
두 번째 규칙은 빨간색 엑스 표시이다. 이 표시는 해당 방향에 같을 룰 타일이 없는 경우를 의미한다.
룰 타일의 주요 규칙은 이 두 가지로 대부분 표현할 수 있다. 어느 방향에 같은 룰 타일이 있느냐 없느냐에 따라서 대부분의 경우를 구현할 수 있다.
방향규칙
하지만 모든 방향에 대한 경우를 일일이 구현하는 일은 굉장히 힘든 반복작업이기 때문에 룰 타일의 규칙에는 추가 방향 규칙 역시 제공한다.
Fixed
Fixed는 고정된 방향에만 적용하거나 방향에 상관이 없는 경우에 사용된다.
대체로 모든 방향에 타일이 있는 경우나 십자형태로 배치된 가운데 블록처럼, 가운데 들어가는 타일에 주로 사용된다.
Rotated
Rotated는 중심을 기준으로 90도, 180도, 270도 회전시킨 방향에도 똑같이 적용하는 규칙이다.
주로 십자가 끝부분처럼 이미지가 회전되어 표현되어야 하는 경우에 사용된다.
MirrorX
MirrorX는 좌우 방향으로 대칭시켜주는 규칙이다. 왼쪽 타일과 오른쪽 타일이 같을 때 사용된다.
MirrorY
MirrorY는 상하 방향으로 대칭시켜주는 규칙이다.
위쪽 타일과 아래쪽 타일이 같아서 대칭 시켜줄 때 주로 사용된다.
MirrorXY
MirrorXY는 MirrorX 규칙과 MirrorY 규칙을 섞은 것으로 상하좌우 모두 대칭시켜주는 규칙이다.
모서리 타일에 주로 사용된다.
출력 규칙
싱글(Single)
타일이 얼마나 설치되든 같은 이미지만 사용하려고 할 때 사용된다. 너무 많이 사용되면 반복되는 타일이 많아짐으로써 배경이 단조롭게 보이는 단점이 있다.
랜덤(Random)
여러 타일을 섞어서 무작위로 출력하는 방법이다. Size를 늘려서 중간에 깨진 타일을 섞어서 출력한다던가 Shuffle을 Rotated로 넣어서 회전된 타일을 출력한다던가 하는 방식으로 사용할 수 있다. 타일맵에 무작위성을 줌으로써 타일맵의 단조로움을 줄여줄수 있다.
대신 무작위로 사용되는 타일은 일반 타일과 회전 타일 등과의 연속성을 잘 확인해야 한다. 일반 타일이 무작위 출력된 타일이나 회전된 타일과의 연결이 부자연스럽게 이어지면 플레이어들의 눈에 심하게 띄는 문제가 발생한다.
애니메이션(Animation)
여러 타일을 설정된 시간에 맞춰 순서대로 출력하여 애니메이션을 보여주는 타일의 설정이다. 주로 배경에 흐르는 폭포수 같은 효과를 줄 때 주로 사용된다.
사용시 주의점
2D 엑스트라는 아직 유니티 테크놀러지 측에서도 개선 중인 기술로 룰 타일을 사용할 때, 주의해야할 점이 있다.
이 문제는 심각한 이슈사항인데, 타일 팔레트에 룰 타일을 올려둔 채로 씬의 타일맵에 계속 그려보면서 타일링 룰을 수정하면 어느 시점부터 심각한 수준의 메모리 누수가 발생한다. 특히 유니티 엔진이 응답없음 상태가 되고 메모리 점유율이 계속 올라가는 상태라면, 유니티를 종료하고 다시 실행해도 실행하자마자 메모리 누수가 시작될 확률이 높다.
그렇기 때문에 타일맵과 룰 타일을 안정적으로 사용하고 싶다면, 룰 타일의 타일링 룰을 먼저 작성한 뒤 팔레트를 만들어서 룰 타일을 올리고 간단하게 씬에서 테스트한 뒤, 문제가 없다면 그대로 사용하고, 만약 타일링 룰을 수정해야 한다면, 현재 타일 팔레트를 삭제하고 타일링 룰을 수정한 뒤 다시 타일 팔레트를 만들 것을 권장한다.
