Explorer 2D Game Kit 분석 (4) 

게임플레이 요소 (1)


작성 기준 버전 :: 2019.1.4f1


그림 1

 

본격적으로 게임플레이와 관련된 요소들에 대해서 분석해볼 차례이다.


그림 2

 

기본적인 하이어라키 뷰(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)가 그것이다.


씬 트랜지션 데스티네이션 컴포넌트(Scene Transition Destination Component)


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)


피직스 헬퍼 컴포넌트는 게임이 플레이되는 상황에서 어디서든지 호출될 수 있기 때문에 싱글톤 패턴으로 작성되어 있으며, 캐릭터가 밟고 서는 플랫폼이나 타일맵에 관련된 물리적인 처리를 담당하고 있다.


사실 피직스 헬퍼 같은 컴포넌트는 개발자가 편의에 따라서 작성하기 나름인 스크립트이다. 게임마다 필요한 물리 연산이나 처리는 모두 다르기 마련이라, 필요한 물리 작업에 따라서 피직스 헬퍼의 내용은 천차만별로 달라질 수 있다. 다만, 이렇게 자주 사용되는 기능을 분류 별로 묶어서 어디서든지 호출할 수 있게 헬퍼 클래스로 만드는 작업은 관련된 기능을 이리저리 흩뜨려 놓는 것보다 확실히 더 나은 효율적인 작업을 보장한다.




Explorer 2D Game Kit 분석 (1) - 개요

Explorer 2D Game Kit 분석 (2) - Start 씬 해부하기 (1)

Explorer 2D Game Kit 분석 (3) - Start 씬 해부하기 (2)

Explorer 2D Game Kit 분석 (4) - 게임플레이 요소 (1)


반응형

Programming 

오브젝트 풀링 기법

 

 

 

작성 기준 버전 :: 2019.2

 

프로그래밍에서 오브젝트를 생성하거나 파괴하는 작업은 꽤나 무거운 작업으로 분류된다. 오브젝트 생성은 메모리를 새로 할당하고 리소스를 로드하는 등의 초기화하는 과정으로, 오브젝트 파괴는 파괴 이후에 발생하는 가비지 컬렉팅으로 인한 프레임 드랍이 발생할 수 있다.

 

이러한 문제를 해결하기 위해서 사용되는 기법이 바로 오브젝트 풀링(Object pooling)이다.

 

오브젝트 풀링의 개념

 

오브젝트 풀링의 개념은 아주 간단하다. 

 

 

먼저 풀링을 할 오브젝트를 담을 오브젝트 풀을 구성한다.

 

 

그 다음 풀링할 오브젝트를 생성해서 오브젝트 풀에서 그 오브젝트들을 관리하게 만든다.

 

 

외부에서 해당 오브젝트가 필요하면 오브젝트 풀에서 꺼내간다.

 

 

오브젝트 풀에서 꺼낸 오브젝트의 사용이 끝나면 오브젝트를 풀에 돌려준다.

 

 

오브젝트 풀에서 오브젝트를 가져오려고 할 때, 모든 오브젝트가 이미 사용중이라면 새로운 오브젝트를 생성해서 꺼내준다.

 

이것이 바로 오브젝트 풀의 개념이다. 게임에 필요한 오브젝트를 미리 생성해서 필요할 때마다 꺼내쓰고 사용이 끝나면 오브젝트 풀에 돌려주는 것이다. 이렇게 함으로써, 오브젝트가 필요할 때마다 생성하고 다 쓰면 파괴하는 것이 아니라, 게임이 시작될 때, 필요한 만큼의 오브젝트만 생성하고, 모자라면 추가로 생성하고, 게임이 끝나면 파괴하는 방식으로 오브젝트의 생성/파괴 횟수를 줄일 수 있게 된다.

 

오브젝트 풀링 기법은 특히 메모리가 부족하고 CPU의 성능이 낮은 디바이스의 사양이 낮았던 예전에 주로 사용되었던 기법이지만, 현재에 와서도 게임의 최적화를 위해서 많이 사용되며, 모바일 게임이 많이 제작되면서 PC에 비해서 모자란 디바이스 성능으로 인해서 재조명 받는 기법이다.

 

보통 자주 생성되었다가 파괴되어야 하는 총알이나, 캐릭터가 뛸 때 발생하는 먼지 이펙트 같은 곳에 많이 사용되는 기법이다.

 

 

유니티 엔진에서의 구현

 

기본 세팅

 

기본적인 세팅은 다음과 같다.

 

 

씬 한 가운데 캐릭터의 역할을 할 초록색 박스를 배치했다.

 

public class Shooter : MonoBehaviour
{
    [SerializeField]
    private GameObject bulletPrefab;

    private Camera mainCam;

    void Start()
    {
        mainCam = Camera.main;
    }

    void Update()
    {
        if(Input.GetMouseButton(0))
        {
            RaycastHit hitResult;
            if(Physics.Raycast(mainCam.ScreenPointToRay(Input.mousePosition), out hitResult))
            {
                var bullet = Instantiate(bulletPrefab).GetComponent<Bullet>();
                var direction = new Vector3(hitResult.point.x, transform.position.y, hitResult.point.z) - transform.position;
                bullet.transform.position = direction.normalized;
                bullet.Shoot(direction.normalized);
            }
        }
    }
}

 

그리고 박스 게임 오브젝트에는 마우스 클릭 방향으로 총알 게임 오브젝트를 생성해서 발사하는 Shooter 컴포넌트가 부착되어 있다.

 

 

public class Bullet : MonoBehaviour
{
    private Vector3 direction;
    public void Shoot(Vector3 direction)
    {
        this.direction = direction;
        Destroy(gameObject, 5f);
    }

    void Update()
    {
        transform.Translate(direction);   
    }
}

 

그리고 지정된 방향으로 5초 간 날아가다 자동으로 소멸하는 총알 프리팹 역시 만들어두었다.

 

 

이것을 테스트 해보면 마우스를 클릭하면 엄청난 양의 총알 오브젝트가 새로 생성되고 시간이 지나면 모두 파괴되는 것을 볼 수 있다.

 

 

이 상황을 프로파일러를 통해서 확인해보면 총알을 생성하는 Instantiate와 파괴하는 Destroy가 어느 정도 성능을 잡아먹고 있는 것을 확인할 수 있다.

 

오브젝트 풀 구현

 

public class ObjectPool : MonoBehaviour
{
    public static ObjectPool Instance;

    [SerializeField]
    private GameObject poolingObjectPrefab;

    Queue<Bullet> poolingObjectQueue = new Queue<Bullet>();

    private void Awake()
    {
        Instance = this;

        Initialize(10);
    }

    private void Initialize(int initCount)
    {
        for(int i = 0; i < initCount; i++)
        {
            poolingObjectQueue.Enqueue(CreateNewObject());
        }
    }

    private Bullet CreateNewObject()
    {
        var newObj = Instantiate(poolingObjectPrefab).GetComponent<Bullet>();
        newObj.gameObject.SetActive(false);
        newObj.transform.SetParent(transform);
        return newObj;
    }

    public static Bullet GetObject()
    {
        if(Instance.poolingObjectQueue.Count > 0)
        {
            var obj = Instance.poolingObjectQueue.Dequeue();
            obj.transform.SetParent(null);
            obj.gameObject.SetActive(true);
            return obj;
        }
        else
        {
            var newObj = Instance.CreateNewObject();
            newObj.gameObject.SetActive(true);
            newObj.transform.SetParent(null);
            return newObj;
        }
    }

    public static void ReturnObject(Bullet obj)
    {
        obj.gameObject.SetActive(false);
        obj.transform.SetParent(Instance.transform);
        Instance.poolingObjectQueue.Enqueue(obj);
    }
}

 

오브젝트 풀링 기법을 구현하는 기초적인 코드의 전체는 위의 코드와 같다. 

 

public static ObjectPool Instance;

private void Awake()
{
    Instance = this;

    Initialize(10);
}

 

이 코드를 하나씩 살펴보자. 우선 오브젝트 풀의 경우 오브젝트를 생성하는 어떤 코드에서든 접근이 가능해야하는 경우가 많기 때문에 싱글톤 패턴으로 구현되는 경우가 많다. 

 

[SerializeField]
private GameObject poolingObjectPrefab;

 

그리고 생성해야할 오브젝트의 프리팹을 가지고 있다. 프리팹을 가지고 있어야 하는 이유는 처음 생성해둔 오브젝트를 모두 꺼내주고 나서, 꺼내준 오브젝트를 미처 돌려받기 전에, 오브젝트를 요청받았을 때, 새로운 오브젝트를 생성해서 꺼내주기 위한 것이다.

 

Queue<Bullet> poolingObjectQueue = new Queue<Bullet>();

 

큐(Queue)를 이용해서 생성된 총알 오브젝트를 순서대로 관리한다. 만약 오브젝트 풀에서 오브젝트를 꺼내주는 순서와 돌려받는 순서를 제대로 관리하지 못하면, 하나의 오브젝트를 여러 곳에 빌려주는 등의 문제가 발생할 수 있다.

 

private void Awake()
{
    Instance = this;

    Initialize(10);
}

 

게임 오브젝트가 생성되면 제일 먼저 실행되는 Awake() 함수에서는 싱글톤 패턴에서 사용되는 오브젝트 풀 인스턴스에 자신을 할당하는 일과 오브젝트 풀을 초기화하는 Initialize() 함수를 호출한다. 

 

private void Initialize(int initCount)
{
    for(int i = 0; i < initCount; i++)
    {
        poolingObjectQueue.Enqueue(CreateNewObject());
    }
}

 

Initialze() 함수에서는 매개변수로 받은 초기화 갯수 값에 따라서 CreateNewObject() 함수에서 만들어진 새로운 총알 오브젝트를 pooling Object Queue에 넣어준다. 이렇게 게임이 시작하기 전에 사용될 게임 오브젝트를 미리 적절한 갯수를 만들어 줌으로써 게임 플레이 도중에 발생할 과부하를 게임 준비 과정인 로딩으로 돌릴 수 있다. 모두 잘 알겠지만, 플레이어는 아주 조금 더 긴 로딩은 당장 용납하지만, 플레이 도중에 발생하는 렉은 용납하지 못한다.

 

private Bullet CreateNewObject()
{
    var newObj = Instantiate(poolingObjectPrefab).GetComponent<Bullet>();
    newObj.gameObject.SetActive(false);
    newObj.transform.SetParent(transform);
    return newObj;
}

 

CreateNewObject() 함수는 poolingObjectPrefab으로부터 새 게임 오브젝트를 만든 뒤 비활성화해서 반환하는 역할을 한다. 이렇게 곧바로 비활성화하는 이유는 아직 오브젝트 풀이 꺼내주지 않은 오브젝트는 비활성화된 것으로써 플레이어의 눈에 띄지 않아야하기 때문이다.

 

public static Bullet GetObject()
{
    if(Instance.poolingObjectQueue.Count > 0)
    {
        var obj = Instance.poolingObjectQueue.Dequeue();
        obj.transform.SetParent(null);
        obj.gameObject.SetActive(true);
        return obj;
    }
    else
    {
        var newObj = Instance.CreateNewObject();
        newObj.gameObject.SetActive(true);
        newObj.transform.SetParent(null);
        return newObj;
    }
}

 

GetObject() 함수는 오브젝트 풀이 가지고 있는 게임 오브젝트를 요청한 자에게 꺼내주는 역할을 한다. 단, 모든 오브젝트를 꺼내서 빌려줘서 poolingObjectQueue에 빌려줄 오브젝트가 없는 상태라면 CreateNewObject() 함수를 호출해서 새로운 오브젝트를 생성해서 빌려준다.

 

public static void ReturnObject(Bullet obj)
{
    obj.gameObject.SetActive(false);
    obj.transform.SetParent(Instance.transform);
    Instance.poolingObjectQueue.Enqueue(obj);
}

 

ReturnObject() 함수는 빌려준 오브젝트를 돌려받는 함수이다. 돌려받은 오브젝트를 비활성화한 뒤 정리하는 일을 처리한다.

 

무엇이든지 빌려줬으면 돌려받아야 한다. 이 원칙은 프로그래밍에서도 매우 중요한 원칙으로 사용한 오브젝트를 제대로 돌려받지 않으면 GetObject() 함수를 호출할 때, 계속해서 새로운 오브젝트를 생성하고 사라지지 않은 오브젝트들이 씬에 쌓이게 된다. 이것이 바로 메모리 누수이다.

 

 

코드 작성이 끝나면 씬에 새 게임 오브젝트를 배치하고 오브젝트 풀 컴포넌트를 부착하고 pooling Object Prefab 프로퍼티에 풀링해야할 게임 오브젝트의 프리팹을 할당해주면 된다.

 

 

그 다음에는 총알 오브젝트를 생성하는 부분과 파괴하는 부분을 수정해야 한다.

 

public class Shooter : MonoBehaviour
{
    void Update()
    {
        if(Input.GetMouseButton(0))
        {
            RaycastHit hitResult;
            if(Physics.Raycast(mainCam.ScreenPointToRay(Input.mousePosition), out hitResult))
            {
                var bullet = ObjectPool.GetObject(); // 수정
                var direction = new Vector3(hitResult.point.x, transform.position.y, hitResult.point.z) - transform.position;
                bullet.transform.position = direction.normalized;
                bullet.Shoot(direction.normalized);
            }
        }
    }
}

 

우선 생성하는 부분은 Shooter 클래스의 Update() 함수에 Instanitate()로 총알을 생성하던 부분을 ObjectPool.GetObject()로 대체하면 된다.

 

public class Bullet : MonoBehaviour
{
    private Vector3 direction;
    public void Shoot(Vector3 direction)
    {
        this.direction = direction;
        Invoke("DestroyBullet", 5f);
    }

    public void DestroyBullet()
    {
        ObjectPool.ReturnObject(this);
    }

    void Update()
    {
        transform.Translate(direction);   
    }
}

 

그 다음 파괴하는 부분은 Bullet 클래스에서 DestoryBullet() 함수에서 ObjectPool.ReturnObject()를 호출해서 오브젝트 풀에 돌려주도록 구현하고 Shoot() 함수에서 Destory() 함수를 호출하던 부분을 Invoke()로 5초 뒤에 DestoryBullet() 함수를 호출하도록 수정한다.

 

 

 

플레이를 해서 테스트 해보면 총알이 일정 갯수만큼 생성되고 나면 더 이상 생성되지 않으며, 시간이 지나면 소멸되어야 하는 총알 오브젝트들이 비활성화되서 오브젝트 풀로 반환되는 것을 확인할 수 있다.

 

 

프로파일러를 통해서 확인해보면 최대 생성량에 도달한 이후에는 Instatiate와 Destroy로 인한 작업이 발생하지 않는 것을 볼 수 있다.

반응형
  1. 료용 2020.05.04 01:14 신고

    베르님 안녕하세요 유투브 잘보고있습니다.

    이 글 정말 좋은글인데 제가 이해를 못하는부분이있어서 질문드립니다.

    Initialze() 이 함수 awake에서 10으로 주시지않았습니까? 그러면 queue에 10개의 bullet의 오브젝트가 들어있는거지않습니까??

    그런데 그러면 10개가 넘는다면 새로운 bullet를 생성해주시는데

    var newObj = Instance.CreateNewObject();

    newObj.gameObject.SetActive(true);

    newObj.transform.SetParent(null);

    return newObj;

    여기서 이렇게 새로 생성한다음에

    ReturnObject()

    으로 받는다면 queue에는 지금 영상에서 보듯이 수십개의 bullet가 저장되는 개념아닌가요?

    그렇다면 처음에 Initialze() 에 10으로 줄이유가없지않나요? 이부분이 너무헷갈려서 .. 유투브에서 물어보려다가 너무길게 될 질문이라 여기다가 올립니다 ㅠㅠ

    • wergia 2020.05.04 12:47 신고

      Awake 함수에서 Initialize로 10개를 미리 만들어두는 것은 게임에서 사용될 오브젝트의 갯수를 예측해서 미리 만들어두는 것입니다.

      예시에서는 미리 만들어둔 갯수를 모두 사용하고나면 이후에 생성되는 것을 보여드리기 위해서 10개만 만들었지만 실제로는 게임을 여러 번 실행해서 테스트를 진행해보고 평균적으로 게임에 몇 개의 오브젝트가 필요한지 산출해낸 뒤 그 갯수를 미리 생성해두게 만듭니다.

      그러면 게임이 시작될 때 그 오브젝트 갯수를 미리 생성해두는 과정이 처리됩니다.

      이렇게 미리 필요한 갯수를 적당히 생성해두면 대부분은 미리 생성해둔 오브젝트를 사용하고 오브젝트가 부족해지면 새로 생성해서 사용하게 됩니다.

    • 료용 2020.05.04 15:20 신고

      그렇다면 혹시 10개정도만 쓰겠다! 라는느낌으로 awake에 해놓은건가요? 어차피 10개이상 bullet가 생성된다면 queue 의 사이즈는 bullet의 반납되는 수만큼 늘어났다가 다시 queue에 있던 bullet을 빌려주는 이런개념인거죠? 10개를 훨씬넘어서는

    • wergia 2020.05.04 22:21 신고

      10개 정도 사용할 것 같다고 예측하고 10개만 생성해둔 겁니다. 하지만 예시에서는 예측을 넘어서서 더 많은 양을 사용하게 되었으니 추가로 생성한 거구요.

      그리고 추가로 생성한 Bullet은 사용이 모두 완료된 후에 다시 Queue로 반납되어서 보관됩니다.

    • 료용 2020.05.08 19:12 신고

      감사합니다 베르님 확이해갔어요

    • wergia 2020.05.08 20:21 신고

      다행입니다 ㅜㅜ
      설명하기가 어려워서 이해 잘하셨을까 했는데

    • 료용 2020.05.08 20:57 신고

      죄송합니다 ...

      베르님 딱하나만 더...

      그런데 bullet을 많이생성하게되면 queue가 이때까지 최대로 많이생성했던 bullet의 갯수만큼의 사이즈를 가지게되지않나요?
      그러면 그거대로 느려지게되는 이유가되지않는건가요?

    • wergia 2020.05.09 11:08 신고

      만약 풀링하는 오브젝트가 사용하는 리소스의 용량이 매우 크다면 메모리를 많이 소모할 수도 있습니다.

      하지만 대부분 풀링하는 오브젝트는 총알 화살 같은 물체이기 때문에 사용하는 리소스의 용량이 크지 않은 물체가 대부분입니다.

      그리고 Bullet 같은 오브젝트가 쌓여서 메모리가 완전히 소모되어 게임이 느려지는 순간은 굉장히 늦게 오는 편이고 그렇게 될 오브젝트가 쌓이기도 어려운 구조입니다.

      하지만 가비지 컬렉터로 인한 프레임 드랍은 언제든지 찾아올 수 있습니다.

      이러한 프레임 드랍을 없애는게 주요한 목표이기 때문에 오브젝트 풀링을 사용합니다.

      오브젝트를 미리 생성해서 게임이 끝날때까지 사용하다가 게임이 끝나고 난 뒤 로딩 타임에 소멸시켜서 가비지 컬렉팅으로 인한 프레임 드랍을 로딩시간으로 편입시키는 등의 방법으로 게임 중의 프레임 드랍을 최소화하는 겁니다.

    • 료용 2020.05.09 16:37 신고

      감사합니다 베르님 마지막설명이 딱 이해하기쉬워졌어요

    • wergia 2020.05.10 22:08 신고

      언제든 궁금하신 점 있으시면 질문해주세요!
      아는 부분이라면 최대한 답변해드릴게요!

  2. moody 2020.06.17 13:09

    너무 좋은 자료 잘보고갑니다 ! 이런글 올려주셔서 너무 감사해요

    • wergia 2020.06.22 23:44 신고

      다음에는 심화과정으로 한 번 만들어 보겠습니다 ㅎㅎ

  3. Groza 2020.12.03 20:58

    정말 감사합니다 ㅎㅎ

  4. 베르사랑 2020.12.16 17:57

    베르님 현재 디펜스 게임 제작중에 있습니다.
    베르님의 강의대로 오브젝풀링 구현 후
    여러개의 타워에서 업데이트로 빌려오는데
    가끔 어느 타워가 공격을 하지 않습니다.ㅜ
    이게 동시에 꺼내오면서 몇몇 타워들이 가져오질
    못하는건가요?ㅜ
    여러 타워 업데이트 문에서 호출하여 사용하고 싶은데
    방법이 없을까요?ㅜ

  5. Cargold 2021.08.11 18:16

    풀링은 선택이 아니라 필수!

Physics 

컴포지트 콜라이더 2D(Composite Collider 2D)

 

작성 기준 버전 :: 2019.1.4f1

 

컴포지트 콜라이더 2D 컴포넌트는 다수의 2D 콜라이더를 하나의 콜라이더로 합쳐주는 역할을 하는 컴포넌트이다. 이 컴포넌트는 주로 여러 개의 콜라이더가 하나의 콜라이더로 취급하기 위해서 사용된다.

 

두 콜라이더의 충돌 감지

 

 

그림 1

 

[그림 1]을 보면 원형의 폴리곤 콜라이더를 가진 오브젝트와 사각 콜라이더를 가진 오브젝트가 함께 겹쳐져 있으며 두 오브젝트가 같은 부모 게임 오브젝트 밑에 있는 것을 확인할 수 있다. 위와 같은 상태에서는 두 개의 각 콜라이더가 충돌을 각각 감지한다.

 

public class CollisionTest : MonoBehaviour

{

    private void OnCollisionEnter2D(Collision2D collision)

    {

        Debug.Log(string.Format("OnCollisionEnter2D :: / ", gameObject.name, collision.gameObject.name));

    }

 

    private void OnCollisionStay2D(Collision2D collision)

    {

        Debug.Log(string.Format("OnCollisionStay2D :: / ", gameObject.name, collision.gameObject.name));

    }

 

    private void OnCollisionExit2D(Collision2D collision)

    {

        Debug.Log(string.Format("OnCollisionExit2D :: / ", gameObject.name, collision.gameObject.name));

    }

}

 

위와 같이 충돌을 감지하는 코드를 작성하고,

 

그림 2
그림 3

 

콜라이더가 있는 각 오브젝트에 부착한 뒤,

 

그림 4

 

[그림 4]와 같이 아래로 떨어지는 게임 오브젝트를 만들어서 충돌 테스트를 해보면,

 

그림 5

 

[그림 5]의 로그와 같이 각각의 오브젝트가 따로 충돌을 감지하는 것을 확인할 수 있다.

 

 

컴포지트 콜라이더 2D(Composite Collider 2D)

 

이런 식으로 각각의 콜라이더가 따로 충돌을 감지하는 것이 아니라 두 콜라이더가 하나로 취급되어 충돌을 감지하고자 할 때, 컴포지트 콜라이더 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 옵션으로 만들어진 컴포지트 콜라이더를 클릭하는 테스트를 진행해보면 그 차이를 명확하게 인지할 수 있다.

반응형
  1. 료용 2019.12.26 02:05

    안녕하세요 베르님 좋은글잘보고있습니다.

Tilemap (3) 

타일맵에 콜라이더 추가하기


작성 기준 버전 :: 2019.1.4f1


이전 섹션들에서는 타일맵 생성 방법2D 엑스트라의 룰 타일을 이용한 타일 자동 연결 기능을 알아보았다. 이번 섹션에서는 타일맵에 콜라이더를 추가하는 방법을 배워볼 것이다.


이제까지 타일맵에 사용될 타일 이미지를 만들고 가져오는 방법, 타일맵을 만들고 사용하는 방법들을 배웠다. 이제 만들어낸 타일맵을 이용해서 맵을 그려내면 게임 레벨이 될 것이다. 하지만 여기에 아직 부족한 점이 있다.


지금까지 배운 것들로는 맵을 그리기만 할 수 있다. 무슨 말인가 하면, 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

 

타일맵에 콜라이더 컴포넌트를 붙인 상태로 다시 게임을 플레이해보면 떨어진 공이 바닥에 맞고 튕기는 것을 볼 수 있다.



컴포지트 콜라이더 2D 컴포넌트(Composite Collider 2D Component)


[그림 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를 사용하는 경우에 주의할 점은 하위에 있는 모든 콜라이더를 하나로 통합하기 때문에, 플랫폼 게임을 만들 때 벽 타일의 콜라이더와 바닥 타일의 콜라이더가 플레이어와 충돌 시 다른 동작을 하게 만들고 싶다면 벽 타일의 타일맵과 바닥 타일의 타일맵을 분리하거나, 캐릭터가 충돌한 방향을 검출해서 벽인지 바닥인지를 검출하는 등의 추가 작업이 필요하다.  




Tilemap (1) - 2D 게임의 기본 타일맵!

Tilemap (2) - 룰 타일로 타일맵 자동 연결하기

Tilemap (3) - 타일맵에 콜라이더 추가하기


반응형

Tilemap (2) 

룰 타일로 타일맵 자동 연결하기

 

작성 기준 버전 :: 2019.1-2019.2

 

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

 

지난 섹션에서는 간단하게 타일맵을 만들고 사용하는 방법에 대해서 알아보았다. 이번 섹션에서는 룰 타일 기능을 이용한 동일 타일을 연달아 놓았을 때, 자동으로 연결되는 기능을 구현하는 방법을 알아보자.

 

타일의 자동 연결은 어떻게?

 

 

같은 타일을 놓으면 오른쪽 십자가처럼 자동으로 연결되기를 바랄 수 있다. 하지만 유니티 타일맵 기본 기능 만으로는 같은 타일을 옆에 놓아봤자 왼쪽 십자가처럼 끊어진 십자가만 놓아지고 오른쪽 십자가처럼 만들려면 직접 일일이 배치를 해야한다.

 

유니티 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 엑스트라는 아직 유니티 테크놀러지 측에서도 개선 중인 기술로 룰 타일을 사용할 때, 주의해야할 점이 있다.

 

 

이 문제는 심각한 이슈사항인데, 타일 팔레트에 룰 타일을 올려둔 채로 씬의 타일맵에 계속 그려보면서 타일링 룰을 수정하면 어느 시점부터 심각한 수준의 메모리 누수가 발생한다. 특히 유니티 엔진이 응답없음 상태가 되고 메모리 점유율이 계속 올라가는 상태라면, 유니티를 종료하고 다시 실행해도 실행하자마자 메모리 누수가 시작될 확률이 높다.

 

그렇기 때문에 타일맵과 룰 타일을 안정적으로 사용하고 싶다면, 룰 타일의 타일링 룰을 먼저 작성한 뒤 팔레트를 만들어서 룰 타일을 올리고 간단하게 씬에서 테스트한 뒤, 문제가 없다면 그대로 사용하고, 만약 타일링 룰을 수정해야 한다면, 현재 타일 팔레트를 삭제하고 타일링 룰을 수정한 뒤 다시 타일 팔레트를 만들 것을 권장한다.

 


 

Tilemap (1) - 2D 게임의 기본 타일맵!

Tilemap (2) - 룰 타일로 타일맵 자동 연결하기

Tilemap (3) - 타일맵에 콜라이더 추가하기

반응형

Tilemap (1)

2D 게임의 기본 타일맵!

 

작성 기준 버전 :: 2019.1 - 2019.2

 

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

 

  

예전에 RPG메이커를 사용했을 때는 맵이 타일(Tile) 방식으로 이루어져 있어서 타일 팔레트를 가져와서 마치 그림 그리듯이 원하는 타일을 칠해주는 방식으로 맵을 만들 수 있었다.

 

유니티 엔진을 처음 배웠던 5 버전에서는 이러한 기능이 없어서 2D 맵 오브젝트를 직접 배치하거나 타일맵 기능을 직접 구현해야만 했었다. 하지만 유니티 2017.2 버전에서부터 타일맵 기능이 유니티에도 추가되었다. 맵오브젝트를 배치할 필요없이 그림 그리듯이 맵을 만들 수 있다는 것은 굉장한 장점이다. 

 

 

 

타일맵의 타일을 하나 추가해서 아래쪽 이미지와는 조금 다를 수 있다.

  

샘플용 간단한 타일맵 이미지를 다운받은 뒤, 타일맵의 사용법에 대해서 알아보자. 구글에서 적당한 리소스를 다운받아서 사용해도 좋다.

 

 

타일 팔레트(Tile Palette) 만들기

 

타일맵을 씬에 배치하기 이전에 먼저 타일맵을 색칠할 수 있는 타일의 종류를 모아둔 것을 만들어야 하는데 이것을 유니티 엔진에서는 타일 팔레트(Tile Palette)라고 부른다. 이 타일 팔레트를 만드는 방법에 대해서 배워보자.

 

타일 팔레트가 될 이미지 임포트 & 세팅

 

먼저 타일 팔레트에 들어갈 이미지를 임포트하고 타일맵에 사용하기 좋게 세팅해야 한다.

 

 

다운로드 받은 타일맵 이미지를 프로젝트에 임포트한다. 처음으로 임포트한 이미지는 대부분 설정이 위와 같을 것이다. 타일맵 이미지의 임포트 세팅을 적절하게 설정해주어야 한다. 

 

우선 Pixels Per Unit은 이미지의 픽셀을 몇 개를 단위로 유니티 엔진의 공간 상에서 1단위(유닛, Unit)로 표현할 것인가에 대한 설정이다. 유니티에서의 1단위는 보통 1m를 의미한다. 즉, 몇 개의 픽셀을 1m로 볼 것인가를 의미하는 셈이다. 타일맵 이미지를 열어서 확인 해보면 알겠지만 타일맵의 이미지는 한 칸당 128픽셀로 이루어져 있다. 한 칸을 1미터로 볼 것이기 때문에 Pixel Per Unit에 128을 입력해주자.

 

그 다음 설정은 Sprite Mode 값이다. 이 설정의 기본 값은 Single인데 이미지 한 장을 한 장의 스프라이트(Sprite)로 본다는 의미이다. 타일맵 이미지를 보면 알 수 있겠지만 타일맵 이미지는 한 장이 하나의 타일이 아니라 여러 장의 타일이 그려져 있는 것을 알 수 있다. 이 때문에 한 장의 이미지가 하나의 스프라이트가 아닌 그려진 타일의 수만큼의 스프라이트를 가져야한다는 것을 알 수 있다. 

 

 

Multiple로 설정해주자. 그 다음에는 이 이미지가 어떻게 나누어져야 하는지를 정하기 위해서 스프라이트 에디터(Sprite Editor) 버튼을 클릭한다.

 

 

 

그러면 스프라이트 에디터 창이 열리는데 기본적으로 타일맵 이미지가 하나의 스프라이트로 이루어지고 있음을 확인할 수 있다.

 

 

이미지를 여러 개의 스프라이트로 나누기 위해서 스프라이트 에디터 창의 상단 메뉴 중에서 슬라이스(Slice)를 선택하고 자동(Autometic)으로 되어 있는 타입을 Grid by Cell Count로 바꾼다.

 

 

 

그리고 컬럼(Column)과 로우(Row)를 각각 5와 3으로 변경하고 슬라이스 버튼을 누른다.

 

 

 

그렇게 하면 하나의 스프라이트로 되어 있던 타일맵 이미지가 여러 개의 스프라이트로 나누어지는 것을 볼 수 있다. 상단 바의 Apply 버튼을 누르고 적용한다.

 

 

 

프로젝트 뷰에서도 이 모습을 확인할 수 있다.

 

타일 팔레트 만들기

 

 

타일 팔레트는 상단 메뉴바에서 [Window>2D>Tile Palette] 항목을 선택한다.

 

 

그렇게 하면 위의 이미지와 같이 타일 팔레트 뷰가 열린다. 여기서 Create New Palette 버튼을 누르고

 

 

팔레트의 이름을 정하고 Create 버튼을 누른 뒤 저장하면 빈 타일 팔레트가 생성된다.

 

 

그 다음 타일로 만들고자 하는 스프라이트를 타일 팔레트로 드래그 하고 저장하면 타일맵 에셋들이 프로젝트 뷰에 생성되는 것을 볼 수 있다.

 

 

 

그리고 타일 팔레트에도 추가한 타일틀이 보여지는 것을 확인할 수 있다. 여기서 이 원하는 타일을 선택하고 씬에 배치된 타일맵에 타일을 그리면 된다.

 

 

타일맵 생성

 

 

우선 타일맵을 생성하기 위해서는 Create>2D>Tilemap을 선택하면 된다. 이 생성 과정의 경우에는 하이어라키(Heirarchy) 뷰에서 우클릭을 하거나 하이어라키 뷰 상단의 Create 메뉴 버튼, 혹은 상단 메뉴바의 GameObject 메뉴를 선택해서도 똑같이 만들 수 있다.

 

 

타일맵을 생성하면 위의 이미지와 같이 게임씬에 타일맵을 그리기 쉽게 격자선을 그려주는 그리드(Grid) 컴포넌트가 부착된 게임 오브젝트가 생성된다.

 

 

그리고 자식 게임 오브젝트로는 타일맵 컴포넌트(Tilemap Component)와 타일맵 렌더러 컴포넌트(Tilemap Renderer Component)가 부착된 게임 오브젝트가 생성된다. 앞서 만든 타일 팔레트에서 타일을 선택해서 이 타일맵 게임 오브젝트에 타일을 그려서 게임 맵을 만들면 된다. 그리드 아래에 여러 타일맵 게임 오브젝트를 넣어서 여러 층의 타일맵을 겹쳐서 맵을 만들 수도 있다.

 

타일맵 그려보기

 

 

 

타일맵이 만들어졌으면 타일 팔레트에서 타일을 선택해서 맵을 그려보자. 클릭하고 드래그하면 맵이 손쉽게 그려진다. 그리고 시프트(Shift) 키를 누르고 클릭 & 드래그하면 그려진 타일들이 지워진다.

 

 

 

추가로 [ ] 대괄호 키를 누르면 타일을 회전시킬 수 있다.

 


 

Tilemap (1) - 2D 게임의 기본 타일맵!

Tilemap (2) - 룰 타일로 타일맵 자동 연결하기

Tilemap (3) - 타일맵에 콜라이더 추가하기

반응형
  1. 익명 2020.12.22 15:49

    비밀댓글입니다

Explorer 2D Game Kit 분석 (3) 

Start 씬 해부하기 (2)


작성 기준 버전 :: 2019.1.4f1


Start 씬


 

지난 섹션에 이어서 Start 씬에 대한 분석을 이어나가보자.



UI


 

하이어라키 뷰(Hierarchy View)에서 UI로 분류된 게임 오브젝트는 스크린 페이더(Screen Fader), 이벤트 시스템(Event System), 스타트 메뉴 캔버스(Start Menu Canvas), 옵션 캔버스 마스터(Option Canvas Master)가 있다. 분류에서도 알 수 있듯이 모두 UI와 관련이 있는 게임 오브젝트들이다.


스크린 페이더 게임 오브젝트(Screen Fader Game Object)


 

스크린 페이더 게임 오브젝트에는 스크린 페이더 컴포넌트(Screen Fader Component)가 부착되어 있고 자식 게임 오브젝트로 블랙 페이더(Black Fader), 게임 오버 캔버스(Game Over Canvas), 로딩 캔버스(Loading Canvas)를 가진다.


스크린 페이더 컴포넌트(Screen Fader Component)


public class ScreenFader : MonoBehaviour

 

스크린 페이더 컴포넌트는 씬을 이동할 때, 화면을 페이드 인(fade in), 페이드 아웃(fade out) 시키는 역할을 하는 컴포넌트이다.


public static ScreenFader Instance

{

    get

    {

        if (s_Instance != null)

            return s_Instance;


        s_Instance = FindObjectOfType<ScreenFader> ();


        if (s_Instance != null)

            return s_Instance;


        Create ();


        return s_Instance;

    }

}


public static void Create ()

{

    ScreenFader controllerPrefab = Resources.Load<ScreenFader> ("ScreenFader");

    s_Instance = Instantiate (controllerPrefab);

}


void Awake ()

{

    if (Instance != this)

    {

        Destroy (gameObject);

        return;

    }

        

    DontDestroyOnLoad (gameObject);

}

 

스크린 페이더는 씬을 불러오거나 캐릭터의 위치를 이동시킬 때, 항상 존재해야 되는 컴포넌트이기 때문에 역시 싱글톤으로 구현되어 있다.


 

위 코드에는 약간의 문제점이 있는데 만약 존재하는 스크린 페이더가 없으면 새 스크린 페이더를 생성하는 Create() 함수를 보면 Resources 폴더에서 스크린 페이더 프리팹을 로드해서 인스턴스화하게 되어있지만, 프로젝트 뷰를 보면 스크린 페이더 프리팹은 Resources 폴더가 아닌 곳에 존재한다. 그렇기 때문에 만약 씬에 스크린 페이더가 없는데, 호출하면 스크린 페이더가 제대로 생성되지 않고 오류가 발생하게 된다. 이 문제를 해결하기 위해서는 SceneControl 폴더에 Resources 폴더를 만들고 ScreenFader 프리팹을 거기로 옮겨주면 문제는 해결된다.


기능


public enum FadeType

{

    Black, Loading, GameOver,

}


public static IEnumerator FadeSceneIn ()

public static IEnumerator FadeSceneOut (FadeType fadeType = FadeType.Black)

protected IEnumerator Fade(float finalAlpha, CanvasGroup canvasGroup)


스크린 페이더 컴포넌트에서는 화면이 페이드 아웃/인 되는 경우를 같은 씬 내에서 텔레포트하는 Black, 씬과 씬 사이를 이동하는 Loading, 플레이어의 캐릭터가 죽어서 리스폰되는 GameOver, 이렇게 세 가지로 나누어서 정의하고 있다.


그리고 주요 기능을 하는 함수 3가지를 가진다. 화면이 점차 밝아지면서 씬으로 들어가는 효과를 주는 FadeSceneIn(), 화면이 점차 어두워지면서 씬에서 빠져나오는 효과를 주는 FadeSceneOut(), 그리고 Fade() 함수는 FadeSceneIn() 함수와 FadeSceneOut() 함수 양쪽에서 호출되는 내부 함수로 화면을 밝게 하거나 어둡게하는 효과를 처리한다.


이런 식으로 씬 로드를 처리할 때, 별도의 로딩 씬을 만들지 않고, UI로 덮어씌우는 방식을 커튼식 로딩 UI로 분류할 수 있다. 다만 유니티 콘텐츠 팀에서는 로딩 UI와 씬 로딩 기능을 합치지 않고, 씬을 로딩하는 씬 컨트롤러와 UI를 덮어씌우는 스크린 페이더로 분리시켜두었다. 이렇게 함으로써 스크린 페이더를 활용할 때 씬을 이동하는 경우 뿐만 아니라 씬 내부에서 텔레포트를 할 때도 스크린 페이더를 사용할 수 있게 활용도를 높일 수 있었다.


자식 오브젝트들(Child Objects)


 

스크린 페이더의 기능에 대해서 알아보았으니 이제 스크린 페이더 게임 오브젝트의 자식 게임 오브젝트들에 대해서 확인해보자. 스크린 페이더의 자식 게임 오브젝트는 블랙 페이더(Black Fader), 게임 오버 캔버스(Game Over Canvas), 로딩 캔버스(Loading Canvas), 이렇게 3개이며, 앞선 스크린 페이더 컴포넌트 분석에서 봤듯이 블랙 페이더는 같은 씬 내에서 텔레포트로 이동할 때 보여질 UI, 게임 오버 캔버스는 캐릭터가 죽어서 리스폰 될 때 보여질 UI, 로딩 캔버스는 다른 씬으로 이동할 때 보여질 UI이다. 각 자식 오브젝트들은 UI를 구성할 이미지들을 자식 오브젝트로 가지며 각각의 화면 구성은 아래와 같다.


블랙 페이더게임 오버 캔버스로딩 캔버스

 

각자 구성하고 있는 이미지들은 다르지만, 이 자식 오브젝트들은 UI를 그릴 각각의 캔버스를 각자 가지며 자식 이미지들을 한꺼번에 컨트롤할 캔버스 그룹을 컴포넌트를 가진다.


여러 UI들을 하나의 캔버스 밑에 두지 않는지 의아해할 수도 있다. 하지만 모든 UI를 하나의 캔버스 아래에 두면 UI의 덩어리가 커져서 관리가 힘들어질 뿐만 아니라 유니티에서는 UI를 그릴 때, 캔버스 안의 UI 요소가 하나라도 변경되면 해당 UI 요소가 속한 캔버스의 모든 UI가 다시 그려지기 때문에 성능 면의 문제가 발생할 수 있다. 그렇기 때문에 UI를 구성할 때는 적절한 기능 단위로 UI를 묶어서 캔버스를 구성하는 것이 좋다.


그리고 캔버스 그룹은 UI 게임 오브젝트 하위에 속하는 자식 UI들을 한꺼번에 통제해야할 때 유용하게 사용된다. 여기서는 캔버스 아래에 있는 여러 이미지 들의 알파 값을 한꺼번에 조절해서 UI를 투명하게 하거나 그 반대의 작업을 하고자 사용되었다.



스타트 메뉴 캔버스(Start Menu Canvas)


 

스타트 메뉴 캔버스는 Start 씬에 제일 전면에 기본적으로 깔려 있는 UI 캔버스이다.


 

스타트 메뉴 캔버스에는 플레이어 인풋 컴포넌트(Player Input Component), 스타트 UI 컴포넌트(Start UI Component), 메뉴 액티비티 컨트롤러 컴포넌트(Menu Activity Controller Component)가 부착되어 있으며, UI 요소 들로는 배경 화면과 UI를 구분 짓기 위한 백그라운드 틴트 이미지와 메뉴를 구성하는 제목, 메뉴판 등의 이미지 그리고 메뉴 기능을 동작시키는 버튼을 가진다.


이 중에서 플레이어 인풋 컴포넌트는 이 씬에서 처리하는 작업이 없고 단지 옵션에서 플레이어에게 키를 알려주기 위해서 존재하기 때문에 게임 씬에서 분석하기로 하고 지금은 넘어가도록 한다. 그리고 메뉴 액티비티 컨트롤러 역시 사실상 하는 기능이 없는 상태이기 때문에 여기서는 넘긴다.


스타트 UI 컴포넌트(Start UI Component)


public class StartUI : MonoBehaviour 

{

    public void Quit()

    {

#if UNITY_EDITOR

        EditorApplication.isPlaying = false;

#else

Application.Quit();

#endif

    }

}

 

스타트 UI 컴포넌트 역시 크게 하는 일은 없다. UI 중에 EXIT GAME 버튼이 눌렸을 때 호출될 이벤트만 구현되어 있다. 여기서 볼만한 점은 유니티 에디터에서 실행되었을 때는 에디터의 isPlaying을 false로 만들어서 플레이를 중지시키고 빌드된 상황에서는 어플리케이션을 종료하도록 UNITY_EDITOR 심볼을 통해서 정의되어 있다는 점이다. 이런 식의 조건부 컴파일 방법은 정해진 심볼에 따라 특히 유니티에서는 빌드하고자 하는 플랫폼이나 운영체제에 따라 실행될 코드를 분리할 수 있다는 점이다.


조건부 컴파일에도 역시 단점과 주의해야할 점이 분명이 있다. 비주얼 스튜디오 기준으로 활성화되지 않은 심볼의 코드는 회색으로 표시되며 활성화되지 않는다. 그 때문에 인텔리센스 역시 동작하지 않으며, 이 구간에서는 자동완성을 지원하지 않는다. 때문에 신텍스 에러가 발생하지 않도록 주의해야 하며, 한 조건부 코드에 로직 변경이 발생했을 때, 다른 조건부 코드에도 까먹지 말고 변경된 로직을 적용해주어야 한다. 


조건부 컴파일을 사용하면 세심하게 관리해야할 코드가 늘어난다. 수정사항이 발생했을 때 활성화된 코드와 비활성화된 코드를 제대로 바꿔주지 않으면 에러가 발생하고 작업 시간과 빌드 시간이 배로 늘어날 것이다. 그렇기 때문에 가능하다면 플랫폼에 특화된 코드보다는 모든 플랫폼에서 동작하는 코드를 작성하고 불가피한 경우에만 조건부 컴파일로 코드를 나눌 것을 권장한다.


버튼의 사용법


남은 스타트 메뉴 캔버스의 요소들은 대부분 기본적인 것으로 별달리 언급할 요소가 못되지만, 시작 메뉴의 버튼들은 이야기해 볼 만한 것이 있다.



보통 유니티의 UI에서 버튼과 상호작용할 때 생기는 효과를 사용할 때는 기본적으로 색깔만 바뀌는 컬러 틴트(Color Tint)를 사용하거나 조금 더 특별한 방식으로 효과를 주고 싶을 때는 스프라이트를 교체하는 스프라이트 스왑(Sprite Swap) 기능을 주로 사용한다.


 

Start 씬에서 플레이를 실행하고 각 버튼에 마우스를 올려보면 작은 삼각형이 회전하는 연출이 보일 것이다. 이것은 컬러 틴트나 스프라이드 스왑만으로는 불가능한 연출이다.

 

스타트 메뉴 캔버스에 속한 버튼을 선택해보면 그 이유를 알 수 있는데 트랜지션(Transition)을 컬러 틴트나 스프라이트 스왑이 아닌 애니메이션(Animation)으로 설정되어 있고 별도의 애니메이터 컨트롤러가 붙어있는 것을 볼 수 있다.


 

각 상황마다 버튼이 실행할 애니메이션을 만들어서 이미지가 바뀌거나 색이 바뀌는 것보다 더욱 다양한 연출을 할 수 있다.



옵션 캔버스 마스터(Option Canvas Master)


 

옵션 캔버스 마스터는 게임의 설정을 조절하기 위한 UI들을 모아둔 캔버스로 자식 게임 오브젝트로 음향을 설정하기 위한 오디오 캔버스와 게임 플레이 조작을 위한 컨트롤 캔버스를 가지고 있다. 다만 컨트롤 캔버스의 경우, 키 변경 기능을 구현해두지 않았기 때문에 게임에서 사용하는 키를 보여주는 기능만 있다. 그리고 옵션 캔버스 마스터 자체는 캔버스 분리 이 외에는 평범하게 만들어졌기 때문에 특별하게 언급할 부분이 없다.


Scene Assets


 

스타트 씬에서 씬 에셋으로 분류해둔 게임 오브젝트들은 카메라, 포스트 프로세싱, 라이트, 그리고 씬을 꾸미는 배경 게임 오브젝트들이다.


원근감 연출


사실 씬 에셋 파트에서는 크게 조명할 부분은 없지만, 볼만한 부분은 원근감 연출에 있다.


 

보통의 2D 게임에서는 투영 방식(Projection)을 직교법(Orthographic)으로 설정해서 원근감이 사라지게 만드는 경우가 많다. 


 

하지만 게임 키트에서는 원근법(Perspective)으로 설정하여 카메라와의 거리에 따라서 오브젝트의 크기게 달라보이게 만들었다.


 

그리고 원근감을 연출하기 위한 두 번째 장치로 Start Screen Sprite Offsetter 라는 컴포넌트를 만들어서 마우스의 움직임을 감지하고 오프셋 수치에 따라서 배경에 배치된 오브젝트들이 다르게 움직이게 만들어져 있다.


 

잠시 화면을 가리는 스타트 메뉴를 비활성화 시키고 플레이 버튼을 눌러서 게임을 실행시킨 뒤, 마우스를 움직여보면 배경이 마우스의 움직임에 따라서 반응하여 더욱 원근감을 강하게 느낄 수 있도록 만들어주는 것을 볼 수 있다.


이것으로 스타트 씬에 대한 분석은 끝났고 이 다음부터는 게임 플레이와 관련된 부분을 분석해보자.




Explorer 2D Game Kit 분석 (1) - 개요

Explorer 2D Game Kit 분석 (2) - Start 씬 해부하기 (1)

Explorer 2D Game Kit 분석 (3) - Start 씬 해부하기 (2)

Explorer 2D Game Kit 분석 (4) - 게임플레이 요소 (1)


반응형

Explorer 2D Game Kit 분석 (2) 

Start 씬 해부하기 (1)


작성 기준 버전 :: 2019.1.4f1


Start 씬


 

2D 게임 키트에서 제일 처음으로 분석해볼 것은 바로 Start 씬이다. Start 씬은 게임 키트에서 게임이 시작되는 메인 메뉴를 구성하고 있다. 이 씬에서 하이어라키 뷰에 게임 오브젝트들은 어떻게 배치되어 있는지, UI는 어떻게 구성하고 있는지, 그리고 스크립트들은 어떻게 짜여 있는지를 알아볼 것이다.



하이어라키 뷰(Hierarchy view)


 

하이어라키 뷰에서는 시작 씬에 배치된 게임 오브젝트들을 리스트 형식으로 모두 한 번에 볼 수 있다. 실제로 게임을 만들면서 씬에 게임 오브젝트들을 배치하다보면 제대로 된 정리가 이루어지지 않고 난장판이 되는 경우가 다반사이다. 그에 반해 유니티 콘텐츠 팀에서 제작한 2D 게임 키트의 경우에는 위의 이미지와 같이 깔끔하게 하이어라키 뷰를 정리해두었다.


 

우선 빈 게임 오브젝트를 이용하여 경계선을 지어서 분류별로 게임 시스템과 관련된 게임 오브젝트, UI 게임 오브젝트, 해당 씬에서만 사용되는 게임 오브젝트 등으로 구분해두었다. 이렇게 해둠으로써 어디에 어떤 게임 오브젝트가 있는지 일일이 찾을 필요없이 카테고리별로 빠르게 찾을 수 있게 된다. 시작 씬 이외에도 게임을 플레이하는 씬인 Zone1~5 씬이 있는데 대부분의 씬에서도 약간의 차이점은 있지만 이러한 분류를 따르고 있다. 


개발자 별로 자신에게 적절하거나, 팀원과 상의한 후 팀의 씬 정리 규칙을 세우고 그 규칙에 따라 게임 오브젝트를 배치한다면 한결 보기 좋게 씬을 관리할 수 있다. 



System


하이어라키 뷰에서 시스템으로 분류된 게임 오브젝트는 씬 컨트롤러(Scene Controller), 트랜지션 스타트(Transition Start), 백그라운드 뮤직 플레이어(Background Music Player)가 있다. 시스템 쪽으로 분류해둔 게임 오브젝트들은 게임 시스템과 관련된 오브젝트이며, 대부분 모든 씬에서 존재해야되는 오브젝트들이 많다.


씬 컨트롤러 게임 오브젝트(Scene Controller Game Object)


 

씬 컨트롤러 게임 오브젝트에는 씬 컨트롤러 컴포넌트와 씬 컨트롤러 래퍼 컴포넌트가 부착되어 있다. 우선 씬 컨트롤러 컴포넌트는 다른 씬을 불러오는 씬 로드 기능을 관리하고 있으며 씬 컨트롤러 래퍼 컨트롤러 컴포넌트는 씬 컨트롤러 컴포넌트를 감싸는 역할을 한다(이 감싸는 역할이란 무엇인가는 잠시 후에 설명하도록 하겠다).


씬 컨트롤러 컴포넌트(Scene Controller Component)


public class SceneController : MonoBehaviour

 

씬 컨트롤러 컴포넌트는 앞서 이야기 했듯이 다른 씬을 불러오는 씬 로드 관리를 담당하는 컴포넌트이다. 


protected static SceneController instance;


public static SceneController Instance

{

    get

    {

        if (instance != null)

            return instance;


        instance = FindObjectOfType<SceneController>();


        if (instance != null)

            return instance;


        Create ();


        return instance;

    }

}


public static SceneController Create ()

{

    GameObject sceneControllerGameObject = new GameObject("SceneController");

    instance = sceneControllerGameObject.AddComponent<SceneController>();


    return instance;

}


void Awake()

{

    if (Instance != this)

    {

        Destroy(gameObject);

        return;

    }


    DontDestroyOnLoad(gameObject);


    m_PlayerInput = FindObjectOfType<PlayerInput>();


    if (initialSceneTransitionDestination != null)

    {

        SetEnteringGameObjectLocation(initialSceneTransitionDestination);

        ScreenFader.SetAlpha(1f);

        StartCoroutine(ScreenFader.FadeSceneIn());

        initialSceneTransitionDestination.OnReachDestination.Invoke();

    }

    else

    {

        m_CurrentZoneScene = SceneManager.GetActiveScene();

        m_ZoneRestartDestinationTag = SceneTransitionDestination.DestinationTag.A;

    }

}


씬 컨트롤러 컴포넌트에서 제일 먼저 살펴볼 부분은 이것이다. 씬을 불러오는 기능은 모든 씬에서 존재하며 다른 씬을 불러올 수 있어야 하기 때문에 싱글톤 패턴DontDestoryOnLoad가 적용되어 있다.


protected IEnumerator Transition(string newSceneName, bool resetInputValues, SceneTransitionDestination.DestinationTag destinationTag, TransitionPoint.TransitionType transitionType = TransitionPoint.TransitionType.DifferentZone)

{

    m_Transitioning = true;

    PersistentDataManager.SaveAllData();


    if (m_PlayerInput == null)

        m_PlayerInput = FindObjectOfType<PlayerInput>();

    m_PlayerInput.ReleaseControl(resetInputValues);

    yield return StartCoroutine(ScreenFader.FadeSceneOut(ScreenFader.FadeType.Loading));

    PersistentDataManager.ClearPersisters();

    yield return SceneManager.LoadSceneAsync(newSceneName);

    m_PlayerInput = FindObjectOfType<PlayerInput>();

    m_PlayerInput.ReleaseControl(resetInputValues);

    PersistentDataManager.LoadAllData();

    SceneTransitionDestination entrance = GetDestination(destinationTag);

    SetEnteringGameObjectLocation(entrance);

    SetupNewScene(transitionType, entrance);

    if(entrance != null)

        entrance.OnReachDestination.Invoke();

    yield return StartCoroutine(ScreenFader.FadeSceneIn());

    m_PlayerInput.GainControl();


    m_Transitioning = false;

}

 

씬 컨트롤러 컴포넌트의 가장 중심 기능인 씬 로드 기능은 Transition() 코루틴 함수에 정의되어 있다. 그 외의 함수들은 씬을 다시 시작하는 함수, 목표 지점 태그로  이동할 위치를 가져오는 함수 등 부가적인 기능을 구현하고 있다.


씬 컨트롤러 래퍼 컴포넌트(Scene Controller Wrapper Component)


public class SceneControllerWrapper : MonoBehaviour

{

    public void RestartZone (bool resetHealth)

    {

        SceneController.RestartZone (resetHealth);

    }


    public void TransitionToScene (TransitionPoint transitionPoint)

    {

        SceneController.TransitionToScene (transitionPoint);

    }


    public void RestartZoneWithDelay(float delay)

    {

        SceneController.RestartZoneWithDelay (delay, false);

    }


    public void RestartZoneWithDelayAndHealthReset (float delay)

    {

        SceneController.RestartZoneWithDelay (delay, true);

    }

}


씬 컨트롤러 래퍼 컴포넌트는 씬 컨트롤러 컴포넌트를 감싸는 컴포넌트로 호출 방향을 구분하기 위해서 만들어졌다.


 

호출 방향의 구분의 개념은 위의 이미지와 같다. 위의 이미지에서 볼 수 있듯이 씬에 배치된 게임 오브젝트의 이벤트로 호출될 때는 씬 컨트롤러 래퍼 컴포넌트를 통해서 호출되도록 만들고, 스크립트 내부에서 호출될때는 씬 컨트롤러를 직접 호출하게 설계되어 있다. 굳이 이렇게 나누어서 설계를 할 필요가 있는가 싶겠지만, 이렇게 씬 쪽에서 호출되는 방향과 내부 스크립트에서 호출되는 방향을 구분함으로써 문제가 발생했을 때, 어느 쪽 호출에서 문제가 발생했는지 빠르게 발견할 수 있다는 장점이 있다.



트랜지션 포인트 게임 오브젝트(Transition Point Game Object)


 

트랜지션 포인트 게임 오브젝트는 박스 콜라이더(Box Collider)와 트랜지션 포인트(Transition Poiont) 컴포넌트를 가진 게임 오브젝트로 실제로는 박스 콜라이더에 접촉한 플레이어를 다른 씬으로 전송하는 역할을 담당하는 게임 오브젝트이다.


단, 현재 씬은 플레이어의 캐릭터가 존재하지 않는 메인 메뉴 씬이기 때문에, 플레이어 캐릭터 오브젝트가 박스 콜라이더에 충돌하는 상황은 존재하지 않을 것이다.


트랜지션 포인트 컴포넌트(Transition Point Component)


[RequireComponent(typeof(Collider2D))]

public class TransitionPoint : MonoBehaviour


트랜지션 포인트 컴포넌트는 해당 컴포넌트가 부착된 게임 오브젝트가 소유한 콜라이더 2D(Collider2D)에 접촉한 플레이어 캐릭터를 다른 지역으로 보내는 역할을 한다. 그렇기 때문에 RequireComnent 어트리뷰트를 이용해서 트랜지션 포인트 컴포넌트가 부착되는 게임 오브젝트에는 반드시 Collider2D 컴포넌트가 부착되어 있어야 함을 정의하고 있다.


public enum TransitionType

{

    DifferentZone, DifferentNonGameplayScene, SameScene,

}


public enum TransitionWhen

{

    ExternalCall, InteractPressed, OnTriggerEnter,

}

 

그리고 트랜지션 포인트 클래스 내부에는 Transition Type과 Transition When이라는 열거형 두 가지가 정의되어 있다. Transition Type은 트랜지션 포인트가 어떤 종류의 씬으로 전환되는지를 의미한다. DifferentZone 타입은 다른 게임 플레이 씬으로 이동하는 것을 의미한다. 스타트 씬에 있는 트랜지션 포인트 역시 DifferentZone으로 설정되어 있는 것을 볼 수 있는데, 메인 메뉴 씬을 기준으로 시작 게임 씬 역시 "다른 게임 플레이 씬"이기 때문에 DifferentZone으로 설정되는 것이 맞다. DifferentNonGameplayScene 타입은 다른 씬이지만, 게임 플레이 씬은 아닌 경우이다. 예를 들자면 게임 플레이 씬에서 다시 메인 메뉴 씬으로 돌아오는 경우이다. SameScene은 같은 씬의 다른 지점으로 이동할 때를 의미한다.


TransitionWhen 열거형은 어느 시점에 전송을 시작할 것인가에 대한 것인데, ExternalCall은 외부에서 호출이 있을 경우를 의미한다. 앞에서 메인 메뉴에서는 플레이어 캐릭터 오브젝트가 없기 때문에 박스 콜라이더에 충돌하는 상황이 벌어지지 않을 것이라고 말했다. 그렇기 때문에 위의 이미지에서 스타트 씬의 트랜지션 포인트 게임 오브젝트에 부착된 트랜지션 포인트 컴포넌트의 Transition When의 값이 ExternalCall으로 설정되어 있는 것을 볼 수 있다. 즉, 콜라이더의 충돌을 이용하지 않는 경우라면 ExternalCall을 사용하는 것이다. InteractPressed는 플레이어 캐릭터가 트랜지션 포인트에 접촉한 상태에서 상호작용 키를 눌렀을 때를 의미한다. OnTriggerEnter 타입은 캐릭터가 트랜지션 포인트의 콜라이더에 접촉하는 순간에 바로 전송을 시작한다.


protected void TransitionInternal ()

{

    if (requiresInventoryCheck)

    {

        if(!inventoryCheck.CheckInventory (inventoryController))

            return;

    }

        

    if (transitionType == TransitionType.SameScene)

    {

        GameObjectTeleporter.Teleport (transitioningGameObject, destinationTransform.transform);

    }

    else

    {

        SceneController.TransitionToScene (this);

    }

}


트랜지션 포인트 컴포넌트에서 다른 씬으로 이동시키는 주요 기능은 TransitionInternal() 함수에서 처리하고 있으며, 여기에서 다른 씬을 로드하는 기능을 담당하는 씬 컨트롤러를 호출한다. 그리고 때에 따라서 트랜지션 타입이 SameSceme이라면 이동시키고자 하는 게임 오브젝트(예를 들어 플레이어)를 같은 씬 내의 목표 위치로 이동시키는 기능 역시 함께 담당한다.


프리팹화


트랜지션 포인트 게임 오브젝트는 파란색 육면체 아이콘을 보면 프리팹화되어 있는 것을 볼 수 있다. 이렇게 함으로써 플레이되고 있는 씬이나 캐릭터의 위치를 이동시키기 위해서 트랜지션 포인트를 일일이 만들 필요없이 트랜지션 포인트 프리팹을 원하는 위치에 가져다 놓고 프로퍼티만 설정하면 언제든 위치 이동 장치를 만들 수 있는 것으로 재활용성을 극대화했음을 알 수 있다.


씬 이름 활용법


 

이 트랜지션 포인트의 구현법 중에 가장 유용하다고 평할만한 포인트는 바로 씬 이름을 다루는 부분이다. 보통 다른 씬을 호출할 때, 씬 이름을 문자열로 호출하거나 빌드 세팅에 등록된 씬 인덱스를 이용해서 호출하는 경우가 많은데 이런 방법들은 몇 가지 문제점을 내포하고 있다. 


우선 씬 인덱스를 사용하는 방법은 등록된 씬의 순서가 변경되면 의도하지 않은 다른 씬이 호출되는 문제가 쉽게 발생한다.


그리고 일반적인 문자열을 사용하는 방식은 사용자의 오타 문제가 있을 수 있고, 특히 코드 난독화를 사용할 때, 상수 타입의 고정된 문자열을 코드에서 직접 사용한다면, 코드 난독화가 상수 문자열로 코드에 들어있는 씬 이름을 암호화해서 원하는 씬을 불러오지 못하는 경우도 발생할 수 있다.


그렇다면 2D 게임 키트에서는 어떻게 씬 이름을 다루어서 이런 문제를 해결했는지 살펴보자.


[SceneName]

public string newSceneName;


트랜지션 포인트 스크립트에는 해당 포인트가 플레이어를 어떤 씬으로 보낼지에 대한 변수인 new Scene Name 변수가 선언되어 있다.


 

일반적인 공개된 문자열이라면 인스펙터 뷰에서 위의 이미지와 같이 보여야할 것이다.

 

하지만 인스펙터 뷰에서 트랜지션 포인트 컴포넌트의 New Scene Name 프로퍼티를 보면 일반적인 string과는 다르게 팝업 선택 필드 방식으로 빌드 세팅에 등록된 씬 이름들을 선택할 수 있게 되어 있다. 이런 식으로 빌드 세팅에 등록된 이름을 선택하는 방식이면 등록된 씬의 순서가 변경될 때의 문제나 오타 문제, 씬 이름이 암호화될 문제 역시 발생하지 않는다.


[SceneName]


보통의 공개된 문자열과 다른 부분은 바로 이 SceneName 어트리뷰트가 붙어있다는 점이다. 바로 이 SceneName 어트리뷰트를 사용해서 이 어트리뷰트가 붙은 string은 인스펙터 창에서 인풋 필드(Input Field) 대신에 등록된 씬 이름이 드롭다운 형식으로 표현되게 만든 것이다.


public class SceneNameAttribute : PropertyAttribute

{}


SceneName 어트리뷰트를 [F12] 키로 따라가보면 씬 네임 어트리뷰트는 정의만 되어있고 내부에는 아무 것도 없다.


[CustomPropertyDrawer(typeof(SceneNameAttribute))]

public class SceneNameDrawer : PropertyDrawer


씬 네임 어트리뷰트의 실제 기능을 구현하는 코드는 씬 네임 드로워(Scene Name Drawer)에 있다. 씬 네임 드로워는 씬 네임 어트리뷰트가 부착된 프로퍼티를 인스펙터 뷰에서 어떻게 보여줄 것인가를 정의한다.


int m_SceneIndex = -1;

GUIContent[] m_SceneNames;

readonly string[] k_ScenePathSplitters = { "/", ".unity" };


public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)

void Setup(SerializedProperty property)

 

씬 네임 드로워는 3개의 멤버 변수와 2개의 함수로 이루어져있는데, m_SceneIndex는 현재 인스펙터 뷰에서 선택한 인덱스를 m_SceneNames는 팝업 선택 필드에서 보여줄 씬 이름들을 담는다. 그리고 k_ScenePathSplitters는 위의 빌드 세팅 이미지에서 볼 수 있듯이 [2D Game Kit/Scene/씬이름]으로 나타나는 씬 경로를 [ / ]로 쪼개고 씬 이름만 가져오기 위해서 정의된 것이다.


public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)

{

    if (EditorBuildSettings.scenes.Length == 0) return;

    if (m_SceneIndex == -1)

        Setup(property);


    int oldIndex = m_SceneIndex;

    m_SceneIndex = EditorGUI.Popup(position, label, m_SceneIndex, m_SceneNames);


    if (oldIndex != m_SceneIndex)

        property.stringValue = m_SceneNames[m_SceneIndex].text;

}

 

OnGUI() 함수는 에디터의 GUI가 그려질 때 호출되는 함수로, 씬 네임 드로워에서는 씬 네임 어트리뷰트가 부착된 프로퍼티의 GUI를 개발자가 정의한 대로 인스펙터 뷰에 그려주는 역할을 한다.


void Setup(SerializedProperty property)

{

    EditorBuildSettingsScene[] scenes = EditorBuildSettings.scenes;

    m_SceneNames = new GUIContent[scenes.Length];


    for (int i = 0; i < m_SceneNames.Length; i++)

    {

        string path = scenes[i].path;

        string[] splitPath = path.Split(k_ScenePathSplitters, StringSplitOptions.RemoveEmptyEntries);


        string sceneName = "";

        if (splitPath.Length > 0)

            sceneName = splitPath[splitPath.Length - 1];

        else

            sceneName = "(Deleted Scene)";

        m_SceneNames[i] = new GUIContent(sceneName);

    }


    if (m_SceneNames.Length == 0)

        m_SceneNames = new[] { new GUIContent("[No Scenes In Build Settings]") };


    if (!string.IsNullOrEmpty(property.stringValue))

    {

        bool sceneNameFound = false;

        for (int i = 0; i < m_SceneNames.Length; i++)

        {

            if (m_SceneNames[i].text == property.stringValue)

            {

                m_SceneIndex = i;

                sceneNameFound = true;

                break;

            }

        }

        if (!sceneNameFound)

            m_SceneIndex = 0;

    }

    else m_SceneIndex = 0;


    property.stringValue = m_SceneNames[m_SceneIndex].text;

}


Setup() 함수는 OnGUI() 함수에서 m_SceneIndex가 -1일 때, 즉 프로퍼티가 선택되지 않았을 때, 호출된다. Setup() 함수는 EditorBuildSettings에서 빌드 세팅에 등록된 씬의 목록을 가져와 OnGUI() 함수에서 팝업 선택 필드에서 그릴 수 있는 GUIContent로 가공하는 역할을 한다. 이런 과정을 통해서 빌드 세팅에 등록된 씬의 이름을 가져와서 팝업 선택 필드에 넣어주는 것이다.


이 이야기는 분석을 진행하면서 계속 말하겠지만, 이런 씬 네임 어트리뷰트와 씬 네임 드로워를 정의함으로써 프로그래머는 약간의 귀찮음을 감수하고 추후에 발생할 수 있는 버그와 문제 등을 예방할 수 있고 더 나아가서 에디터에서 주 작업을 진행할 디자이너의 편의와 작업 효율을 향상시킬 수 있게 된다.



백그라운드 뮤직 플레이어 게임 오브젝트(Background Music Player Game Object)


 

백그라운드 뮤직 플레이어에는 백그라운드 뮤직 플레이어 컴포넌트(Backgroung Music Player Component)가 부작되어 있다. 이 컴포넌트는 이름 그대로 게임에서 흘러나오는 배경 음악을 관리한다.


백그라운드 뮤직 플레이어 컴포넌트(Background Music Player Component)


public class BackgroundMusicPlayer : MonoBehaviour


이 컴포넌트는 배경 음악을 관리하는 컴포넌트로 배경 음악 역시 모든 씬에서 흘러나와야 하기 때문에 싱글톤 패턴으로 작성되어 있다. 다만 이번 예제인 2D 게임 키트에서는 배경 음악의 변경이 거의 없기 때문에 크게 언급할 부분은 없다. 다만, 직접 내부 코드나 오디오 믹서를 사용하는 부분은 참고해 볼만하다.




Explorer 2D Game Kit 분석 (1) - 개요

Explorer 2D Game Kit 분석 (2) - Start 씬 해부하기 (1)

Explorer 2D Game Kit 분석 (3) - Start 씬 해부하기 (2)

Explorer 2D Game Kit 분석 (4) - 게임플레이 요소 (1)


반응형

+ Recent posts