오늘 한 일

• 유니티 심화 주차 강의 진도 나가기
• 동적 생성 특강 듣기
• JSON 복습하기

유니티 JSON

개념

JSON은 JavaScript 객체 문법으로 구조화된 데이터를 표현하기 위한 문자 기반 표준 포맷으로 웹이나 네트워크에서 서버와 클라이언트 사이에 데이터를 주고 받을 때 주로 사용된다.

특징

• JSON의 데이터는 Key와 Value의 쌍으로 이루어진 데이터로 저장된다.

  {
    "이름": "홍길동",
    "나이": 25,
    "성별": "남성",
    "직업": "개발자",
    "주소": {
        "도시": "서울",
        "우편번호": "12345"
    },
    "취미": ["독서", "음악감상", "여행"]
  }

• 다른 언어에서도 JSON을 읽고 쓸 수 있는 기능이 제공된다. (JSON이 언어로부터 독립적인 데이터 포맷이기 때문)

  // 사용 가능한 언어
  JavaScript, Python, Java, C#, PHP, Ruby, Swift ... 그외 등등

• 주석을 넣을 수 없다

장단점

장점

• 텍스트를 사용하기 때문에 사람이 이해하기 쉽다.
• 직렬화와 비직렬화 함수를 통해서 변환이 편하다.

단점

• 작은 문법 오류에도 민감하게 반응한다.

사용 방법

기본적으로 실험해볼 데이터들

// 기본적인 데이터 구조와 리스트, Dictionary
public class JsonTestClass
{
    public string name;
    public int health;
    public float speed;
    public List<string> itemList = new List<string>();
    public Dictionary<string, float> potionList = new Dictionary<string, float>();
>
    public JsonTestClass()
    {
        name = "르탄";
        health = 100;
        speed = 5f;
        itemList.Add("스파르타의 창");
        itemList.Add("스파르타의 방패");
        potionList.Add("회복 물약", 4);
        potionList.Add("마나 물약", 3);
    }
>
    public void Print()
    {
        Debug.Log($"이름: {name}");
        Debug.Log($"체력: {health}");
        Debug.Log($"속도: {speed}");
        foreach (string item in itemList)
        {
            Debug.Log($"소지한 아이템 {item}");
        }
        foreach (var data in potionList)
        {
            Debug.Log($"포션 목록 - {data.Key} : {data.Value}");
        }
    }
}
>
// Vector3
public class JsonVector
{
    public Vector3 vector3 = new Vector3(1f, 1f, 1f);
}
>
// MonoBehaviour
public class TestMono : MonoBehaviour
{
    public int i = 10;
    public Vector3 v3 = new Vector3(2f, 2f, 2f);
}

Newtonsoft JSON으로 테스트

코드

// 기본 데이터 구조 직렬화
JsonTestClass jTest1 = new JsonTestClass();
string jsonData = JsonConvert.SerializeObject(jTest1); // 오브젝트를 매개변수로 전달
Debug.Log(jsonData);
>
// 기본 데이터 구조 역직렬화
JsonTestClass jTest2 = JsonConvert.DeserializeObject<JsonTestClass>(jsonData);
jTest2.Print();
>
// MonoBehaviour 직렬화
GameObject obj = new GameObject();
obj.AddComponent<TestMono>();
Debug.Log(JsonConvert.SerializeObject(obj));
>
// Vector3 직렬화
JsonVector jVector = new JsonVector();
Debug.Log(JsonConvert.SerializeObject(jVector));

결과

-

• 기본 데이터 구조 직렬화

• 
• 기본 데이터 구조 역직렬화

• 
• MonoBehaviour 클래스 자기 참조 루프
  • MonoBehaviour를 상속받는 클래스를 직렬화할 때에 순환 구조를 해결해도 다른 예외는 해결책이 없다. 그래서 상속받지 않는 클래스가 대신 값을 받아오거나 다른 매개 변수를 통해서 직렬화해줘야한다.

• 
• Vector3 normalized 루프
  • Vector3를 어거지로 정상 직렬화하고 싶다면..

    JsonVector jVector = new JsonVector();
    JsonSerializerSettings setting = new JsonSerializerSettings(); // setting을 건들여준다.
    setting.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
    Debug.Log(JsonConvert.SerializeObject(jVector));

    
• 위와 같이 Loop 설정을 바꿔서 직렬화할 수 있지만, 문제는 좌표가 아닌 다른 것들도 다 딸려서 저장되기 때문에 사용하지 않는 편이다.
• 그래서 MonoBehaviour를 상속받는 클래스처럼 따로 특정값만 받아서 직렬화해주는 방식을 사용한다.

유니티 기본 제공 Json Utility로 테스트

코드

// 기본적인 데이터 구조 직렬화
 JsonTestClass jTest1 = new JsonTestClass();
 string jsonData = JsonUtility.ToJson(jTest1);
 Debug.Log(jsonData);
>
// 기본적인 데이터 구조 역직렬화
 JsonTestClass jTest2 = JsonUtility.FromJson<JsonTestClass>(jsonData);
 jTest2.Print();
>
// Vector3 직렬화
 JsonVector jVector = new JsonVector();
 string jsonVector = JsonUtility.ToJson(jVector);
 Debug.Log(jsonVector);
>
// Mono 직렬화
 GameObject obj = new GameObject();
 var test1 = obj.AddComponent<TestMono>();
 test1.i = 100;
 test1.v3 = new Vector3(3f, 3f, 3f);
 /// 직렬화 할 때는 게임 오브젝트가 아니라 해당 클래스 컴포넌트를 직접적으로 가져와줘야한다.
 string jsonData2 = JsonUtility.ToJson(obj.GetComponent<TestMono>());
 Debug.Log(jsonData2);
>
// Mono 역직렬화
 GameObject obj2 = new GameObject();
 // 기존 역직렬화와 다르게 Overwrite를 사용한다
 JsonUtility.FromJsonOverwrite(jsonData, obj2.AddComponent<TestMono>());
 // FromJsonOverwrite - 새로운 오브젝트를 만들지 않고, 기존에 있는 오브젝트에 클래스의 변수값을 덮어씌우는 처리를 한다.

결과

• 보면은 Dictionary가 Serialize 되지 않은 모습을 볼 수 있다. (Json Utility는 Dictionary와 클래스 Serialize를 지원하지 않는다.)

• 클래스는 [System.Serializable]로 해결 가능하지만,

• Dictionary는 아예 지원하지 않는다. (외부 라이브러리를 사용해야된다;)

• Vector3나 MonoBehaviour를 상속받는 클래스의 오브젝트를 직렬화할 때 정상적으로 직렬화된다.

테스트로 알아낸 것

파일을 만들어서 저장하고 읽어오기

파일을 만들어서 저장하기

// 파일 경로 지정 (File 모드 읽거나 만들거나)
 FileStream saveStream = new FileStream(Application.dataPath + "/test.json", FileMode.OpenOrCreate);
 // 데이터를 만들어서 직렬화
 JsonTestClass jTest1 = new JsonTestClass();
 string jsonSaveData = JsonConvert.SerializeObject(jTest1);
 // 문자열인 Json 데이터를 인코딩 UTF8의 GetBytes 함수로 Byte 배열로 만들어준다. (파일 저장 때문에)
 byte[] saveData = Encoding.UTF8.GetBytes(jsonSaveData);
 // 쓰고 닫기
 saveStream.Write(saveData, 0, saveData.Length);
 saveStream.Close();

저장된 결과

• 잘 저장된 모습을 볼 수 있다. (Application.dataPath면 Assets 파일에다 저장될 것이다.)
• 

만든 파일을 읽어오기

// 지정된 파일 열기 (FileMode.Open)
FileStream loadStream = new FileStream(Application.dataPath + "/test.json", FileMode.Open);
// 생성된 파일 stream에서 Read로 데이터를 읽어드린 다음 읽은 데이터를 반대로 String으로 인코딩해준다.
byte[] loadData = new byte[loadStream.Length];
loadStream.Read(loadData, 0, loadData.Length);
loadStream.Close();
string jsonLoadData = Encoding.UTF8.GetString(loadData);
// 그 다음에 이 문자열을 DeSerialize해준다.
JsonTestClass jTest2 = JsonConvert.DeserializeObject<JsonTestClass>(jsonLoadData);
jTest2.Print();

불러서 읽은 결과

• 
• 기본적인 데이터 구조들이 불러와진 걸 볼 수 있다.
  이와 같이 게임 데이터를 로컬에 저장하고 불러오는 세이브 기능을 구현해볼 수 있다.

추가적으로

Json 데이터를 클래스로 만드는 방법이 있는데 Json 2 C#를 검색하면 Json 데이터를 읽고 자동으로 클래스로 만들어주는 사이트들이 있다.

참고 자료

베르의 게임 개발 유튜브

JSON으로 작업하기

작성하면서 느낀점

저번에 Visual Studio로만 하는 JSON 활용법과 Unity에서 하는 JSON 활용법이 달라서 신기했다. 추후에 가능하다면 JSON을 통한 멀티 플레이어 기능 구현을 하는 방법을 알아둬야겠다.

오늘 한 일

• 팀프로젝트 진행하기 ( 토끼 만들기 )
• AI 내비게이터를 좀 더 깊게 파보기

오늘은 AI 내비게이터를 활용한 도주 AI를 만들어볼 생각이다.

도주 AI

목표

• 기본적으로는 플레이어로 부터 잘 멀어져야한다.

• 모서리에 붙었을 경우에 대한 이동 처리도 생각해줘야한다.
• 도주에 어느 정도 랜덤성을 부여해줘야한다.

기초적인 프레임워크

 // 필요한 컴포넌트
 protected Animator animator;
 protected NavMeshAgent agent;
>
 // 플레이어 거리 구하기
 protected float playerDistance;
>
 // 상태
 protected AIState aiState;
>
 // SO
 public AnimalSO statSO;
>
 void Awake()
 {
     agent = GetComponent<NavMeshAgent>();
     animator = GetComponent<Animator>();
 }
>
 void Start()
 {
     ChangeState(AIState.Idle);
 }
>
 protected virtual void Update()
 {
     if (aiState == AIState.Dead) { return; }
 >    
     // 플레이어 거리 감지
     playerDistance = (transform.position - CharacterManager.Instance.Player.transform.position).sqrMagnitude; // sqr을 활용했으니 제곱을 하는 걸 잊지 맙시다.
>
     animator.SetBool("Moving", aiState != AIState.Idle);
>
     switch (aiState)
     {
         case AIState.Idle:
             // IdleState();
             break;
         case AIState.Flee:
             FleeState();
             break;
     }
>
     animator.speed = agent.speed / statSO.walkSpeed;
 }
>
 // 상태 변환
 protected virtual void ChangeState(AIState state)
 {
     aiState = state;
>
     switch (aiState)
     {
         case AIState.Idle:
             agent.isStopped = true;
             agent.speed = statSO.walkSpeed;
             break;
         case AIState.Flee:
             agent.isStopped = false;
             agent.speed = statSO.runSpeed;
             break;
         case AIState.Dead: // 초기화 작업
             agent.isStopped = true;
             agent.speed = 0f;
             animator.speed = 1f;
             agent.ResetPath();
             animator.SetBool("Dead", true);
             _collider.isTrigger = true; // 통과 시키게 하기 위해서
             Invoke("Destroy", 30f);
             break;
     }
 }
 >
 ... IdleState 부분 생략...
 >
 // 도주 상태 시
 void FleeState()
 {
     if (agent.remainingDistance < 1f)
     {
         agent.SetDestination(NewFleePoint());
     }
     else
     {
         ChangeState(AIState.Idle);
     }
 }
>
// 도주 목적지 설정
 Vector3 NewFleePoint()
 {
 > 목적지 설정 코드
 }
>
// 술래잡기 테스트용
 private void OnCollisionEnter(Collision collision)
 {
     if (collision.gameObject.CompareTag("Player"))
     {
         if (aiState == AIState.Dead) { return; }
         ChangeState(AIState.Dead);
     }
 }
>
 protected virtual void Destroy()
 {
     Destroy(this.gameObject);
 }

• 스파르타 코딩클럽에서 제공된코드를 살짝 고쳐줬다.

구현하는 과정

반대 방향으로만 도망

코드

    void FleeState()
    {
        if (agent.remainingDistance < 1f)
        {
            agent.SetDestination(NewFleePoint());
        }
        else
        {
            ChangeState(AIState.Wandering);
        }
    }
>
    Vector3 NewFleePoint()
    {
        Vector3 dir = transform.position - CharacterManager.Instance.Player.transform.position.normalized;
        return transform.position + dir;
    }

• 모서리를 만나면 너무 약하다.

랜덤으로 돌리지만 특정 부분만 거르기

코드

    void FleeState()
    {
        if (agent.remainingDistance < 1f)
        {
            agent.SetDestination(NewFleePoint());
        }
        else
        {
            ChangeState(AIState.Wandering);
        }
    }
>
    Vector3 NewFleePoint()
    {
        NavMesh.SamplePosition(transform.position + (Random.onUnitSphere * statSO.safeDistance), out NavMeshHit hit, statSO.safeDistance, NavMesh.AllAreas);
        int i = 0;
        while (GetDestinationAngle(hit.position) > 90 || playerDistance < statSO.safeDistance)
        {
            NavMesh.SamplePosition(transform.position + (Random.onUnitSphere * statSO.safeDistance), out hit, statSO.safeDistance, NavMesh.AllAreas);
            i++;
            if (i == 30)
                break;
        }
        return hit.position;
    }
>
    float GetDestinationAngle(Vector3 targetPos)
    {
        return Vector3.Angle(transform.position - CharacterManager.Instance.Player.transform.position, transform.position + targetPos);
    }

• 전보다 낫지만 뭔가 보충이 좀 더 필요해보인다. 플레이어에게 꼴아박는 경우가 있다;

최종 개선

• FleeState에 조건을 추가하여 좀 더 능동적인 도주 패턴을 덧붙여줬다.

  코드

    void FleeState()
   {
       float destinationDistance = (agent.destination - CharacterManager.Instance.Player.transform.position).sqrMagnitude;
  // 조건에다가 목적지가 플레이랑 가깝지 않은 지 그리고 당장 플레이어와 너무 가깝지 않은지에 따른 조건을 추가해뒀다.
       if (agent.remainingDistance < 1f || destinationDistance < statSO.safeDistance * statSO.safeDistance || playerDistance < 1f)
       {
           agent.SetDestination(NewFleePoint());
       }
       else
       {
           ChangeState(AIState.Wandering);
       }
   }
  ... 아랫 부분은 랜덤 방향 도주와 동일하다.

개선 후 결과

• 빨간색이 랜덤 도주, 파란색이 추가적인 조건을 덧붙여준 토끼다
• 체감상 느끼기로는 그냥 뭉쳐있으면 도주 능력이 어느 정도 약해질 수 밖에 없는 것 같다.
• 실제 적용으로는 다를 수도 있으니, 되도록이면 코드는 간결하게 만들수록 좋을 것이다.

오늘 알게된 코드

Vector

.sqrMagnitude

• 루트를 씌우지 않은 벡터의 스칼라값으로 기존 magnitude보다 연산은 빠르지만 조건 덧붙여줄 때에는 조건을 제곱해줘야한다.

  NavMeshAgent

  .FindClosetEdge(out NavMeshHit edgeHit)

• 현재 위치에서 가장 가까운 NavMesh의 바깥 테두리 위치를 가져온다.

느낀점

확실히 한 사람이 여러 역할을 분담받는 것보다는 파트를 나눠 한 사람씩 역할을 맡으니까. 좀 더 세부적인 사항을 신경 쓸 수 있어서 좋은 것 같다.

오늘 한 일

• 팀 프로젝트 기획 후 진행
• AI 내비게이터 배우기

AI 내비게이터

개념

유니티의 기능 AI 길찾기 기능 중 하나로 런타임 이전에 이동 가능한 영역을 지정하고, Nav Mesh Agent 컴포넌트를 활용하여 해당 AI에게 길찾기 능력을 부여해주는 기능이다.

특징

Navigation Mesh (네비게이션 매쉬)

• 3D 공간을 그리드로 나누어 이동 가능한 영역과 불가능한 영역을 구분하는 매쉬입니다. 캐릭터는 이 영역을 기반으로 경로를 계산해서 이동합니다.
  • 
  • 
  • 하나는 움직이지 않는 지형을 위한 영역 지정이고 또 다른 하나는 움직이는 오브젝트를 위한 영역 지정이다.

Pathfinding(경로 탐색)

• 캐릭터의 현재 위치에서 목표 지점까지 가장 적절한 경로를 찾는 알고리즘입니다.
• 주로 A* 알고리즘 등이 사용되며, 지정된 목표 위치까지 최단 경로를 탐색합니다.

Steering Behavior (스티어링 동작)

• 캐릭터나 NPC가 경로를 따라 이동할 때보다 자연스러운 동작을 구현하는데 사용됩니다.
• 동적으로 캐릭터의 이동 방향과 속력을 조정하여 부드럽고 현실적인 이동을 시뮬레이션 합니다.
  • 

Obstacle Avoidance (장애물 피하기)

• 캐릭터가 이동 중에 장애물과 충돌하지 않도록 하는 기술입니다. 각종 센서나 알고리즘을 사용하여 장애물을 감지하고 피하는 동작을 수행합니다.
  • 

Local Avoidance (근접 회피)

• 여러 캐릭터나 NPC가 서로 충돌하지 않도록 하는 기술입니다. 캐릭터들 사이의 거리를 유지하거나 회피 동작을 수행하여 서로 부딪히지 않도록 합니다.

사용하는 방법

NavMesh 영역 정하기

1. 내비게이션 (Obsolete)

들어가기 전에 기초 설명

Agents

• 길 찾기를 수행할 Agent들의 Obstacle Avoidance를 설정하고 모으는 리스트이다.
• 

Areas

• 각 영역의 가중치 값을 정하는데 사용하는 항목이다.
• 

Bake

• 모든 기초 설정이 완료되었다면, Bake를 하여 Agents들의 이동 영역을 산출해준다.

Object

• 선택한 오브젝트들에게 Area를 부여해주는 곳이다
• Navigation Static을 선택해주지 않으면, 해당 오브젝트에게서 이동 영역을 산출해줄 수 없다.
• 

이동 가능 영역 Bake하기

• 내비게이션(Obsolete) 창 열기
  • 

• Object를 선택하고 Inspector창에 있는 Navigation (Obsolete) 창을 선택한다.

• Bake를 하기 전에 Static을 활성화하고, 원하는 Area를 설정한다.

• 산출하고자 하는 오브젝트들에게 Object 설정을 해줬다면 Bake를 해주자
• 필자는 이동영역이 붕뜨는 것을 방지하기 위해서 Radius를 0.1로 설정하고 Bake한다.

• 아래와 같이 보이긴한데 흐릿하게 보인다면 잘 산출된 것이다.

NavMeshAgent로 영역 통한 이동 구현하기

이제 이동 영역을 정했으니 이동 영역을 사용하는 동물을 만들어보자

NavMeshAgent 컴포넌트

• AI Navigation을 활용한 캐릭터의 이동을 위해서는 들어가야하는 컴포넌트로 오브젝트의 자연스러운 이동이나 장애물 피하기 경로 찾기 설정들을 할 수 있다.
• 원하는 오브젝트에다가 위 컴포넌트를 추가시키자!

  각종 설정

  Steering

• Speed 최대 이동 속도(초당 월드 단위로)
• Angular Speed 최대 회전 속도(초당 각도)
• Acceleration 최대 가속(제곱 초당 월드 단위로)
• Stopping distance 에이전트는 목표 위치에 가까워졌을 시 정지합니다.
• Auto Braking 활성화 시 에이전트는 목적지에 다다를 때 속도를 줄입니다. 에이전트가 멀티플 포인트 사이에서 부드럽게 움직여야 하는 순찰과 같은 동작을 할 때에는 반드시 비활성화 시켜야 합니다.

  Obstacle Avoidance

• Radius* 에이전트의 반경은 장애물과 다른 에이전트 간의 충돌 계산하기 위해 사용됩니다.
• Height* 에이전트가 장애물 밑으로 지나갈 수 있는 높이 간격입니다.
• Quality* 장애물 회피 품질입니다. 에이전트의 수가 많다면 장애물 회피 품질을 줄임으로써 CPU 시간을 절약할 수 있습니다. 회피를 없음으로 설정할 경우 충돌만 해결할 수 있을 뿐 다른 에이전트와 장애물에 대한 적극적인 회피는 하지 않습니다.
• Priority* 낮은 우선 순위의 에이전트는 이 에이전트의 회피 대상에서 제외됩니다.

     값은 0에서 99사이에서 설정되어야 하며 낮은 숫자가 높은 우선 순위임을 의미합니다.

필요한 기초 코드

// 네임스페이스
using UnityEngine.AI; 
>
// 컴포넌트 가져오기
NavMeshAgent agent;
void Awake()
{
    agent = GetComponent<NavMeshAgent>();
}

기초적으로 사용하게될 각종 NavMeshAgent의 멤버들

프로퍼티

• isStopped: NavMesh 에이전트가 현재 경로를 따라 이동을 중지하거나 계속하는지를 설정하거나 가져옵니다. ( 해당 설정을 활성화 시에는 NavMeshAgent를 이용한 움직임이 정지됩니다.)
• remainingDistance: 에이전트의 위치와 현재 경로의 목적지 사이의 거리를 나타냅니다.

  메서드

• bool SamplePosition(Vector3 sourcePosition, out AI.NavMeshHit hit, float maxDistance, int areaMask) (NavMesh) sourcePosition으로부터 지정된 maxDistance 내에서 가장 가까운 NavMesh의 지점을 찾습니다.
• bool SetDestination(Vector3 target) 목적지를 설정하거나 업데이트하여 새 경로에 대한 계산을 트리거합니다.

  추가적인 설명

• NavMeshHit

• NavMesh 쿼리에 대한 결과 정보가 담겨져있다. 프로퍼티 : distance, hit, mask, normal, position

배회하는 코드

    void Update()
    {
        // 플레이어 감지
        playerDistance = (transform.position - CharacterManager.Instance.Player.transform.position).sqrMagnitude; // sqr을 활용했으니 제곱하는 걸 잊지 맙시다.
>
        WanderingState();
    }
>
    void WanderingState()
    {
        if (agent.remainingDistance < 0.1f)
        {
            NewWanderingPoint();
        }
    }
>
    private void NewWanderingPoint()
    {
        NavMesh.SamplePosition(transform.position + (Random.onUnitSphere * detectDistance), out NavMeshHit hit, detectDistance, NavMesh.AllAreas);
        agent.SetDestination(hit.position);
    }

• 위 코드는 목표에 도착하면 주기적으로 목적지를 계속 바꾸는 코드이다.

  적용 결과

  
• 자신의 주위로 계속해서 배회한다. (detectDistance를 1로 설정해두었다.)

각종 코드 주의 사항

• SetDestination을 사용할 때 곧바로 Vector3를 넣으면 의도된대로 작동이 안될 수도 있다.

• Navmesh를 벗어난 목적지로 설정해버릴 경우 그대로 자리에서 멈춰버린다.

  - SamplePosition은 랜덤으로 정하는 게 아니라 받은 sourceposition값에서 가장 가까운 NavMesh를 찾는 역할을 하는 것이다.

• 
• SamplePosition은 위와 같은 과정으로 포지션 값을 뽑는 것이고, 만약에 적절한 NavMesh 값을 찾지 못하면 false를 반환한다.

참고 자료

유니티

NavMeshAgent

NavMeshAgent의 멤버

영상

[유니티] 클릭 이동 구현하기 | Navigation(NavMesh) - 오늘코딩

오늘 한 일

• 배운 내용 정리하기
• 밍글데이
• 팀원 간 개인 프로젝트 서로 피드백하기

3차원의 시점

2차원과 다른점

• 2차원은 아무런 설정 없이 캐릭터가 움직일 때 카메라를 따라가게 만들면 되지만, 3차원은 마우스에 따라서 시야를 바꿔줘야할 필요가 있다. (3차원의 각도가 요구된다)
• 3차원은 2차원과 달리 카메라를 상하좌우로 틀어줘야할 필요가 있다.

3차원 시야 구현 방법

카메라의 3차원 회전

• x-는 카메라가 위를 보고, x+는 카메라가 아래를 본다.
• y-는 카메라가 좌를 보고, y-는 카메라가 우를 본다.
• 물론 추후에 이동 때문에 y rotation을 돌 때에는 캐릭터 오브젝트를 회전시킬 예정이다.

Delta

• 마우스 포인터의 이동값을 받아낸다. (포인터가 한 프레임에서 다음 프레임으로 이동할 때의 변화량) 즉 델타를 나타냅니다. (DeltaTime이랑 비슷한 느낌) (게임 화면 좌표 기준으로 포인터 위치 변화량을 뽑아낸다.)
• 상하가 -x, +x의 값이고
• 좌우가 -y, +y의 값이다.
  위를 보면 알겠지만 Delta.y의 값은 카메라 각도의 상하 움직임에 사용되어야하고 (-로 반영) Delta.x의 값은 캐릭터 좌우의 움직임을 구현해야한다. (캐릭터의 yRot을 구현)

구현하기

Hierarchy 설정

• 

  코드

   void Start()
   {
       ...
       CharacterManager.Instance.Player.OnLook += Look;
       Cursor.lockState = CursorLockMode.Locked; // 이걸 해두지 않으면 마우스가 화면에서 벗어난다.
   }
  >
    private void Look(Vector2 direction)
    {
        camCurXRot += direction.y * lookSensitive; // 민감도 배수
        camCurXRot = Mathf.Clamp(camCurXRot, minXLook, maxXLook);
        cameraContainer.localEulerAngles = new Vector3(-camCurXRot, 0, 0); // 카메라의 x축 회전
  >
        transform.eulerAngles += new Vector3(0, direction.x * lookSensitive, 0); // 캐릭터의 y축 회전
    }

  구현된 모습

  

• 의도된대로 잘 움직여진다.

3차원의 이동

2차원과 다른점

2차원

• 2차원은 x축과 y축이 존재하고, 3차원은 x축, y축, z축이 존재한다.
• 2차원은 Vector2, 3차원은 Vector3를 사용해서 움직인다.
• 
• x - 좌우 | y - 상하

• x - 좌우 | y - 높이 | z - 앞뒤

이러한 특징을 가졌기 때문에 상하좌우를 움직일 때는 3차원에서는 y부분이 사용되지 않게 조심하자

3차원 걷기 구현 방법

• 2차원과 달리 3차원은 x, z를 활용해서 이동해야한다. (Vector2를 그대로 적용해버리면 높이가 올라가는 현상이 발생한다;)

• 바라보는 시점에 따라서도 줘야하는 값이 달라진다. 그럴 때 사용하는 코드는 transform.forward(오브젝트 앞뒤), transform.right(오브젝트 우좌) // 안하면 그냥 말 그대로 x와 z의 방향대로 움직이게 된다. (인형뽑기의 팔이나 다름 없다)
• 해당 사진을 보면
• transform.forward는 저 파란색 화살표 방향의 단위 벡터*를 반환해주고
• transform.right는 빨간색 화살표의 단위 벡터*를 반환해준다는 의미가 된다.

구현하기

코드

• 이동 부여 방식은 취향껏 AddForce의 Acceleration과 ClampMagnitude를 걸어주었다.
  • Vector3.ClampMagnitude(대상값, 최대값) 대상 벡터의 스칼라값이 최대값을 넘지 못하게 막는다.

    void FixedUpdate()
    {
      Move();
    }
    >
    private void Move()
    {
      if (currentMove == Vector3.zero) { return; } // 움직임이 없을 시 즉시 반환
    >
      Vector3 dir = transform.forward * currentMove.y + transform.right * currentMove.x; // 이게 3차원의 포인트이다.
      dir = dir.normalized;
    >
      _rigidbody.AddForce(dir * moveSpeed, ForceMode.Acceleration);
      _rigidbody.velocity = Vector3.ClampMagnitude(_rigidbody.velocity, maxVelocity); // 스칼라 Clamp
    }
    >
    private void MoveInput(Vector2 direction)
    {
      currentMove = direction;
    }
    >    

    구현된 모습

    
• 보이는 걸로는 잘 모르겠지만, 의도된대로 잘 움직인다.

3차원 이동에서 알게된 코드

transform.forward - 파란색 화살표의 단위 벡터 transform.right - 빨간색 화살표의 단위 벡터 Vector3.ClampMagnitude(대상값, 최대값) - 대상 벡터의 스칼라값이 최대값을 넘지 못하게 제한

쓰면서 느낀점

확실히 복습을 해보면서 부족한 부분을 채우니 해당 코드나 값들에 대한 이해도가 높아졌다.

오늘 한 일

• 챌린지반 과제 풀이
• 개인 프로젝트 진행 후 제출

_ 작성 중... _ 이번 TIL은 필자의 생각이 많이 들어있습니다.

기능 구상

기능 구상에 관하여

이 과정은 게임의 기획보다는 좀 더 세부적으로 들어가보는 과정이 담겨져있다.

기능을 구상하게 되는 과정

구상 단계

1. 필요성

2. 흐름 파악

3. 명시화

적용 단계

4. 적용

5. 개선 및 프레임워크 반영

1. 필요성

기능을 구상하기 앞서 사실 그 기능이 필요해야 구상을 하게되지 않을까 생각한다, 설령 지금 당장이 아니더라도 추후에 쓰이게될 것 같은 경우에도 마찬가지다. 물론 필요성이라는 것도 개인의 주관에 따라서 달라지니 팀 프로젝트를 하고 있다면 회의를 통해 필요성을 도출하고 결정해줘야할 필요가 있다.

필요성에서 따져야할 3가지

• 방향성 -> 지금 개발하는 게임의 방향성에 맞는가?
• 범용성 -> 여러 게임에 전반적으로 자주 쓰이는 기능인가?
• 독자성 -> 타 게임들과는 차별성을 가지는가?

방향성

지금 개발하는 게임의 방향성에 맞는가?

마인크래프트

슬레이더 스파이어

• 
  두 가지 게임의 아이템 보관법에 대해서 가지고 와보았다. 하나는 필요한 템을 자기가 원하는 대로 넣고, 필요 없으면 템을 버릴 수 있는 (개방적인 인벤토리)이고, 다른 하나는 원하는 아이템만 가지고 오거나 버릴 수 없다. (폐쇄적인 인벤토리) 이렇게 둘이 똑같은 인벤토리임에도 불구하고 서로 다른 기능을 가지게 되는 이유는 게임의 방향성에 있을 것이다. 게임의 방향성에 따라 자유도에 맞춰서 인벤토리를 자유롭게 건들 수 있게 하느냐. 아니면 게임의 난이도 조절과 컨셉에 맞게 인벤토리를 폐쇄적으로 만드느냐는 우리가 개발하고자 하는 게임의 방향성에 따라서 달라지게 될 것이다.

범용성

여러 게임에서 전반적으로 자주 쓰이는 기능인가?

돈스타브

스타듀밸리

타르코프

인벤토리라는 기능이 주로 사용되는 게임들은 아이템이 있고 그 아이템들을 통해서 살아가거나 수익을 내거나와 같이 생존과 자원 관리의 특징을 가진 게임에서 자주 쓰일 것이다. 물론 인벤토리를 생략해도 해당 게임의 특징이 사리지지는 않지만 없으면 많이 아쉬운 느낌이 들 수도 있다.

독자성

기존에 있던 게임들과는 다른 특별한 특징을 가지는가?

백팩 히어로

위 이미지에 대해 설명해주자면 위의 인벤토리가 특별한 이유가 아이템을 단순히 한 칸씩 담는 게 아니라 아이템의 모양에 따라서 차지하는 공간이 다르다. 이 뿐만 아니라 배치된 위치에 따라서 아이템들끼리 서로 버프나 디버프롤 주고받게 되어서 인벤토리 정리에 매우 많은 신경을 써줘야한다. (인벤토리의 공간을 기존과 다르게 더욱 능동적으로 활용했다.)

2. 흐름 파악

그렇다면 그 기능이 필요하다는 게 확실시 된다면, 이제 그 기능의 대략적인 구상을 해볼 차례이다.

데이터 흐름 파악하기

데이터 흐름을 파악하는 것이 제일 먼저 중요하다. 예시로 인벤토리의 데이터 흐름을 생각해보자

기능의 기초적인 흐름 파악

1. 템을 줍는다 -> 2. 주운 템을 보관한다 -> 3. 보관한 템을 사용한다 -> 4. 사용한 템을 처리한다.
   사실 그냥 단순하게 내가 가방을 가지고 있다고 생각하고 내가 그걸 어떻게 흘러가는지를 생각해보면 된다. (설령 가방이 아니더라도 뭔가를 보관하고 들고 다닐 수 있는 거면 죄다 인벤토리라고 파악해도 된다. 추상화) 이렇게 생각하는 과정이 단순해 보일 순 있지만, 사실 이렇게 과정을 잘 나눠줘야 그 다음 과정을 넘어갈 수 있다.

흐름의 구체화 1 (육하원칙)

1. 템을 줍는다 누가: 플레이어 | 언제: 원할 때 | 어디서: 템이 있는 자리 무엇을: 떨어진 템 | 어떻게: RayCast로 감지해서 특정 입력으로 | 왜: 필요/호기심 2. 주운 템을 보관하다 누가: 인벤토리 | 언제: 플레이어가 템을 주울 때 | 어디서: 인벤토리 역할 오브젝트 or 스크립트에 무엇을: 주운 템을 | 어떻게: 배열, 리스트, Prefab들을 활용해서 | 왜: 나중에 사용하기 위해 3. 보관한 템을 사용하다 누가: 플레이어 | 언제: 원할 때 | 어디서: 필요한 장소에서 무엇을: 필요한 템 | 어떻게: 템을 선택 후 키 또는 마우스 입력 등 | 왜: 필요/호기심 4. 사용한 템을 처리한다 누가: 인벤토리/템 | 언제: 템이 사용됐을 때 | 어디서: 인벤토리에서 무엇을: 사용된 템 | 어떻게: 템의 특징에 따라서 처리(장착, 소모 등) | 왜: 게임의 방향성

아니면 아래와 같은 구상도 가능하다.

흐름의 구체화 2 (필요성)

*1. 템을 줍는다 * -> 템의 정보 -> 템을 감지하고 가져오는 기능 -> 주워진 템은 사라져야 한다.

2. 주운 템을 보관한다 -> 템을 담을 공간 -> 템을 담는 방식(단일, 스택 및 아이템 배치 위치, 순서 등등) -> 가지고 있는 템을 출력

3. 보관한 템을 사용한다 -> 사용하고자하는 템의 참조값(주소값), -> 사용을 위한 입력 방법 (클릭, 키 입력, 버튼 등)

4. 사용한 템을 처리한다 -> 사용한 템의 타입 (장착, 소모품) -> 사용한 아이템의 타입에 따라 처리해줄 메서드 -> 사용 후 갯수를 감소하거나 템 칸 정리

심지어 위와 같은 구상 과정도 필수적인 부분이라 추가적인 기능을 생각해본다면.. 아이템 정리 - 정렬, 버리기, 유저의 직접적인 정리(드래그 앤 드롭) 핫 키 - 버튼 하나만으로 들고 있는 템을 바꾸거나, 소모품을 바로 소비

그리고 추가적으로 게임의 방향성에 따라서 인벤토리의 UI와 가지게 되는 기능도 다양하게 달라질 수 있다.

3. 명시화

데이터의 흐름이 어느 정도 구체화되었다면 이제는 시각화해볼 차례이다.

시각화를 위한 다양한 방법

• FlowChart
• UML
• ERD
• 그 외의 여러가지 방법

FlowChart

• 플로우 차트는 순서도 또는 흐름도라고도 불리며 ,어떠한 일을 처리하는 과정을 순서대로 간단한 기호와 도형으로 도식화한 것을 의미한다.

  간단한 플로우차트

  • 

    플로우차트 사용 규칙

    플로우 차트를 작성할 때 사용 규칙은 이와 같다.
• 1* 기호의 내부에는 처리할 내용이 들어가야한다.
• 2* 순서는 위에서 아래로, 왼쪽에서 오른쪽을 원칙으로 하며 그 외의 경우는 화살표로 사용해야 한다.
• 3* 흐름선은 서로 교차해도 무관하며 서로 영향을 주지 않는다.
• 4* 흐름선 여러 개가 모여 하나로 합칠 수 있다.
• 5* 기호의 모형은 가로, 세로의 비율은 정하지 않으나 잘 구분할 수 있어야한다.

  플로우차트 일반적 기호

• 

인벤토리 기능을 플로우 차트로 나타내보기

_... 추후에 작성 바람... _

UML

UML 다이어그램은 Unified Modeling Language(통합 모델링 언어)를 사용하여 시스템과 소프트웨어를 시각화하는 방법입니다. 복잡한 소프트웨어 시스템의 설계, 아키텍처 등을 이해하기 위해 UML 다이어그램을 작성합니다.

UML 예시

1. 클래스만 표현

• 
• 스파르타 코딩 클럽 자료입니다.

2. 필드와 메서드까지 표현

• 화살표의 방향은 주로 해당 클래스가 대상의 데이터에 접근하게 될 때 표시해준다.
• 필드와 메서드를 명시하게 될 경우 쓰일 것 같은 필드와 메서드를 잘 구상해줘야한다.
• ERD도 UML과 비슷한 계열이지만, 데이터의 상호작용을 좀 더 세세하게 표현한 다이어그램이다.

UML을 활용하여 인벤토리 기능 구상해보기

... 추후에 작성 바람 ...

참고 자료

FlowChart

• 플로우 차트란 무엇인가? - 미니맘바

• 위키백과

  UML

• UML이란?

작성하면서 느낀점

역시 뭔가 뚜렷한 기능이나 디자인 패턴에 관한 TIL 작성은 쉬운 편에 속하지만 추상적인 개념들(구상이나, 정의되어있지 않은 지식)에 대해서는 확실히 TIL 작성에 길을 헤매이게 되는 느낌이 많이 든다.

오늘 한 일

• 챌린지반 과제 풀이
• 프로젝트 진행하기 (~ 선택 구현 사항 3)

Rigidbody

개념

Rigidbody는 게임 오브젝트가 물리 제어로 동작하게 합니다. Rigidbody는 Force와 Torque를 받아 오브젝트가 사실적으로 움직이도록 해주고, Rigidbody가 포함된 모든 게임 오브젝트는 중력의 영향을 받을 수 있게되며, 스크립팅을 통해 가해진 힘으로 움직이거나 NVDIA PhysX 물리 엔진을 통해 다른 오브젝트와 상호작용하게 됩니다.

컴포넌트의 각종 프로퍼티

Mass

• 오브젝트의 질량 (디폴트 값을 킬로그램)
• 코드 _rigidbody.mass = 10;

  테스트 영상

  ---

  각종 이동 처리

• 각 물체의 mass는 흰색은 1 회색은 100으로 설정해주었다.

  _rigidbody.velocity = direction * speed * Time.deltaTime;

  흰색과 회색에서 각각 250으로 설정해주었다.

• 둘이 속도가 균일하게 나온다.

_rigidbody.AddForce(direction * speed * Time.deltaTime, ForceMode.Force);

흰색과 회색에게 각각 50으로 설정해주었다.

• 가속이 생기는데 mass에 따라서 차이가 발생한다.

Force 모드에서 흰색은 50 회색은 5000으로 설정

• 서로 mass 차이가 나는 상태에서 Force로 동일한 속도를 내고자 한다면 a(mass) : b(mass) = a(Force) : b(Force)를 통해서 계산해줘야할 것 같다.

_rigidbody.AddForce(direction * speed * Time.deltaTime, ForceMode.Acceleration);

흰색과 회색에게 각각 50으로 설정해주었다.

• mass 상관 없이 둘이 동일한 속도로 가속이 발생한다.

_rigidbody.AddForce(direction * speed * Time.deltaTime, ForceMode.Impulse);

흰색과 회색에게 각각 10으로 설정해주었다.

• 가속이 폭발적으로 증가하고 mass에 따라서 차이가 발생한다.

_rigidbody.AddForce(direction * speed * Time.deltaTime, ForceMode.VelocityChange);

흰색과 회색에게 각각 10으로 설정해주었다.

• mass 상관없는 impulse mode인 것 같다.

Drag

• 위치 이동의 저항 (중력과 움직임에 저항이 생긴다)
• 코드 _rigidbody.drag = 10;

테스트 영상

---

중력 저항

초기 설정

• Drag 설정

• 파란색은 기본값(0)
• 빨간색은 20

  • 각자에게 중력을 추가해주었다.

  • Drag가 없는 파란색 직육면체는 바로 떨어지고 Drag가 20인 빨간색은 천천히 떨어진다.

이동 저항

초기 설정

• Drag 설정

• 파란색은 기본값(0)
• 빨간색은 20

  사용된 이동 코드

  IEnumerator MovePlatform()
  {
     Vector3 direction = (directions[curDirectionIdx] - transform.position).normalized; // 방향 단위 벡터
     while (true) // 목표 지점에 도착할 때까지 반복합니다.
     {
         if (Vector3.Distance(transform.position, directions[curDirectionIdx]) < 0.2f) { break; }
         _rigidbody.velocity = direction * speed * Time.deltaTime; // 초를 따라 추가
         yield return null;
     }
     _rigidbody.velocity = Vector3.zero; // velocity 0으로 만들기 (이게 없으면 날라가니 주의)
     yield return new WaitForSeconds(waitTime); // 멈추는 시간 설정
     curDirectionIdx++;    // 다음 목적지로
     if (curDirectionIdx >= directions.Count) // Count를 넘는다면
     {
         curDirectionIdx = 0; // 다시 0으로
     }
     StartMove(); // 움직임 재시작
  }

  • speed는 500으로 설정해주었다.
  • 해당 영상에서 보이듯이 Drag가 없는 파란색은 빠르게 움직이고 Drag가 있는 빨간색은 천천히 움직인다.

+ 정지 코드 제외

speed를 250으로 바꿔주었다.

• 빨간색은 Velocity를 주는 것을 멈추면 잘 멈추는 반면 파란색은 그대로 나아가버린다.

각종 이동 처리

_rigidbody.velocity = direction * speed * Time.deltaTime;

파란색과 빨간색에게 각각 250으로 설정해주었다.

• 빨간색이 저항을 받아서 그런지 속도가 감속되는 현상이 생긴다. (프레임 단위로 velocity = 처리이다.)

_rigidbody.AddForce(direction * speed * Time.deltaTime, ForceMode.Force);

파란색과 빨간색에게 각각 50으로 설정해주었다.

• 파란색은 가속이 잘 전달되는 반면 빨간색은 이상하게 속도 제한이 걸리는 것 같다.

_rigidbody.AddForce(direction * speed * Time.deltaTime, ForceMode.Impulse);

파란색과 빨간색에게 각각 10으로 설정해주었다.

• 위와 마찬가지로 빨간색에게 속도 제한이 걸린다.

Impulse 모드 빨간색만 200으로 설정

• 아무리 힘을 줘도 저항 때문에 속도가 중첩이 되질 않는다..

Angular Drag

• 회전의 저항
• 코드 _rigidbody.angularDrag = 10;

테스트 영상

---

_rigidbody.angularVelocity = Vector3.up * rotateSpeed;

• AngularDrag 설정

• 파란색은 기본값(0.05)
• 빨간색은 20
• rotateSpeed를 20으로 설정했다.

  • 멈추는 버튼을 추가해서 멈추는 실험 해당 영상을 보면 파란색 직육면체가 좀 더 빨리 회전하는 것을 볼 수 있고 움직임을 멈췄을 경우 파란색은 천천히 멈추고 빨간색은 바로 멈추는 것을 알 수 있다.

_rigidbody.AddTorque(Vector3.up * rotateSpeed);

• AddTorque는 각도 버전의 Addforce라 생각해주면 된다. (기본 Forcemode는 Force이다.)
• 속도는 각각 20으로 설정해뒀다.
• 해당 영상을 보면 알 듯이 빨간색은 저항을 받아서 속도의 제한을 받고 파란색은 잘 회전되는 모습을 볼 수 있다.
• 그리고 멈췄을 경우 저항이 있는 빨간색(20)은 바로 멈추고 파란색(0.05)은 천천히 멈추고 있는 것을 볼 수 있다.

UseGravity

• 중력 유무
  앞선 Drag 영상에서 봤듯이 물체에 중력을 부여해줄 수 있다. 중력을 사용하지 않겠다면 체크란을 비워주면 된다.
• 코드 Rigidbody(의 인스턴스).useGravity = true;

Is Kinematic

• 오브젝트가 물리 엔진으로 제어되지 않고 오로지 Trasnform으로만 조작된다. 플랫폼을 옮기는 경우나 HingeJoint가 추가된 리지드바디를 애니메이션화하는 경우에 유용하다
• 코드 Rigidbody(의 인스턴스).isKinematic = true;
• 당연하겠지만 velocity에 변화를 주려하면 이러한 에러가 발생한다.

Interpolate

• 리지드바디의 움직임이 어색해 보일 경우에 사용한다.
  • None - 보간 없음
  • Interpolate - 이전 프레임의 트랜스폼에 맞게 움직임을 부드럽게 처리합니다.
  • Extrapolate - 다음 프레임의 트랜스폼을 추정해 움직임을 부드럽게 처리합니다.
• 코드 Rigidbody(의 인스턴스).interpolation = RigidbodyInterpolation.Interpolate;

Collision Detection

• 빠르게 움직이는 오브젝트가 충돌의 감지 없이 다른 오브젝트를 지나쳐가는 것을 방지합니다.

  Discrete

• 물리 시스템이 불연속 충돌 검사를 사용하여 이 리지드바디의 콜라이더에 대한 충돌을 계산합니다. 이 리지드바디가 빠르게 움직이는 충돌에 관여하지 않는 경우 Discrete를 선택합니다.Discrete 충돌 검사는 컴퓨터 리소스를 많이 사용하지 않습니다.

  Continous

• 물리 시스템은 스위핑 기반 CCD를 사용하여 이 리지드바디의 콜라이더와 정적 콜라이더(연관된 리지드바디가 없는 콜라이더) 간의 충돌을 계산합니다. 이 리지드바디가 정적 콜라이더와의 빠르게 움직이는 충돌에 관여하는 경우 Continuous를 선택합니다. 스위핑 기반 CCD는 Discrete 또는 Continuous Speculative보다 컴퓨터 리소스를 많이 사용합니다.

  Continuous Dynamic

• 물리 시스템은 스위핑 기반 CCD를 사용하여 이 리지드바디의 콜라이더와 Discrete 충돌 검사로 설정된 콜라이더를 제외한 다른 모든 콜라이더 간의 충돌을 계산합니다. 이 리지드바디가 임의의 콜라이더와의 빠르게 움직이는 충돌에 관여하는 경우 Continuous Dynamic을 선택합니다. 스위핑 기반 CCD는 Discrete 또는 Continuous Speculative보다 컴퓨터 리소스를 많이 사용합니다.

  Continuous Speculative

• 리지드바디와 콜라이더에 추측성 연속 충돌 검사를 사용합니다. 키네마틱 바디를 설정할 수 있는 유일한 CCD 모드입니다. 이 메서드는 스위핑 기반 연속 충돌 검사보다 리소스를 덜 소모합니다.

Constraints

• 리지드 바디의 움직임에 대한 제약사항
  • Freeze Position - 월드 좌표계의 X, Y, Z 축에서 이동하는 리지드 바디의 움직임 제한 유무
  • Freeze Rotation - 로컬 좌표계의 X, Y, Z 축에서 회전하는 리지드 바디의 움직임 제한 유무
• 코드
  • 
    혹여나 Rigidbody에 힘을 가했는데 의도된 대로 움직여지지 않으면 이 체크란을 확인해주자. Transform.position을 이용한 이동의 제한은 막힌 게 아니니 그것을 사용해도 된다.

참고 자료

유니티 공식 문서

유니티 공식 문서 스크립트 레퍼런스

유니티 입문 강좌 part 3 - 리지드 바디 - 케이디

작성하면서 느낀점

유니티라는 엔진을 알면 알수록 생각보다 자기가 모르는 것에 대한 실험을 하기가 좋은 환경이라고 생각이 든다.

오늘 한 일

• 스파르타 코딩클럽 강의 수강 (~ 1-15)
• 챌린지반 특강 수강하기 (디자인 패턴 상편)
• 명령 패턴에 대해서 자세히 파고 들기

명령 패턴(Command Pattern)

개념

발송자에서 수신자로 곧바로 명령을 전달하는 것이 아닌 중간 과정에서 새로운 명령 클래스를 생성하여 명령에 대한 처리를 독자적으로 수행하는 객체를 만드는 패턴이다. (명령의 객체화)

구조와 특징

구조

발송자 클래스(Invoker)

• 요청(명령)의 시작을 관리하는 역할
  • 해당 클래스에는 명령 객체에 대한 참조를 저장하기 위한 필드가 있어야한다. (참조 변수든 리스트 형태든 뭐든간에)
  • 발송자는 요청을 수신자에게 직접 보내는 대신 해당 명령을 작동시킨다.
  • 발송자는 명령 객체를 생성할 책임은 없고 일반적으로 생성자를 통해 클라이언트로부터 미리 생성된 명령을 받는다.

_명령(command) 인터페이스 _

• 일반적으로 명령을 실행하기 위한 단일 메서드만을 선언한다.

  구체적_명령

• 다양한 유형의 요청(명령)을 구현
  • 구체적_명령은 자체적으로 작업을 수행해서는 안되며, 대신 수신자 객체 중 하나에다가 호출을 전달해야한다. (그러나 코드의 단순화를 위해서 작업 수행 로직이 병합될 수 있다.)
  • 수신자 객체에서 메서드를 실행하는 데 필요한 매개변수들은 구체적_명령 필드들로 선언할 수 있다. 생성자를 통해서만 이러한 필드의 초기화를 허용함으로써 명령 객체들을 불변으로 만들 수 있다.

수신자 클래스(Receiver)

• 일부 작업 수행이 포함된 클래스
  • 거의 모든 객체는 수신자 역할을 할 수 있다.
  • 대부분의 명령 클래스들은 요청이 수신자에게 전달되는 방법에 대한 세부 정보만 처리하는 반면 수신자 자체는 실제 작업을 수행한다.

클라이언트

• 구체적_명령 인스턴스를 만들고 설정한다.
  • 클라이언트는 수신자 인스턴스를 포함한 모든 요청 매개변수들을 명령의 생성자로 전달해야하며, 그렇게 만들어진 명령은 하나 또는 여러 발송자에게 전달될 수 있다.

특징

명령의 캡슐화

• 특정 작업을 수행하는데 필요한 정보를 객체로 만드는 것 이 객체는 작업을 수행하는 메서드와 그 메서드를 호출할 때 필요한 매개변수 등의 정보를 포함한다. 이렇게하면 명령 객체는 작업을 수행하는데 필요한 모든 정보를 가지고 있으므로, 이 객체를 저장하거나 전달하거나 나중에 실행하는 등의 작업을 할 수 있다.
  ! 캡슐화를 통해서 명령의 저장 및 재사용이나 명령의 실행 및 취소가 가능하다.

예시

코드 출처 : 리팩토링 구루

namespace command_Pattern
{
   // Command 인터페이스는 명령을 실행하는 메서드를 선언한다
    public interface ICommand
    {
        void Execute();
    }
>
    // 일부 명령은 자체적으로 간단한 작업을 구현할 수 있다
    class SimpleCommand : ICommand
    {
        private string _payload = string.Empty;
>
        public SimpleCommand(string payload) // 생성자
        {
            this._payload = payload;
        }
>
        public void Execute() // 단순 작업
        {
            Console.WriteLine($"단순명령: 저는 출력과 같이 단순한 일을 해낼 수 있습니다.({this._payload})");
        }
    }
>
    // 그러나, 일부 명령들은 더 복잡한 작업을 수신자(Receiver)라고 불리는 객체에게 위임할 수 있다
    class ComplexCommand : ICommand
    {
        // 내 명령을 수행해줄 수신자
        private Receiver _receiver;
>
        // 수신자의 메서드를 실행하는 데 필요한 컨텍스트 데이터
        private string _a;
>
        private string _b;
>
        // 복합 명령은 생성자를 통해 하나 이상의 수신자 객체와 함께 모든 컨텍스트 데이터를 받아들일 수 있다
        public ComplexCommand(Receiver receiver, string a, string b)
        {
            this._receiver = receiver;
            this._a = a;
            this._b = b;
        }
>
        // 명령은 수신자의 어떤 메서드에게든 위임할 수 있다
        public void Execute()
        {
            Console.WriteLine("복합 명령: 복잡한 작업은 수신자 객체들에 의해 수행되어야합니다.");
            this._receiver.DoSomething(this._a);
            this._receiver.DoSomethingElse(this._b);
        }
    }
>
    // 수신자 클래스는 어떤 중요한 작업 로직을 포함하고 있다
    // 그들은 요청을 수행하는 데 관련된 모든 종류의 작업을 수행하는 방법을 알고 있다
    // 사실, 어떤 클래스든지 수신자로써 역할을 할 수 있다
    class Receiver
    {
        // 작업 처리 메서드들
        public void DoSomething(string a)
        {
            Console.WriteLine($"수신자: ({a})에서 작업.");
        }
>
        public void DoSomethingElse(string b)
        {
            Console.WriteLine($"수신자: ({b})에서도 작업");
        }
    }
>
    // 발송자는 하나 또는 여러 명령어와 연결되어 있고, 명령에 요청을 보내는 역할을 한다.
    class Invoker
    {
        private ICommand _onStart; // 자신의 일을 시작하기 전에 호출할 명령
>
        private ICommand _onFinish; // 자신의 일이 끝나고 나서 호출할 명령
>
        // 명령 초기화 (명령 할당)
        public void SetOnStart(ICommand command)
        {
            this._onStart = command;
        }
>
        public void SetOnFinish(ICommand command)
        {
            this._onFinish = command;
        }
>
        // 호출자는 구체적인 명령이나 수신자 클래스에 의존하지 않는다
        // 명령을 실행함으로써 간접적으로 수신자에게 요청을 전달한다
        public void DoSomethingImportant()
        {
            Console.WriteLine("발송자: 제가 시작하기 전에 작업을 수행하시길 원하시는 분 있나요?");
            if (this._onStart is ICommand)
            {
                this._onStart.Execute();
            }
>
            Console.WriteLine("발송자: ..중요한 일을 수행하는 중입니다...");
>
            Console.WriteLine("발송자: 제가 끝나고 나서 작업을 수행하시길 원하시는 분 있나요?");
            if (this._onFinish is ICommand)
            {
                this._onFinish.Execute();
            }
        }
    }
>
    class Program
    {
        static void Main(string[] args)
        {
            // 클라이언트 코드는 호출자를 어떤 명령어로든 매개변수화할 수 있습니다
            Invoker invoker = new Invoker(); // 발송자 인스턴스
            invoker.SetOnStart(new SimpleCommand("안녕!")); // 시작 부분에 단순 명령 할당
            Receiver receiver = new Receiver(); // 수신자 인스턴스 (복합 명령을 위한 것)
            invoker.SetOnFinish(new ComplexCommand(receiver, "이메일 보내기", "보고서 작성")); // 끝나는 부분에 복합 명령 할당
>
            invoker.DoSomethingImportant(); // 설정된 명령 실행
        }
    }
}

실행 결과

해당 구조 분석

• 클라이언트에서 명령을 생성하여 발송자 인스턴스에게 전달하는 방식임을 알 수 있다.
• 발송자는 명령을 호출하는 순서를 정할 수 있는 것을 볼 수 있다.
• 명령 클래스들은 작업이 단순하다면 스스로 수행이 가능하고 복잡한 작업일 경우 수신자를 통해서 수신자의 메서드를 활용한다.

장단점

장점

1. 단일 책임 원칙

• 작업을 호출하는 클래스들은 이러한 작업을 수행하는 클래스들로부터 분리할 수 있다.

  2. 개방/폐쇄 원칙

• 기존 코드를 수정하지 않고 새 명령들을 도입할 수 있다.

  3. 실행 취소/다시 실행을 구현

  4. 작업들의 지연된실행을 구현

  5. 간단한 명령들의 집합을 복잡한 명령으로 조합

단점

1. 발송자와 수신자 사이에 완전히 새로운 레이어를 도입하기 때문에 코드가 복잡해질 수 있다.

주요 용도

주요 기능

시간을 되돌리는 기능 (되돌리기, 시간 역행 등)

로그를 기록하고 복구하는 기능

주로 사용하는 게임

RTS 멀티 플레이 환경에서 플레이어들의 입력을 동기화 및 통일화(결정론적 락스텝)

체스나 바둑 같은 게임에서 기보를 기록 및 수 되돌리기 기능

직접 만들어보기

... coming soon ...

참고 자료

리팩토링 구루 - 커맨드 패턴

TIL을 작성하면서 느낀점

디자인 패턴이라는 것은 사실은 뭔가 흐릿흐릿했던 코드 구조들을 정형화하게 된 일종의 도구라고 생각한다. 물론 이 패턴을 알지 않아도 점차 코딩을 하다보면 디자인 패턴에 가까워지긴 하지만, 디자인 패턴을 대략적으로 아는 것과 뚜렷하게 아는 거랑은 큰 차이가 있다고 생각한다. 앞으로 코딩할 때 다양한 디자인 패턴을 배워서 내 개발 실력을 한층 끌어올리기 위해 노력해야겠다.

오늘 한 일

• 챌린지반 과제 풀이
• 스파르타 코딩클럽 진도 나가기 (~ 1-10)

Raycast

개념

유니티의 기능 중 하나로 보이지 않는 선(Ray)을 출력하여 해당 선에 닿인 오브젝트들의 정보를 가져오는 유니티 기능 중 하나이다.

사용 방법

Ray 만들기

Ray ray = new Ray(transform.position, transform.forward); // 오브젝트
Ray ray = Camera.main.ViewportPointToRay(new Vector3(0.5f, 0.5f, 0)); // 카메라 중심
Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition)); // 마우스

Raycast를 활용해서 검출하기

void Update()
{
    IsPlayer();
}
>
void IsPlayer()
{
   Ray ray = new Ray(lazer.position, Vector3.forward); // (위치, 방향)
   if (Physics.Raycast(ray, 10f, playerLayerMask))
   {
       text.text = "정면 감지됨";
   }
}

Raycast()

매개 변수에 대한 설명

origin

• Ray 시작점

  direction

• Ray 방향

• ! 위 둘을 퉁쳐서 ray를 넣기도 한다.*

  maxDistance

• Ray의 최대 검출 거리 (기본값은 Infinite이다)

  layerMask

• Ray에 적중된 오브젝트가 건네준 레이어와 동일한 지 검사

  RaycastHit

• 가장 가까운 오브젝트의 정보를 가져옴

• RaycastHit - 객체의 정보

• RaycastHit.point - 레이캐스팅이 감지된 위치

• RaycastHit.distance - Ray의 원점에서 충돌 지점까지의 거리

• RaycastHit.transform - 충돌 객체의 transform 정보

  queryTriggerInteraction

• 적중된 오브젝트들을 쿼리를 통해서 감지할 지 무시할 지 정한다.

각종 오버로딩

-> Physics.Raycast

사용 시 알아야할 것

Raycast를 제대로 활용하려면 오브젝트의 방향이 어디인지 알아야한다.

• 
• 해당 화살표들은 보면, 빨간색은 X, 녹색은 Y, 파란색은 Z 방향이다.

실험 코드

 void IsPlayer()
 {
     Ray rayF = new Ray(lazer.position, Vector3.forward); // (위치, 방향)
     Ray rayB = new Ray(lazer.position, Vector3.back);
     Ray rayL = new Ray(lazer.position, Vector3.left);
     Ray rayR = new Ray(lazer.position, Vector3.right);
     Ray rayU = new Ray(lazer.position, Vector3.up);
>
     if (Physics.Raycast(rayF, 10f, playerLayerMask))
     {
         text.text = "정면 감지됨";
     }
     else if (Physics.Raycast(rayB, 10f, playerLayerMask))
     {
         text.text = "후면 감지됨";
     }
     else if (Physics.Raycast(rayL, 10f, playerLayerMask))
     {
         text.text = "좌측 감지됨";
     }
     else if (Physics.Raycast(rayR, 10f, playerLayerMask))
     {
         text.text = "우측 감지됨";
     }
     else if (Physics.Raycast(rayU, 10f, playerLayerMask))
     {
         text.text = "상측 감지됨";
     }
     else
     {
         text.text = "아무것도 감지되지 않음";
     }
 }

영상 결과

• 기본적인 시험
• 
• 해당 영상을 보면 아래와 같은 결과가 도출될 수 있음을 알 수 있다.
• 오브젝트들을 관리할 때 이 화살표를 유의하면서 Raycast를 활용해주자

• rotation을 돌려서 시험
• rotation이 바뀐거랑 Ray의 방향이랑은 전혀 관계가 없는 것 같다.

작성하면서 느낀점

새로운 강의 자료가 나오니 실력을 더 쌓을 수 있게 될 수 있어서 좋은 반면 해당 강의 내용을 제대로 소화해내려면은 TIL을 좀 더 간결하고 알차게 써줘야할 필요성이 느껴진다.

오늘 한 일

• 챌린지반 과제 풀이 (오브젝트 풀링)
• 프로젝트 제출 및 발표
• 객체 지향 특강 2부

오늘은 객체 지향 특강에서 들었던 SOLID 원칙에 대해서 알아보고자 한다.

SOLID 원칙

• 객체 지향 프로그래밍에서 소프트웨어 디자인의 다섯 가지 기본원칙 이 원칙은 소프트웨어의 유지보수성, 확장성, 재사용성 등을 향상시키는 데 중요한 역할을 한다.

1. S - Single Responsibility Principle (단일 책임 원칙)
   • 클래스는 하나의 책임만 가져야 하며, 해당 클래스의 변경 사유는 하나여야 합니다.
2. O - Open/Closed Principle (개방/폐쇄 원칙)
   • 소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 합니다.
3. L - Liskov Substitution Principle (리스코프 치환 원칙)
   • 하위 클래스는 상위 클래스에서 가능한 모든 동작을 수행할 수 있어야 합니다.
4. I - Interface Segregation Principle (인터페이스 분리 원칙)
   • 클라이언트는 사용하지 않는 메서드에 의존하도록 강요받아서는 안 됩니다. (단일 책임 원칙의 인터페이스 버전)
5. D - Dependency Inversion Principle (의존성 역전 원칙)
   • 상위 모듈은 하위 모듈에 의존해서는 안 되며, 둘 모두 추상화에 의존해야 합니다. (또한 상위 모듈을 상속받은 자기와 같은 단계의 모듈로부터 상속 받아서는 안된다.)
     이 원칙을 준수하면 유지보수성이 높아지고 확장이 용이하며, 더욱 견고하고 효율적인 소프트웨어를 만들 수 있게 됩니다

단일 책임 원칙

단일 책임 원칙(Single Responsibility Principle, SRP)은 소프트웨어 개발에서 가장 기본적인 원칙 중 하나로, 각 클래스는 단 하나의 책임만을 가져야 한다는 원칙입니다. 이것은 클래스가 변경되어야 하는 이유가 단 하나여야 한다는 것을 의미합니다.

1. 클래스는 단일 기능을 수행합니다: 각 클래스는 한 가지 명확한 목적이나 기능을 수행합니다. 이는 클래스가 변경되어야 하는 이유를 명확하게 파악할 수 있도록 합니다.
2. 모듈성과 재사용성을 높입니다: 단일 책임을 가진 클래스는 다른 클래스와의 결합도가 낮아지므로 모듈화가 용이해집니다. 이로써 코드를 재사용하고 수정하기 쉬워집니다.
3. 유지보수가 용이합니다: 각 클래스가 단일 책임을 가지므로 코드의 수정이 필요할 때 해당 클래스만 수정하면 됩니다. 이는 코드의 복잡성을 줄이고 유지보수 비용을 낮출 수 있습니다.
   소프트웨어에서 데이터베이스 접속, 데이터 처리, 사용자 인터페이스 표시 등 각각의 작업은 서로 다른 책임을 가지고 있다. 따라서 각각의 작업을 담당하는 클래스를 따로 구성하는 것이 SRP를 준수하는 좋은 방법이다.
   SRP를 지키지 않는 코드는 한 클래스가 너무 많은 책임을 가지거나, 여러 기능을 포함하고 있는 형태이다. 이러한 형태는 가독성이 떨어지고 유지 보수의 어려움을 증가시킨다.

단일 책임 원칙을 준수한 코드 예시

using System;
>
// 사용자 정보를 관리하는 클래스
public class UserManager {
    private Database database;
>
    public UserManager(Database database) {
        this.database = database;
    }
>
    // 사용자를 데이터베이스에 저장하는 메서드
    public void SaveUser(User user) {
        // 데이터베이스에 저장하는 로직
    }
>
    // 사용자를 데이터베이스에서 불러오는 메서드
    public User LoadUser(int userId) {
        // 데이터베이스에서 사용자 정보를 불러오는 로직
        return null;
    }
}
>
// 데이터베이스 관리 클래스
public class Database {
    // 데이터베이스 연결 및 관리를 위한 메서드
}
>
// 사용자 정보 클래스
public class User {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

이 코드에서는 UserManager 클래스는 사용자 정보의 저장 및 로드와 같은 사용자 관리 기능만을 수행합니다. 따라서 클래스의 책임이 명확하게 구분되어 있습니다.

단일 책임 원칙을 준수하지 않은 코드 예시

using System;
>
// 사용자 정보를 관리하고 동시에 UI를 업데이트하는 클래스
public class UserManager {
    private Database database;
    private UIUpdater uiUpdater;
>
    public UserManager(Database database, UIUpdater uiUpdater) {
        this.database = database;
        this.uiUpdater = uiUpdater;
    }
>
    // 사용자를 데이터베이스에 저장하고 동시에 UI를 업데이트하는 메서드
    public void SaveUserAndUpdateUI(User user) {
        // 데이터베이스에 저장하는 로직
        // UI를 업데이트하는 로직
    }
>
    // 사용자를 데이터베이스에서 불러오고 동시에 UI를 업데이트하는 메서드
    public User LoadUserAndUpdateUI(int userId) {
        // 데이터베이스에서 사용자 정보를 불러오는 로직
        // UI를 업데이트하는 로직
        return null;
    }
}
>
// 데이터베이스 관리 클래스
public class Database {
    // 데이터베이스 연결 및 관리를 위한 메서드
}
>
// UI를 업데이트하는 클래스
public class UIUpdater {
    // UI 업데이트를 위한 메서드
}

이 코드에서는 UserManager 클래스가 사용자 정보의 저장과 동시에 UI 업데이트도 수행합니다. 이는 클래스가 여러 가지 책임을 가지고 있어서 단일 책임 원칙을 위반하는 것입니다. 이러한 경우 클래스가 변경되어야 하는 이유가 둘 이상이 될 수 있으며, 코드의 유지보수가 어려워질 수 있습니다.

개방/폐쇄 원칙

개방/폐쇄 원칙(Open/Closed Principle, OCP)는 소프트웨어 설계 원칙 중 하나로, "소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고 수정에는 닫혀 있어야 한다"는 원칙을 의미합니다. 즉, 새로운 기능을 추가할 때는 기존 코드를 수정하지 않고 확장을 통해 가능하도록 해야 합니다.

1. 추상화와 다형성 활용: 추상화를 통해 인터페이스나 추상 클래스를 정의하고, 다형성을 활용하여 이를 구현하는 클래스들을 만듭니다. 새로운 기능이 추가되면 새로운 구현 클래스를 만들어 기존 인터페이스를 구현하면 됩니다.

2. 확장 포인트 제공: 기존 코드에 새로운 기능을 추가하기 위한 확장 포인트를 제공합니다. 이를 통해 새로운 기능을 추가하는데 필요한 수정을 최소화하고, 기존 코드의 안정성을 유지할 수 있습니다.

3. 디자인 패턴 활용: 디자인 패턴 중 전략 패턴, 팩토리 패턴 등을 활용하여 OCP를 지키는 방법이 있습니다. 이러한 패턴은 새로운 기능을 추가할 때 기존 코드 수정을 최소화하고 확장성을 높일 수 있도록 도와줍니다.
   OCP를 준수하면 코드의 재사용성과 유연성을 높일 수 있으며, 새로운 기능 추가 시 코드 변경으로 인한 부작용을 최소화할 수 있습니다.

OCP를 지킨 코드 예시

// 추상화를 통한 확장 포인트 제공
public interface IShape
{
    void Draw();
}
>
// 기존 코드 수정 없이 새로운 기능 추가
public class Circle : IShape
{
    public void Draw()
    {
        Console.WriteLine("Drawing a circle");
    }
}
>
public class Square : IShape
{
    public void Draw()
    {
        Console.WriteLine("Drawing a square");
    }
}
>
// 새로운 기능을 추가하기 위해 확장
public class Triangle : IShape
{
    public void Draw()
    {
        Console.WriteLine("Drawing a triangle");
    }
}

위 코드에서는 IShape 인터페이스를 통해 도형을 추상화하고, 이를 구현하는 클래스들을 만듭니다. 새로운 기능을 추가할 때는 기존 코드를 수정하지 않고 IShape 인터페이스를 구현하는 새로운 클래스를 추가함으로써 확장합니다.

OCP를 지키지 않은 코드 예시

public class DrawingTool
{
    public void DrawCircle()
    {
        Console.WriteLine("Drawing a circle");
    }
>
    public void DrawSquare()
    {
        Console.WriteLine("Drawing a square");
    }
}
>
// 새로운 기능 추가 시 기존 코드를 수정해야 함
public class DrawingToolExtended : DrawingTool
{
    public void DrawTriangle()
    {
        Console.WriteLine("Drawing a triangle");
    }
}

위 코드에서는 새로운 기능을 추가할 때 기존 클래스를 상속받아 새로운 메서드를 추가하는 방식을 사용합니다. 이 경우 새로운 기능을 추가할 때마다 기존 코드를 수정해야 하므로 OCP를 위반하게 됩니다. 또한 이러한 방식은 클래스 간의 결합도가 높아져 유지보수가 어려워질 수 있습니다.

리스코프 치환 원칙

리스코프 치환 원칙(Liskov Substitution Principle, LSP)은 객체 지향 프로그래밍에서 중요한 원칙 중 하나입니다. 이 원칙은 “하위 타입은 그것의 기반(상위) 타입으로 대체될 수 있어야 한다”는 원칙을 나타냅니다. 즉, 어떤 클래스를 사용하는 코드는 그 클래스의 하위 클래스를 사용하더라도 동일하게 작동해야합니다.

• 하위 클래스는 상위 클래스에서 가능한 모든 동작을 수행할 수 있어야 한다.
• 이 원칙은 상속 관계에서 하위 클래스가 상위 클래스와 동일하게 행동하도록 보장하여 프로그램의 논리적 일관성을 유지해야 합니다.

리스코프 치환 원칙의 예시

Animal이라는 상위 클래스가 있고, Dog과 Cat이라는 두 개의 하위 클래스가 있다고 가정해봅시다. 이 경우, Animal 클래스를 사용하는 코드는 Dog 또는 Cat 클래스를 사용하더라도 동일하게 작동해야 합니다.

public class Animal
{
    public virtual void Speak()
    {
        Debug.Log("The animal speaks.");
    }
}
>
public class Dog : Animal
{
    public override void Speak()
    {
        Debug.Log("The dog barks.");
    }
}
>
public class Cat : Animal
{
    public override void Speak()
    {
        Debug.Log("The cat meows.");
    }
}
>
public class AnimalTest
{
    public void LetAnimalSpeak(Animal animal)
    {
        animal.Speak();
    }
}

위 코드에서는 LetAnimalSpeak메서드는 Animal 클래스의 인스턴스를 매개변수로 받습니다. 그러나 이 메서드는 Dog 또는 Cat 클래스의 인스턴스를 받아도 동일하게 작동합니다. 이것이 리스코프 치환 원칙을 따르는 예입니다. 이 원칙을 따르면 코드의 유연성과 재사용성이 향상 되며, 클래스 계층 구조의 설계가 개선됩니다.

리스코프 치환 원칙을 위반의 예시

직사각형과 정사각형의 관계를 생각해봅시다. 정사각형은 직사각형의 특별한 경우이므로, 직사각형 클래스를 상속하여 정사각형 클래스를 만들 수 있을 것 같습니다. 그러나 이 경우 문제가 발생할 수 있습니다. 직사각형 클래스에서 너비와 높이는 독립적으로 설정할 수 있지만, 정사각형 클래스에서는 너비와 높이가 항상 같아야합니다. 따라서 정사각형 클래스는 직사각형 클래스의 모든 기능을 제대로 대체할 수 없으므로, 이 경우는 리스코프 치환 원칙을 어기는 경우이다.

대체 가능한 비유 - 고래는 물에 살지만 아기를 낳기 때문에 어류 클래스가 아니라 포유류 클래스에 속하는 거랑 비슷하다. 해당 경우에는 어류 클래스의 알을 낳는 기능을 상속받지 못했기 때문에 리스코프 치환 원칙을 어기게 되는 것이다.

그래서 이와 같이 상속하기 애매한 부분에서는 클래스의 상속 대신에 인터페이스의 상속을 이용해줘야한다.

public interface Size
{
    public void GetShape();
}
>
public enum Habitat // 열거형으로도 속성을 나눠줄 수 있다.
{
    Land,
    Marine
}

인터페이스 분리 원칙

'인터페이스 분리 원칙(Interface Segregation Principle, ISP)'을 나타냅니다. 이 원칙은 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙을 의미합니다. 즉, 클라이언트에게 필요한 메서드만을 제공해야 하며, 불필요한 메서드는 제거하거나 다른 인터페이스로 분리해야 합니다.

예를 들어, ISmartPhone이라는 인터페이스가 있고, 이 인터페이스에는 여러 가지 스마트폰 기능을 정의하는 여러 메서드가 있다고 가정해 봅시다. 그런데 이 중 일부 기능은 특정 스마트폰 모델에서만 지원되는 기능일 수 있습니다. 이런 경우, 모든 스마트폰 모델이 ISmartPhone 인터페이스의 모든 메서드를 구현해야 하는 것은 비효율적입니다.

해당 원칙을 지킨다면

1. 코드의 복잡성 감소 ** **2. 유지 관리가 용이 3. 코드의 재사용성이 향상 4. 클래스와 인터페이스의 설계가 개선

인터페이스 분리 원칙을 지킨 예시

public interface IBasicPhone
{
    void Call(string number);
    void SendText(string number, string text);
}
>
public interface IAdvancedPhone : IBasicPhone
{
    void UseWirelessCharging();
    void UseBiometrics();
}
>
public class BasicPhoneModel : IBasicPhone
{
    public void Call(string number) { /* 구현 */ }
    public void SendText(string number, string text) { /* 구현 */ }
}
>
public class AdvancedPhoneModel : IAdvancedPhone
{
    public void Call(string number) { /* 구현 */ }
    public void SendText(string number, string text) { /* 구현 */ }
    public void UseWirelessCharging() { /* 구현 */ }
    public void UseBiometrics() { /* 구현 */ }
}

이 코드에서 BasicPhoneModel은 기본적인 전화와 문자 메시지 기능만을 지원하므로 IBasicPhone 인터페이스만을 구현하고, AdvancedPhoneModel은 추가적인 무선 충전과 생체 인식 기능을 지원하므로 IAdvancedPhone 인터페이스를 구현합니다. 이렇게 하면 각 스마트폰 모델은 자신이 지원하는 기능을 정의하는 인터페이스만을 구현하게 되므로, 인터페이스 분리 원칙을 준수하게 됩니다

의존 역전 원칙

의존 역전 원칙(Dependency Inversion Principle, DIP)

• 상위 모듈은 하위 모듈에 의존해서는 안됩니다. 둘 다 추상화에 의존해야합니다.
• 추상화는 세부 사항에 의해 의존해서는 안됩니다. 세부 사항이 추상화에 의존해야합니다.
  이 원칙은 소프트웨어 구조의 결합도를 줄이는데 중요한 역할을 합니다. 이를 통해 소프트웨어의 유지 보수성과 확장성이 향상됩니다. 이 원칙을 따르면, 시스템의 각 부분을 독립적으로 개발하고 변경할 수 있으므로, 전체 시스템에 대한 영향을 최소화할 수 있습니다.

의존 역전 원칙을 지킨 예시

public interface IWeapon
{
    void Use();
}
>
public class Player
{
    private IWeapon _weapon;
>
    public Player(IWeapon weapon)
    {
        _weapon = weapon;
    }
>
    public void Attack()
    {
        _weapon.Use();
    }
}
>
public class Sword : IWeapon
{
    public void Use()
    {
        // 공격 로직
    }
}

이 예시에서는 Player 클래스가 IWeapon이라는 인터페이스에 의존하고 있습니다. 이로 인해 Player는 Sword 뿐만 아니라 IWeapon 인터페이스를 구현하는 어떤 무기와도 작동할 수 있습니다. 이렇게 하면 Player 클래스를 변경하지 않고도 다른 무기를 사용할 수 있습니다. 이것이 의존 역전 원칙을 지키는 방법입니다. 이 원칙을 따르면 코드의 유연성과 재사용성이 향상됩니다.

의존 역전 원칙을 지키지 않은 예시

public class Player
{
    private Sword _sword;
>
    public Player()
    {
        _sword = new Sword();
    }
>
    public void Attack()
    {
        _sword.Swing();
    }
}
>
public class Sword
{
    public void Swing()
    {
        // 공격 로직
    }
}

위의 코드에서 Player 클래스는 Sword 클래스에 직접적으로 의존하고 있습니다. 이는 Player가 다른 무기를 사용하려면 Player 클래스를 변경해야함을 의미합니다.

작성하면서 느낀점

객체 지향 원칙을 얼핏 들어보기만 했지 제대로 이해했다는 생각은 많이 들지 않았다. 오늘 특강을 듣고 다시 이해해보는 과정을 거치니까. 전보다 좀 더 잘 이해하게 되었다.

오늘 한 일

• 챌린지반 과제 풀이 (제너릭 싱글턴 구현하기)
• 팀 프로젝트 진행 (파워업 추가(보호막), 프로젝트 마무리, 발표 준비)
• 게임 프로젝트 개발하면서 아쉬웠던 점 회고하기

...작성 중... 오늘은 객체 지향의 4가지 특징에 대해서 회고하고, 객체 지향 프로그래밍의 특징을 활용하여 프로젝트에서 구현한 기능 중 하나인 떨어지는 오브젝트들을 리팩토링해보기로 했다.

기초적인 부분들은 어느 정도 넘어갈 수도 있으니 주의하자

객체 지향 프로그래밍

개념

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모음으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다. 위키백과

4가지 특징

추상화

• 구체적인 여러 물건들의 공통적인 특징이나 기능을 추출하는 것
• 불필요한 세부 사항들을 제거하고 가장 본질적이고 공통적인 부분만을 추출하여 표현하는 것
  객체 지향 프로그래밍 중 하나인 추상화는 여러 객체의 공통적인 부분을 묶어서 동일한 데이터와 기능들을 클래스로 묶어서 상속해주기 위해 사용된다. (또는 인스턴스를 생성할 때 인스턴스마다의 공통된 특징을 묶어서 클래스 하나만으로도 다양한 종류의 인스턴스를 만드는 코드를 기획할 때 쓰인다. [클래스를 붕어빵틀이라고 설명하는 이유]

추상화 예시

• 
• 위 이미지를 보면 마인크래프트의 도구들을 하나로 묶어주는건데, 마인크래프트를 해보면 알겠지만 각 도구들에게는 특정 블럭을 캐면 다른 걸 들고있는 것보다 빨리 캐는 특성을 가지고 있다. (DigSpeed) 추상화를 이용한다면 공통된 특징을 찾아내고 이것을 통해서 객체들이 상속받을 부모 클래스를 설계할 수 있다.

조금 더 추상화해보자

• 
• 위와 같이 도구, 음식, 블럭으로 추상화해봤고 이러한 모든 애들이 플레이어의 인벤토리에 들어가기 때문에 Item이라는 추상화까지 해낼 수 있다. 마인크래프트에서 아이템들은 전부 인벤토리 칸에 들어갈 수 있다. (Pick())

이렇게 게임 속 객체들에 대한 추론 뿐만 아니라 실제 사물에서도 이러한 추론을 통해 공통된 특징을 유추해볼 수 있다. (자동차, 오토바이 -> 이동수단) 이러한 추상화를 잘한다면 구체화된 객체들에게 상속해줄 부모 클래스의 설계를 잘해낼 수 있다. 그렇기 때문에 게임 기획에 있어서 추상화라는 개념은 매우 중요한 요소이다.

상속

• 특정 클래스의 데이터와 기능들을 하위 클래스에게 물려주는 것
  상속을 통해서 각 객체들마다 중복되는 코드를 계속해서 써내는 것보다는 공통된 특징들을 부모 클래스를 하나 만들어내고 그러한 특징을 가진 객체들에게 상속시켜주자. 앞서했던 추상화를 통해 오브젝트끼리의 공통된 데이터와 기능을 추출하고 그걸 바탕으로 상속된 부모 클래스를 만들어주면 더욱더 효율적으로 상속시켜줄 수 있다.

기본적인 상속

• 
• 위 이미지를 보면 Tool 클래스는 Sword의 부모 클래스로 Sword 클래스에게 필드와 기능들을 전달해주고 있다. 이 상속을 이용한다면 공통된 특징들은 부모 클래스로 통해서 전해주고 자신의 구체적인 특징들은 자식 클래스에서 구현해주면 된다.

상속 관계

• 
• 상속의 길이에는 제한이 없다 (위에서부터 상속된 클래스의 모든 멤버들을 가져갈 수 있는 것이다.) 하지만 *클래스의 다중 상속은 불가능하니 그 점을 유의하자 (*하나의 클래스가 두 개의 클래스를 상속 받는 것)

인터페이스

• 객체 지향 프로그래밍의 기능 중 하나로 기능의 틀을 만드는 역할을 한다. 인터페이스는 클래스처럼 상속 받을 수 있지만 인터페이스 내에 있는 메서드들을 반드시 표현해줘야한다.

  인터페이스 사용

• 필드 구현이 불가능하다. (상수는 가능하다.)
• 인터페이스를 상속 받는다면 해당 인터페이스의 멤버들을 모두 구현해줘야한다.
• 클래스와 달리 다중 상속이 가능하다.

  인테페이스 예시

• 
• 인터페이스는 주로 자주 사용되는 기능에 대한 부분을 구현해줄 때 사용된다. (분류로 나누기에는 애매할 때)

상속은 공통된 데이터와 기능을 부모 클래스를 통해 상속하여 코드의 중복을 줄이기 위해 사용된다. 좀 더 디테일하게 들어가주면 클래스는 주로 객체들의 명사적인 부분, 정체성에 대해 설정할 때 기획해주는 것이 좋고, 인터페이스는 주로 객체들의 동사적, 기능적인 부분에 대해 설정할 때 기획해주는 것이 올바른 방향이다. class -> A is ~ ||| Interface -> A can ~

다형성

• 어떤 객체가 상황에 따라서 다양한 기능이나 속성을 가질 수 있는 것을 말한다.
  예를 들어서 검이라는 무기는 적을 공격할 수 있지만, 거미줄을 쉽게 깨는 역할도 있고, 아이템 액자에 걸어줄 수 있는 등 단순히 한 가지의 특징이나 기능 뿐만 아니라 다양한 것들을 수행해낼 수 있다는 것을 말한다. 다형성의 특징을 가진 기능은 주로 overriding과 overloading이나 상위 클래스의 변수를 참조하는 기능들이 있다.

상위 클래스/인터페이스 참조

사실 다형성의 가장 큰 부분을 생각한다면 아무래도 상위 존재 참조에 대한 부분이 있을 것이다. 우리가 특정 기능에 대한 액세스를 시도하기 위해서는 해당 클래스 타입 인스턴스를 받아오고 그 클래스 내에 있는 메서드를 실행시켜줘야한다.

코드 예시

// 인스턴스를 받아와서 일을 수행하는 코드
public class Something
{
    public void Method1(Class1 instance)
    {
        instance.method1;
    }
}

만약에 개발을 수행하면서 비슷한 기능을 가진 클래스가 추가적으로 생기게 된다면 그 많은 클래스들에 대한 추가적인 처리도 해줘야한다.

코드 예시

// 추가적인 클래스들의 액세스를 위해서 추가적으로 overloading을 해줘야한다.
    public void Method1(Class1 instance)
    {
        instance.method1;
    }
    public void Method1(Class2 instance)
    {
        instance.method1;
    }
    public void Method1(Class3 instance)
    {
        instance.method1;
    }
    public void Method1(Class4 instance)
    {
        instance.method1;
    }
// 이렇게 되면 쓸데 없이 코드가 길어지고 난잡해진다.

이 현상이 계속 반복된다면 그만큼 일이 가중될 것이니 전혀 효율적인 방법이 아니다. 하지만 그 클래스들의 상위 클래스/인터페이스를 참조한다면 메서드의 액세스가 필요한 클래스가 계속 추가된다하더라도 추가적인 일이 발생되지는 않게 되어 확장성을 용이하게 만들어준다.

// 상위 클래스 타입으로 가져와주자
public void Method1(ParentClass instance)
{
    instance.method1; 
}

이와 같이 다형성을 잘 이용한다면 적은 코드만으르도 다양한 걸 표현해낼 수 있고 액세스의 편의성을 가져다준다.

캡슐화

• 서로 연관있는 속성과 기능들을 하나의 캡슐로 만들어 데이터를 외부로부터 보호하는 것
  사실 보호하는 측면도 있지만, 일처리적인 부분으로 보면 굳이 밖에서 내부 필드들을 건들지 않아도 독립적으로 처리할 수 있게 만들어주는 측면도 존재한다. 자신의 필드를 독자적으로 해결해낼 수 있다면 클래스 간의 결합도를 효과적으로 줄여줄 수 있다.
  캡슐화에 밀접하는 기능들은 주로 접근 제한자, 프로퍼티에 해당한다.

리팩토링 해보기

• OOP의 특징들을 토대로 내가 프로젝트에서 구현했던 떨어지는 오브젝트들을 리팩토링해볼 생각이다.

리팩토링 전

Food.cs

public class Food : MonoBehaviour
{
    [SerializeField] private LayerMask playerCollisionLayer;
    [SerializeField] private LayerMask shieldCollisionLayer;
>
    private FoodAnimator animator;
    private void Awake()
    {
        animator = GetComponent<FoodAnimator>();
    }
>
    private int scorePoint = 100; 
>
    void Update()
    {
        transform.position += Vector3.down * Time.deltaTime * 2 * SpawnManager.instance.speedScaling;
    }
>
    private void OnTriggerEnter2D(Collider2D other)
    {
        if(IsLayerMatched(shieldCollisionLayer, other.gameObject.layer)) { return; }
>
        if (IsLayerMatched(playerCollisionLayer.value, other.gameObject.layer))
        { 
            GameManager.instance.ScoreEarn(scorePoint);
            SoundManager.instance.PlayClickSound();
            animator.IsHit(true);
        }
        Invoke("Disabled", 3f);     
    }
>
    private bool IsLayerMatched(int layerMask, int objectLayer)
    {
        return layerMask == (layerMask | (1 << objectLayer));
    }
>
    private void Disabled()
    {
        gameObject.SetActive(false);
        animator.IsHit(false);
    }
}

Avoid.cs

public class AvoidFood : MonoBehaviour
{
    public IObjectPool<GameObject> pool { get; set; }
>
    [SerializeField] private LayerMask playerCollisionLayer;
>
    void Update()
    {
        transform.position += Vector3.down * Time.deltaTime * 2 * SpawnManager.instance.speedScaling; // 속도 스케일링
    }
    private void OnTriggerEnter2D(Collider2D other)
    {
        if (IsLayerMatched(playerCollisionLayer.value, other.gameObject.layer))
        { 
            PlayerController controller = other.gameObject.GetComponent<PlayerController>();
            controller.CallDieEvent();
>
            Invoke("GameOverEvent",0.5f);            
        }        
        gameObject.SetActive(false);
    }
>
    private bool IsLayerMatched(int layerMask, int objectLayer)
    {
        return layerMask == (layerMask | (1 << objectLayer));
    }
>
    private void GameOverEvent()
    {
        SystemManager.instance.CallGameOver();
    }
}

PowerUp.cs

public class PowerUp : MonoBehaviour
{
    [SerializeField] private LayerMask playerCollisionLayer;
    [SerializeField] private LayerMask shieldCollisionLayer;
>
    private FoodAnimator animator;
>
    private void Awake()
    {
        animator = GetComponent<FoodAnimator>();
    }
>
    void Update()
    {
        transform.position += Vector3.down * Time.deltaTime * 2.5f * SpawnManager.instance.speedScaling; // 속도 스케일링
    }
>
    private void OnTriggerEnter2D(Collider2D other)
    {
        if (IsLayerMatched(shieldCollisionLayer, other.gameObject.layer)) { return; }
>
        if (IsLayerMatched(playerCollisionLayer.value, other.gameObject.layer))
        {
            SoundManager.instance.PlayItemSound();
            animator.IsHit(true);
            Movement playerCoroutine = other.gameObject.GetComponent<Movement>();
            playerCoroutine.StartSpeedUP();
        }
        Invoke("Disabled", 3f);
    }
>
    private bool IsLayerMatched(int layerMask, int objectLayer)
    {
        return layerMask == (layerMask | (1 << objectLayer));
    }
>
    private void Disabled()
    {
        gameObject.SetActive(false);
        animator.IsHit(false);
    }
}

심지어 파워업은 사이즈 증가, 사이즈 감소, 보호막까지 3개 더 있다

문제점 짚기

• 중복되는 코드들이 많다.
  • Animator, LayerMask
  • 아래로 이동
  • 트리거 감지, 레이어 검사
  • 비활성화
• 다 따로 나눠져 있어서 코드도 완전 제각각이다.

리팩토링 이후

어떻게 리팩토링을 할까?

• 코드를 하나로 통일시키고 생성하는 과정에서만 다르게 하자! (SO의 정보 -> 오브젝트의 정보를 담는 스크립트)
  • 플레이어와 부딪혔을 때 발생하는 상호작용을 다른 부분으로 갈아끼우는 방식으로 들어가면 좋을 것 같다. (상호작용 관련 enum과 enum을 받아서 switch로 상호작용을 처리하는 클래스를 만들자)
  • 혹여나 플레이어 레이어 뿐만 아니라 다른 레이어에 부딪혔을 때도 상호작용 부분도 만들어 주는 것도 좋다. (Layer를 단일로 받지 않고 List로 바꾸고 이걸 SO로 전해받는 식으로 해주면 될 것 같다)
    일단 꾸미는 부분은 잠시 예외시키고 상호작용 부분에만 신경써보자.

리팩토링 코드

FallingObject.cs

public class FallingObject : MonoBehaviour
{
    public FallingObjectSO objectSO; // SO를 넣어주는 것 (또는 스폰 매니저에서 줘도 된다.)
>
    void Update()
    {
        transform.position += Vector3.down * Time.deltaTime * 2;
    }
>
    private void OnTriggerEnter2D(Collider2D collider)
    {
        foreach (LayerMask layer in objectSO.InteractionWhenEnter) // foreach를 통해 모두 검사 (||와 비슷)
        {
            if (IsLayerMatched(layer, collider.gameObject.layer))
            {
                ItemInteractionManager.instance.InteractionActive(objectSO.type, objectSO.Score);
                  break;
            }
        }
>
        foreach (LayerMask layer in objectSO.DestroyWhenEnter)
        {
            if (IsLayerMatched(layer, collider.gameObject.layer))
            {
                Disabled();
                  break;
            }
        }
    }
>
    private bool IsLayerMatched(int layerMask, int objectLayer)
    {
        return layerMask == (layerMask | (1 << objectLayer));
    }
>
    private void Disalbed()
    {
        gameObject.SetActive(false);
    }
}
>

FallingObjectSO.cs

[CreateAssetMenu(fileName = "FallingObjectSO", menuName = "FallingObject", order = 0)]
public class FallingObjectSO : ScriptableObject
{
    public List<LayerMask> InteractionWhenEnter;    // 이 레이어에 부딪히면 상호작용을 일으킨다
    public List<LayerMask> DestroyWhenEnter;        // 이 레이어에 부딪히면 사라지게 한다.
>
    public int Score;                // 점수 ( 점수 획득 상호작용에 쓰임 )
    public InteractionType type;    // 상호작용 타입
}    

ItemInteractionManager.cs

public enum InteractionType
{
    Score,
    Big,
    Small,
    Shield,
    GameOver = 100
}
>
public class ItemInteractionManager
{
    public static ItemInteractionManager instance = new ItemInteractionManager();
    public void InteractionActive(InteractionType type, int score)
    {
        switch((int)type)
        {
            case 0:
                // 점수 증가 - GameManager.instance.EarnScore(score);
                break;
            case 1:
                // 크기 증가 - SpawnManager.instance.SizeChange = 2.0f;
                break;
            case 2:
                // 크기 감소 - SpawnManager.instance.SizeChange = 0.5f;
                break;
            case 3:
                // 쉴드 활성화 - GameManager.instance.player.ShieldActive();
                break;
            case 100:
                // 게임 오버 - SystemManager.instance.
                break;
        }
    }
}

위와 같이 객체 지향의 특징인 추상화와 다형성을 활용해서 코드를 좀 더 간결하고 깔끔하게 리팩토링하고 새로운 것이 추가되어도 코드의 통일성을 해치지 않게 되어 서로 다르게 생성되는 경우가 발생하지 않는다.

참고 자료

사진 - 마인크래프트

동영상

1. 객체지향 프로그래밍이 뭔가요? - 얄팍한 코딩 사전 2. 객체지향 프로그래밍? 문과도 이해쌉가능. 10분컷 - 노마드 코더

위키 백과

1. 객체 지향 프로그래밍 - 위키백과

   블로그

*1. 객체 지향 프로그래밍의 4가지 원칙 - 나태웅 *

TIL을 쓰면서 느낀점

객체 지향이라는 것을 뭔가 정확히 알기보다는 겉으로만 알고 있는 느낌이 강했지만, 다시 한번 복습하고 알아보니 어떤 원리를 작용하게 되는지 자세히 알게 되었다. 그리고 코드를 짤 때는 이상하게도 뭔가 뚜렷하게 코드를 떠올리는 것보다는 추상적인 것에서부터 시작해서 마치 그림을 그리듯이 구도를 짠 다음에 자기가 알고 있는 코드를 동원하게 되는 느낌이다. 디자인 패턴이에 대해서 배울 때 그게 강하게 느껴진다. 아무래도 코드를 잘 짜려면 다양한 디자인 패턴을 겪어봐야할 필요도 느껴졌다.

오늘 한 일

• 챌린지반 과제 풀이 (제너릭 싱글턴 구현하기)
• 팀 프로젝트 진행 (오브젝트 풀링, 파워업 추가)
• 챌린지반 특강 듣기 (Delegate, event, UnityAction)
• 여태까지 배운 내용 시험 풀기

오늘은 선언해두면 언제 어디서든 접근이 가능한 싱글턴 패턴에 대해서 알아보자

싱글턴

기초 개념

싱글턴은 클래스에 인스턴스가 하나만 있도록 하면서 이 인스턴스에 대한 전역 접근 지점을 제공하는 생성 디자인 패턴입니다. 리팩토링 구루

• 모든 인스턴스들이 싱글턴 패턴에게 접근이 가능하다.

기초 구현

싱글턴을 선언할 때 가장 중요한 키워드에 대해서 설명해주겠다.

static (정적 선언)

• 인스턴스가 아닌 클래스에 속하는 정적 멤버를 선언할 때 사용하는 키워드입니다.
• 클래스, 인터페이스 및 구조체에서 필드, 메서드, 속성, 연산자, 이벤트 및 생성자에 static 키워드를 추가할 수 있습니다
• static 한정자는 인덱서 또는 종료자와 함께 사용할 수 없습니다.

  public class Class1
  {
    public static int staticField = 2;
  >    
    public static void staticMethod()
    {
        Console.WriteLine("저는 정적 메서드입니다. 바로 외부에서 호출이 가능합니다.");
    }
  }
  >
  // 호출 해보기
  static void Main(string[] args)
  {
    Console.WriteLine(Class1.staticField);
    Class1.staticMethod();
  }

• 
• 정적 선언한 필드와 메서드들은 인스턴스 선언 없이 바로 외부로 호출이 가능하다.

% static 사용 시 주의사항 %

1. static이 아닌 멤버에서는 static 멤버를 사용 가능하지만 static인 멤버에서 static이 아닌 멤버를 사용할 수 없다

(사용하려면 인스턴스 생성을 해줘야한다)

• 
• 그래서 위와 동일한 이유로 Progam 클래스에 선언했다고 해서 Main 함수에서 사용이 불가능한 이유와 동일하다.

2. static 멤버는 인스턴스 단위로 참조가 불가능하다.

• 
• static은 아예 클래스 소속이기 때문에 클래스 자체로 불러줘야한다.

static은 아예 클래스 자체에 속하기 때문에 이 점을 이용해서 싱글턴을 만들어내는 것이다.

static을 활용해 싱글턴 선언하기

유니티에서 가장 기초적인 싱글턴

public class GameManager : MonoBehaviour
{
    public static GameManager instance;
    void Awake()
    {
        instance = this; // this는 클래스의 현재 인스턴스를 가리킨다.
    }
}

VisualStudio에서 기초적인 싱글턴

public class GameManager
{
    public static GameManager instance = new GameManager(); // Awake 같은 건 없으니 이로 대체해주자.
>
    public int field = 1;
}
>
// 사용해보기
static void Main(string[] args)
{
    GameManager.instance.field = 4;
    Console.WriteLine(GameManager.instance.field);
}

• 
• 숫자가 잘 변경되고 호출된 모습을 볼 수 있다.

• 해당 코드들을 잘 보면 static을 이용해 클래스 소속 클래스타입 멤버를 선언해서 거기에 자기 자신을 할당하는 방식이다.

이것도 싱글턴 패턴인가요?

    static class staticClass
    {
        public static int staticField = 4;
>
        public static void staticMethod()
        {
            Console.WriteLine("정적 클래스의 정적 메서드입니다.");
        }
    }

• 물론 싱글톤과 비슷하게 static 필드를 바꿀 수 있고 메서드도 호출 가능하지만, 싱글턴에 비해서 제한적인 사항이 많다.

1. 정적 멤버만 선언 가능
2. 인터페이스 구현 불능
3. 상속과 재정의 불능

• 정적 클래스는 단순히 서로 연관된 메서드를 묶어두는 것에만 가깝기 때문에 절차적 프로그래밍에 가깝다고 본다.
• 해당 코드의 사용처는 주로 유틸리티 클래스, 수학 함수 등에서 사용된다.

싱글턴 사용 시 주의할 점

싱글턴의 편의성 때문에 사용에 주의해야 한다.

1. 싱글턴 클래스가 많은 책임과 기능 짊어질 수도 있다.

• 가능하다면 최대한 여러 클래스로 분담해주는 것이 좋다. (의존도와 결합도에 유의해줘야한다.)

  2. 객체 생성 시기를 제어할 수 없다.

• 그래서 주로 항상 상주해야만 하는 GameManager나 AudioManager과 같은 곳에 싱글톤을 사용하는 편이다.

  3. 유니티에서는 겹쳐서 생성되는 경우를 주의해야한다.

• if (instance == null)을 통해 클래스의 instance가 겹치지 않게 유의해줘야한다.

유니티에서 싱글턴 패턴 구현하기

현재 사용하는 싱글턴

public class SystemManager : MonoBehaviour
{
    public static SystemManager instance;
>
    void Awake()
    {
        if (instance == null)
        {
            instance = this;
            DontDestroyOnLoad(instance); // 씬이 넘어가도 파괴되지 않게하기
        }
        else
        {
            Destroy(gameObject); // 겹치는 건 파괴
        }

제너릭 싱글턴(오브젝트 탐색)

코드 출처 - 실리의 프로그램 사이트

public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
    private static T instance;
>
    public static T Instance
    {
        get
        {
            if (instance == null)
            {
                GameObject obj;
                obj = GameObject.Find(typeof(T).Name);
                if (obj == null)
                {
                    obj = new GameObject(typeof(T).Name);
                    instance = obj.AddComponent<T>();
                }
                else
                {
                    instance = obj.GetComponent<T>();
                }
            }
            return instance;
        }
    }
>
    public void Awake()
    {
        DontDestroyOnLoad(gameObject);
    }
}

• 해당 제너릭 싱글턴은 오브젝트를 기준으로 찾아내기 때문에 해당 싱글턴을 상속받은 클래스와 오브젝트의 이름이 동일해야한다.

참고 자료

리팩토링 구루 - 싱글톤 패턴

Learn.Microsoft - static 한정자

실리의 프로그램 사이트 - Unity Singleton을 제네릭으로 만들어놓고 써봅시다

작성하면서 느낀점

기존에 알고 있음에도 불구하고 다시 써보고 정리해보니 전보다 이해가 깊이 되고 좀 더 발전된 방식의 싱글톤 사용이 가능해졌다. 기존 지식을 회고하는 것만으로도 코드 기획에 많은 도움이 되는 것 같다.

오늘 한 일

• 챌린지반 과제 풀이 (InputSystem에서 키 바인딩 덮어씌우기)
• 팀 프로젝트 진행 (UI 상호작용, 게임 기본 로직, 파워업 추가)
• 특강 듣기 (유니티의 다양한 직군)

Coroutine

개념

작업을 다수의 프레임에 분산하는 메서드로 Unity에서 코루틴은 실행을 일시정지하고 제어를유니티에 반환하지만, 중단된 부분에서 다음 프레임을 계속할 수 있는 메서드입니다. (비동기처럼 작동하는 것처럼 보이지만, 엄연히 메인 스레드에서 실행되는 동기 작업입니다.)

함수와 코루틴의 차이

• 함수는 return을 만날 때까지 계속 제어권을 가지게되는 반면에 코루틴은 yield return을 통해서 중간 지점에서 제어권을 반환했다가 다시 조건을 충족하면 제어권을 가져오는 방식으로 작업을 처리한다.

사용방법

코루틴 메서드 선언하기

IEnumerator Coroutine1()    //IEnumerable랑 헷갈리지 않게 조심해야한다.
{
    // 처리하고자 하는 코드
    yield return null; //yield return을 반드시 넣어줘야한다.
    // yield return null 이후 실행해줄 코드
} // 여기까지 와야 코루틴 끝

코루틴 사용하기

StartCoroutine(Coroutine1());
StartCoroutine("Coroutine1"); // 문자열로도 가능하다.

• 성능상 문자열보다는 메서드 형태로 전달해주는 것이 좋다.

  사용할 때 주의사항

• Awake에서 실행하면 잘 작동이 안될 수도 있다. (Awake의 호출 순서 때문이다(오브젝트 활성화 전에 호출))
• 비활성화 상태에서 코루틴을 동작시키려하면 작동이 안된다.

코루틴의 다양한 제어점 반환

yield return null

• 다음 프레임까지 대기 후 실행
  • 

    yield return new WaitForFixedUpdate()

• 다음 FixedUpdate가 호출될 때까지 대기 후 실행
  • 

    yield return new WaitForEndOfFrame()

• 현재 프레임이 종료될 때까지 대기 후 실행
  • 

    yield return new WaitForSeconds(float)

• 지정한 초만큼 대기 후 실행 Update와 LateUpdate 사이에서 실행

  yield return new WaitForSecondsRealtime(float)

• 괄호 안의 시간(초)이 지날 때까지 대기 후 실행 (timeScale의 영향을 안 받음) Update와 LateUpdate 사이에서 실행

  yield return new WaitUntil()

• 괄호 안의 조건이 만족할 때까지 대기 후 실행 Update와 LateUpdate 사이에서 실행

  yield return new WaitWhile()

• 괄호 안의 조건이 만족하지 않을 때까지 대기 후 실행 Update와 LateUpdate 사이에서 실행

  yield return StartCoroutine()

• 다른 코루틴이 끝날 때까지 대기 후 실행

코루틴 멈추기

yield break

• 이 코드가 적힌 시점에서 코루틴을 멈춘다

코루틴에게 매개변수 전달

StartCoroutine(Coroutine1(매개변수1, 매개변수2, 매개변수3));
StartCoroutine("Coroutine1", 매개변수_단일);
// 메서드로 보내면 여러 개를 보낼 수 있고 문자열로 보내면 하나 밖에 못 보낸다

코루틴 외부 상호작용

외부에서 멈추기

StopCoroutine("Coroutine1") // 문자열로 시작했을 때에만 가능하다.
>
// 다른 방법
Coroutine myCoroutine1;
>
{
    myCoroutine1 = StartCoroutine(Coroutine1());
    ...
    StopCoroutine(myCoroutine1); // 접근만 된다면 다른 클래스에서도 사용 가능하다.
}

스크립트 내 코루틴 모두 멈추기

StopAllCoroutine(); // 스크립트 내 코루틴 모두 멈추기

주요 사용 용도

• 주로 일시적인 효과 처리나 시간차 호출이 필요할 경우에 사용한다.

• Update보다 보다도 유연한 시간 처리가 가능하다 (다양한 제어점 반환 옵션이 존재하기 때문)

  아이템의 지속 시간 처리

   public void StartSpeedUP() // 외부 접근용 메서드
   {
           // 지속된 효과가 없다면 효과를 시작하고, 존재한다면 계속 쌓아준다.
       if (speedUPDuration <= 0) { StartCoroutine(SpeedUP()); }
       else { speedUPDuration += 10; }
   }
  >
   IEnumerator SpeedUP() // 스피드 코루틴
   {
       speedUPDuration += 10;     // 초기 지속 시간 갱신
       speedUP = 2f;            // 속도 배수
       while (speedUPDuration > 0) // 시간이 0보다 작아질 때까지 계속
       {
           yield return new WaitForSeconds(1f); // 1초 대기
           speedUPDuration -= 1; // 1초 감소
       }
       speedUP = 1f; // 지속 시간이 끝나면 원래대로
   }

  

다양한 아이템을 시간 차를 다르게해서 생성하기

    void Start()
    {
        StartCoroutine(SpawnFood());
        StartCoroutine(SpawnAvoidFood());
        StartCoroutine(SpawnPowerUPs());
    }
>
    IEnumerator SpawnFood()
    {
        while (true)
        {
            yield return new WaitForSeconds(foodSpawnSpeed);
            Instantiate(food);
        }
    }
>
    IEnumerator SpawnAvoidFood()
    {
        while (true)
        {
            yield return new WaitForSeconds(AvoidfoodSpawnSpeed);
            Instantiate(avoidFood);
        }
    }
>
    IEnumerator SpawnPowerUPs()
    {
        while (true)
        {
            yield return new WaitForSeconds(PowerUPSpawnSpeed);
            Instantiate(powerUP);
        }
    }

참고 자료

• 유니티 Docs

  베르의 게임 개발 유튜브

• 코루틴 다루기 (1) - 코루틴 기초 | 유니티

• 코루틴 다루기 (2) - 코루틴 중단하기 + 코루틴 매개변수 + yield break | 유니티

  케이디

• 유니티로 배우는 C# 강좌 Part 完 - 코루틴

  KKIMSSI

• [Unity] yield return 종류

작성하면서 느낀점

왠지 이 코루틴을 굉장히 많이 사용하게 될 것 같다는 느낌이 든다;

오늘 한 일

• 챌린지반 과제 풀이
• 팀 프로젝트 진행하기 ( 볼륨 슬라이더 구현, 더블탭 대쉬 구현 )
• Input System에 대해서 자세히 파고 들기

오늘은 입력의 처리를 받는 Input System에 대해서 알아보자.

UnityEngine.InputSystem

기초 설명

유니티에서 기존 Input Manager의 단점을 해소하고 확장성 있게 개량한 입력 처리 기능이다.

장점

• Cross-Platform Compatibility New Input System은 다양한 플랫폼과 입력 장치에 대해 일관된 방식으로 작동합니다.
• Rebinding 플레이어가 게임 내에서 자신의 입력 설정을 변경할 수 있도록 지원합니다.
• Multiplayer Support 여러 플레이어가 동일한 장치에서 게임을 플레이하거나, 각각의 장치에서 게임을 플레이할 때 입력을 쉽게 처리할수 있습니다.

사용 방법

1. Input System 설치

• 설치 후 프로젝트를 재시작해줘야한다.

2. Input Action Asset 추가

• 
• 생성하고자 하는 곳에 오른쪽 클릭 후 Create -> Input Actions를눌러 추가한다.

3. Input Action 창 설정

3-1. Control Shceme

• 각종 입력 장치에 대한 종류를 구분하는 것으로 추가해두면 Action을 설정에서 사용한다.
• 필수적인 과정은 아니지만, 혹시나 컨트롤러에 대한 구분이 필요할 경우에는 해두는 것이 좋다
• 해당 컨트롤러 스킴을 설정해두면 Player Input에서 설정해줄 수 있다.
  • Any로 설정해두면 컨트롤 스킴 상관없이 처리한다는 의미이다. 혹여나 다양한 컨트롤러를 지원하고 싶다면 Any로 설정해두고 Auto-Switch를 켜두는 게 좋다.

3-2. Action Map

• 특정 개체(Player 등)나 기능(UI)단위로 구별해둔 Action 리스트로 주로 관련된 것끼리 묶어줘서 컴포넌트에 전달할 때 사용된다.
  • 아래 이미지를 보면 +를 통해서 Map을 추가해줄 수 있다.
  • 
• InputAction 컴포넌트로 가보면 구별해놓은 Action Map 설정들을 고를 수 있다.
  • 
  • 여기서 None으로 설정해버리면 아무 액션도 받지 않겠다는 의미이다; (근데 유니티에서 필요한 것을 알아서 찾아가는 것 같다.) //굳이 None으로 설정해두지는 말자

3-3. Action

• 특정 행동의 입력 처리를 설정하는 걸로 주로 처리받을 값과 입력 처리를 관리하는 곳이다.
  • Move를 선택한 상태로 오른쪽을 보면 ActionType과 Control Type을 설정할 수 있다.

    Action Type

    입력에 따른 이벤트 트리거를 설정하는 곳으로 기능의 요구 사항에 맞게 설정해주면 좋다.
  • ** Value ** - 기본적인 액션 타입으로 컨트롤의 상태가 지속적으로 변하는 모든 입력에 대해서는 이를 사용한다.
  • ** Button ** - 주로 누를 때마다 한번씩 액션을 트리거하는 입력에 사용하는 것이 좋습니다.
  • ** Pass-Through ** - 바인딩된 모든 컨트롤의 변경 사항이 해당 컨트롤의 값을 가진 콜백을 트리거합니다. 이는 컨트롤 세트로부터 모든 입력을 처리하려는 경우에 유용합니다.

    Control Type

    트리거한 이벤트에 전달할 매개변수 종류를 지정하는 곳이다.
• 아래 이미지가 해당하는 매개변수들의 종류이다.

3-4. Binding

• 해당 액션에게 키입력을 넣어주는 과정이다.
• 3-4-1. 해당 액션에 오른쪽 클릭을 눌러 추가하거나, +를 통해 추가해줄 수 있다.
  • Value Any가 아니고서야는 오른쪽 클릭으로 추가해주는 게 편할 것이다.
• 3-4-2. 해당 Binding을 눌러서 Path에서 키를 추가해주면 된다.
  • 왼쪽에 매우 작은 상단바를 눌러주면 입력을 감지해주는데 넣고 싶은 키를 입력하면 감지해줘서 선택 가능할 수 있다.

4. Player Input 컴포넌트

• Add Component에서 Player Input를 찾아 추가해주자
  • 
• Player Input에 만들어두었던 Input Action Asset을 넣어주자
  • 

Behavior 설정

• 주로 메시지의 범위나 메시지를 전달하는 방식을 정해주는 곳이다.

• InputValue value

  • Send Messages : 동일한 게임 오브젝트의 컴포넌트에 메시지를 날린다.
  • BroadCast Messages : 같은 게임 오브젝트와 그 자식 게임 오브젝트의 컴포넌트에 메시지를 날린다. (성능 문제 때문에 추천하지 않는다)

• InputAction.CallbackContext context (더 자세한 이벤트 처리 가능)

  • Invoke Unity Event : OnClick처럼 Unity Event형태로 관리된다. (매우 편리하다)
    • 
  • Invoke C Sharp Events : PlayerInput.OnActionTriggered에 호출하고 싶은 이벤트 등록해서 어떤 이벤트인지 확인해서 쓸 수 있다.

5. 스크립트에서 이벤트 처리하기

• 요구되는 네임스페이스

  using UnityEngine.InputSystem

  SendMessages 또는 BroadCast Messages일 경우

• 아래 이미지에 적힌 함수를 적어서 호출해줘야한다.

  private void OnMove(InputValue value) // 접근 제한자 제한이 없다.
  {
    Vector2 direction = value.Get<Vector2>();    // 값을 가지고 올 때는 .Get<>();을 활용한다.
    CallMoveEvent(direction);
  }
  >
  // Value Any일 경우에는 (주로 bool값 매개변수 전달에 사용된다.)
  value.isPressed;    // interaction이 없는 상태에서 키를 눌렀을 때 true 뗐을 때false를 반환한다.

Invoke Unity Event일 경우

• Events/ActionMap을 열어 거기에 해당하는 메서드를 추가해줘야한다.

  public void OnDash(InputAction.CallbackContext context) // 사용을 위해서는 반드시 public 이상이어야 한다.
  {
    if (context.started)    { // 입력 시작 시 (주로 키입력이 시작됐을 때 발동) }
    if (context.performed)    { // 조건 충족 시 (인터랙션의 조건이 충족되었을 경우) }
    if (context.canceled)    { // 조건 미충족 시 또는 취소 시 (조건 충족 후 키를 떼거나 조건이 충족되지 못했을 시) }
  } // 위와 같은 자세한 설정이 가능한데 해당 조건에 따라서 필요한 기능을 넣어주면 된다.

  Invoke C Sharp Events는 사용한 적이 없기에 넘어간다..

Interaction

키에 추가적인 조건을 걸어줘서 키를 누르고 일정 시간이 충족되고 나서 떼야 호출되는 경우나 연속으로 키를 눌러야 호출되는 등의 다양한 조건들을 걸어줄 수 있다.

• 

  공통된 설정

• Press Point - 이벤트가 호출되기 위한 임계값으로 사실 키보드 같은 경우에는 키 입력이 들어오기만 하면 1로 판정이 되서(하나만 누르든 동시에 누르든 간에) 키보드에서 쓰이기보다는 조이스틱이나 게임 패드에 주로 사용된다.

  Hold | 꾸욱 눌러줘야 호출하는 상호작용

• Hold Time : 첫 활성화부터 얼마 이상의 활성화를 유지해야 호출되는 지를 설정한다.

  Multi Tap | 여러번 눌러줘야 호출하는 상호작용

• Tap Count : 몇 번까지 눌러줘야 호출되는 지를 설정

• Max Tap Spacing : 키 입력이 시작되고 나서 비활성화 상태에서의 허용 시간

• Max Tap Duration : 활성화 상태에서의 키 유지를 허락하는 시간 (넘어가면 취소된다.)

  Press | 눌렀을 때, 뗐을 때 호출할 지의 상호작용

• Press Only : 눌렀을 때 호출

• Release Only : 뗐을 때 호출

• Press & Release : Press + Release를 합친 것이다.

  Slow Tap

• Min Tap Duration : 키를 누르고 최소 유지 시간 이후 뗐을 때 호출되는 시간을 정한다.

  Tap

• Max Tap Duration : 키를 누르고 최대 유지 시간 이전에 뗐을 때 호출되는 시간을 정한다.

각종 상호작용에 대한 실험 정리

참고 자료

• [유니티 TIPS] 다양한 입력 장치를 손쉽게 지원하는 Input System 패키지 공략

• docs.unity3d.com/Input Action Assets

작성하면서 느낀점

사실 오늘 작성하는 것보다 Input Action을 활용한 더블탭 대쉬를 넣으려고 하다가 MultiTap의 performed 조건이 Tap Count 충족에서 눌렀을 때가 아닌 누르고 뗐을 때라는 점에서 많이 난감했지만, 오히려 왜 굳이 InputAction에 의존해야하는 생각을 해서 코드로 하면 좀 더 쉽고 간단히 짤 수 있을 거라는 생각을 하게 되었다. 그래서 InputAction을 활용하지 않고 스크립트 내에서 그대로 처리했더니 도리어 InputAction을 활용했던 것보다 코드가 좀 더 간결해지고 빈틈 없이 작성할 수 있게 되었다. 이런 점을 생각해보면 이러한 기능들 이전에 결국 코드를 설계하고 짜는 그러한 기본 바탕들이 제일 중요하다는 걸 알게 되었다.

오늘 한 일

• 챌린지반 과제 진행
• 팀 프로젝트 계획 수립 및 진행
• 객체 지향 특강 듣기
• 기초적인 오브젝트 추적 구현해보기

오늘은 적들이 플레이어를 찾고 추적하는 방법의 기초적인 구현을 해보려고 한다.

오브젝트 추적

적이 플레이어 오브젝트를 찾아서 쫓아가기까지 필요한 과정

1. 플레이어 오브젝트를 식별한다

• 적 오브젝트는 플레이어를 감지하는 기능 또는 플레이어의 정보를 어디선가 받아와야 된다.

2. 자신과 플레이어 오브젝트까지의 방향을 구한다.

• 플레이어 Transform이 요구되고, normalized를 하여 단위 벡터를 구한다.

3. 구한 방향을 향해서 플레이어를 쫓아간다.

• FixedUpdate를 활용해서 전 과정에서 구한 단위 벡터값을 이용해 플레이어의 방향으로 이동한다.

플레이어의 위치를 항상 가진 상태의 추적

플레이어의 Transform을 명확하게 아는 상태에서의 추적을 구현해보자

• Player의 오브젝트를 싱글턴화할 수는 없으니 싱글턴된 게임 매니저를 이용해야한다. (스파르타 코딩클럽 스크립트를 참고해서 만들었습니다)

1. 플레이어 오브젝트 정보 받아오기

public static GameManager Instance;
{
    public Transform Player { get; private set; }    // 플레이어의 위치 참조
    [SerializeField] private string playerTag = "Player"; // 플레이어 태그
>
    private void Awake()
    {
        Instance = this;
        Player = GameObject.FindGameObjectWithTag(playerTag).transform; // 태그를 통해 플레이어 오브젝트를 찾는다.
    }
}
>
// Enemy.cs
  private Transform Target { get; private set; } // 플레이어 트랜스폼 참조할 변수
>
  private void Start()
  {
      Target = GameManager.Instance.Player; // 게임 매니저에 있는 플레이어 트랜스폼을 받아온다
  }

• 게임 매니저로부터 플레이어의 Transform을 받아온다

2. 플레이어 오브젝트 쪽 방향 구하기

private void FixedUpdate()
{
    direction = DirectionToTarget(); // FixedUpdate로 실시간으로 플레이어의 위치를 계산한다.
    ...
}
>
private Vector2 DirectionToTarget()
{
    return (Target.position - transform.position).normalized; // 플레이어까지의 단위 벡터를 구한다.
}

3. 구한 방향 쪽으로 이동하기

private void FixedUpdate()
{
    ...
    CallMoveEvent(direction); // CallMoveEvent 내에서 움직이는 메서드가 구현되어있습니다.
}

• 구한 단위 벡터를 이용해서 플레이어 쪽으로 향한다.

결과물

• 플레이어가 어디에 있든 항상 따라온다. (뱀서류에 어울리는 추적 방식)
• 추가 구현 사항을 해주면 플레이어의 방향에 따라서 스프라이트를 뒤집거나 일정 거리 이상은 안 따라가게 하는 등의 기능을 넣을 수 있다.

Collider를 이용한 플레이어 추적

적 오브젝트가 고유의 Collider를 이용해 플레이어를 추격하는 로직을 구현해보자

• 
• 오브젝트 자체가 탐지 기능을 가지고 있기에 타 오브젝트의 의존도가 낮은 편이다. (사실 식별 말고는 2번째는 차이가 없으니 식별과 이동에만 집중해보자)

플레이어 식별

public class ColliderVision : TopDownController
{
    [SerializeField] private string targetTag = "Player";    // 
    private GameObject FindTarget;    // 찾은 적 오브젝트 정보를 담는다.
>
    [SerializeField] private Collider2D colliderVision; // 자식이 가지고 있는 Collider를 가져온다.
>
      private void OnTriggerEnter2D(Collider2D collision) // 특정 오브젝트가 Collider에서 진입할 때 호출
    {
        if (collision.CompareTag(targetTag))    // 태그 확인
        {
            ... (추후에 작성) ...
            FindTarget = collision.gameObject;    
        }
    }
>
    private void OnTriggerExit2D(Collider2D collision)    // 특정 오브젝트가 Collider에서 나갔을 때 호출
    {
        if (collision.CompareTag(targetTag))    // 태그 확인
        {
            ... (추후에 작성) ...
        }
  }

• Collider 설정

  
• Collider를 이와 같이 설정하였다.

플레이어 추적

private Vector2 targetDirection;    // 타겟 방향 (계산은 전 방법과 동일하니 생략)
>
private bool isTargetFind = false;    // 타겟 식별 유무
private Vector2 stopMove;            // 정지를 위한 벡터
>
[SerializeField] private Transform colliderTransform;    // 충돌체 Transform
>
void Start()
{
    stopMove = Vector2.zero; // 0 벡터 할당
}
>
private void FixedUpdate()    // 물리 처리 업데이트
{
    if (!isTargetFind)     // 타겟을 찾지 못했을 경우
    { 
        return; 
    }
        targetDirection = DirectionToTarget();    // 타겟 목표 방향 최신화
        CallMoveEvent(targetDirection);        // 이동 이벤트 호출
        ChangeRotation(targetDirection);    // 충돌체 방향 돌리기
}
>
private void OnTriggerEnter2D(Collider2D collision)    // 충돌체 진입 시
{
    if (collision.CompareTag(targetTag))    // 태그 확인
    {
        isTargetFind = true;    // 타겟 식별 true
        FindTarget = collision.gameObject;    // 충돌체에 진입한 오브젝트를 할당한다
    }
}
>
 private void OnTriggerExit2D(Collider2D collision)    // 충돌체 이탈 시
 {
     if (collision.CompareTag(targetTag))    // 태그 확인
     {
         isTargetFind = false;    // 타겟 식별 false
         targetDirection = Vector2.zero;    // 0벡터 할당
         CallMoveEvent(stopMove);    // 이동 이벤트 멈추기
     }
 }

구현 결과

• 
• 콜라이더에 플레이어가 진입하게 되면 적이 추적을 하기 시작한다.
• 플레이어의 위치를 최대한 놓치지 않기 위해서 콜라이더도 플레이어의 방향에 따라 움직이게 만들었다.

  + 추가 구현 (탐색 기능, 스프라이트 뒤집기)

• 
• 추가 구현을 통해 적 오브젝트에게 매우 간단한 탐색 기능을 만들어서 주변을 탐색하게 만들어봤다.

상시 추적법과 Collider 추적법의 장단점

상시 추적법

• 장점

  • 매우 빠르고 간단하게 구현할 수 있다.
  • 참조를 통해 플레이어의 정보를 가져오기 때문에 메모리가 덜 든다.

• 단점

  • 플레이어 정보를 주는 오브젝트에게 의존해야한다.
  • 추적 방식의 확장성이 떨어진다.
  • 플레이어 중간에 가려지는 오브젝트가 있을 경우의 식별 처리가 힘들다

    Collider 추적법

• 장점

  • 탐색과 추적 방식의 확장성이 높다.
  • 타 오브젝트에게 의존하지 않아도 된다.

• 단점

  • 오브젝트가 많을 경우 그만큼 연산량이 많아진다.
  • 플레이어 중간에 가려지는 오브젝트가 있을 경우의 식별 처리가 힘들다.

그 외에 알게된 점

FixedUpdate와 이벤트

FixedUpdate에서 이벤트에게 한번이라도 direction을 전달할 경우 그 이벤트는 direction 값이 변경되거나 다른 명령으로 인해 중지될 때까지 계속 활성화된다.

버그 리포트)

private void OnTriggerExit2D(Collider2D collision)
{
    if (collision.CompareTag(targetTag))
    {
        isTargetFind = false;
        targetDirection = Vector2.zero;
        // CallMoveEvent(stopMove); <- 이를 제거할 경우
    }
}

• 플레이어를 놓쳤음에도 플레이어를 식별했던 마지막 방향으로 떠나버린다.

Transform.rotation와 Transform.eulerAngles의 반환값

• Transform.rotation는 쿼터니언으로 사실상 우리가 해석할 수 없는 값을 반환하고
• Transform.eulerAngle는 0~360도 값을 반환해준다. (atant2 * Rad2Deg와 유니티에 보이는 rotation이랑 전혀 다른 값을 반환하니 주의하자)

사용한 에셋

• 고양이 캐릭터 Cute Legends Cat Heroes
• 타일 Sprout Lands - Asset Pack

작성하면서 느낀점

내가 만들고 싶은 게임을 구현하기 위해서 더 많은 기능 구현 방법에 대해서 알고 싶어졌다. 내가 아는 선 안에서는 최대한의 기능 구현이 가능한 상태이지만, 아직까지도 모르는 것이 많다고 느껴졌다. 좀 더 많은 학습을 통해서 게임 내의 모든 로직을 구현해 구동이 가능한 나만의 게임을 출시해보고 싶다.

오늘 한 일

• 챌린지반 과제 진행
• 개인 프로젝트 진행 후 제출
• 오브젝트 풀링 파헤치기

오늘은 게임 개발에 널리 사용되는 테크닉 중 하나인 오브젝트 풀링에 대해서 알아보자

오브젝트 풀링

개념

필요한 객체를 미리 생성해두고 사용이 필요할 때 pool에서 꺼내고, 사용이 끝나면 다시 pool에 반납하는 방식의 테크닉이다.

방법

1. 객체를 미리 생성해두는 방식
2. 미리 안 만들어놓고 필요한 상황이 왔을 때 만드는 방식

• _ 둘다 혼합해서 사용하는 경우도 있으니 요구 사항에 맞게 만들면 된다._

오브젝트 풀링을 사용하는 이유

1. 메모리 할당과 가비지 컬렉팅으로 인한 프레임 드랍 최소화

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

• Destroy 함수로 게임 오브젝트를 파괴한다고 선언하면 곧바로 메모리에서 사라지는 것이아니라 가비지 콜렉터가 수거해서 파괴하기 전까지는 메모리에 남아있다. (쌓여있는 가비지가 많으면 많을수록 수거 파괴에 더 많은 시간이 걸린다.)

2. 메모리 단편화

• 메모리를 제거하는 과정에서 빈 공간이 생기는데, 만약에 새로 할당될 메모리 크기가 빈 메모리 공간보다 크다면 해당 메모리 공간을 사용하지 못하고, 들어갈 수 있는 메모리 공간이 있는지 다시 탐색한다. 설령 흩어져있는 빈 메모리 공간들의 크기가 해당 메모리보다 크더라도 각자의 빈 메모리 공간이 부족하다면 말이다. 이것을 외부 메모리 단편화라고 부른다.
• 외부 메모리 단편화의 문제점은 앞서 말했듯이 메모리 공간이 충분함에도 불구하고 메모리를 할당하지 못하는 현상이다. 유니티의 가비지 컬렉터는 이러한 메모리 외부 단편화를 해결해주지 못한다. (*****Compaction 기능을 지원하지 않는다!)

  *해당 문서 내용 중에서 -> 'The garbage collector is also non-compacting, which means that Unity doesn’t redistribute any objects in memory to close the gaps between objects'

  -> "유니티의 가비지 컬렉터는 비압축 방식으로 메모리 상의 객체들 사이의 공간을 메우기 위해 객체들을 재배치하지 않습니다."

  외부 메모리 단편화 예시

• *[1] 메모리2를 가비지 콜렉터가 수거해 파괴했다.**

[2] 메모리4를 할당하려하지만 해당 빈 메모리 공간의 크기가 부족해 할당을 할 수가 없다.

**[3] 메모리4는 자기가 들어갈 수 있는 공간을 찾아서 할당한다. **

[4] 이 과정이 지속되면 메모리 공간이 충분함에도 불구하고 할당하지 못하는 상황이 발생한다.

그래서 위와 같은 이유로 인해 오브젝트 풀링을 사용해야하는 이유이다.

Object Pool의 2가지 구현 방법

클래스로 생성하기

UML 간략화

• 해당 스크립트는 스파르타 코딩클럽에서 사용한 오브젝트 풀링 스크립트를 필수적인 부분만 남겨서 만든 스크립트입니다.

1. 오브젝트 생성 및 보관

ObjectPool 클래스는 오브젝트를 초기 생성 후 타 클래스에게 오브젝트를 넘겨주는 역할을 해준다.

코드 예시)

public class ObjectPool : MonoBehaviour
{
    public GameObject prefab;     // 투사체 정보 보관 
    public int size;             // 초기 생성 갯수
>
    public Queue<GameObject> objectPool;    // 오브젝트를 보관할 큐
>
    void Awake()
    {
        objectPool = new Queue<GameObject>();        // 큐 초기화
        for (int i = 0; i < size; i++)    // 정해진 갯수만큼 반복
        {
            GameObject obj = Instantiate(prefab);    // 오브젝트 생성
            obj.SetActive(false);                    // 비활성화
            objectPool.Enqueue(obj);                // 큐에 할당
        } // 해당 과정이 오브젝트를 생성하고 풀에 보관하는 과정이다.
    }

런타임

• 초기 갯수를 20으로 정해놓으면 프로젝트 실행 시 이와 같이 Prefab을 인스턴스화 해준다.

2. 오브젝트 전달

오브젝트가 필요하게 되면 ObjectPool이 TopDownShooting에게 오브젝트를 전달해주는 과정이다.

코드 예시)

// ObjectPool.cs
   public GameObject SpawnFromPool()
   {
       GameObject obj = objectPool.Dequeue();    // 큐에서 나온 걸 obj에 할당
       objectPool.Enqueue(obj);                    // obj를 다시 큐에 할당
       obj.SetActive(true);        // obj 활성화
       return obj;                // obj를 반환
   }
>   
// TopDownShooting.cs
    private TopDownController controller;    // 옵서버 관리 클래스
    private ObjectPool objectPool;            // 오브젝트 풀
    [SerializeField] private Transform projectileSpawnPosition; // 투사체 생성 위치
    private Vector2 aimDirection = Vector2.right;    // 마우스 위치 
>
    void Awake()
    {
        controller = GetComponent<TopDownController>();
        objectPool = GetComponent<ObjectPool>();
    }
>
  void Start()
  {
      controller.OnAttackEvent += OnShoot;    // 클릭할 시 호출되는 이벤트에 할당
      controller.OnLookEvent += OnAim;        // 마우스 위치를 전달해주는 이벤트에 할당
  }
  private void OnAim(Vector2 newAimDirection)
  { 
      aimDirection = newAimDirection.normalized;    // 받은 마우스 방향을 보관
  }
>
  private void OnShoot()
  { 
      CreateProjectile();    // 투사체 생성
  }
>
  private void CreateProjectile()    // 투사체를 가져오고 필요한 정보를 전달
  {
      GameObject obj = objectPool.SpawnFromPool();    // Pool로부터 obj 반환 받기
      ...
  }

런타임

• 마우스 클릭 이벤트로 인해 맨 위에 있는 오브젝트들부터 활성화되는 모습이다.

3. 오브젝트 사용 및 정보 전달

전달받은 오브젝트에 필요한 정보를 전해준다.

• 
• TopDownShooting.cs

• 
• ProjectileController.cs

코드 예시)

 // TopDownShooting.cs 
     private void CreateProjectile()
    {
        ...
        obj.transform.position = projectileSpawnPosition.position;    // 생성 위치 전달
        ProjectileController attackController = obj.GetComponent<ProjectileController>();    // obj로부터 스크립트 가져오기
        attackController.InitializeAttack(aimDirection); // 가져온 스크립트의 메서드를 실행
    }
>    
// ProjectileController.cs
    private Vector2 direction;    // 날라갈 방향
    private bool isReady;        // 생성 시간 동안 준비되지 않은 상태에서 움직이는 거 막는 용도
>
    private Rigidbody2D rigidbody;    // 위치 이동에 필요한 컴포넌트
>
    private void Start()
    {
        rigidbody = GetComponent<Rigidbody2D>();
    }
>
    private void Update()
    {
        if (!isReady) { return; }
        ...
        rigidbody.velocity = direction * 5;    // 해당 방향으로 이동
    }
>
    public void InitializeAttack(Vector2 direction)    // 호출된다면 초기 세팅 메서드
    {
        this.direction = direction;            // 전달받은 방향 할당
        transform.right = this.direction;    // 스프라이트의 렌더러 방향 정하는 용도
        ...
        isReady = true;    // 사용 준비 완료
    }

런타임

• 전달받은 정보대로 투사체가 잘 날라가는 모습이다.

  4. 사용이 끝나면 비활성화

  

  코드 예시)

  public class MyProjectileController : MonoBehaviour
  {
    private float currentDuration; // 생성 경과 시간
     ...
  >   
    private void Update()
    {
        ...
        currentDuration += Time.deltaTime;    // 생성 경과 시간 업데이트
        if (currentDuration > 2) { DestroyProjectile(); }    // 생성 경과 시간이 일정 이상 넘으면 파괴 메서드 호출
        ...
    }
  >    
    public void InitializeAttack(Vector2 direction)
    {
        currentDuration = 0;    // 생성 경과 시간 초기화
    }
  >
    private void DestroyProjectile() // 사용이 끝날 때 호출되는 메서드
    { gameObject.SetActive(false); }

  런타임

  
• 생성 후 일정 이상의 시간이 넘어가면 사라지는 모습이다.

구현 후 프로젝트 실행의 모습

UnityEngine.Pool 사용하기

using UnityEngine.Pool을 활용해서 오브젝트 풀링을 구현하는 방법이다.

• 참고 자료 -> 유니티 오브젝트 풀링 | 유니티 [UN-OP-1] 베르의 게임 개발 유튜브

UML 간략화

• 위 방식은 필요 시에 생성되고 재활용하는 방식을 채용했다.

nameSpace UnityEngine.Pool

• 해당 네임스페이스를 디컴파일해보면 위와 같은 형태로 되어있다. 메서드 내부는 생략했다
• 각각의 필드를 해석해주자면
• m_List* - 오브젝트 풀
• m_CreatFunc* - 생성 델리게이트
• m_ActionOnGet* - 사용 델리게이트
• m_ActionOnRelease* - 해제 델리게이트
• m_ActionOnDestroy* - 파괴 델리게이트
• m_MaxSize* - 최대 보관 갯수
• m_CollectionCheck* - 컬렉션 체크 활성 또는 비활성화 (리스트로 돌아올 때 겹치는 오브젝트가 있는지 확인하는 용도이다.)
• CountAll* - 총 오브젝트 갯수
• CountActive* - 활성화 중인 오브젝트 갯수
• CountInActive* - 비활성화 중인 오브젝트 갯수
• ++는 생성자에 해당하고 +는 메서드에 해당한다

오브젝트 풀 생성하기

• 
• 필수 요구 사항으로 생성 메서드만 줄 것 같아도 되지만, 그러면 말 그대로 생성만 되기 때문에 결국 원활한 사용을 위해서는 사용 메서드와 사용 해제 메서드까지는 있어야한다.

  코드 예시)

  public class Shooter : MonoBehaviour
  {
    [SerializeField] private GameObject _BulletPrefab; // 투사체 Prefab
  >
    private IObjectPool<Bullet> _Pool;    // 오브젝트 풀
  >
    private void Awake()
    {
        _Pool = new ObjectPool<Bullet>(CreateBullet, OnGetBullet, OnReleaseBullet, OnDestroyBullet, maxSize:50); // 오브젝트 풀을 생성하게 담기
    }
  >
    private Bullet CreateBullet()    // 투사체 생성
    {
        Bullet bullet = Instantiate(_BulletPrefab).GetComponent<Bullet>(); // 투사체 생성
        bullet.SetManagedPool(_Pool);    // 투사체에 해제 및 파괴 메서드 사용 때문에 필요하다. 
        return bullet;
    } // 미리 생성되는 건 아니고 필요할 시 생성하게 된다. (ObjectPool의 Get() 발동 시)
  >
    private void OnGetBullet(Bullet bullet) // 투사체 사용 
    {
        bullet.gameObject.SetActive(true);
    }
  >
    private void OnReleaseBullet(Bullet bullet) // 투사체 해제
    {
        bullet.gameObject.SetActive(false);
    }
  >
    private void OnDestroyBullet(Bullet bullet) // 투사체 파괴 
    {
        Destroy(bullet.gameObject);
    }
  }

• Shooter 클래스가 기능이 겹친 것처럼 보이지만 사실상 네임스페이스에 있는 ObjectPool 클래스를 가져와서 사용하는 것이라 메서드만 들고 있지 기능은 분리되어있다고 봐도 무방하다.

오브젝트 사용 및 정보 전달

코드)

// Shooter.cs
    [SerializeField] private Transform _PlayerPosition;
>
    private TopDownController controller;
>    
    void Start()
    {
        controller = GetComponentInParent<TopDownController>();
        controller.OnAttackEvent += ShootBullet; // 클릭 이벤트 할당
    }
>
    private void ShootBullet()
    {
        var direction = ((Vector2)transform.position - (Vector2)_PlayerPosition.position).normalized;
        var bullet = _Pool.Get(); // Pool에서 투사체를 가져온다. (없다면 생성해서 주고, 있다면 가진 오브젝트를 준다.)
        bullet.transform.position = transform.position; // 투사체 소환 지점 지정
        bullet.Shoot(direction); // 목표 방향을 전해준다.
    }
>
// Bullet.cs
    private Vector2 _Direction; // 방향
>
    [SerializeField]
    private float _Speed = 7f; // 속도
>
    void Update()
    {
        transform.Translate(_Direction * Time.deltaTime * _Speed); // 지정된 방향으로 이동
    }
>
    public void Shoot(Vector2 dir)
    {
        _Direction = dir; // 목표 방향을 할당 받는다.
         ...
    }

사용이 끝나면 비활성화

public class Bullet : MonoBehaviour
{
    private IObjectPool<Bullet> _ManagedPool;
     ...
 >   
    public void SetManagedPool(IObjectPool<Bullet> pool)
    {
        _ManagedPool = pool; // ObjectPool의 기능을 사용하기 위해 가져온다
    } 
>
    public void Shoot(Vector2 dir)
    {
        ...
        Invoke("DestroyBullet", 2f); // 2초 후에 총알 파괴메서드 호출
    }
>
    public void DestroyBullet()
    {
        _ManagedPool.Release(this);    // 현재 오브젝트에게 사용 해제 메서드를 호출한다.
    } // 지정한 Maxsize보다 많다면 해당 오브젝트는 파괴될 것이고, 적다면 리스트에 보관된다.
}

구현 후 프로젝트 실행의 모습

• 
• 필요한 만큼 생성하고, 사용되는 모습을 볼 수 있다.

• 
• maxSize보다 더 많은 오브젝트가 생성되었을 때 초과 생성된 오브젝트는 제거된다.

참고 자료

에셋

• 고양이 캐릭터 Cute Legends Cat Heroes
• 타일 Sprout Lands - Asset Pack

  Object Pool

• *베르의 게임 개발 유튜브 *

• 유니티 오브젝트 풀링 | 유니티 [UN-OP-1]

• 오브젝트 풀링 구현하기

• 글릭의 만들어가는 세상

• 오브젝트 풀링 - 유니티로 공부하는 게임 제작기술(Object Pooling)

  유니티 자료

• Incremental garbage collection

그 외에 알게된 점

버그 리포트

• 컴파일 오류가 생긴 상태에서 CreateAssetMenu를 사용하려 하면 적용이 안된다. (컴파일 오류를 해결하면 정상적으로 적용된다.)

투사체에게 의도되지 않은 물리적인 충격을 입고 싶지 않다면

• 투사체의 Collider에서 Layer Overrides에서 Force Send Layers를 Nothing으로 바꿔주면 된다.

작성하면서 느낀점

코드를 작성하고 실행시키면서 알게된 사실은 코드를 읽는 능력이 매우 중요하다는 사실을 알게되었다. 특히 지금 단계와 같이 아직 모르는 코드들이 너무 많을 때에는 더 중요하게 작용하는 것 같다. 다양한 코드들을 해석해보는 시간과 모르는 코드들을 PsuedoCode화 시켜보는 시간을 많이 들여야될 것 같다. 그리고 TIL을 좀 더 효율적으로 썼으면 한다. 아직까지 TIL 작성에 시간적 효율이 좋지 않은 것 같다.

오늘 한 일

• 알고리즘 문제 풀기 (Leetcode 2373 문제)
• 챌린지반 배정 및 과제 진행
• 개인 프로젝트 진행하기

오늘은 미리 설정해두면 타일 작업을 빠르게 해줄 수 있는 RuleTile에 대해 알아보자

RuleTile

RuleTile이란? 유니티 주소

타일에 규칙을 부여해 해당 타일이 배치된 3x3 범위의 주변 위치에 있는 타일의 존재 유무에 따라서 알맞은 타일을 정해진 규칙대로 설치하는 유니티의 타일 기능 중 하나이다.

타일 시트를 자르는 방법은 생략하겠다. 스프라이트 시트를 짜르는 걸 알고싶다면 이쪽으로.

RuleTile을 만들고 팔레트에 넣기

룰 타일 만들기

• 적당한 에셋 공간을 찾아서 우클릭을 누른 후 Create/2D/Tiles/Rule Tile을 눌러서 생성한다.

룰타일 오브젝트 팔레트에 넣기

• 룰타일 오브젝트를 집어서 팔레트 칸에 넣어준다.

• 
• 생성된 RuleTile을 누르면 이와 같은 정보 창이 뜰텐데 하나하나에 대해서 설명해주겠다.

룰 타일 Inspector 기본 정보

기본값 (스프라이트)

• 
• 기본값 스프라이트(타일)로 만약에 아래쪽에 넣게될 규칙 타일 리스트 중에서 그 어떤 것도 해당되지 않으면 해당 스프라이트가 들어가게된다.

  기본값 (GameObject, Collider)

• 
• 만약에 기본값 스프라이트가 들어갔을 시 같이 들어가는 게임오브젝트와 충돌체이다.

! Sprite와 Grid의 차이

• 
• 왼쪽이 Sprite Collider이고, 오른쪽이 Grid Collider이다. Sprite는 Sprite의 모양에 따라서 충돌체를 결정하고 Grid는 타일 한 칸의 충돌체 모양을 가진다.

Number of Tiling Rules

• 
• 이번 TIL에서 가장 중요한 요소로 룰 타일의 리스트를 나열하는 것이다.
• +와 -를 통해서 선택한 목록을 추가 제거할 수 있고,
• GameObject, Collider, Sprite는 규칙에 해당한다면 Sprite가 배치되고 가지게 되는 속성이다. (위 Default랑 하는 역할이 동일하다.)
• 우선 순위는 맨 위부터 시작하고 아래부터 깐다. 그러니까 동일한 조건의 타일이 있더라도 가장 위에 있는 타일부터 배치된다. (Default는 리스트에 아무런 조건도 부합되는 타일이 없다면 마지막으로 배치된다.)

룰타일 규칙 정하기

그렇다면 이제 타일 규칙 목록을 생성해서 규칙을 하나씩 넣어주자

타일 규칙 편집기

• 
• 타일 규칙 편집기로 기본적으로 위와 같이 되어있다.
• 아무 아이콘도 없다면 해당 칸이 깔려있던 말던 배치하라는 의미이다. (위 사진과 같은 상태가 Default와 동일한 상태이다.)
• 첫번째 클릭하면 초록색 화살표가 나오고 두번째 클릭하면 X자, 3번째 클릭은 다시 비어있는 상태가 된다.

해당 칸에 타일이 존재해야한다

• 
• 해당 아이콘은 해당 칸에 타일이 존재해야한다는 조건을 넣어주는 아이콘이다.
• 해당하는 칸에 타일이 없다면 배치되지 않는다.
• 주로 다른 타일이랑 붙어지는 부분에다가 아이콘을 넣는 편이다.

  아이콘 배치 예시)

• 

해당 칸이 비어야한다

• 
• 해당 아이콘은 해당 칸에 아무 타일도 있어서는 안되는 조건을 넣어주는 아이콘이다.
• 해당하는 칸에 타일이 있다면 배치되지 않는다.
• 주로 다른 타일이랑 붙어지지 않는 부분에다가 해당 아이콘을 넣어주는 편이다.

  아이콘 배치 예시)

• 

규칙 확장 옵션

중앙에 있는 아이콘이 달랐던 것을 볼 수 있는데 만약에 내가 타일 이미지가 별로 없거나 룰타일을 최소한으로 설정하고 싶다면 매우 유용한 설정이다.

Rotate

• 
• 타일 규칙을 90도, 180도, 270도로 돌렸을 때 부합하는 타일 배치가 있다면 배치해준다.
• 이게 놀라운 점은 그냥 배치하는 게 아니라 돌렸을 때 맞았던 방향대로 스프라이트도 돌아가서 맞춰준다.

  적용 예시)

  적용 전

• 

적용 후

• 

  이게 있다면 타일 하나로 4개의 타일을 충당할 수 있는 효율이 생긴다.

MirrorX와 MirrorY

• 
• 
• 상하(MirrorX) 또는 좌우(MirrorY)로 뒤집었을 경우에도 타일을 배치할 수 있도록 규칙을 확장해준다.

MirrorX+Y

• 
• 상하 좌우를 합친 버전이다.
• Rotate와 같다고 생각하겠지만 엄연히 다르니, 타일맵 제작에 필요한 규칙을 사용해주면 된다.

  예시) Rotate와 상하좌우의 차이

  Rotate

• 

상하좌우

위 확장 옵션을 잘 이용하기만 한다면 적은 양의 타일만으로도 타일맵을 빠르게 표현할 수 있다.

타일 3개만으로도 네모난 타일맵을 만들 수 있다.

OutPut 설정

마지막으로 Output설정에 대해서 알아보자

Single

• 단순하게 sprite 칸에 있는 스프라이트대로 나온다.

Random

• 맵 타일 중간중간에 무작위로 다양한 타일 배치를 깔아준다.

Noise : 시드값을 담당하는 기능이다.

Noise 사용하는 모습)

Shuffle : 타일의 배치를 돌리거나, 반대로 뒤집거나 하는 기능이다.

• 
• 무작위적으로 타일이 돌려져서 배치됨으로 이쁘게 안 나올 가능성이 크다.

Size : 타일 리스트에 해당한다. 원하는만큼 추가시켜서 다양한 타일이 나오게 하자.

• 
• size 크기만큼 스프라이트를 넣어줄 수 있다.

  주의점!

• 리스트에 빈 스프라이트를 방치한다면 구멍이 뚫린채로 나온다

Animation

• 타일의 애니메이션을 설정해준다.
• 기존 애니메이션 타일과 동일한 기능을 가진다.

단일 애니메이션 타일과 룰타일 애니메이션 타일

• 
• 윗쪽이 단일 애니메이션 타일, 아래쪽이 룰타일 애니메이션 타일이다.

참고 자료

RuleTile

• Tilemap (2) - 룰 타일로 타일맵 자동 연결하기 - 베르의 프로그래밍 노트

  에셋

• 타일 Sprout Lands - Asset Pack

개인 프로젝트를 진행하면서 알게된 점

Resources.Load() 사용 시 주의점

Resources.Load 사용 시 Resources 파일을 만들어둬야한다! (사용 시 Assets/Resources 이후의 파일과 폴더만 탐지한다)

GameObject.name을 유의하자!

해당 프로퍼티는 오브젝트의 이름을 붙이는데 사용되는 프로퍼티이다. 혹여나 무언가에 이름을 붙일 일이 생긴다면 해당 프로퍼티명을 피하고 짓자

UI에서 사용하는 RectTransform과 월드 좌표에서 사용하는 Transform의 차이

UI에서 위치로는 anchoredPosition, 크기로는 sizeDelta를 사용한다

씬을 비교하는 방법

SceneManager.GetActiveScene().name == "해당 씬 네임" 해당 코드를 사용하면 현재 활성화된 씬이 해당 씬 네임과 동일한 지 비교할 수 있다.

GetComponentInChildren<>()를 사용할 경우

사실 자기 자신의 컴포넌트부터 확인한 다음에 없을 경우에 자식의 맨 윗순번부터 컴포넌트를 확인하는 과정을 거친다.

DateTime.Now

현재 시각을 알아내는 메서드이다. ToString()을 할 때 다양한 옵션이 존재한다.

오늘 느낀점

오늘 챌린지 과제를 진행하면서 확실하게 정리해두지 않은 내용들은 어떻게 해결할 지 감이 안 잡힌다. 일을 처리하는 순서는 보이지만, 이 일들을 어떻게 처리할 지 모르니 게임에서 필수적인 요소들을 배워둬야할 필요성을 느꼈다.

오늘 한 일

• 알고리즘 문제 풀기 (LeetCode 786 문제)
• 스파르타 강의 진도 나가기 완료!
• 개인 프로젝트 진행하기

일단 모르는 내용은 살짝 미뤄둬고 당장 해야할 프로젝트를 진행하면서 캐릭터가 바라보는 방향을 다르게 해보는 코드를 짜보려한다.

캐릭터 방향 전환하기

목표

이번에 이 친구가 마우스를 따라 상하좌우를 바라보게 하고, 움직이는 모습도 그에 맞춰서 코드를 짜볼 생각이다.

해당 에셋을 다운 받을 수 있는 곳(itch.io)

스프라이트 시트를 가용 가능한 이미지로 바꾸는 방법

스프라이트 시트

• 해당 에셋 캐릭터 이미지를 보면 이와 같이 되어있을 것이다.
• 
• 사용하기 전에 전처리 과정을 해보도록 하자!

Import Settings

• 
• 해당 스프라이트 시트를 가지고 와서 누르면 Inspector에서 이와 같은 설정이 나올텐데 여기서 Sprite Mode를 Multiple로 바꾸고, Filter Mode를 Point로 해주자 _ 필터 모드를 바꾸지 않으면 이미지가 흐릿하게 보인다._

Sprite Editor

• 그 다음에 Sprite Editor로 들어가면 이와 같은 창이 나오게 될텐데

• Slice에서 아래와 같은 설정을 만진 후 이미지들이 격자 무늬 안에 잘 들어가는지 확인하고 Slice를 해주자
• Type* : Grid By Cell Sice && Pixel : Size 16, 16
• Slice를 완료하면 이와 같이나온다.

• 자르기를 완료한 후에는 오른쪽 아래창에 작업하기 편한 이름을 붙여주고, Position값을 맞춰가면서 캐릭터의 스프라이트가 어긋나지 않도록 설정해주자.

• 상단바 오른쪽 부분의 Apply를 눌러주면 작업한 것이 Asset에 반영된다!
• 작업이 완료된 스프라이트 시트의 모습

! 주의할 점

• Apply는 작업의 Save와 같은 역할을 해주니까. Apply를 누르는 것을 잊지 말자
• 반드시 이미지 사용 이전에 (렌더러에 붙이기, Animation Clip 활용) 이 작업을 완료하자

마우스의 방향 구하기

1. 벡터 계산하기

   마우스의 위치를 월드 좌표로 변환 후 캐릭터에서부터 마우스 좌표까지의 벡터를 구한다.

• 

  주요 코드

  Vector2 newAim = value.Get<Vector2>();
  Vector2 worldPos = camera.ScreenToWorldPoint(newAim);
  newAim = (worldPos - (Vector2)transform.position).normalized;

왜 벡터의 값을 구할 때 왜 순서가 중요한 건가요?

설명해주자면 좌표 간의 거리만 구한다면 '스칼라'라고 하고, 그 스칼라에서 방향을 추가한다면 '벡터'라고 한다. (그 좌표 간의 거리를 크기라고 부릅니다) 벡터는 단순 거리 뿐만 아닌 '방향'이라는 요소도 존재하기 때문에 A에서 B의 벡터와 B에서 A의 벡터는 전혀 다른 것이다. 이해가 안된다면 아래의 설명을 보며 들어가보자

사진을 예시로 들어 계산

• 
• 캐릭터 좌표는 (0, 0) 마우스 좌표는 (2, 2)라고 치자.
• 사진처럼 캐릭터 좌표에서 마우스 좌표까지의 벡터가 존재하는데 사실 단순하게 생각만 해봐도 캐릭터 좌표에 얼마를 더하면 마우스 좌표가 되는지를 생각해보면 되는 것이다. 그래서 마우스 좌표에서 캐릭터 좌표를 뺀다면 "(2, 2) - (0, 0) = (2, 2)"가 나오고 이를 캐릭터 좌표에 대입해주면 마우스 좌표가 나오는 것이다. 그러니까 정확히 말해주자면 벡터는 좌표 간의 거리를 구한다기 보다는 해당 좌표에서 '이러한 값'을 더한다면 이 좌표는 이쪽으로 이동한다라는 것인데, 그 '이러한 값'이라는 게 바로 벡터이다. (위치값을 말하는 게 아니라 위치를 이동시키는 값이다.)
• 그래서 방향을 인지 못하고 잘못 계산해서 (0, 0) - (2, 2)로 계산해버린다면 그 벡터는 캐릭터 좌표에서 마우스 좌표의 벡터가 아니라 그 반대 방향의 벡터가 되어버린다. 캐릭터 좌표에서 -(2, 2)를 더한다면 아래처럼 되어버린다.
• 

  + 추가적으로 그러한 벡터를 normalized해버리면 단위벡터가 된다. (크기가 1인 벡터를 단위 벡터라 부름)

• ** 주로 벡터의 방향만을 구하고자 할 때 normalized를 해주는 편이다.**

  이해에 도움된 동영상

2. 아크 탄젠트로 각(Degree) 구하기

   아직 컴퓨터를 위한 각도를 구한 것은 아니니 아크탄젠트를 활용해 각도를 구해주자

   주요 코드

   float rotZ = Mathf.Atan2(direction.y, direction.x) * Mathf.Rad2Deg;

   아크탄젠트는 탄젠트의 역함수로 높이(y)/밑변(x)을 통해서 얻은 탄젠트 값을 각도로 산출해내는 역삼각함수이다. (직접 계산해볼 생각은 하지마라; 탄젠트 1값으로 산출되는 45도 말고는 다른 각도들을 구하는 건 수포자에겐 힘든 계산이다;)
   • Mathf.Atan2는 라디안을 반환하므로 Mathf.Rad2Deg를 통해 각도로 환산해줘야한다.
   • 

3. 마우스를 직접 움직여서 각도의 위치 구하기

그럼 이제 직접 마우스를 움직이면서 어디에 위치하냐에 따라서 각도가 반환되는지 알아보자!

구분시키고 싶은 범위

• 
• 위 사진과 같이 대각선으로 구분지어 4가지의 범위로 구분하여 지정하고자 한다.

구하는 과정

• 
• 테스트의 원활함을 위해 가로 세로 표시선 및 대각선으로 선을 긋고 UI Text에서 각의 값을 나오게 해보았다. 삼각형은 마우스 역할을 해주는 친구이다.

• 우쪽
• 

• 우측 상단
• 

• 좌측
• 

• 하단
• 
• 테스트 GIF
• 

위 사진을 보면 알게되는 사실이 캐릭터가 좌표평면의 0, 0에 해당하고 마우스의 좌표까지의 벡터로 역삼각함수를 산출해내는 것을 알 수 있다.

위 결과로 알아내게 된 마우스의 위치에 따라서 나오는 각도값

! 이제 위 값들을 이용해 조건들을 세우고 애니메이션을 전환시켜보자!

조건에 따라서 애니메이션 전환해보기

조건문을 세우고 애니메이터를 만져보자

1. 애니메이터 조건 설정

매개변수를 int로 지정해준 다음, 아래와 같이 애니메이션 흐름을 짜고 조건을 자기의 번호에 해당하면 변환하게 해주자.

• 
• 
• direction : 0 = 뒤쪽 ||| 1 = 앞쪽 ||| 2 = 왼쪽 ||| 3 = 오른쪽이다.

2. 조준 스크립트에 애니메이션 조건문 만들기

if (rotZ < 135 && rotZ > 45)
{
    animator.SetInteger("direction", 0);
}
else if (rotZ < -45 && rotZ > -135)
{
    animator.SetInteger("direction", 1);
}
else if (Mathf.Abs(rotZ) > 135)
{
    animator.SetInteger("direction", 2);
}
else if (rotZ < 45 && rotZ > -45)
{
    animator.SetInteger("direction", 3);
}

결과

• 
• 의도된 대로 잘 돌아간다.

뛰는 모션도 넣어보자

방향에 따라서 뛰는 애니메이션도 달리해보자

1. 애니메이터 조건 설정

• 달리는 애니메이션은 보는 방향 뿐만 아니라 추가적인 조건이 존재함으로 그 점을 잘 신경써줘야한다.
• 각각의 바라보는 방향에다가 일치하는 달리기들을 붙여준다.
• 달릴 때는 달리는 애니메이션을 설정해주고
• 
• 
• 달리기가 풀릴 때는 두 개의 Transitions를 붙여서 각각 조건을 바라보는 방향이 달라지거나, 움직이지 않을 때로 설정한다.

! Transition를 하나로 해서 조건을 2개 붙이면 어떻게 되나요?

• Transitions 하나에 조건을 2개 붙이게 된다면 그것은 if 조건문에서 &&에 해당하는 조건이다. 만약에 조건을 합쳐서 붙인다면 바라보는 방향대로 움직이고 있다가 멈추면 계속해서 달리기 애니메이션이 실행되게 되는 것이다. 그래서 Transition을 2개 나눠서 각각의 조건을 붙이면 if 조건문의 ||에 해당하게 되므로 달리기를 멈추거나 방향을 바꾸면 달리기 애니메이션을 탈출하게 되는 것이다.

Transitions 하나에 조건 2개를 붙인다면;

• 
• 움직임을 멈췄을 때 달리기 애니메이션을 끝내지 않고, 방향까지 바꿔야 비로소 애니메이션을 멈춘다;

코드 짜기

• 새 스크립트를 짠 후에 InputSystem을 활용하여 Move 버튼을 누르고 있을 때 참을 할당하게 설정해주었다!

  using UnityEngine.InputSystem;
  >
  public class PlayerAnimation : MonoBehaviour
  {
    private Animator animator;
  >
    void Awake()
    {
        animator = GetComponent<Animator>();
    }
  >
    private void OnMoveAnimation(InputValue value)    // 매우 중요한 부분!
    {
        animator.SetBool("Move", value.isPressed);
    }
  }

  결과

• 
• 의도된 대로 잘 움직여진다.
• 굳이 부자연스러운 점 한가지가 있다면 마우스를 빙빙 돌릴 때 따로 처리를 해줘야할 애니메이션이 있다면 더 부드러워질 것이다.

그 외에 알게된 점

Vector2.magnitude

벡터의 크기를 반환해준다. (x^2+y^2) 제곱근으로 계산해준다. 제곱근의 과정없이 더 빠르게 계산해주는 친구로는 Vector2.sqrMagnitude가 있다. 이 sqrMagnitude 같은 경우에는 두 벡터의 크기를 비교하는 경우에는 이 sqrMagnitude를 사용하는 것이 좋다.

작성하면서 느낀점

한번 보고 따라쳐본 코드를 내가 이 코드를 알았다. 내가 이 기능을 넣을 수 있다는 능력을 얻었다라고는 보기 힘든 것 같다. 분명 내가 본 내용임에도 불구하고 이거 어떻게 해야되지하면서 다시 강의 자료를 찾아보며 코드를 짜면서 이해과정을 거치게 되었다. 아무래도 개인 프로젝트를 진행하면서 내가 강의에서 봤던 코드들을 다시 한번 이해해보면서 내 것으로 만드는 과정을 잘 거쳐줘야 비로소 강의 내용들이 내 능력이 될 수 있음을 깨닫게 되었다.

오늘 한 일

• 알고리즘 문제 풀기 (LeetCode 3075 문제)
• 스파르타 강의 진도 나가기 (~1-13)
• ScriptAbleObject 파헤치기

오늘은 강의 진도를 나아가면서 여러가지를 알게 되었는데 그 중에 Unity의 주요 기능 중 하나인 ScriptableObject에 대해서 자세히 알아보려고 한다.

ScriptableObject

간단 설명

클래스 인스턴스와는 별도로 대량의 데이터를 저장하는 데 사용할 수 있는 데이터 컨테이너입니다. 에디터 세션 동안 데이터를 저장 및 보관하고, 데이터를 프로젝트의 에셋으로 저장하여 런타임 시 사용합니다.

간략한 사용 과정

1. ScriptableObject를 상속받는 스크립트 작성

2. 작성 후 추가된 CreateAssetMenu에서 커스텀 에셋 생성

3. 생성된 ScriptableObject의 field 데이터들을 조정

4. ScriptableObject의 데이터 사용

직접 만들어보자 (사용한 코드 - Unity 메뉴얼)

1. ScriptableObject를 상속받는 스크립트 작성

• 개체 생성에 관한 정보를 담는 SO 스크립트

  using UnityEngine;
  >
  [CreateAssetMenu(fileName = "Data", menuName = "ScriptableObjects/SpawnManagerScriptableObject", order = 1)]
  public class SpawnManagerScriptableObject : ScriptableObject
  {
    // 생성된 애들 이름
    public string prefabName;
  >
    // 얼마의 프리팹을 만들까? 
    public int numberOfPrefabsToCreate;
    // 생성 지점 리스트
    public Vector3[] spawnPoints;
  }

  그럼 위에 있는 코드들을 하나씩 하나씩 설명해보겠다.

CreateAssetMenu

설명

ScripableObject를 상속 받은 스크립트를 Assets/Create 메뉴에 표시하여 Asset에 쉽게 생성하고 저장하기 위해 사용되는 속성(Attribute)이다.

• fileName
  • 생성될 시 기본적으로 부여되는 파일 이름
  • 

• menuName
  • Create 하위 메뉴바에서 보여지게 될 이름을 정한다 '/'처리를 할 때마다 새로운 하위 메뉴로 이어간다.
  • 

• order
  • Create 메뉴바에서 보여지게될 우선순위를 정해주는 변수이다.
  • order = 1
    • 
    • 맨 상단에 위치
  • order = int.MaxValue
    • 
    • 맨 하단에 위치

ScriptableObject

설명

Unity의 주요 기능 중 하나로 게임에서 주로 재사용 가능한 데이터 또는 설정을 저장하는데 사용되는 클래스입니다. 기본 유니티 프로젝트에서 파생되나, MonoBehaviour과 달리 게임 오브젝트에 연결할 수 없으므로 CreateAssetMenu와 함께 사용하여 프로젝트 에셋으로 저장한 후에 활용해야합니다. Unity 에디터와 통합되어 인스펙터 창에서 직접 수정하고 관리할 수 있습니다.

• 사실 CreateAssetMenu를 제외한 딱히 사용되는 코드는 없고, 이걸 상속을 받게된다면 Create 메뉴바로 해당 오브젝트를 빠르게 생성하고 해당 스크립트 내 작성한 클래스의 필드들을 마음껏 커스터마이징할 수 있는 기능을 얻게 된다.

  ! 주의할 점

• 필드들의 접근 제한자는 최소한 public 범위 정도는 되어야한다. (protected 이하로 내려가면 다른 오브젝트에서 해당 필드의 사용이 힘들다.)

+ [Head("Category")]

• 인스펙터 창에서 데이터를 관리할 때 가독성을 높여주는 역할을 해준다.
  • 사용하는 방법

    [Header("Attack Info")]
    public float size;
    public float delay;
    public float power;
    public float speed;
    public LayerMask target;
    >
    [Header("Knock Back Info")]
    public bool isOnKnockback;
    public float knockbackPower;
    public float knockbackTime;

• 
• 사진처럼 데이터들을 목록화하여 보기 좋게 관리해줄 수 있다.

2. 작성 후 추가된 CreateAssetMenu에서 커스텀 에셋 생성

1. 파일을 이와 같이 만들어 정리를 쉽게 한다

• 
• Scripts는 ScriptableObject 스크립트들이 모이는 곳, 뒤에 SO 붙은 게 ScriptableObject 에셋을 생성하는 곳이다.

2. Scriptable Object 생성

• 
• 우클릭 -> Create -> menuName 지정해준대로 찾아가주면 이와 같이 생성된다.

3. Scriptable Object 이름 지정

• 
• F2를 눌러 이름을 지어주자

사실 이 항목은 크게 중요한 거 없고 정리를 잘해주자

3. 생성된 ScriptableObject의 field 데이터들을 조정

• 생성한 오브젝트의 Inspector 보면 밑의 사진처럼 나와있을 것이다.
• 
• 원하는대로 필드를 마음껏 조종해보자

+ Range(minValue, maxValue)

• 값의 범위를 지정해 제한 시키는 속성이다.

  [Range(1, 10)] public int numberOfPrefabsToCreate;

  위와 같이 접근 제한자보다 앞세워서 사용하는 속성(Attribute)인데 이처럼 코드를 짜주면,

• 
• Inpsector에서 위와 같이 슬라이더가 생기는데

• 
• 최소값과 최대값의 범위만큼 움직일 수 있다.

4. ScriptableObject의 데이터 사용

• SO를 참조하는 스크립트

  public class Spawner : MonoBehaviour
  {
    // 생성에 사용될 게임 오브젝트
    public GameObject entityToSpawn;
  >
    // 정의되었던 SO를 담아줄 변수이다.
    public SpawnManagerScriptableObject spawnManagerValues; // 생성 매니저 SO
  >
    // 개체를 생성할 때마다 이름에 같이 붙여줄 숫자로, 개체가 생성될 때마다 증가한다.
    int instanceNumber = 1;
  >
    void Start()
    {
        SpawnEntities();    // 스폰 메서드
    }
  >
    void SpawnEntities()
    {
        int currentSpawnPointIndex = 0; // 소환 작업에 쓰일 인덱스
  >
        for (int i = 0; i < spawnManagerValues.numberOfPrefabsToCreate; i++) // SO에 있는 Prefabs 소환 횟수
        {
            // SO에서 정해진 스폰 지점에서 프리팹의 인스턴스 생성 
            GameObject currentEntity = Instantiate(entityToSpawn, spawnManagerValues.spawnPoints[currentSpawnPointIndex], Quaternion.identity);
  >
            // SO에 정의된 문자열에 고유한 숫자를 덧붙여줘서 생성된 개체의 이름을 지어준다.  
            currentEntity.name = spawnManagerValues.prefabName + instanceNumber;
  >
            // 다음 소환 지점의 인덱스로 이동한다.. 인덱스의 범위를 넘어간다면, 시작점으로 다시 되돌아간다.
            currentSpawnPointIndex = (currentSpawnPointIndex + 1) % spawnManagerValues.spawnPoints.Length;
  >
            instanceNumber++;
        }
    }
  }

• SO를 담아줄 변수와 그 SO를 사용하는 메서드를 구현하고자 하는 기능대로 짜주면 된다.
• ! 스크립트 파일의 이름이 클래스와 동일해야한다.(Unity의 규칙)*

• Inspector 세팅

• SpawnManagerSO
  • 

• Spawner Object
  • 

• 실행 결과

  • 
  • 
  • 위와 같이 지정한 스폰 횟수와 스폰 지점대로 생성이 잘 된다.

장단점

장점

1. 클래스 필드의 다양한 값들을 쉽고 빠르게 만들 수 있다.

• Create 메뉴바에서 SO를 만든 후 Inspector에서 원하는 대로 건들여주면 된다.

2. 기존에 프리팹을 생성할 때마다 해당 데이터의 자체 사본이 생성되는데, 이러한 방법을 사용하여 중복 데이터를 저장하는 대신 ScriptableObject를 이용하여 데이터를 저장한 후 모든 프리팹의 참조를 통해 동일한 정보를 전달할 수 있다.

• 기존 방식
  • 
  • 같은 값을 계속해서 만들고 있다.
• SO를 이용한 방식
  • 
  • SO를 참조하여 값을 가져오고 있다. (불필요한 중복 데이터로 인한 데이터 낭비 감소)
  • 그래서 많은 양의 동일한 정보를 사용하는 오브젝트를 생성할 때 유리하다.

3. 생성된 스크립터블 오브젝트는 asset파일로 저장되기 때문에 다른 Unity 프로젝트로 복사할 수 있다.

• 
• 1주차 팀프로젝트 과제로 옮겨보면 잘 옮겨진다.
  • 주의사항
• SO의 본체인 스크립트를 빼먹으면 안된다.
• 동일한 파일 경로를 유지해줘야한다. (Unity가 에셋의 상대 경로를 사용한다.)
• 버전 간 호환성 및 의존되는 스크립트나 플러그인을 잘 봐줘야한다.
• 파일을 이동할 때는 Unity의 Export Package 기능을 사용하면 다른 프로젝트로 쉽게 이동할 수 있다.

단점

1. 런타임 중에서는 ScriptableObject의 데이터를 수정할 수 없다. 그래서 런타임 중에 매번 변동되어야하는 데이터는 사용을 지양하는 것이 좋다.

주로 만들 수 있는 것

• 변수 설계 (데이터 컨테이너, 열거형)

• 이벤트 설계 (델리게이트 및 옵서버 패턴)

• 런타임 세트

  • 참고 자료 1
  • 참고 자료 2

지금 내가 생각하는 사용 시점

1. 게임에서 재사용이 잦은 스텟이 있을 때 (Hp, Attack, Speed와 같은 데이터들)

2. 아이템 사전이나 몬스터 사전과 같이 오브젝트끼리 같은 변수를 사용하지만 서로 간의 값을 달리하려할 때 (아이템 enum, 몬스터 enum 등)

3. 오브젝트의 생성을 담당하는 오브젝트가 존재할 때 (생성 지점, 생성 횟수, 생성 조건 등등)

참고자료

• Unity 문서

• 스크립터블 오브젝트 | 유니티 - 베르의 게임 개발 유튜브
• 스크립터블 오브젝트로 게임을 설계하는 세 가지 방법
• 협업과 코딩 측면에서 유용한 스크립터블 오브젝트 활용법 6가지

추가로 알게된 점들

- Attribute(속성)

이 녀석들은 []"대괄호"를 주로 사용하고 접근 제한자보다 앞서 사용하는 특징을 가졌다.

• [Header()]
• [Serializable], [SerializeField]
• [CreateAssetMenu(fileName = string, menuName = string/string , order = int32)]
• [Range(,)]

작성하면서 느낀점

위 내용을 작성하면서 알게된 게, 내가 처음에 정확한 자료가 별로 없는 줄 알고 Unity 매뉴얼과 봤던 유튜브 영상만으로 내용을 작성하다가 뭔가 부족하다 싶어서 더 조사해본 결과 스크립터블 오브젝트를 전문적으로 다룬 자료를 찾아내게 되었다. 아무래도 TIL을 작성하기 전에 자료 조사 측면에서 좀 더 신경을 쓰고 조사를 해야겠다는 생각이 들었다. 그리고 추후에 시간이 된다면 이벤트 설계와 런타임 세트를 활용한 스크립터블 오브젝트도 한번 활용해볼 생각이다.

오늘 한 일

• 팀 노션 페이지 짜기
• 스파르타 코딩클럽 진도 나가기 (~1-6)
• 옵서버 패턴에 대해 분석하기

오늘은 강의 내용에서 새로 알게된 디자인 패턴 옵저버 패턴에 대해서 알아보려고 합니다. 자료를 찾아보면서 여러가지 좋은 설명들을 보고 그걸 토대로 제가 해석한 결과를 적어볼려고 합니다.

옵서버 패턴

설명

알림 메서드(event를 활용한)가 있는 특정 대상에게 옵저버를 붙여서 대상자의 정보나 상태가 변했을 때 대상자는 그 정보를 자신에게 연결된 모든 옵저버에게 신호를 보내고 그 신호를 받은 옵저버들은 전달 받은 정보를 토대로 자신의 기능을 작동시킨다.

개념적인 구조

옵서버 패턴의 인터페이스

// 옵서버의 인터페이스
 public interface IObserver
 {
     // 대상자로부터 업데이트를 받습니다.
     void Update(ISubject subject);
 }
 >
 // 발신자, 대상자의 인터페이스
   public interface ISubject
  {
        // 인터페이스에 필드를 선언할 수는 없지만 이 인터페이스를 상속 받은 
      // 발신자 클래스들은 List<IObserver>의 필드를 가진다.
  >
      // 대상자에게 옵저버를 붙입니다.
      void Attach(IObserver observer);
      // 대상자로부터 옵저버를 분리합니다.
      void Detach(IObserver observer);
      // 모든 옵저버에게 이벤트에 대해 알립니다.
      void Notify();
  }

옵서버 추가

// 발신자(subject) class 
// 옵저버 관리 메서드
public void Attach(IObserver observer)
{
    Console.WriteLine("주체: 옵저버를 연결합니다.");
    this._observers.Add(observer);
}
>
public void Detach(IObserver observer)
{
    this._observers.Remove(observer);
    Console.WriteLine("주제: 옵저버를 분리합니다.");
}
>
 var subject = new Subject(); // 발신자(subject) 인스턴스화
 >
 // 옵서버 인스턴스화 및 발신자 구독
 var observerA = new ConcreteObserverA();
 subject.Attach(observerA);
> 
 var observerB = new ConcreteObserverB();
 subject.Attach(observerB);

옵서버 리스트 내에 있는 모든 옵서버에게 알림

// 발신자 (Subject)
// 특정 정보 또는 상태
public int State { get; set; } = -0;
>
// 구독자들에게 업데이트를 날립니다.
public void Notify()
{
    Console.WriteLine("발신자: 옵저버들에게 알립니다...");
>
    foreach (var observer in _observers)
    {
        observer.Update(this);
    }
}
>
// 보통, 구독 로직은 오직 대상자가 할 수 있는 일의 일부분입니다.
// 대상자는 일반적으로 중요한 작업수행 로직을 가지고 있으며 
// 중요한 작업 수행이 벌어졌을 때 알림 메서드를 작동한다. (또는 그 이후에)
public void SomeBusinessLogic()
{
    Console.WriteLine("\n발신자: 중요한 일을 하고 있습니다.");
    this.State = new Random().Next(0, 10);
>
    Thread.Sleep(15);
>
    Console.WriteLine("발신자: 저의 정보가 이와 같이 변했습니다: " + this.State);
    this.Notify(); // 알림 메서드 발동
}
>
  // 구체적인 옵저버들은 자기가 구독한 대상자로부터 발신된 업데이트에 반응합니다.
  class ConcreteObserverA : IObserver
  {
      public void Update(ISubject subject)
      {
          if ((subject as Subject).State < 3)  // 값에 따라서 출력하는 조건을 붙여놓았다
          {
              Console.WriteLine("구체적인관찰자A: 이벤트에 반응했습니다.");
          }
      }
  }
>
  class ConcreteObserverB : IObserver
  {
      public void Update(ISubject subject)
      {
          if ((subject as Subject).State == 0 || (subject as Subject).State >= 2)
          {
              Console.WriteLine("구체적인관찰자B: 이벤트에 반응했습니다.");
          }
      }
  }
>
// Program.Main
   subject.SomeBusinessLogic(); // 알림 메서드가 들어간 메서드 발동
   subject.SomeBusinessLogic();

출력 결과

• 
• 출력을 보면 옵서버가 정보를 무작정 받아들이는 게 아니라 자신의 조건문에 따라서 출력을 결정한다. (물론 들어오는 신호를 받고 싶지 않다면 Detach 메서드를 이용해주면 된다.)

  옵서버 분리

  // Program.main
  subject.Detach(observerB); // 옵저버를 제거하는 메서드
  >
  subject.SomeBusinessLogic();

  출력 결과

• 
• 0 또는 2 이상의 정보를 받으면 작동하는 B옵저버의 Console.WriteLine()이 호출되지 않았다.

장단점

장점

• 비동기적으로 상태 변경을 감지할 수 있다. (주기적인 조회를 통한 데이터 낭비 최소화)
• 런타임 시점에서 원하는 기능을 자유롭게 연결 해제할 수 있다.
• 발신자의 코드를 변경하지 않고도 새 클래스들을 옵저버 리스트를 통해서 기능을 추가할 수 있다. (개방/폐쇄의 원칙)

단점

• 연결된 옵서버들의 알림이 무작위로 받는다. (추가되는 방식으로 옵저버를 연결하면 정확히는 들어온 순서대로 호출되긴 한다.) [하지만 어렵다고 한다..]
  • 
  • 
• 다수의 옵저버 객체를 등록 이후 해지하지 않는다면 불필요한 메모리 누수가 발생할 수도 있다.

주 사용 용도

• 대상 객체의 상태를 감지할 필요가 있을 경우 (체력이나 몬스터 처치 횟수 등등)
• 하나의 정보를 여럿이서 받아야하는 상황일 때 (조작키로 받은 데이터를 -> 플레이어의 이동, 플레이어의 애니메이션, 몬스터의 플레이어 추적에 사용해야할 때 등등)
• 런타임 중에 유동적으로 기능을 연결 분리해야할 때 (퀘스트, 특정 아이템의 기능)

참고 자료

• 사용한 코드 및 참고한 개념 (리팩토링 구루)
• 옵저버 패턴 - 완벽 마스터하기 (인파 티스토리)

강의에서 본 코드 해석하기 (6강 내용)

• 한 번에 코드를 다 치면 내용이 너무 많으니 UML과 같이 간략히 정리해보았다.
• 보라색은 입력 처리를 받는 특수 에셋, 노란색은 클래스 스크립트이다. (특수 에셋에게 OnMove, OnLook, OnFire의 이벤트 함수가 있다)
• 아직은 TopDownController가 하나의 클래스에만 정보를 전달하고 있지만, 다른 기능의 클래스가 플레이어의 입력 처리 정보가 필요할 경우에 TopDownController의 수정 없이 추가적으로 등록하여 정보를 받아올 수 있다. (확장성이 매우 좋다)

작성하면서 느낀점

유니티 수업을 들으면서 기초를 잘 다져놓지 않으면 이해 못했을 내용들이 수두룩하다고 생각한다. 그래서 TIL을 작성하고 난다면 주기적으로도 부족한 부분들을 확인하고 꾸준히 채워나아가야만 앞으로의 개발 실력을 늘려나갈 수 있는 길이라 생각한다.

오늘 한 일

• 발표 준비 및 프로젝트 발표
• 게임 개발 특강 듣기

오늘은 발표로 인해 배운 게 없지만, 들어가기에 앞서 내가 배웠던 자료형들의 명령들을 정리해볼 생각이다.

참고한 사이트

리스트

특징

동적으로 변할 수 있는 배열 (C#에서는 자세히 파고 들면 배열의 파생이다;)

생성자

List<T>()        //    기본 생성자
List<T>(Int32)    //    초기 용량 설정 생성자

속성

Capacity        // 크기를 조정하지 않고 내부 데이터 구조가 보유할 수 있는 전체 요소 수를 가져오거나 설정
Count            // 요소 수 (배열의 길이와 비슷하다)
Item[Int32]     // 인덱싱

메서드

검사

GetType()
리스트의 타입 가져오기

추가, 제거

Add(T)
리스트 끝 부분에 개체 추가
>
Insert(Int32, T)
지정된 인덱스에 개체 추가
>
Clear()
리스트 비우기
>
Remove(T)
맨 처음 발견되는 특정 개체 제거
>
RemoveAt(Int32)
지정된 인덱스에 있는 요소 제거
>
RemoveRange(Int32, Int32)
지정된 범위의 요소 제거

탐색

Contains(T)    
해당 리스트에 있는지 여부를 확인
>
Equals(Object)
지정된 개체가 현재 개체와 같은지 확인

정렬

Reverse()
리스트 전체의 순서를 반대로 바꾼다.
>
Sort()
기본 비교자를 사용하여 전체 리스트의 요소를 정렬

복사, 반환

CopyTo(Int32, T[], Int32, Int32)
배열의 지정된 인덱스에서 시작하여, 리스트에 있는 일련의 요소를 호환되는 1차원 배열에 복사
>
CopyTo(T[])
배열의 처음부터 시작하여 전테 리스트를 호환되는 1차원 배열에 복사
>
CopyTo(T[], Int32)
배열의 지정된 인덱스에서 시작하여 전체 리스트를 호환되는 1차원 배열에 복사
>
Slice(Int32, Int32)
해당 범위에 있는 일련의 요소에 대한 단순 복사본 만들기
>
ToArray()
새 배열에 복사
>
ToString()
문자열로 반환

작업 수행

ForEach(Action<T>)
리스트 내에 있는 모든 Action을 호출

딕셔너리

특징

고유한 키와 값의 컬렉션을 나타낸다.

생성자

Dictionary<TKey,TValue>()    // 기본 생성자

속성

Count        // 딕셔너리에 포함된 키/값의 수
>
Item[TKey]    // 지정된 키에 연결된 값을 가져오거나 설정
>
Keys        // 딕셔너리의 키를 포함하는 컬렉션을 가져온다
>
Values        // 딕셔너리의 값을 포함하는 컬렉션을 가져온다

>
### 메서드
>
#### 검사
```c
ContainsKey(TKey)    
지정한 키값이 포함되어있는지 확인
>
ContainsValue(TValue)    
지정한 값이 있는지 확인
>
Equals(Object)    
지정된 개체가 현재 개체와 같은지 확인
>
GetType()    
현재 인스턴스의 타입을 가져온다.

추가, 제거

Add(TKey, TValue)    
지정한 키와 값을 사전에 추가
>
Clear()    
딕셔너리 비우기
>
Remove(TKey)    
딕셔너리에서 지정한 키가 있는 값을 제거
>
Remove(TKey, TValue)    
딕셔너리에에서 지정된 키를 갖는 값을 제거 후 value 매개 변수에 요소를 복사
>
TryAdd(TKey, TValue)    
지정된 키와 값을 사전에 할당 시도 //TryParse와 비슷한 역할

복사, 반환

ToString()    
현재 개체를 나타내는 문자열을 반환
>
TryGetValue(TKey, TValue)    
지정한 키와 연결된 값을 가져오려고 시도

Stack

특징 : LIFO 후입선출 (나중에 들어간 거 먼저 빠진다)

생성자

Stack<T>()        // 기본 생성자

속성

Count            // 스택에 있는 요소의 갯수

메서드

검사

Contains(T)    
스택에 요소가 있는지 여부를 확인
>
Equals(Object)    
지정된 개체가 현재 개체와 같은지 확인
>
GetType()    
현재 인스턴스의 타입을 가져온다.

추가, 제거

Clear()    
스택 비우기
>
Pop()    
스택의 맨 위에서 개체를 제거하고 반환합니다.
>
Push(T)    
개체를 스택의 맨 위에 삽입합니다.
>
TryPop(T)    
스택의 맨 위에 개체가 있는지 여부를 나타내는 값을 반환하고, 개체가 있는 경우 result 매개 변수에 복사 후에 제거

복사, 반환

CopyTo(T[], Int32)    
지정된 배열 인덱스에서 시작하는 기존 1차원 배열에 스택을 복사
>
MemberwiseClone()    
현재 객체의 단순 복사본을 만든다
>
Peek()    
스택의 맨 위에서 개체를 제거하지 않고 반환합니다.
>
TryPeek(T)    
스택의 맨 위에 개체가 있는지 여부를 나타내는 값을 반환하고, 개체가 있는 경우 이를 result 매개 변수에 복사
>
ToArray()    
스택을 새 배열에 복사합니다.
>
ToString()    
현재 개체를 나타내는 문자열을 반환합니다.

Queue

특징

FIFO 선입선출 (먼저 들어간 게 먼저 빠진다)

생성자

Queue<T>()        // 기본 생성자

속성

Count            // 큐에 포함된 요소 수

메서드

검사

Contains(T)    
큐에 해당 요소가 있는지 판별
>
EnsureCapacity(Int32)    
이 큐의 용량이 지정된 용량 이상인지 확인하고, 현재 용량이 보다 지정돤 용량보다 작으면 지정된 용량 이상으로 증가
>
Equals(Object)    
지정된 개체가 현재 개체와 같은지 확인
>
GetType()    
현재 인스턴스의 타입을 가져온다
>

추가, 제거

Clear()    
큐 비우기
>
Dequeue()    
큐의 시작 부분에서 개체를 제거하고 반환
>
Enqueue(T)    
개체를 큐의 끝 부분에 추가
>
TryDequeue(T)    
큐의 시작 부분에서 개체를 제거하고, 이를 result 매개 변수에 복사

복사, 반환

CopyTo(T[], Int32)    
큐 요소를 지정한 배열 인덱스에서 시작하여 기존의 1차원 배열에 복사
>
MemberwiseClone()    
현재 객체의 단순 복사본을 만든다
>
Peek()    
큐의 시작 부분에서 개체를 제거하지 않고 반환
>
TryPeek(T)    
큐의 시작 부분에 개체가 있는지 여부를 나타내는 값을 반환하고, 개체가 있는 경우 이를 result 매개 변수에 복사
>
ToArray()    
큐 요소를 새 배열에 복사
>
ToString()    
현재 개체를 나타내는 문자열을 반환

HashSet

특징

컬렉션 내에 중복된 값이 없다.

생성자

HashSet<T>()    //기본 생성자

속성

Count            // 집합에 포함된 요소 수

메서드

검사

Contains(T)    
해쉬셋에 지정된 요소가 포함되어 있는지 확인
>
EnsureCapacity(Int32)    
이 해시 집합이 백업 스토리지의 추가 확장 없이 지정된 수의 요소를 보유할 수 있는지 확인
>
Equals(Object)    
지정된 개체가 현재 개체와 같은지 확인
>
GetType()    
현재 인스턴스의 타입을 가져온다

추가, 제거

Add(T)    
지정된 요소를 집합에 추가
>
Clear()    
해쉬셋 비우기
>
Remove(T)    
해쉬셋에서 지정된 요소를 제거
>
TrimExcess()    
해쉬셋의 용량을 실제로 포함된 요소 수로 설정하고 구현별로 다른 근방 값으로 올린다

복사, 반환

CopyTo(T[])    
해쉬셋의 요소를 배열에 복사
>
CopyTo(T[], Int32)    
지정된 배열 인덱스에서 시작하여 해쉬셋의 요소를 배열에 복사
>
CopyTo(T[], Int32, Int32)    
지정된 배열 인덱스에서 시작하여 해쉬셋에서 지정된 수의 요소를 배열에 복사
>
MemberwiseClone()    
현재 Object의 단순 복사본을 만든다
>
ToString()    
현재 개체를 나타내는 문자열을 반환
>
TryGetValue(T, T)    
집합에서 지정된 값을 검색하여 동일한 값을 찾은 경우 해당 값을 반환

작성하면서 느낀점

이후에도 부족한 부분이 무엇인지 확인하고 시간 계획을 정해서 배운 것들을 정리하고 채워나아가야할 것 같다. 앞으로 이 사전은 사용해본 것이나 필요하다고 생각되는 게 생길 때마다 주기적으로도 계속 업데이트 할 예정이다.