베르의 프로그래밍 노트

Programming 

- 

로딩 씬(Loading Scene) 구현하기(커튼 방식)

작성 기준 버전 :: 2019.1.4f1

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

게임의 장르와 배경들의 종류는 많고도 많지만 그 어떤 종류의 게임이던간에 아주 가벼운 게임이 아닌 이상 반드시 등장하는 장면이 있다. 그 장면은 바로 로딩 씬이다. 다들 로딩 씬이 등장하면 언제쯤 지나가려나 하며 로딩 바에 마우스를 올리고 정말로 바가 채워지고 있는지 확인해본 경험이 있을 것이다. 게임을 처음으로 접했던 어린 시절에는 이런 로딩 씬이 왜 필요한지도 몰랐고 그냥 재미있는 게임을 할 시간을 잡아먹는 나쁜 녀석이라는 생각만 가득했다.

하지만 게임 개발을 시작한 이후로 이 로딩 씬만큼 중요한 씬이 또 없다는 것을 깨달을 수 있었다. 로딩 씬의 역할은 단지 시간만 잡아먹는 것이 아니라 게임의 씬이 전환될 때 다음 씬에서 사용될 리소스들을 물리적인 저장소에서 읽어와서 메모리에 올리는 등의 게임을 하기 위한 준비를 하는 작업이다.

만약에 게임에 로딩 장면이 존재하지 않는다면 어떻게 될까? 아마 플레이어는 다음 씬으로 넘어가는 동안 가만히 게임이 멈춘 화면을 보고 있거나 까만 화면을 보고 있어야 한다. 그런 일이 발생한다면 로딩이 얼마나 진행되었는지 알 수 없고 이 게임이 로딩 중인지 정지한 것인지 구분할 수도 없어서 너무 답답할 것이다. 그렇기 때문에 씬이 전환될 때에는 로딩 씬을 만들어서 플레이어에게 로딩이 얼마나 진행되었는지 알려주면서 플레이어가 지루하지 않게 게임 게임 팁이나 게임 스토리등을 보여주는 것이다.

개념

이전에는 로딩하는 씬을 전용으로 만들어서 로딩하는 방법을 소개했었다. 이번에는 그 방법과는 다르게 마치 무대에서 잠시 커튼을 내리고 무대를 교체하는 것과 비슷하게 로딩 바를 보여주는 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를 페이드 인 아웃을 시켜서 자연스럽게 등장시키기 위해서 캔버스 그룹을 사용한다. 그리고 진행도를 표현하기 위해서 이미지를 멤버 변수로 가진다. 

public void LoadScene(string sceneName)
{
    gameObject.SetActive(true);
    SceneManager.sceneLoaded += LoadSceneEnd;
    loadSceneName = sceneName;
    StartCoroutine(Load(sceneName));
}

private IEnumerator Load(string sceneName)
{
    progressBar.fillAmount = 0f;
    yield return StartCoroutine(Fade(true));

    AsyncOperation op = SceneManager.LoadSceneAsync(sceneName);
    op.allowSceneActivation = false;

    float timer = 0.0f;
    while (!op.isDone)
    {
        yield return null;
        timer += Time.unscaledDeltaTime;

        if (op.progress < 0.9f)
        {
            progressBar.fillAmount = Mathf.Lerp(progressBar.fillAmount, op.progress, timer);
            if (progressBar.fillAmount >= op.progress)
            {
                timer = 0f;
            }
        }
        else
        {
            progressBar.fillAmount = Mathf.Lerp(progressBar.fillAmount, 1f, timer);

            if (progressBar.fillAmount == 1.0f)
            {
                op.allowSceneActivation = true;
                yield break;
            }
        }
    }
}

private void LoadSceneEnd(Scene scene, LoadSceneMode loadSceneMode)
{
    if(scene.name == loadSceneName)
    {
        StartCoroutine(Fade(false));
        SceneManager.sceneLoaded -= LoadSceneEnd;
    }
}

private IEnumerator Fade(bool isFadeIn)
{
    float timer = 0f;

    while(timer <= 1f)
    {
        yield return null;
        timer += Time.unscaledDeltaTime * 2f;
        sceneLoaderCanvasGroup.alpha = Mathf.Lerp(isFadeIn ? 0 : 1, isFadeIn ? 1 : 0, timer);
    }

    if(!isFadeIn)
    {
        gameObject.SetActive(false);
    }
}

커튼 방식으로 로딩 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가 나타난 후에 아래쪽 로딩 바가 자연스럽게 차오르고 두 번째 씬으로 넘어가는 것을 확인할 수 있다.

위의 예시에서는 씬의 로딩 진행도 만을 이용해서 진행 정도를 체크했지만, 유니티에서는 다음 씬에서 사용될 애셋 번들을 불러오는 것 또한 로딩에 포함될 수 있고, 만약 네트워크 게임을 제작한다면 네트워크 동기화 정도도 포함될 수 있다.

여담으로 일부 게임 제작자의 경우에는 로딩 시간이 너무 짧아서 로딩 시간동안 보여주고자 하는 팁이나 스토리 등이 너무 빠르게 스쳐지나간다고 생각하는 경우에는 일부러 로딩 속도를 늦추거나 페이크 로딩 시간을 넣어서 로딩 시간을 일부러 길게 만드는 경우도 있다.

이렇게 로딩 UI를 무대의 커튼처럼 전면에 깔아서 로딩하는 방법 이외에도 아예 로딩씬을 불러온 뒤에 다음 씬을 로딩하는 방법도 있으며 해당 방법은 링크에서 확인할 수 있다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Programming 

- 

유니티에서의 싱글톤 패턴 활용

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

여러 종류의 프로그램을 만들다 보면 어떤 문제를 해결하기 위해서 비슷한 형태의 코드를 만들게 되는 경우가 자주 있다. 이런 비슷한 유형의 문제를 해결하는 방법을 묶어낸 것을 바로 프로그래밍 패턴이라고 한다. 이러한 프로그래밍 패턴은 유니티 엔진에서 스크립트를 작성하는데도 똑같이 유효하기 때문에 프로그래밍 패턴을 공부하는 것이 상당한 도움이 될 것이다.

일반적인 싱글톤 패턴(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# 클래스로 싱글톤 패턴을 사용한다면 위의 코드 예시와 똑같이 구현하면 된다. 하지만 모노비헤이비어를 상속받는 컴포넌트 클래스에서의 싱글톤 패턴 구현은 조금 달라진다.

우선 모노비헤이비어를 상속받는 컴포넌트 클래스와 일반 C# 클래스의 차이점을 알아둬야 한다.

var newSingleton = new GameObject("Singleton Class");

newSingleton.AddComponent<SingletonClass>();

우선, new 연산자를 통해서 생성되는 일반 C# 클래스의 오브젝트와 달리 컴포넌트 클래스의 오브젝트를 생성할 때는 게임 오브젝트를 생성한다음에 AddComponent() 함수를 이용해서 게임 오브젝트에 컴포넌트를 붙여줘야 한다. 그렇기 때문에 일반 C# 클래스와 같이 생성자를 private으로 바꾸는 방법으로는 클래스 외부에서의 오브젝트의 생성을 막을 수 없다.

뿐만 아니라, 이미 컴포넌트가 부착된 오브젝트가 씬에 만들어져 있는 경우도 있을 수 있고, 컴포넌트가 부착된 프리팹이 생성되는 경우까지 있다. 그렇기 때문에 일반 C# 클래스와 같이 생성자로 외부 생성을 막는 방법은 전혀 유효하지 않다.

public class SingletonClass : MonoBehaviour

{

    private static SingletonClass 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를 호출하는 구조로 코드의 흐름이 알기 어려워지고 싱글톤 패턴을 가진 오브젝트의 코드 크기는 점점 거대해져서 기형적으로 비대한 구조가 만들어지며, 나중에는 따로 분리해내거나 정리하기 어려워진다.

때문에 싱글톤 패턴을 사용할 때는 편리함에 너무 취하지 않아야 하며, 해당 클래스가 너무 비대화되지 않는지, 처리하기로 설계한 기능 이외의 것을 처리하려고 하고 있지 않은지를 끊임없이 경계해야 한다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

DontDestroyOnLoad 

- 

파괴하지 않을 게임 오브젝트 만들기

작성 기준 버전 :: 2019.1.4f1

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

유니티에서는 씬(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) 관리가 필요하다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Scriptable Object 

- 

스크립터블 오브젝트(Scriptable Object) 기본 사용법

작성 기준 버전 :: 2019.1 ~ 2019.2

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

스크립터블 오브젝트(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 스크립터블 오브젝트를 선택해보면 위의 이미지와 같이 좀비의 정보에 대한 프로퍼티들이 보인다.

스크립터블 오브젝트 사용하기

앞에서 스크립터블 오브젝트를 생성하는 방법을 배웠으니 이번에는 스크립터블 오브젝트를 사용하는 방법에 대해서 알아보자.

위의 표와 같이 다섯 종류의 좀비 데이터를 담을 스크립터블 오브젝트를 만들어보자.

우선 제일 처음 만든 스크립터블 오브젝트를 복사해서 다섯 개로 만든다.

각 파일의 이름을 좀비 종류에 맞게 바꿔준다.

그리고 표의 내용에 맞게 각 스크립터블 오브젝트에 데이터를 입력해준다.

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 프로퍼티에는 서로 다른 좀비 데이터 스크립터블 오브젝트들이 참조되고 있는 것을 확인할 수 있다.

스크립터블 오브젝트의 특징 및 응용

에디터에서는 스크립터블 오브젝트에 데이터를 저장하는 작업이 언제나 가능하지만, 배포된 빌드에서는 데이터를 저장할 수 없고 개발시 설정한 스크립터블 오브젝트 에셋에 저장된 데이터만을 사용할 수 있다.

그리고 스크립터블 오브젝트는 에셋 파일 형태로 관리되기 때문에 에셋번들 태그를 이용해서 에셋 번들로 빌드하고 배포하는 방식으로 게임 데이터를 업데이트시키는데 사용할 수도 있다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Programming

- 

일반 C# 클래스와 게임 오브젝트의 컴포넌트로써의 클래스

유니티로 게임을 개발할 때, 게임 씬에 배치되며 하이어라키 뷰에 존재하는 객체를 게임 오브젝트(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());
    }

    public IEnumerator SomeCoroutine()
    {
      yield return null;
        Debug.Log("CSharpClass :: SomeCoroutine()");
    }

}

이런 CSharpClass를 컴포넌트가 아닌 일반 C# 오브젝트처럼 사용하려고 하면 생성해서 사용하려고 시도할 것이고 아직 유니티에서의 스크립팅 작업에 익숙하지 않은 개발자라면 일반 C#과 모노비헤이비어에서 상속받는 기능을 혼용해서 사용하려고 시도할 수 있다. 마치 아래의 코드 예시와 같이 :

public class ComponentClass : MonoBehaviour

{

    void Start()

    {

        StartCoroutine(CreateCSharpClassObject());

    }

 

   private IEnumerator CreateCSharpClassObject()

    {

       var some = new CSharpClass();

        Debug.Log(some);

        some.SomeFunction1();

        yield return StartCoroutine(some.SomeCoroutine());

        some.SomeFunction2();

    }

}

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));

    }

 

    public IEnumerator SomeCoroutine()
    {
      yield return null;
        Debug.Log("CSharpClass :: SomeCoroutine()");
    }

}

ComponentClass.cs

public class ComponentClass : MonoBehaviour

{

    void Start()

    {

        Debug.Log("ComponentClass :: Start");

    }

 

    void Update()

    {

        Debug.Log("ComponentClass :: Update");

    }

}

그 다음에는 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# 클래스의 함수가 정상적으로 동작하는 것을 확인할 수 있다.

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

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

[투네이션]

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

[디스코드 채널]

UNet 

- 

UNet 지원 중단과 새로운 네트워크 지원 예정

이전 포스트에서 유니티에서 지원하는 네트워크 게임 구현 API인 UNet에 관한 내용을 다룬 적이 있으며, 추후에 추가적인 내용을 다룰 예정이었지만 지난 2018년 8월 2일에 유니티 공식 블로그에 게시된 글에 의하면 UNet은 deprecated 되었으며 새로운 네트워크 API를 지원하기 위한 준비를 하고 있다고 이야기하고 있다.

UNet 튜토리얼 (1) - 개요 글에서 이야기하였듯이 UNet의 구조는 위의 이미지처럼 전송 계층에 가까운 LLAPI(Low Level API)와 게임에 필요한 기능을 제공하는 HLAPI(High Level API)로 나누어져 있다. 이 LLAPI와 HLAPI는 유니티의 계획에 의하면 :

1. HLAPI는 2018.4(LTS) 이후 더 이상 유니티와 함께 제공되지 않음. 2018.4(LTS) 출시일 이후 2년 동안 유니티의 장기 지원 정책에 따라 중요한 수정 사항 제공.

2. LLAPI는 2019.4(LTS) 이후 더 이상 유니티와 함께 제공되지 않음. 2019.4(LTS) 출시일  이후 2년 동안 중요한 수정 사항 제공.

3. 유니티 릴레이 서버 및 레거시 매치 메이커 서비스는 2018.4(LTS) 제공 이후 3년 이상 계속 운영하며 다음 서비스로 전환 계획.

UNet은 더 이상 사용되지 않지만 ECS(Entity Component System)와 대응이 되는 차세대 네트워크 기능을 곧 제공할 예정이다. 유니티가 제공할 예정인 기능은 다음과 같다.

1. 기존 UNet의 HLAPI 및 LLAPI를 대체하며 DOTS와 호환되는 새로운 네트워킹 계층.

2. P2P 지원 릴레이 서버를 대체하는 멀티 플레이 게임 서버 호스팅 서비스.

3. 레거시 매치 메이커 서비스를 대체하는 새로운 매치 메이킹 서비스.

유니티의 네트워크 API 제공 계획은 다음과 같습니다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Programming

-

로딩 씬(Loading Scene) 구현하기

(씬 교체 방식)

작성 기준 버전 :: 2019.2.9f1

게임의 장르와 배경들의 종류는 많고도 많지만 그 어떤 종류의 게임이던간에 아주 가벼운 게임이 아닌 이상 반드시 등장하는 장면이 있다. 그 장면은 바로 로딩 씬이다. 다들 로딩 씬이 등장하면 언제쯤 지나가려나 하며 로딩 바에 마우스를 올리고 정말로 바가 채워지고 있는지 확인해본 경험이 있을 것이다. 게임을 처음으로 접했던 어린 시절에는 이런 로딩 씬이 왜 필요한지도 몰랐고 그냥 재미있는 게임을 할 시간을 잡아먹는 나쁜 녀석이라는 생각만 가득했다.

하지만 게임 개발을 시작한 이후로 이 로딩 씬만큼 중요한 씬이 또 없다는 것을 깨달을 수 있었다. 로딩 씬의 역할은 단지 시간만 잡아먹는 것이 아니라 게임의 씬이 전환될 때 다음 씬에서 사용될 리소스들을 물리적인 저장소에서 읽어와서 메모리에 올리는 등의 게임을 하기 위한 준비를 하는 작업이다.

만약에 게임에 로딩 장면이 존재하지 않는다면 어떻게 될까? 아마 플레이어는 다음 씬으로 넘어가는 동안 가만히 게임이 멈춘 화면을 보고 있거나 까만 화면을 보고 있어야 한다. 그런 일이 발생한다면 로딩이 얼마나 진행되었는지 알 수 없고 이 게임이 로딩 중인지 정지한 것인지 구분할 수도 없어서 너무 답답할 것이다. 그렇기 때문에 씬이 전환될 때에는 로딩 씬을 만들어서 플레이어에게 로딩이 얼마나 진행되었는지 알려주면서 플레이어가 지루하지 않게 게임 팁이나 게임 스토리등을 보여주는 것이다.

개념

로딩 씬을 구현하는 방법에는 여러가지 방법이 있을 수 있지만 이번 섹션에서는 로딩씬을 불러들인 다음에 호출하는 씬을 비동기로 호출하는 방법을 사용한다.

구현하기

앞에서는 로딩 씬의 필요성에 대해서 이야기했다면 이제는 실제로 로딩씬을 유니티에서 구현하는 방법을 알아보자. 

코드 작성하기

로딩 씬을 불러오고 로딩작업을 진행하는 LoadingSceneManager 클래스를 생성하고 다음의 코드를 작성한다.

using System.Collections;

using UnityEngine;

using UnityEngine.UI;

using UnityEngine.SceneManagement;

 

public class LoadingSceneManager : MonoBehaviour

{

    public static string nextScene;

 

    [SerializeField]

    Image progressBar;

 

    private void Start()

    {

        StartCoroutine(LoadScene());

    }

 

    public static void LoadScene(string sceneName)

    {

        nextScene = sceneName;

        SceneManager.LoadScene("LoadingScene");

    }

 

    IEnumerator LoadScene()

    {

        yield return null;

 

        AsyncOperation op = SceneManager.LoadSceneAsync(nextScene);

        op.allowSceneActivation = false;

 

        float timer = 0.0f;

        while (!op.isDone)

        {

            yield return null;

 

            timer += Time.deltaTime;
            if (op.progress < 0.9f)            {                progressBar.fillAmount = Mathf.Lerp(progressBar.fillAmount, op.progress, timer);                if (progressBar.fillAmount >= op.progress)                {                    timer = 0f;                }            }            else            {                progressBar.fillAmount = Mathf.Lerp(progressBar.fillAmount, 1f, timer);
                if (progressBar.fillAmount == 1.0f)                {                    op.allowSceneActivation = true;                    yield break;                }            }

        }

    }

}

처음 씬을 불러오는 방법을 배우는 유니티 게임 제작자의 경우에는 대부분 SceneManager.LoadScene()을 사용하지만, 로딩 씬을 만들기 위해서는 SceneManager.LoadSceneAsync()를 사용해야 한다. LoadScene()의 경우에는 동기 방식으로 불러올 씬을 한꺼번에 불러오고 다른 모든 것이 불러오는 동안 기다리는 방식으로 불러오는 도중에는 다른 작업을 할 수 없게 되지만, LoadSceneAsync()의 방식은 비동기 방식으로 씬을 불러오는 도중에도 다른 작업이 가능한 방식이다. 로딩의 진행 정도는 LoadSceneAsync() 함수가 AsyncOperation 클래스 형식으로 반환한다.

위의 코드에서는 AsyncOperation 클래스의 객체인 op를 통해서 allowSceneActivation을 false로 설정하는데, 이 옵션은 씬을 비동기로 불러들일 때, 씬의 로딩이 끝나면 자동으로 불러온 씬으로 이동할 것인가를 의미한다. 로딩씬에서 이 값을 false로 설정하는 것은 로딩이 완료되었을 때, 자동으로 다음 씬으로 넘어가지 않고 기다린다는 의미이다. allowSceneActivation이 false일 때는 씬이 로드될 때, 95%까지만 로딩되고 더 이상 불러들이지 않는다. 다시 allowSceneActivation을 true로 변경하면 그 때 마무리 로딩을 완료하고 씬을 불러오게 된다.

코드 작성을 완료했다면 코드를 저장하고 에디터로 넘어간다.

씬 구성

그 다음에는 로딩 씬을 구성한다.

로딩 씬을 위의 이미지와 같이 구성하자. 초록색 막대는 다음 씬이 얼마나 로딩되었는지 알려주는 진행막대(Progress Bar)이다. 배경은 아무런 이미지 없이 카메라가 찍고 있는 텅 빈 씬을 보여주고 있지만, 실제의 게임에서는 그 게임의 일러스트나 게임 장면 등을 넣을 수 있고, 덤으로 게임 팁(Tip)이나 게임의 배경이 되는 스토리를 보여줄 수도 있다. 그렇게 하면 엘리베이터에 거울을 달아두면 엘리베이터 탑승자들이 거울을 보느라 엘리베이터가 조금 느려도 속도에 신경을 덜 쓰게 되는 것처럼 로딩을 기다리는 유저들 또한 배경 이미지나 팁, 배경 스토리를 읽으면서 로딩의 지루함을 덜어낼 수 있게 되는 것이다.

진행막대로 사용되는 이미지의 경우에는 스케일을 조정해서 로딩의 진행도를 표시할 수도 있지만, 만약 위의 이미지처럼 단색의 이미지를 사용하는 것이 아닌 경우에는 이미지가 찌그러져 출력될 것이기 때문에 가능하다면 Image Type을 Filled를 사용할 것을 권장한다. Fill Method를 Horizontal로 설정하면 수평으로 채워지고 Fill Origin를 Left로 하면 이미지가 왼쪽부터 채워진다. 그리고 Fill Amount를 이용해서 로딩이 얼마나 진행되었는지 표시할 수 있다.

그 다음에는 로딩 씬에 게임 오브젝트를 하나 생성하고 Loading Scene Manager로 이름을 지은다음에 LoadingSceneManager 스크립트를 추가한다. 그리고 하이어라키 뷰에서 Progress Bar 이미지를 Progress Bar 프로퍼티에 끌어다 넣는다.

테스트 세팅하기

위의 과정을 모두 마쳤다면 두 개의 씬을 새로 만들고 씬이 전환되었음을 확인하기 위해서 각 씬에 다른 모양의 게임 오브젝트를 추가해준다.

using UnityEngine;
public class SceneLoadTester : MonoBehaviour
{
    private void Update()
    {
        if (Input.GetKeyDown(KeyCode.Space))
        {
            LoadingSceneManager.LoadScene("Scene2");
        }
    }
}

그리고 LoadingSceneManager의 기능을 테스트하기 위해 스페이스바를 누르면 LoadingSceneManager를 호출하는 코드를 작성하고 Scene1에 게임 오브젝트를 생성해서 스크립트를 넣어준다.

상단의 [File > Build Settings] 메뉴를 선택하거나 [Ctrl + Shift + B]를 눌러서 빌드 세팅 창을 연 다음 만든 씬들을 빌드될 씬 목록에 넣어준다.

테스트

그런 후에 첫 번째 씬에서 플레이 버튼을 눌러 게임을 실행하고 스페이스바를 누르면 첫 번째 씬에서 로딩 씬으로 넘어간 후에 아래쪽 로딩 바가 자연스럽게 차오른뒤에 두 번째 씬으로 넘어가는 것을 확인할 수 있다.

위의 예시에서는 씬의 로딩 진행도 만을 이용해서 진행 정도를 체크했지만, 유니티에서는 다음 씬에서 사용될 애셋 번들을 불러오는 것 또한 로딩에 포함될 수 있고, 만약 네트워크 게임을 제작한다면 네트워크 동기화 정도도 포함될 수 있다.

여담으로 일부 게임 제작자의 경우에는 로딩 시간이 너무 짧아서 로딩 시간동안 보여주고자 하는 팁이나 스토리 등이 너무 빠르게 스쳐지나간다고 생각하는 경우에는 일부러 로딩 속도를 늦추거나 페이크 로딩 시간을 넣어서 로딩 시간을 일부러 길게 만드는 경우도 있다.

이 글은 이전에 작성된 로딩 씬 구현하기 글의 새로운 버전으로 좀 더 따라하기 쉽고 이전에는 생략되었던 중간과정이 추가되었으며 코드가 약간 수정되었다.

로딩 씬을 불러온 뒤에 다음 씬을 로딩하는 이 방법 이외에도 로딩 UI 만을 무대 커튼처럼 전면에 깔아두고 다음 씬을 로딩하는 방법도 있다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]