유니티 콘텐츠 팀에서 제작한 2D 게임 키트는 아티스트와 디자이너 등의 개발자들이 코드 작성 작업을 제외하고 게임플레이를 쉽게 구성할 수 있게 하는 것이 목적이다. 이를 반대로 해석하면 프로그래머가 어떤 식으로 작업을 해주면 아티스트와 디자이너들이 더욱 손쉽게 게임 레벨을 구성할 수 있게 툴과 시스템을 만들 수 있는지를 배울 수 있다는 의미와 같다.
2D 게임 키트의 분석의 진행은 다음과 같이 이루어질 것이다.
게임 키드에 포함된 씬을 하나씩 살펴보면서 어떻게 게임 오브젝트들이 배치되어 있는지, UI 구성은 어떻게 되어 있는지, 디자이너 등의 개발자가 레벨 구성을 쉽게 하도록 도와주기 위해서 어떤 식으로 코드가 구성 되었는지 등을 살펴보게 될 것이다.
Explorer 2D 게임 키트 에셋 다운로드 및 세팅
우선 게임 키트를 에셋을 설치하기 위해 빈 프로젝트를 생성한다.
에셋 스토어에서 2D Game Kit를 검색해서 다운로드받은 뒤 임포트 작업을 진행한다.
에셋 임포트가 끝나면 위의 이미지처럼 2D 게임 키트의 에셋들이 추가된다.
Start 씬을 열어보면 위와 같은 게임화면이 게임 뷰에 나타난다. 이로써 게임 키트에 대한 분석을 하기 위한 준비가 끝났다.
참고
Explorer 2D Game Kit 분석은 2019.1 버전을 사용할 것을 권장한다. 2019.2 버전의 유니티를 사용할 경우, 움직이는 플랫폼 발판이나 밀어서 이동 가능한 상자 오브젝트가 제대로 작동하지 않을 가능성이 높다.
유니티에서 게임 오브젝트는 씬에 배치될 수 있는 오브젝트를 의미한다. 이 게임 오브젝트에 어떤 컴포넌트가 붙는가에 따라서 그 게임 오브젝트의 역할이 결정되는데, 씬에 하나만 배치되는 오브젝트는 컴포넌트를 직접 부착해서 배치할 수는 있지만 똑같은 오브젝트를 많이 배치해야 되는 경우에 매번 배치할 때마다 필요한 컴포넌트를 부착하는 작업을 해야한다면 이것은 매우 비효율적인 작업이 된다.
일일이 게임 오브젝트를 생성한 다음 컴포넌트를 붙이는 비효율에서 벗어나기 위해서 제일 처음 만들어진 게임 오브젝트를 복사해서 배치할 수도 있는데, 이것은 또 다른 비효율적인 작업에 봉착하게 된다. 만약 이렇게 붙여넣은 오브젝트들의 크기를 전부 2배로 키워야 한다면? 그럼 붙여넣은 게임 오브젝트들을 일일이 찾아서 스케일 값을 바꿔주어야 한다. 이것 역시 심각하게 비효율적인 작업이다.
이러한 예시 이외에 어떤 게임 오브젝트를 게임이 진행하는 도중에 생성해서 배치해야 된다면, 코드 상에서 빈 게임 오브젝트를 생성하고, 거기에 필요한 컴포넌트를 붙여서 일일이 초기화해서 배치를 하는 것 역시 비효율적이다.
비효율적인 작업들 1 : 새 오브젝트마다 손수 컴포넌트 붙이고 설정하기
앞서 제시한 예시들을 하나씩 따라가보자.
우리는 이제 씬에 이른바 "Elegance Black Box"라고 명명된 검은색의 Black Box 컴포넌트가 부착된 상자를 여러 개 배치하려고 한다. 이 멋진 검은 상자를 만들기 위해서 우리는 다음과 같은 작업을 해야한다.
먼저 새 상자를 만든다.
새 상자의 이름을 "Elegance Black Box"로 변경한다.
그 다음 머티리얼에 검은 색 머티리얼을 넣고 Black Box 컴포넌트를 붙여준다(사실 따로 순서를 진행할 수도 있지만 그만큼 번거롭고 지루해지기 때문에 그냥 합쳤다).
자 총 4단계의 과정을 거쳤다. 이 작업을 만들고자 하는 "Elegance Black Box"의 갯수만큼 반복하면 된다. 고작 4단계인데 이렇게 번거롭다. 만약 더 복잡한 구조의 게임 오브젝트라면 어떻겠는가?
비효율적인 작업들 2 : 배치된 게임 오브젝트 복제하기
유니티 엔진에서는 복제하고자 하는 게임 오브젝트를 선택하고 우클릭하여 [Duplicate] 항목을 선택하거나 [Ctrl + D] 단축키를 눌러서 복제할 수 있다.
와! 일일이 새 게임 오브젝트를 만들고 컴포넌트를 붙이는 작업을 하지 않아도 된다! 혁명적인가? 분명 여기까지는 혁명적이다. 하지만 원수같은 기획자들이 "Elegance Black Box"를 좀 더 우아하게 강조하기 위해서 크기를 25% 키우자고 주장했다.
그나마 예시에서는 갯수가 적고 하이어라키 뷰에서 오브젝트가 흩어져 있지 않아서 모두 선택해서 빠르게 해결했다. 하지만 하이어라키 뷰에서 다른 게임 오브젝트 밑에 숨어있다거나 흩어져있다면 일일이 찾아서 수정해야 한다. 물론 하이어라키 뷰의 검색 기능을 이용하면 훌륭하게 해결할 수 있을 지도 모른다. 그러나 이런 검색 작업 역시 비효율적인것은 사실이다.
비효율적인 작업들 3 : 코드에서 동적으로 생성하기
이번에는 동료 디자이너가 "멋진 검은 상자가 게임 중에 동적으로 생성되면 좋겠는데!"라고 말했다.
public static BlackBox CreateNewBlackBox()
{
var newBox = GameObject.CreatePrimitive(PrimitiveType.Cube).AddComponent<BlackBox>();
거기에 당신은 위와 같이 블랙 박스를 생성하는 코드를 만들어 냈다. 이러면 끝난 것일까? 아니다. 디자이너가 블랙 박스에 대해서 수정사항을 가지고 올 때마다 당신은 코드를 수정해야 한다. 거기에 컴파일 시간은 덤이다! 그리고 지금은 간단한 오브젝트라 코드가 몇 줄 되지 않지만 복잡한 오브젝트면 코드의 양이 늘어나고 거기에 더불어 버그의 확률도 함께 상승한다.
우리의 구세주 프리팹
이러한 모든 문제를 해결하기 위해서 있는 것이 바로 프리팹이다. 프리팹은 게임 오브젝트와 거기에 붙여진 컴포넌트와 그 프로퍼티들을 에셋의 형태로 저장하는 것이다.
프리팹 만들기
프리팹을 만드는 방법은 아주 간단하다. 하이어라키 뷰에서 프리팹으로 만들고자 하는 게임 오브젝트를 선택해서 프로젝트 뷰로 끌어다 놓기만 하면 된다. 프리팹이 된 게임 오브젝트는 앞의 아이콘이 무채색 육면체에서 파란 육면체로 바뀐다.
배치된 게임 오브젝트 한꺼번에 변경하기
이번에도 아까 전처럼 씬에 배치된 모든 블랙 박스의 크기를 변경하고 싶을 수 있다. 프리팹으로는 이런 작업이 아주 간단하다.
프로젝트 뷰에서 원본 프리팹을 선택하고 프리팹의 크기를 변경해주면 씬에 배치된 모든 프리팹 인스턴스의 크기가 함께 변경된다. 하지만 이 방법은 씬에 배치된 각각의 인스턴스의 프로퍼티가 수정된 상태라면 적용되지 않으니 주의해야 한다.
프리팹 인스턴스에서 편집
위 예시에서는 프리팹 원본에서 수정된 것을 프리팹 인스턴스로 적용되는 내용이었다. 반대로 씬에 배치된 프리팹 인스턴스를 수정하고 이것을 원본 프리팹에 적용할 수도 있다. 씬에 배치된 프리팹 인스턴스 게임 오브젝트를 선택하면 일반 게임 오브젝트와는 다르게 인스펙터 뷰의 게임 오브젝트의 이름 아래에 Prefab : Open, Select, Override 버튼을 볼 수 있다.
여기서 Open 버튼을 선택하면 선택된 프리팹의 원본만을 수정할 수 있는 전용 씬으로 이동된다. 여기서는 프로젝트 뷰에서는 보이지 않는 프리팹 원본의 깊은 자식 오브젝트까지 열어서 수정할 수 있게 된다. 또한 수정된 프리팹의 내용은 자동으로 저장되며 하이어라키 뷰의 프리팹 아이콘 옆의 < 버튼을 클릭하면 다시 원래 씬으로 돌아올 수 있다.
원본 프리팹을 더블 클릭하거나 씬에 배치된 프리팹 인스턴스 옆의 > 버튼을 클릭해도 프리팹 수정 씬으로 들어올 수 있다.
Select 버튼을 클릭하면 프로젝트 뷰의 원본 프리팹이 바로 선택된다.
Override 버튼은 만약 프리팹 인스턴스에 원본 인스턴스와 달라진 점이 있다면 내용이 나타난다. 여기서 Revert All을 선택하면 프리팹 인스턴스의 변경 사항이 초기화되고 프리팹 원본 값으로 돌아간다. Apply All을 선택하면 프리팹 인스턴스의 수정 사항이 반대로 프리팹 원본에 덮어 씌워진다.
프리팹 인스턴스화
프로젝트 뷰에 존재하는 프리팹 원본은 에셋 상태로 이 상태 그대로는 게임 씬에서 보거나 사용할 수 없다. 이것을 게임 씬에 배치하고 사용할 수 있게 생성하는 과정을 인스턴스화라고 한다. 프리팹 인스턴스화는 게임 오브젝트의 Instantiate() 함수를 이용해서 할 수 있다.
프로젝트 뷰에 있는 게임 오브젝트는 크게 두 가지 방법으로 가져올 수 있다.
Resources 폴더에서 가져오기
첫 번째 방법은 Resources 폴더에서 가져오는 것이다. 이 방법은 어느 경로이든 무관하게 가져오고자 하는 프리팹이 프로젝트 뷰에서 Resources 폴더 안에 들어있기만 하면 된다. 단, Resources 폴더에 들어있는 파일들은 게임이 실행되면 무조건 메모리에 적재되기 때문에 메모리 이슈를 일으키고 싶지 않다면, 필요한 에셋만을 Resources 폴더에 넣어둘 것을 권장한다.
public static BlackBox CreateNewBlackBox()
{
var boxPrefab = Resources.Load<BlackBox>("Elegance Black Box");
return Instantiate(boxPrefab);
}
그 다음 Resources.Load() 함수로 Resources 폴더 안의 프리팹을 가져와서 Instantiate() 함수로 씬에 생성할 수 있다.
씬에 배치된 게임 오브젝트의 컴포넌트의 프로퍼티로 참조하기
public class BoxSpawn : MonoBehaviour
{
[SerializeField]
private GameObject boxPrefab;
private void Start()
{
Instantiate(boxPrefab);
}
}
두 번째 방법은 씬에 배치된 게임 오브젝트에 부착된 컴포넌트의 프로퍼티로 프리팹 원본을 참조하고 있다가 생성하는 방법이다.
씬에 Box Spawner 게임 오브젝트를 만들고 위에서 작성한 Box Spawn 컴포넌트를 부착하고 Box Prefab 프로퍼티에 프리팹을 할당해주면 된다. 그러면 게임이 시작되면 박스 스포너가 블랙 박스를 생성하는 것을 확인할 수 있다.
기타
위에서 제시한 방법 이외에도 에셋 번들에서 가져와서 생성하는 방법 등 다른 기능과 연계된 심화 방법들이 존재한다.
프리팹의 장점
게임 오브젝트가 프리팹화됨으로써 얻을 수 있는 장점은 굉장히 많다. 첫 번째는 재사용이 굉장히 편하다는 점이고, 씬에 흩어져서 배치된 프리팹의 인스턴스들을 한꺼번에 수정하기도 쉽다. 그리고 프로그래머가 컴포넌트만 제대로 만들어준다면, 게임 디자이너들이 프로그래머에게 요청하지 않고도 손쉽게 게임 요소들을 수정할 수 있다는 점이 제일 큰 장점이다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
게임의 장르와 배경들의 종류는 많고도 많지만 그 어떤 종류의 게임이던간에 아주 가벼운 게임이 아닌 이상 반드시 등장하는 장면이 있다. 그 장면은 바로 로딩 씬이다. 다들 로딩 씬이 등장하면 언제쯤 지나가려나 하며 로딩 바에 마우스를 올리고 정말로 바가 채워지고 있는지 확인해본 경험이 있을 것이다. 게임을 처음으로 접했던 어린 시절에는 이런 로딩 씬이 왜 필요한지도 몰랐고 그냥 재미있는 게임을 할 시간을 잡아먹는 나쁜 녀석이라는 생각만 가득했다.
하지만 게임 개발을 시작한 이후로 이 로딩 씬만큼 중요한 씬이 또 없다는 것을 깨달을 수 있었다. 로딩 씬의 역할은 단지 시간만 잡아먹는 것이 아니라 게임의 씬이 전환될 때 다음 씬에서 사용될 리소스들을 물리적인 저장소에서 읽어와서 메모리에 올리는 등의 게임을 하기 위한 준비를 하는 작업이다.
만약에 게임에 로딩 장면이 존재하지 않는다면 어떻게 될까? 아마 플레이어는 다음 씬으로 넘어가는 동안 가만히 게임이 멈춘 화면을 보고 있거나 까만 화면을 보고 있어야 한다. 그런 일이 발생한다면 로딩이 얼마나 진행되었는지 알 수 없고 이 게임이 로딩 중인지 정지한 것인지 구분할 수도 없어서 너무 답답할 것이다. 그렇기 때문에 씬이 전환될 때에는 로딩 씬을 만들어서 플레이어에게 로딩이 얼마나 진행되었는지 알려주면서 플레이어가 지루하지 않게 게임 게임 팁이나 게임 스토리등을 보여주는 것이다.
개념
이전에는 로딩하는 씬을 전용으로 만들어서 로딩하는 방법을 소개했었다. 이번에는 그 방법과는 다르게 마치 무대에서 잠시 커튼을 내리고 무대를 교체하는 것과 비슷하게 로딩 바를 보여주는 UI를 전면에 씌운 뒤 로딩하는 방법을 구현해본다.
구현하기
앞에서는 로딩 씬의 필요성에 대해서 이야기했다면 이제는 실제로 로딩 씬을 유니티에서 구현하는 방법을 알아보자.
코드 작성하기
씬 화면을 가리고 로딩작업을 진행하는 SceneLoader 클래스를 생성하고 다음의 순서로 코드를 작성한다.
using System.Collections;
using UnityEngine;
using UnityEngine.SceneManagement;
using UnityEngine.UI;
SceneLoader는 기존 씬을 UI로 가리고 다른 씬을 불러오는 등의 작업을 해야하기 때문에 UnityEngine.SceneManagement와 UnityEngine.UI 네임스페이스를 using 선언해준다.
public class SceneLoader : MonoBehaviour
{
protected static SceneLoader instance;
public static SceneLoader Instance
{
get
{
if(instance == null)
{
var obj = FindObjectOfType<SceneLoader>();
if(obj != null)
{
instance = obj;
}
else
{
instance = Create();
}
}
return instance;
}
private set
{
instance = value;
}
}
[SerializeField]
private CanvasGroup sceneLoaderCanvasGroup;
[SerializeField]
private Image progressBar;
private string loadSceneName;
public static SceneLoader Create()
{
var SceneLoaderPrefab = Resources.Load<SceneLoader>("SceneLoader");
return Instantiate(SceneLoaderPrefab);
}
private void Awake()
{
if (Instance != this)
{
Destroy(gameObject);
return;
}
DontDestroyOnLoad(gameObject);
}
}
SceneLoader의 기본적인 구성은 위와 같다. 이 클래스는 싱글톤 패턴으로 작성되어서 어디서든지 호출할 수 있도록 만들어졌으며, 전체 패널의 투명도를 조절하는 방식으로 씬 로딩 UI를 페이드 인 아웃을 시켜서 자연스럽게 등장시키기 위해서 캔버스 그룹을 사용한다. 그리고 진행도를 표현하기 위해서 이미지를 멤버 변수로 가진다.
커튼 방식으로 로딩 UI를 구현하는 핵심 코드는 위와 같다. 씬을 로딩하는 로직 자체는 로딩 씬 교체 방식과 같으며 여기에 추가적으로 씬을 로딩하기 직전에 로딩 UI를 페이드 인하는 부분과 로딩이 완전히 끝난 지점에서 페이드 아웃되는 코드가 추가되었다. 그리고 씬 로딩 완료가 완전히 완료된 시점을 확인하기 위해서 SceneManager의 SceneLoaded 콜백에 함수를 추가해주는 코드 역시 추가되었다.
코드를 모두 작성했다면 저장하고 에디터로 돌아간다.
로딩 UI 구성
로딩 UI를 구성하기 위해서 SceneLoader라는 이름으로 캔버스(Canvas)를 하나 만들고 거기에 캔버스 그룹과 아까 만든 Scene Loader 컴포넌트를 부착한다. 그리고 Scene Loader Canvas Group 프로퍼티에 방금 추가한 캔버스 그룹 컴포넌트를 할당해준다.
그 다음엔 화면 전체를 덮는 이미지 하나를 Background라는 이름으로 추가한다. 이 이미지는 화면 전체를 가림으로써 씬이 교체되는 것을 플레이어의 시선에서 가려주고 마우스 입력을 방지하는 용도로 사용된다. 여기에는 검은 이미지 이외에도 플레이어의 시선을 끌만한 컨셉아트나 배경 이미지를 넣어줄 수 있다.
그리고 씬 로딩 진행도를 보여줄 이미지를 Progress Bar라는 이름으로 추가하고 위의 이미지와 같이 설정한다.
Progress Bar 이미지 설정이 끝났다면 SceneLoader 게임 오브젝트를 선택한 뒤, 위의 이미지와 같이 SceneLoader의 액티브를 끄고, Canvas Group의 Alpha 값을 0으로 설정한다. 그리고 Progress Bar 이미지를 Scene Loader 컴포넌트의 Progress Bar 프로퍼티에 할당해준다.
마지막으로 프로젝트 뷰에 Resources 폴더를 만들고 방금 만든 SceneLoader 게임 오브젝트를 드래그해서 프리팹으로 만들어주고 게임 오브젝트를 씬에서 삭제한다.
테스트 세팅하기
위의 과정을 모두 마쳤다면 두 개의 씬을 새로 만들고 씬이 전환되었음을 확인하기 위해서 각 씬에 다른 모양의 게임 오브젝트를 추가해준다.
using UnityEngine;
public class SceneLoadTester : MonoBehaviour
{
private void Update()
{
if (Input.GetKeyDown(KeyCode.Space))
{
SceneLoader.Instance.LoadScene("Scene2");
}
}
}
그리고 SceneLoader의 기능을 테스트하기 위해 스페이스바를 누르면 SceneLoader를 호출하는 코드를 작성하고 Scene1에 게임 오브젝트를 생성해서 스크립트를 넣어준다.
상단의 [File > Build Settings] 메뉴를 선택하거나 [Ctrl + Shift + B]를 눌러서 빌드 세팅 창을 연 다음 만든 씬들을 빌드될 씬 목록에 넣어준다.
테스트
그런 후에 첫 번째 씬에서 플레이 버튼을 눌러 게임을 실행하고 스페이스바를 누르면 첫 번째 씬에서 자연스럽게 로딩 UI가 나타난 후에 아래쪽 로딩 바가 자연스럽게 차오르고 두 번째 씬으로 넘어가는 것을 확인할 수 있다.
위의 예시에서는 씬의 로딩 진행도 만을 이용해서 진행 정도를 체크했지만, 유니티에서는 다음 씬에서 사용될 애셋 번들을 불러오는 것 또한 로딩에 포함될 수 있고, 만약 네트워크 게임을 제작한다면 네트워크 동기화 정도도 포함될 수 있다.
여담으로 일부 게임 제작자의 경우에는 로딩 시간이 너무 짧아서 로딩 시간동안 보여주고자 하는 팁이나 스토리 등이 너무 빠르게 스쳐지나간다고 생각하는 경우에는 일부러 로딩 속도를 늦추거나 페이크 로딩 시간을 넣어서 로딩 시간을 일부러 길게 만드는 경우도 있다.
여러 종류의 프로그램을 만들다 보면 어떤 문제를 해결하기 위해서 비슷한 형태의 코드를 만들게 되는 경우가 자주 있다. 이런 비슷한 유형의 문제를 해결하는 방법을 묶어낸 것을 바로 프로그래밍 패턴이라고 한다. 이러한 프로그래밍 패턴은 유니티 엔진에서 스크립트를 작성하는데도 똑같이 유효하기 때문에 프로그래밍 패턴을 공부하는 것이 상당한 도움이 될 것이다.
일반적인 싱글톤 패턴(Singleton Pattern)
싱글톤 패턴은 프로그래밍 패턴 중에서 상당히 자주 쓰이는 패턴 중 하나로, 클래스의 오브젝트를 단 하나만 생성하고자 할 때 주로 사용된다.
public class SingletonClass
{
private SingletonClass()
{ }
public static SingletonClass Instance
{
get
{
if (Instance == null)
{
Instance = new SingletonClass();
}
return Instance;
}
private set
{
Instance = value;
}
}
}
일반적인 C# 프로그래밍에서는 싱글톤 패턴이 위의 코드와 같이 구현된다. 기본 생성자를 private으로 지정해서 클래스 외부에서 호출하지 못하게 하여서 클래스 외부에서는 오브젝트를 생성할 수 없게 한다. 그리고 Instance라는 프로퍼티를 호출했을 때, Instance 프로퍼티가 비어있다면 처음 한 번 생성하고 그 뒤로를 생성한 Instance를 호출하는 식으로 구현한다.
위와 같은 방법으로 오브젝트를 하나만 생성가능하게 만드는 것이 바로 싱글턴 패턴이다. 싱글톤 패턴은 예를들어 센서와 통신하는 클래스처럼 단 하나만 존재해야하는 경우에 사용된다.
유니티 엔진에서의 싱글톤 패턴
유니티 엔진에서도 싱글톤 패턴을 응용해서 사용할 수 있다. 일단 유니티 엔진에서 일반 C# 클래스로 싱글톤 패턴을 사용한다면 위의 코드 예시와 똑같이 구현하면 된다. 하지만 모노비헤이비어를 상속받는 컴포넌트 클래스에서의 싱글톤 패턴 구현은 조금 달라진다.
var newSingleton = new GameObject("Singleton Class");
newSingleton.AddComponent<SingletonClass>();
우선, new 연산자를 통해서 생성되는 일반 C# 클래스의 오브젝트와 달리 컴포넌트 클래스의 오브젝트를 생성할 때는 게임 오브젝트를 생성한다음에 AddComponent() 함수를 이용해서 게임 오브젝트에 컴포넌트를 붙여줘야 한다. 그렇기 때문에 일반 C# 클래스와 같이 생성자를 private으로 바꾸는 방법으로는 클래스 외부에서의 오브젝트의 생성을 막을 수 없다.
뿐만 아니라, 이미 컴포넌트가 부착된 오브젝트가 씬에 만들어져 있는 경우도 있을 수 있고, 컴포넌트가 부착된 프리팹이 생성되는 경우까지 있다. 그렇기 때문에 일반 C# 클래스와 같이 생성자로 외부 생성을 막는 방법은 전혀 유효하지 않다.
public class SingletonClass : MonoBehaviour
{
private staticSingletonClass instance;
public static SingletonClass Instance
{
get
{
if (instance == null)
{
var obj = FindObjectOfType<SingletonClass>();
if (obj != null)
{
instance = obj;
}
else
{
var newSingleton = new GameObject("Singleton Class").AddComponent<SingletonClass>();
instance = newSingleton;
}
}
return instance;
}
private set
{
instance = value;
}
}
private void Awake()
{
var objs = FindObjectsOfType<SingletonClass>();
if (objs.Length != 1)
{
Destroy(gameObject);
return;
}
DontDestroyOnLoad(gameObject);
}
}
컴포넌트 클래스의 특성에 유의해서 싱글톤 패턴을 작성하면 위의 예시 코드와 같이 구현된다.
우선, 일반 C# 클래스에서와 같이 instance가 null인지 검사를 하되 곧바로 오브젝트를 생성하지 말고 씬에 이미 게임 오브젝트에 부착된 싱글톤 클래스가 있는지 검사하고 만약, 이미 있다면 instance에 넣어준 뒤, instance를 반환한다. 씬에 존재하지 않는 상태라면, 싱글톤 클래스의 오브젝트가 컴포넌트로 부착된 게임 오브젝트를 생성하고 이를 반환한다.
그리고 게임 오브젝트가 생성되거나 컴포넌트가 게임 오브젝트에 부착되었을 때 가장 먼저 실행되는 Awake() 함수에서 씬에 이미 존재하는 같은 싱글톤 오브젝트가 있는지 검사를 한 뒤, 이미 존재하는 오브젝트가 있다면 지금 생성된 오브젝트를 파괴하는 작업을 진행한다.
마지막으로 씬을 전환할때 싱글톤 패턴이 적용된 오브젝트가 파괴되는 것을 막기 위해 DontDestroyOnLoad()를 적용해준다. 보통 유니티에서 싱글톤 패턴을 적용하는 경우는 시스템 매니저와 같이 시스템 전체를 관리하는 오브젝트처럼 여러 씬에서 살아있어야 하는 오브젝트가 대부분이다.
싱글톤 패턴의 장점과 유용성
public class SingletonTester : MonoBehaviour
{
void Start()
{
var singleton = SingletonClass.Instance;
singleton.Function();
}
}
싱글톤 패턴의 장점과 유용성은 게임이나 프로그램에 단 하나만 존재해야하는 클래스를 다룰 때 나타난다. 단 하나만 존재해야 하는 클래스의 생성을 적절하게 통제할 수 있으며, 전체에 단 하나이기 때문에 따로 매번 오브젝트를 생성하거나 탐색해서 찾을 필요없이 instance 프로퍼티를 통해서 빠르게 접근할 수 있다.
싱글톤 패턴의 단점과 해악
싱글톤 패턴의 장점은 프로그램에 단 하나여야 하는 클래스의 오브젝트를 다루는데 뛰어난 효율성을 보여준다는 것인데, 어떤 개발자들은 빠르고 편하게 사용할 수 있다는 점에 주목한다. 그리고 싱글톤 패턴의 모든 단점과 해악성은 여기에서 나온다.
오브젝트를 따로 탐색하거나 생성할 필요가 없이 바로 instance 호출로 바로 가져올 수 있다는 점에 취해서 쉽게 남용되는 패턴이 바로 싱글톤 패턴이다. 이 때문에 조금이라도 가져오기 어려운 오브젝트가 있으면 싱글톤 패턴으로 만들어버리거나, 기능을 싱글톤 패턴을 가진 오브젝트에 합쳐버리는 우를 범하게 된다.
일이 이렇게 진행되기 시작하면, 여기저기서 각기 다른 클래스의 instance를 호출하는 구조로 코드의 흐름이 알기 어려워지고 싱글톤 패턴을 가진 오브젝트의 코드 크기는 점점 거대해져서 기형적으로 비대한 구조가 만들어지며, 나중에는 따로 분리해내거나 정리하기 어려워진다.
때문에 싱글톤 패턴을 사용할 때는 편리함에 너무 취하지 않아야 하며, 해당 클래스가 너무 비대화되지 않는지, 처리하기로 설계한 기능 이외의 것을 처리하려고 하고 있지 않은지를 끊임없이 경계해야 한다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
유니티에서는 씬(Scene, 장면) 단위로 게임이 플레이될 공간이나 장소 등을 구현하며, 한 씬에서 다른 씬으로 넘어갈 때는, 기존 씬이 언로드되면서 기존 씬에 있던 게임 오브젝트(Game Object)는 모두 파괴된다. 아래의 예시를 보자.
위 이미지는 Destroy Object라는 이름의 게임 오브젝트 다섯 개를 배치한 Test Scene의 캡처 화면이다. 플레이가 시작되면 아무것도 없는 Other Scene으로 넘어가게 설계되어 있다.
설계대로 플레이 버튼을 누르면 Test Scene에서 Other Scene으로 이동하며 씬에 배치되어 있는 다섯 개의 Destroy Object가 사라지는 것을 볼 수 있다.
DontDestoryOnLoad 사용법
위의 예시에서 볼 수 있듯이 유니티에서는 새로운 씬을 불러오면 이전 씬에 남아있던 게임 오브젝트들은 모두 사라진다. 하지만 개발자의 의도나 설계에 따라서 몇몇 게임 오브젝트들은 다른 씬으로 넘어갈 때 파괴되지 않도록 할 필요성이 생길 수도 있다.
public class DontDestoryObject : MonoBehaviour
{
private void Awake()
{
DontDestroyOnLoad(gameObject);
}
}
씬 로드시 파괴하지 않을 오브젝트로 만들려면 바로 위의 코드처럼 DontDestroyOnLoad()함수를 호출해서 매개변수로 자신의 게임 오브젝트를 전달하면 된다.
이렇게 파괴하지 않을 오브젝트로 만들어진 게임 오브젝트는 게임 플레이가 시작되고 함수가 호출되면 위의 이미지처럼 Test Scene에서 DontDestroyOnLoad 영역으로 옮겨진다.
만들어진 스크립트를 Dont Destroy Game Object라는 이름의 구체 게임 오브젝트에 붙인 다음 플레이 버튼을 눌러보면 Test Scene에서 Other Scene으로 넘어가면서 Destroy Object는 전부 사라지지만 Dont Destory Game Object는 남아있는 것을 확인할 수 있다.
Don't Destroy On Load 게임 오브젝트 파괴하기
Don't Destory On Load로 설정된 게임 오브젝트는 그럼 파괴할 수 없는 것인가? 라고 생각할 수도 있다. 하지만 제일 앞의 단어가 Can't가 아니라 Don't 임을 명심하자. 파괴할 수 없는 것이 아니라 파괴하지 않는 것이다.
Destroy(gameObject);
Don't Destory On Load로 설정된 게임 오브젝트는 Destroy() 함수를 이용하면 손쉽게 다시 파괴할 수 있다.
설계시 주의 사항
Don't Destory On Load 게임 오브젝트를 사용한 설계를 할 때는 주의할 점이 있다.
위의 이미지와 같이 Don't Destory On Load가 적용된 게임 오브젝트가 들어있는 씬과 다른 씬을 여러 번 왔다 갔다 하는 방식의 구조를 생각해보자.
Test Scene에 진입하면 파괴하지 않는 게임 오브젝트가 Don't Destroy On Load 영역으로 이동되면서 씬을 이동해도 파괴되지 않게 될 것이다. 그 다음 Other Scene으로 이동했다가 다시 Test Scene으로 돌아오면 어떻게 될까? 파괴하지 않는 게임 오브젝트는 Don't Destroy On Load 영역으로 이동했으니 더 이상 Test Scene에 남아있지 않을까?
아니다. 씬을 새로 불러올 때는 해당 씬의 초기 상태로 불러오기 때문에 파괴하지 않는 게임 오브젝트는 새 것이 생성되어 있으며 이것은 그대로 다시 Don't Destroy On Load 영역으로 옮겨진다. 즉, 똑같은 파괴하지 않는 게임 오브젝트가 2개가 되어버리는 것이다.
그대로 두 씬을 왕복하면 같은 게임 오브젝트가 계속해서 누적되는 문제가 발생한다. 이 문제는 그대로 불필요한 메모리 사용을 증가시킬 것이고, 뿐만 아니라 예측할 수 없는 작동 문제 역시 일으킬 수 있다.
해결 방법 1 : 중복 검사 후 파괴하기
public class DontDestoryObject : MonoBehaviour
{
private void Awake()
{
var obj = FindObjectsOfType<DontDestoryObject>();
if (obj.Length == 1)
{
DontDestroyOnLoad(gameObject);
}
else
{
Destroy(gameObject);
}
}
}
해당 게임 오브젝트를 파괴하지 않는 게임 오브젝트로 설정하는 이유가 게임 내에서 단 하나만 존재하는 오브젝트를 만들고자 하는 경우라면 가장 간단하고 손쉬운 해결 방법으로는 게임 오브젝트가 생성된 직후에 실행되는 Awake() 함수에서 현재 씬에 있는 같은 오브젝트가 몇 개인지 검사를 한 뒤 2개 이상이라면 생성된 오브젝트를 파괴하는 방법이다.
해결 방법 2 : 초기화 씬 구현하기
두 번째 방법으로는 파괴하지 않는 게임 오브젝트를 생성하는 전용 씬을 만들고 그 씬에서 파괴하지 않는 게임 오브젝트를 생성한 뒤 다른 씬만 오가는 방식이다. 이 방법 게임 내에서 단 하나만 존재하는 오브젝트를 만들고자 하는 경우에 유용한 방법이다.
해결 방법 3 : 라이프 사이클 관리하기
파괴하지 않는 게임 오브젝트는 위의 예시에서 볼 수 있듯이 씬을 이동한다고 해서 파괴되지 않는다. 그렇기 때문에 제대로 관리하지 않는다면 생성되는 족족 Don't Destroy On Load 영역에 게임 오브젝트가 쌓일 것이다.
위의 두 가지 방법은 게임 내에서 해당 오브젝트를 단 하나만 만들고자 하는 경우에 유용한 방법이다. 만약 해당 오브젝트가 파괴되지 않아야 하지만 여러 개의 오브젝트를 만드는 것을 허용하는 구조라면 위의 방법들은 적절하지 않다.
또한 앞선 예시들은 모두 파괴하지 않을 게임 오브젝트를 정적으로 씬에 배치를 해서 씬이 불러와질 때마다 생성되게 만드는 구조를 채용했다. 하지만 이와 반대로 같은 종류의 파괴되지 않을 게임 오브젝트를 여러 개 생성하는 것을 허용하려고 한다면 정적인 씬 배치 방식보다는 프리팹으로 관리하며 원하는 시점에 생성하는 것이 좋다.
이러한 경우에 더욱 주의해야할 점은 파괴하지 않는 게임 오브젝트들이 동적으로 여러 개 생성되어 작동하고 있으며, 이후에도 계속해서 생성된다는 점이다. 때문에 파괴하지 않은 게임 오브젝트들에 대해서 제대로 추적/관리해야 하며 해당 오브젝트의 사용이 끝나면 파괴하는 식으로 라이프 사이클(Life Cycle) 관리가 필요하다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
스크립터블 오브젝트(Scriptable Object)는 유니티에서 제공하는 대량의 데이터를 저장하는 데 사용할 수 있는 데이터 컨테이너이다. 스크립터블 오브젝트를 사용하면 값의 사본이 생성되는 것을 방지하여 프로젝트의 메모리 사용을 줄일 수 있으며 이것은 모노비헤이비어(MonoBehaviour) 스크립트에 변경되지 않는 데이터를 저장하는 프리팹을 사용하는 프로젝트에서 유용하다고 한다. 변경되지 않는 데이터를 사용하는 프리팹의 데이터를 일반 변수로 구현할 경우 인스턴스화 할때마다 프리펩에 이 데이터에 대한 자체 사본이 생성되는데, 스크립터블 오브젝트를 사용하면 메모리에 스크립터블 오브젝트의 데이터 사본만을 저장하고 이를 참조하는 방식으로 작동한다고 한다.
스크립터블 오브젝트 클래스는 유니티에서 기본적으로 제공하는 것으로 모노비헤이비어 클래스와 마찬가지로 기본 유니티 오브젝트(Unity Object)에서 파생되지만, 모노비헤이비어와 달리, 게임 오브젝트에 컴포넌트로 부착할 수 없고, 프로젝트에 에셋으로 저장된다.
스크립터블 오브젝트 만들기
스크립터블 오브젝트를 만들기 위해서는 ScriptableObject 클래스를 상속받아서 아래의 코드와 같이 구현하면 된다.
using UnityEngine;
[CreateAssetMenu(fileName = "Zombie Data", menuName = "Scriptable Object/Zombie Data", order = int.MaxValue)]
public class ZombieData : ScriptableObject
{
[SerializeField]
private string zombieName;
public string ZombieName { get { return zombieName; } }
[SerializeField]
private int hp;
public int Hp { get { return hp; } }
[SerializeField]
private int damage;
public int Damage { get { return damage; } }
[SerializeField]
private float sightRange;
public float SightRange { get { return sightRange; } }
[SerializeField]
private float moveSpeed;
public float MoveSpeed { get { return moveSpeed; } }
}
CreateAssetMenu 속성은 스크립터블 오브젝트 스크립트를 이용해서 빠르고 쉽게 에셋을 생성할 수 있게 만들어주는 속성이다.
코드를 빌드하고 에디터로 돌아가서 Assets 메뉴를 보면 추가한 menuName 대로 Create>Scriptable Object>Zombie Data 항목이 새로 생긴 것을 볼 수 있다.
그리고 그 항목을 선택하면 Zombie Data의 스크립터블 오브젝트가 생성된다.
생성된 Zombie Data 스크립터블 오브젝트를 선택해보면 위의 이미지와 같이 좀비의 정보에 대한 프로퍼티들이 보인다.
스크립터블 오브젝트 사용하기
앞에서 스크립터블 오브젝트를 생성하는 방법을 배웠으니 이번에는 스크립터블 오브젝트를 사용하는 방법에 대해서 알아보자.
이름
체력
데미지
시야
이동속도
일반 좀비(Normal Zombie)
10
3
10
3
스피드 좀비(Speed Zombie)
5
3
10
5
파워 좀비(Power Zombie)
10
5
10
2
탱커 좀비(Tank Zombie)
20
1
10
1.5
센서 좀비(Sensor Zombie)
3
1
20
2
위의 표와 같이 다섯 종류의 좀비 데이터를 담을 스크립터블 오브젝트를 만들어보자.
우선 제일 처음 만든 스크립터블 오브젝트를 복사해서 다섯 개로 만든다.
각 파일의 이름을 좀비 종류에 맞게 바꿔준다.
그리고 표의 내용에 맞게 각 스크립터블 오브젝트에 데이터를 입력해준다.
public class Zombie : MonoBehaviour
{
[SerializeField]
private ZombieData zombieData;
public ZombieData ZombieData { set { zombieData = value; } }
public void WatchZombieInfo()
{
Debug.Log("좀비 이름 :: " + zombieData.ZombieName);
Debug.Log("좀비 체력 :: " + zombieData.Hp);
Debug.Log("좀비 공격력 :: " + zombieData.Damage);
Debug.Log("좀비 시야 :: " + zombieData.SightRange);
Debug.Log("좀비 이동속도 :: " + zombieData.MoveSpeed);
}
}
그 다음에는 좀비 데이터를 사용할 좀비 클래스를 작성하고
좀비 클래스를 사용하는 프리팹을 만들어준다.
public enum ZombieType
{
Normal, Power, Sensor, Speed, Tank
}
public class ZombieSpawner : MonoBehaviour
{
[SerializeField]
private List<ZombieData> zombieDatas;
[SerializeField]
private GameObject zombiePrefab;
void Start()
{
for (int i = 0; i < zombieDatas.Count; i++)
{
var zombie = SpawnZombie((ZombieType)i);
zombie.WatchZombieInfo();
}
}
public Zombie SpawnZombie(ZombieType type)
{
var newZombie = Instantiate(zombiePrefab).GetComponent<Zombie>();
newZombie.ZombieData = zombieDatas[(int)type];
return newZombie;
}
}
좀비를 소환하는 좀비 스포너 클래스를 만들고 Start() 함수에는 테스트용 코드를 작성한다.
코드를 작성한 뒤에는 씬에 좀비 스포너 게임 오브젝트를 만들고 거기에 Zombie Spawner 컴포넌트를 붙인 뒤에, 앞에서 만든 좀비 데이터 스크립터블 오브젝트와 좀비 프리팹을 프로퍼티에 넣어준다.
모든 세팅을 마친 다음에 플레이 버튼을 눌러서 실행해보면 좀비 게임 오브젝트가 생성되고, 콘솔 창에서는 각 좀비의 정보가 출력되는 것을 볼 수 있다.
그리고 하이어라키 뷰에서 각 좀비의 게임 오브젝트를 살펴보면 각 Zombie 컴포넌트의 Zombie Data 프로퍼티에는 서로 다른 좀비 데이터 스크립터블 오브젝트들이 참조되고 있는 것을 확인할 수 있다.
스크립터블 오브젝트의 특징 및 응용
에디터에서는 스크립터블 오브젝트에 데이터를 저장하는 작업이 언제나 가능하지만, 배포된 빌드에서는 데이터를 저장할 수 없고 개발시 설정한 스크립터블 오브젝트 에셋에 저장된 데이터만을 사용할 수 있다.
그리고 스크립터블 오브젝트는 에셋 파일 형태로 관리되기 때문에 에셋번들 태그를 이용해서 에셋 번들로 빌드하고 배포하는 방식으로 게임 데이터를 업데이트시키는데 사용할 수도 있다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
유니티로 게임을 개발할 때, 게임 씬에 배치되며 하이어라키 뷰에 존재하는 객체를 게임 오브젝트(Game Object)라고 하는데, 이 게임 오브젝트에 부착되는 컴포넌트를 컴포넌트 클래스라고 하고, 게임 오브젝트에 컴포넌트로 부착되지 않고 메모리 상에만 있는, 코드 상에서만 다루어질 클래스를 일반 C# 클래스라고 하자.
왜 이런 복잡한 분류가 있어야 되느냐 싶겠지만, 게임을 개발하다고 보면 유니티에서 기본적으로 제공하는 모노비헤이비어를 상속받는 게임 오브젝트에 컴포넌트로 부착될 클래스 이외의 일반적인 C# 클래스 역시 필요한 시점이 반드시 온다.
컴포넌트 클래스(Component Class)
public class ComponentClass : MonoBehaviour
{
// Start is called before the first frame update
void Start()
{
}
// Update is called once per frame
void Update()
{
}
}
유니티 엔진에서 C# 스크립트를 생성하면 생성된 클래스를 기본적으로 모노비헤이비어(MonoBehaviour) 클래스를 상속받으며 위의 예시 코드와 같이 기본적으로 Start() 함수와 Update() 함수가 만들어진 채로 스크립트가 생성된다.
이렇게 모노비헤이비어 클래스를 상속받는 클래스는 위의 이미지처럼 인스펙터 뷰에서 Add Component 버튼을 통해서 게임 오브젝트에 부착될 수 있으며, 모노비헤이비어 클래스에서 상속받는 다양한 프로퍼티와 함수를 활용할 수 있다. 그리고 게임 오브젝트가 생성될 때는 Start() 함수, 게임 오브젝트가 업데이트되는 동안에는 Update() 함수, 소멸될 때는 OnDestroy() 함수 등 다양한 상황에서 호출되는 콜백 함수 역시 제공받는다.
일반 C# 클래스
public class CSharpClass
{
}
일반 C# 클래스는 모노비헤이비어 클래스를 상속받지 않으며, 게임 오브젝트에 컴포넌트로 부착되지 않는 코드 내에서만 동작하는 클래스를 만들고자 할 때 사용된다. 모노비헤이비어 클래스로부터 상속받는 프로퍼티와 함수들을 사용하지는 못하지만, 컴포넌트로 부착될 필요가 없거나 씬에 배치될 필요가 없는 오브젝트 일 때 사용된다.
일반 C# 클래스는 인스펙터 창의 Add Component 버튼에서 검색해도 게임 오브젝트에 부착할 수 없게 표시되지 않는다.
일반 C# 클래스를 다룰 때 실수할 수 있는 부분
public class CSharpClass:MonoBehaviour
{
// Start is called before the first frame update
void Start()
{
}
// Update is called once per frame
void Update()
{
}
}
그런데 유니티 에디터에서 .cs파일을 처음 생성하면 위와 같이 코드가 생성된다. 일반적으로 유니티에 입문한지 얼마 되지 않은 개발자들은 이때 생성한 클래스의 모노비헤이비어(MonoBehaviour) 클래스 상속을 그대로 두고 사용한다.
이 클래스가 컴포넌트 클래스라면 상관없는 문제지만, 일반 C# 클래스라면 문제가 발생할 수 있다. 우선은 모노비헤이비어 클래스를 상속받음으로써 불필요한 프로퍼티가 생성되는 점이 첫 번째 문제이고, 두 번째 문제는 일반 C# 클래스로써 설계해놓고 게임 오브젝트와 혼용해서 사용하려는 시도가 발생할 수 있다는 점이다.
예시로 코드 내에서 CSharpClass에 모노비헤이비어 클래스를 상속시키고 일반 C# 클래스에서도 실행가능한 기능과 컴포넌트 클래스로서 게임 오브젝트에 부착되었을 때만 가능한 기능을 섞어둔 코드를 아래와 같이 작성해보겠다.
public class CSharpClass
:
MonoBehaviour
{
public int i = 10; void Start() { Debug.Log("CSharpClass :: Start()"); }
void Update()
{
Debug.Log("CSharpClass :: Update()"); }
public void SomeFunction1() { Debug.Log(string.Format("CSharpClass :: Function1({0})", i));
}
public void SomeFunction2() { Debug.Log(string.Format("CSharpClass :: Function2()")); StartCoroutine(SomeCoroutine()); }
이런 CSharpClass를 컴포넌트가 아닌 일반 C# 오브젝트처럼 사용하려고 하면 생성해서 사용하려고 시도할 것이고 아직 유니티에서의 스크립팅 작업에 익숙하지 않은 개발자라면 일반 C#과 모노비헤이비어에서 상속받는 기능을 혼용해서 사용하려고 시도할 수 있다. 마치 아래의 코드 예시와 같이 :
ComponentClass는 게임 오브젝트에 부착될 컴포넌트 클래스이며, 일반적인 C#의 오브젝트 생성 방식을 통해서 CSharpClass를 생성하고 멤버 함수들을 호출하는 역할을 한다. SomeCoroutine()의 호출순서를 보장하기 위해서 코루틴 함수를 통해서 호출했다.
모노비헤이비어를 상속받은 CSharpClass를 기존 C# 방식으로 생성한 뒤 호출 테스트를 하기위해서 씬에 빈 게임 오브젝트를 ComponentClass 컴포넌트를 부착하고 플레이 버튼을 눌러보자.
그러면 위와 같은 로그를 얻을 수 있는데, 위 로그를 통해서 확인할 수 있는 사실은 다음과 같다.
1. 게임 오브젝트가 시작될 때, 실행되어야 하는 Start() 함수와 게임 오브젝트가 존재하는 동안 호출되어야할 Update() 함수가 호출되지 않는다.
2. Debug.Log(some)은 null이라고 표시된다. 즉, 오브젝트가 null reference 상태이다.
3. 하지만 SomeClass의 멤버함수인 SomeFunction1() 함수는 정상적으로 호출되었고 멤버변수 i의 값도 정상적으로 출력되었다. 즉, 오브젝트 자체는 생성되었다.
4. ComponentClass의 게임 오브젝트가 매개체가 되어 호출한 코루틴은 정상으로 동작했다.
5. CSharpClass의 게임 오브젝트가 매개체가 되어 호출한 코루틴은 null reference가 발생하며 동작에 실패했다.
이를 통해서 알 수 있는 사실은 C# 방식으로 모노비헤이비어를 상속받은 클래스를 생성하면 오브젝트는 생성되지만, 게임 오브젝트는 생성되지 않는다는 것이다. 그렇기 때문에 모노비헤이비어에서 상속받아오는 Start() 함수, Update() 함수, StartCoroutine() 함수의 호출에 실패하는 것이다. 이런 문제가 발생하는 것을 막기 위해서 일반 C# 클래스로 설계된 클래스의 .cs 파일을 유니티 엔진에서 생성하면 반드시 모노비헤이비어 클래스 상속을 제거해주어야만 한다.
컴포넌트 클래스와 일반 C# 클래스의 생성
위의 예시를 통해서 알 수 있는 점은 일반 C# 클래스에서는 모노비헤이비어를 상속받지 말아야 한다는 점과 컴포넌트 클래스와 일반 C# 클래스의 생성방법은 다르다는 것이다. 그렇다면 컴포넌트 클래스와 일반 C# 클래스는 각각 어떻게 생성해주어야 하는가를 알아보자.
우선 CSharpClass와 ComponentClass의 코드를 다음과 같이 수정하자.
CSharpClass.cs
public class CSharpClass
{
public int i = 10;
public void SomeFunction1() { Debug.Log(string.Format("CSharpClass :: Function1({0})", i));
그 다음에는 ObjectGenerator라는 이름으로 클래스를 만들고 다음처럼 코드를 작성한다.
public class ObjectGenerator : MonoBehaviour
{
void Start()
{
var gameObj = new GameObject();
gameObj.AddComponent<ComponentClass>();
var obj = new CSharpClass();
obj.SomeFunction1();
StartCoroutine(obj.SomeCoroutine());
}
}
간단한 코드 해설을 덧붙이자면, 게임 오브젝트의 경우 new GameObject()를 호출하면 자동으로 씬에 빈 게임 오브젝트 하나가 배치된다. 그리고 컴포넌트 클래스는 게임 오브젝트의 AddComponent<>() 함수를 호출해서 해당 게임 오브젝트에 컴포넌트로 부착할 수 있다.
일반 C# 클래스는 C#에서와 같이 new 연산자를 통해서 오브젝트를 생성할 수 있다. 그리고 일반 C# 클래스의 멤버 함수로 들어가 있는 코루틴 함수의 경우에는 일반 C# 클래스가 스스로 Start Coroutine을 할 수는 없지만, 다른 게임 오브젝트의 Start Coroutine을 통해서는 코루틴을 시작할 수 있다.
이를 테스트하기 위해서 씬에 게임 오브젝트 하나를 배치하고 Object Generator 컴포넌트를 붙여준다.
그리고 에디터에서 플레이 버튼을 눌러 실행해보면 New Game Object라는 이름의 게임 오브젝트가 하나 새로 생성되고 ComponenetClass가 컴포넌트로 부착되는 것을 볼 수 있으며
로그를 통해서는 컴포넌트 클래스의 함수와 일반 C# 클래스의 함수가 정상적으로 동작하는 것을 확인할 수 있다.
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
유니티 개발을 처음으로 공부하는 개발자들은 기본적으로 게임 오브젝트의 위치를 이동시키는 코드를 작성하려고 할 때, 제일 먼저 떠올리는 코드는 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개발자라면 제발 렉트 트랜스폼을 애용하자. 이상한 문제를 만나기 전에...
[유니티 어필리에이트 프로그램]
아래의 링크를 통해 에셋을 구매하시거나 유니티를 구독하시면 수익의 일부가 베르에게 수수료로 지급되어 채널의 운영에 도움이 됩니다.
