베르의 프로그래밍 노트

이번 포스트에서는 간단하게 중심점을 중심으로 회전하는 캐릭터와 캐릭터에서 일정거리만큼 떨어져서 중심점을 바라보는 카메라를 구현할 때 필요한 공식을 쓸 것이다.

위의 그림에서

O = 중심점(이 점을 중심으로 캐릭터가 움직이고, 카메라는 이 중심점을 바라본다.)

P = 플레이어의 위치

P1 = 이동한 플레이어의 위치

C = 카메라의 위치

C1 = 이동한 카메라의 위치

V = 중심점에서 캐릭터를 가리키는 방향

V1 = 중심점에서 이동한 캐릭터를 가리키는 방향

D = 플레이어와 카메라 간의 거리

D1 = 이동한 플레이어와 이동한 카메라 간의 거리

를 의미한다.

캐릭터의 이동

이 시스템에서

1. 캐릭터가 앞으로 간다는 것은 중심점으로 다가가는 것을 의미한다.

2. 뒤로 간다는 것은 중심점에서 멀어지는 것을 의미한다.

3. 왼쪽으로 간다는 것은 중심점을 기준으로 시계 방향으로 움직이는 것을 의미한다.

4. 오른쪽으로 간다는 것은 중심점을 기준으로 반시계 방향으로 움직이는 것을 의미한다.

각각의 값를 구하는 공식

V = P - O :: 중심점에서 플레이어를 가리키는 방향은 플레이어 위치 값에서 중심점의 위치값을 빼면 구할 수 있다.

V1 = P1 - O :: 중심점에서 이동한 플레이어를 가리키는 방향 역시 위와 같다.

C = P + ( ||V|| * D ) :: 카메라의 위치는 플레이어의 위치에서 ||V|| 방향으로 설정하고자 하는 거리 D 만큼 곱한 것으로 구할 수 있다.

C1 = P1 + ( ||V1|| * D1) :: 위와 같다.

( ||V|| 는 V라는 벡터의 단위 벡터, 즉 길이가 1인 V 벡터를 의미한다.)

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

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

[투네이션]

[Patreon]

[디스코드 채널]

블로그를 보면 우클릭이나 복사를 방지하는 플러그인이나 코드를 사용하는 블로그들이 많다.

물론 남의 사진이나 글을 복사해가서 자신의 것인냥 올리는 일은 분명하게 잘못되었고 나쁜 일 임에 틀림이 없다.

다만 프로그래밍하는 입장인 나로서는 프로그래밍 공부를 하는 사람들이 쓰는 블로그에서 우클릭 방지나 복사 방지를 걸어두는 것은 탐탁지 않다. 이런 블로그에 올라오는 코드는 거의 공부를 위한 코드이고 완벽한 기능을 갖춘 코드라기 보다는 특정한 상황의 예시를 보여주기 위한 예시 코드이다. 공부하는 이들은 이런 예시를 확인하기 위해서 빠르게 복사해서 돌려볼 수 있는게 중요한 법이다. 물론 직접 손으로 쳐보고 익히는 것도 중요한 법이지만, 얼마나 번거롭겠는가. 공부하는 사람에겐 좀 더 자유가 필요하다. 직접 타이핑해서 익히고 싶은 사람은 타이핑을 하는 것이고, 빠르게 복사해서 결과를 확인하고 싶은 사람은 그렇게 하는 것이면 되는 것이다.

물론 타인의 코드를 무작정 복사해서 자신의 결과물인양 삼는 것은 나쁜 일이다. 하지만 그렇게 중요한 코드나 작업물이라면 스스로 공개하지 않으면 되는 것이고, 공부를 위해 공개한 것이라면, 다른 사람이 좀 더 손쉽게 접근할 수 있게 해주자.

너, 나 그리고 우리를 위해

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

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

[투네이션]

[Patreon]

[디스코드 채널]

ScrollView 사용법

작성 기준 버전 :: 5.4 - 2019.4

게임에서 UI 창보다 크거나 많은 내용이 들어가는 콘텐츠를 UI 안에 담기 위해서 사용하는 방법은 여러가지가 있다. 그 중에 대표적인 방법이 바로 버튼 같은 것을 이용해서 페이지를 넘기는 것이고 또 하나는 스크롤을 이용해 UI 내에서 이동하면서 볼 수 있는 스크롤 뷰이다. 이 두 가지의 방법 중에서 어떤 것을 사용할 것인지 결정하는 차이점은 내 개인적인 생각이지만 바로 '연속성'이라는 것이다.

UI에 들어가는 콘텐츠가 연속적이지 않고 흐름이 끊어져도 상관 없다면 페이지 방식을 사용하는 것이 좋고, 들어가는 콘텐츠가 커다란 하나의 것이거나 연속적인 면이 중요해서 연결되어져야 한다면 스크롤 뷰 방식이 적당할 것이다.

이런 스크롤 뷰 방식은 스스로 직접 구현하려면 상당히 귀찮은 면이 많겠지만 유니티 엔진의 UGUI에서는 이미 스크롤 뷰를 지원하고 있다. 그래서 간단한 클릭 몇 번만으로도 스크롤 뷰를 뚝딱하고 만들 수 있다.

Hierachy 뷰에서 우클릭을 UI 메뉴에서 Scroll View를 선택하면 스크롤 뷰가 생성된다.

스크린샷과 같은 형태로 스크롤 뷰가 생성되는데 내용을 하나씩 살펴보자면.

Scroll View :: 우리가 생성한 스크롤 뷰

Viewport :: 표시하고자 하는 콘텐츠가 보여질 곳

Content :: 표시하고자 하는 내용물

Scrollbar Horizontal :: 수평 스크롤바

Scrollbar Vertical :: 수직 스크롤바

를 나타낸다. 스크롤 뷰를 원하는 형태로 수정하기 위해서는 Hierachy에서 Scroll View를 선택하고 Inspector 창을 보면 스크롤 뷰에 대한 옵션을 볼 수 있다.

스크롤 뷰의 옵션들은 Scroll Rect라는 Component에 대부분 포함되어 있다.

Horizontal :: 스크롤 뷰의 수평 이동을 허용할 것인가?

Vertical :: 스크롤 뷰의 수직 이동을 허용할 것인가?

Movement Type :: 스크롤 이동 타입(세 가지가 있다.)

Unrestricted - 콘텐츠가 스크롤 밖으로 나가도 조금도 제한하지 않는다.

Elastic - 콘텐츠가 스크롤 밖으로 나가면 정해놓은 값(Elasticity)만큼의 속도로 스크롤 뷰 안으로 돌아온다.

Clamped - 콘텐츠가 스크롤 밖으로 나가지 못하게 완전히 제한한다.

Inertia :: 관성. 이 값을 켜두면 스크롤을 끌다가 놓으면 바로 정지하지 않고 끌던 속도가 점점 감소하며 멈춘다.

Scroll Sensitivity :: 스크롤 민감도

Horizontal Scrollbar :: 수평 스크롤바

Visibility - 스크롤바가 보이는 방식(항상 보이는 방식인지 콘텐츠의 크기에 따라 보이는 방식인지를 설정할 수 있다.)

(수직 스크롤바 역시 같은 내용이다.)

이 다음으로 다뤄야하는 내용은 바로 콘텐츠이다.

바로 뷰포트 밑에 있는 Content 라는 게임 오브젝트인데, UI에서 보여주고자 하는 내용들은 모두 이 Content 오브젝트의 자식 오브젝트로 배치해야한다. 그리고 이 Content의 크기에 따라 스크롤 뷰의 크기가 결정된다. 그리고 초기 상태는 top, stretch 상태로 설정되어서 크기 값이 Right, Height로 되어있는데 좀더 직관적인 값인 Width, Height로 보기 위해서 top, left 상태로 바꿔주는 것을 추천한다.

현재 설정된 Width 583, Height 300이라는 크기를 Scene에서 보면 아래와 같은 크기이다.

게임을 제작할때 필요한 스크롤 뷰의 크기에 맞춰서 잘 조절해 주어야 한다. 다만 고정된 크기의 스크롤 뷰라면 Inspector 창에서 크기를 직접 조절해도 상관은 없지만 만약 아이템의 갯수와 같은 요소를 통해서 보여져야하는 스크롤 뷰의 크기가 달라져야 한다면 스크립트를 통해서 Content의 크기를 조절하는 방법도 알아둬야 한다.

우선 스크롤 뷰를 쉽게 가져오기 위해서 스크롤 뷰를 가진 오브젝트에 스크립트를 추가한다.

그리고 추가한 스크립트를 통해 다음과 같은 코드를 작성하면 된다.

ScrollView의 Content 크기를 조절하는 스크립트

using UnityEngine;
using UnityEngine.UI;   // UI와 관련된 스크립트 작업을 위해서 추가해 주어야 한다.
using System.Collections;

public class ScrollViewPractice : MonoBehaviour
{
    // 스크롤 뷰와 관련된 수정을 하기 위해 가지고 있는 변수
    ScrollRect scrollRect;

    // Use this for initialization
    void Start ()
    {
        scrollRect = GetComponent<ScrollRect>();    // 게임 오브젝트가 가지고 있는 ScrollRect를 가져온다.

    }
   
    void SetContentSize()
    {
        float width = 100.0f;
        float height = 100.0f;
        // scrollRect.content를 통해서 Hierachy 뷰에서 봤던 Viewport 밑의 Content 게임 오브젝트에 접근할 수 있다.
        // 그리고 sizeDelta 값을 통해서 Content의 높이와 넓이를 수정할 수 있다.
        scrollRect.content.sizeDelta = new Vector2(width, height);
    }
}

위의 코드를 적절히 응용하면 아이템 개수에 따라, 혹은 원하는 크기로 Content의 크기를 조절할 수 있다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

Programming 

- 

Coroutine 내에서의 무한 루프 작성시 주의점

유니티 엔진을 이용해서 게임을 제작하다 보면 코루틴을 자주 사용하게 된다. 몇 초후에 문이 자동으로 열렸다가 닫힌다든지, 화상 데미지로 1초마다 데미지가 얼마씩 들어온다든지 하는 형식으로 말이다.

특정한 경우에는 코루틴을 실행시킨 다음에 안에 무한 루프문을 작동시키는 방식으로 코루틴을 유지하면서 사용하는 방법도 있다.

IEnumerator CoroutineFunction()

{

yield return null;

while(true)

{

Function();

}

}

다만 코루틴 내에서 무한 루프를 처리할 때 주의할 점이 있는데 위의 코드처럼 코루틴을 작성하면 유니티 에디터에서 실행하든 빌드를 해서 실행을 하든 프로그램이 응답없음이 뜨면서 정지를 할 것이다. 이 문제를 해결하는 방법은 매우 간단한데, 바로 while 무한 반복문 안에 yield return을 넣어주는 것이다.

올바른 코루틴 내의 무한 루프 사용법

IEnumerator CoroutineFunction()

{

while(true)

{

yield return null;

Function();

}

}

이 사태의 원인은 코루틴이 돌리는 무한 반복문이 시스템에 독점적으로 돌아가는 상태가 되었기 때문이다. 그렇기 때문에 이를 해결하기 위해서 반복문안에 반드시 yield return을 이용해서 시스템을 다른 코드에 양보해주는 것이 필수이다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

프로그래밍을 할 때 있어서 모든 일이 처음 설계한대로 흘러간다면 얼마나 좋을까? 하지만 Hello World를 출럭하는 프로그램이 아닌 이상에야 그런 일은 있을 수 없다.

확장성을 위해, 재사용성을 위해, 더 나은 구조를 위해 코드와 설계는 변하기 마련이다. 그 와중에 많은 함수나 변수, 클래스가 추가되고 삭제된다. 물론 혼자서만 하는 작업이라면 코드를 바꾸고 바꾼 코드를 바로 적용하면 되지만, 코드 베이스를 만드는 사람과 그 베이스를 이용해서 작업하는 사람이 따로 있는 상황이라면 이야기가 조금 달라진다.

만약 베이스를 작업하는 사람이 몇몇의 함수를 삭제하고 다른 이름의 함수로 대체했다면 그 베이스를 응용하는 사람 역시 그에 대한 사실을 알아야 한다. 물론 일반적인 상식으로 베이스 작업자가 베이스를 변경했다면 다른 작업자에게 바로 알려주고 다른 작업자는 바로 변경하는게 맞는 이야기지만, 사람과 사람 사이의 의사소통이라는게 말처럼 쉽기만 하던가. 베이스 작업자가 변경사항을 몇 개는 빠뜨리고 알려줄 수도 있고, 다른 작업자는 이야기를 들었지만 까먹을 수도 있는 일이다. 여튼 의사소통 과정에서 문제가 발생했다면 다른 작업자는 뜬금없이 바뀐 베이스 코드에 당황을 금치 못할 것이다.

그런 상황을 맞이한 다른 작업자는 당연히 문제를 해결하기 위해서 베이스 작업자에게 어떻게 변경된 것인지 물어보던지, 코드를 뒤져서 바뀐 함수를 적용하던지 하는 노력을 하겠지만 아무래도 이런 방식은 해결 속도도 느릴 뿐더러 효율적이지 못하다.

그렇기 때문에 나온 해결책이 바로 [Obsolete] 라는 어트리뷰트이다.

class TestClass
{
    [Obsolete]
    public void Function1()
    {
    }
}

더 이상 사용하지 않거나 그럴 예정인 클래스나 함수, 변수의 앞에 [Obsolete] 어트리뷰트를 붙여주면 된다. 그렇게 하면 해당 함수를 호출할 때 초록색 밑줄과 함께 더 이상 사용하지 않는 함수라는 경고가 뜬다.

그리고 툴팁에서는 함수 앞에 [deprecated]가 붙게 된다.

이 [Obsolete]는 세 가지 방식의 오버로딩을 지원한다.

class TestClass
{

    [Obsolete]
    public void Function1()
    {

    }

    [Obsolete("Not use anymore.")]
    public void Function2()
    {

    }

    [Obsolete("Not use anymore.", true)]
    public void Function3()
    {

    }
}

[Obsolete] :: 더 이상 사용하지 않는 코드라는 경고만 출력한다.

[Obsolete(string message)] :: 더 이상 사용하지 않는다는 경고에 추가적인 메시지를 남길 수 있다. 이 메시지를 통해 더 이상 사용하지 않는 코드 대신에 사용할 코드를 사용자에게 알릴 수 있다.

[Obsolete(string message, bool error)] :: 추가적인 로그와 함께 이 코드를 사용할 경우에 컴파일 에러를 띄울지를 결정한다. true를 넣어주면 컴파일 에러를 띄워서 이 코드를 사용하면 컴파일을 할 수 없게 된다.

이런 식으로 [Obsolete]를 적절하게 사용하면 베이스 작업자는 코드 작업만으로 다른 작업자에게 코드가 변경되었음을 알림과 동시에 그에 대한 해결책도 전해줄 수 있다. 베이스 작업자가 코드를 변경하고 다른 작업자에게 변경사항을 일일이 알리는 것보다 훨씬 빠르고 효율적인 해결책이다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

어지간한 외국 프로그램에는 기본적으로 있는 문제인 한글 경로 포함 문제는 Unity Collaborate에도 있다. 이 문제는 In The Cloud에서 유니티 클라우드 서버에 저장된 프로젝트 파일을 받아올 때 발생하는 문제인데, 이 파일을 다운받는 경로 상에 한글 경로가 하나라도 포함되면 클라우드 서버에서 프로젝트 파일을 받아오는데 실패한다.

해결책은 매우 간단하다. 프로젝트 파일을 받고자하는 경로상에 한글 이름의 폴더를 두지 않으면 된다. 일본어나 중국어 상에서도 같은 문제가 발생할 지는 모르겠지만, 아마 발생할 확률은 높다고 생각된다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]

ps. 유니티를 재실행하는 것 말고도 다른 해결책이 있다. Inspector 창을 껐다가 켜는 것이다. 하지만 이것 역시 유니티를 재실행하는 것과 비슷한 수준의 귀찮음을 프로그래머에게 가져다 준다.

ps2. 또 다른 해결책으로는 작업하는 도중에는 Collaborate를 끄고, 업데이트나 퍼블리쉬를 할때만 켜서

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

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

[투네이션]

[Patreon]

[디스코드 채널]

나는 C++ 프로그래머라서 그런지 C#의 문법적인건 가끔 까먹는 경우가 많다.

C++의 경우에는 부모 클래스의 생성자를 자식 클래스의 생성자에서 호출할때는 이니셜라이저에 부모 클래스 이름으로 호출해주면 됐었다.

C++의 경우

class Parent;
{
private:
    int i;
public:
    Parent(int i) : i(i) {  }
}

class Child : public Parent
{
private:
    int j;
public:
    Child(int i, int j) : Parent(i), j(j) {  }    // 부모의 이름으로 부모의 생성자를 호출할 수 있다.
}

하지만 C#의 경우는 약간 달라서 부모 클래스의 이름으로는 부모 클래스의 생성자를 호출할 수 없고 base 키워드를 사용해야 한다.

C#의 경우

public class Parent;
{
    private int i;

    public Parent(int i)
    {
        this.i = i;
    }
}

public class Child : Parent
{
    private int j;

    public Child(int i, int j) : base(i)    // 부모 클래스의 생성자를 호출하려면 base 키워드를 사용해야 한다.
    { 
        this.j = j;
    }
}

C# 프로그래밍 책을 한 번 훑어보면서 봤던 내용인데 C#코딩을 자주하는 편은 아니라 정확한 방법을 까먹어서 다시 찾아보게 되었다.

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

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

[투네이션]

[Patreon]

[디스코드 채널]