AR

AR(Augmented Reality)

• 현실 세계 위에 디지털 컨텐츠를 겹쳐 보여주는 기술
• 카메라로 촬영한 사진 위에 가상의 오브젝트를 합성하는 기술

AR Core/ AR Kit

• 유니티에서 AR 기능을 활용할 수 있도록 지원하는 패키지

AR Core

• 안드로이드 / ios 호환
• AR Kit 비해서는 '상대적으로' 성능이 떨어짐.

AR Kit

• ios 전용
• 바디트래킹

AR Foundation

• Unity와 AR 패키지 간의 다리 역할(어댑터 역할)

- AStar 알고리즘

Q. AI 어디 위에서 길을 찾을까?

• 그래프 위에서 움직인다

Node 설계

Q. 노드(Node)하나가 가지고 있을 정보는?

• walkable: 지나갈 수 있는지 없는지 판별 - bool
• position: 좌표 - Vector2Int
• gCost: 시작점부터 현재 위치까지 - int
• hCost (A*): 현재 위치에서 목표까지 - int
• FCost: gCost + hCost - int
• parent - Node

• Node를 알면, Grid는 Node들의 집합체임을 알 수 있음

Q. Node 하나로 길찾기 가능한가?

• 불가능. 노드들 간 연결이(정보가) 필요함 (이웃 노드)

Q. 현재 노드 어디 방향으로 갈 수 있는가?

• 상/하/좌/우
• 상/하/좌/우/우상/좌상/우하/좌하

다익스트라(Dijkstra)

1. 시작점
2. 주변 확장
3. 거리 기록

Q. Node가 퍼져 나가려면 코드에 있어야 될 데이터는?

• OpenList - List
• Closed - HashSet

List의 성격

• 순회 가능
• 인덱스 접근이 용이

Closed 왜 HashSet일까?

• 빠른 검사를 위함 -> O(1)
• 중복 처리 방지

Q. Step 함수에서 무슨 일이 일어나야 될까?

Step()

1. OpenList 에서 어떤 걸 꺼내야할까?
2. 꺼낸 노드 어디로 가는가?
3. 이웃 노드 어떻게 처리하는가?
4. 이동 비용은 어떻게 계산하는가?

다익스트라 정리

• gCost만 사용
• 전부 탐색

[문제점]

• 목표를 찾는 방식 -> 비효율적 -> 그래서 나온 게 휴리스틱(hCost)을 포함한 A* 알고리즘

[다익스트라 vs A* 차이]

• 다익스트라

  • 시작점(S) 기준으로 퍼져 나감 -> 전부 탐색

• A*

  • 목표(T) 방향으로 퍼짐 -> 필요 영역 우선적 탐색

A*

• gCost: 시작점 노드와 현재 노드 사이의 거리
• hCost: 현재 노드와 타겟 노드 사이의 거리
• FCost: 타겟 노드까지 얼마나 걸리는지에 대한 예상값

hCost

[예시]

S ... T

S = (0, 0) T = (4, 0)

현재 노드 좌표 (1, 0) -> 타겟까지 우측 3칸 -> hCost: 목표까지 몇 칸 남았는지를 계산한 숫자

Q. 왜 맨해튼 거리인가?

현재 위치 (1, 2) 타겟 위치 (4, 5)

|4 - 1| + |5 - 2| = 3 + 3 = 6

-> hCost = 6

A Node - 남은거리 (3) B Node - 남은거리 (7)

A Node와 B Node는 gCost가 같다.

Parent - 경로 역추적

• "Parent 노드에 오기 직전 노드"

S -> a -> b -> c -> T

T.parent = c
c.parent = b
b.parent = a
a.parent = S

-> 거꾸로 올라감 isPath = true 순회했다고 표시를 남김

int newCost = currentNode.gCost + 1;

// 더 좋은 길을 찾았거나 || 이웃 노드를 처음 발견했거나

if (newCost < neighbour.gCost || !_openList.Contains(neighbour))
{
    // 비용 갱신
    neighbour.gCost = newCost;
    neighbour.hCost = GetHeuristic(currentNode, _targetNode);
    // 부모(이전) 노드를 기록
    neighbour.parent = currentNode;

    if(!_openList.Contains(neighbour))
    // 리스트에 탐색 후보를 넣는다
        _openList.Add(neighbour);
}

-> 다익스트라 + 휴리스틱 = A*

정리

// #01
Node - 가지고 있는 정보가 무엇이고, 의미하는바가 무엇인가?
    1) walkable
    2) position
    3) gCost
        // A* 용
        3-1) hCost
        3-2) FCost
    4) parent
    5) isPath

// #02
Node 데이터를 처리할 자료구조는 무엇이고, 왜 필요한가?
- OpenList
- ClosedSet

// #03
- 다익스트라 
    - gCost로만 판단
    - StartNode

- A* 
    - FCost로 판단 || FCost 같다면 hCost로 판단
    - StartNode, TargetNode

- Behaviour Tree

흐름도

FSM 복습 (한계점) -> State 복습 (한계점) -> 코드 기반 BT (한계점) -> BT Graph - Unity 6

• Player
• Enemy -> 일정거리 안에 있으면 Player 추적 / 공격 범위 안에 있으면 공격

Enemy AI가 어떻게 Player를 추적하고 동작하게 할끼?

FSM

[기본구조]

switch(currentState)
{
    case State.Idle:
        // 동작
        break;
    case State.Move:
        // 동작
        break;
    ...
}

[ex]

• 상태(State)가 3개일때는? 근데 만약에 상태(State)가 10개 이상이라면?

-> 상태(State)수가 늘수록 코드 복잡도 폭증

State Pattern 복습

[구조]

• Istate.cs (interface)
  • IdleState
  • MoveState
  • JumpState ...
• StateMachine.cs

상태(State) 구성

• Idle
• Move
• Jump

+상태(State)

• Attack
• Dash
• Air 관련 (Jump 비슷한 State)
• Crouch

"전이(Transition) 연결"

상태(State)가 많아질수록

• 비슷한 상태(State) 간, 조건 중복이 많이됨
• 상태(State) 들간 결합도가 커질 수 있음

Behaviour Tree (BT)

• 루트 노드 -> 자식 노드를 순서대로 조건부 판단

Q. State Pattern과 차이?

• 상태(State)는 선택된 현재 상태(State)만 실행 -> 그 상태(State)가 가진 조건부 판별만함
• BT는 조건을 매 프레임 단위로 루트 노드에서부터 판단

BT의 구조

• Node들로 이뤄져 있다

  public enum NodeState { Success, Failure, Running }
  

public abstract class Node { // Update(); public abstract NodeState Evalute(); }

- Evaluate() 실행 결과를 반환

### 다룰 Node
- Selector (OR)
- Sequence (AND)
- Leaf (Condition/ Acition)

---
### Node 종류

1. Composite Node

- 자식 노드들의 실행 흐름을 제어한다
    - `시퀀스(Sequence)` - **AND구조**
        - 순서대로 실행
        - 하나라도 실패하면 즉시 **Failure** 반환
        - 모두 성공하면 **Success** 반환

    - `셀렉터(Selector)` - **OR구조**
        - 자식 중 하나라도 성공하면 **Success** 반환
        - 모두 실패하면 **Failure** 반환

2. Leaf Mode

- **트리의 가장 하위 노드**로 자식을 가지지 않는다
- **조건을 판단(`Condition`)** 하거나 **실제 행동(`Action`)을 수행**

---
### (유니티 실습)BT 구조
- Enemy가 Player 추적 및 공격 구현중
```csharp
           [Root]
              |
          [Selector] - OR구조
           /       \
      [Attack]    [Chase] - Sequence (And 구조)
                     |           
                [IsNearTarget] - Condition(Leaf)
                    |               
                [MoveToTarget]  - Action(Leaf) 

Selector (OR 구조)

• AttackAction: 공격이 가능한가? -> 가능하다면 공격 (Success / Failure)
  • Failure: Chase(추적) 함? (Success / Failure)
    • Success: Target 추적중
    • Failure: IdleState

(+추가) BT 구조 짤 때

1. 동작할 흐름 모식도로 그려보기
2. 노드를 이해하기(Composite, Leaf Node)
3. 코드 짜기

한계점

• 코드 복잡해짐
• 구조 파악 어려움
• 디자이너(기획자) 수정 불편 (못함...)

정리

- State Pattern과 플랫포머 구현

State Pattern

- 문제 코드

public enum StateList
{
   Idle, Move, Jump, Attack
}

public class PlayerState : MonoBehaviour
{
   private int _direction;
   [SerializeField] private StateList CurrentState; 

   private void Update() 
   {
     // 키 입력 에 따른 각 상태 변화

   }

   private void Idle()
   {
     // 기능 로직
     // 애니메이션 변화 로직
     // 예외처리 등
   }

   private void Move()
   {
     // 기능 로직
     // 애니메이션 변화 로직
     // 예외처리 등
   }

   private void Jump()
   {
     // 기능 로직
     // 애니메이션 변화 로직
     // 예외처리 등
   }

   private void Attack()
   {
     // 기능 로직
     // 애니메이션 변화 로직
     // 예외처리 등
   }
}

• 상태(State)가 늘어나면, 조건 분기수(if) 기하급수적으로 늘어남.

꼭 기억해야할 점

-> 게임 기능이 늘어나면 조건문을 늘리는 게 아니라 상태(State)를 늘린다

Q. 상태(State)란?

-> 어떤 객체가 특정 상황에서 어떻게 행동해야 하는지를 결정하는 행동 규칙

코드 문제점

void Update()
{
    HandleInput();
    ApplyGravity();
    CheckGround();

    if (_state == PlayerState.Idle)
    {
        ...
    }
    else if (_state == PlayerState.Move)
    {
        ...
    }
    else if (_state == PlayerState.Jump)
    {
        ...
        if (CanDoubleJump()) ...
        if (InputDash()) ...
        if (InputAttack()) ...
        if (IsHit()) ...
    }
    else if (_state == PlayerState.AirAttack)
    {
        ...
        if (ComboWindowOpen()) ...
        if (IsHit()) ...
        if (IsGrounded()) ...
    }
    else if (_state == PlayerState.Hit)
    {
        ...
        if (RecoverTimeOver()) ...
    }
    else if (_state == PlayerState.Die)
    {
        ...
    }
    // 계속 증가
}

• 상태(State)가 서로를 안다. (엮여있다)
• 책임이 Player한테 몰리는 현상이 일어난다.
• 수정 시 리스크 폭발

State Pattern 구조

요소	책임	하면 안되는 것
Player	상태 실행	상태 로직 직접 구현
StateMachine	상태 교체	입력처리
ConcreteState	자기 상태 행동 전달	다른 상태 내부 접근

[동작 흐름]

User Input -> Player -> StateMachine -> State.Update()
입력 -> 코드 FSM -> 물리 -> Animator

• 게임은 코드 FSM 위에서 동작 Animator는 그 위에 얹힌 표현 계층

[전환 흐름]

CurrentState?.Exit()
↓
NewState.Enter()

Unity에서 상태패턴을 가지는 임의의 객체(Player)

PlayerController.cs 예시

using UnityEngine;

// 입력 처리 / 물리 판정 / 애니메이션 결정
public class PlayerController : MonoBehaviour
{
    Rigidbody2D _rb;
    Animator _animator;

    StateMachine _stateMachine;

    // Player가 사용할 State들
    IdleState Idle;
    MoveState Move;
    JumpState Jump;

    void Start()
    {
        _stateMachine = new StateMachine();
        Idle = new IdleState(this);
        Move = new MoveState(this);
        Jump = new JumpState(this);

        _stateMachine.ChangeState(Idle);
    }

    void Update()
    {
        _stateMachine.Update();
    }

    public void ChangeState(IState state)
    {
        _stateMachine.ChangeState(state);
    }
}

정리

[Player가 모든 상태를 관리하는 코드 문제점]

• 상태 수 X 전환 조건 수 = Update 복잡도 폭증

• 상태(State)가 늘어날수록 Player가 모든 상태 관련 것들을 알아야함

[상태(State) 역할]

• 상태(게임 로직 + 애니메이션) 모두 Player 안에서 처리

[상태(State) 분리로 일어난 이점]

• Update 함수 코드 구현이 없어진 것이 아니라, 책임이 상태(State) 객체로 이동한 것

- 2D

3D 환경과 차이점?

Depth Test -> 기본적으로 해당 단계를 비활성화/생략

-> 2D 랜더링은 Sorting Layer / Order in Layer

유니티 2D 컴포넌트

• Collider 2D

  • Circle
  • Box
  • Capsule
  • Edge
  • Polygon
  • Composite(⭐)

• Rigidbody 2D

• Sprite Renderer

[+추가]

• Physics Material 2D
• Sorting Layer 설정하는 법
• 2D Physics 설정 (Project Settings)

유니티 2D를 제작 전 사고 방식

• Sprite 그림(연출)
• Collider 감지

• 결국 게임 규칙을 따름

Edge Collider 2D

• 선 하나 시작 -> 원하는 콜라이더를 직접 지정 가능

Polygon Collider 2D

• 복잡한 모양 자동 생성
• 성능이 상대적으로 무거움

Composite Collider 2D

• 하위 객체 콜라이더를 하나로 관리해주는 친구

Tilemap

Step 1. Tilemap - Rectangluar 생성

• 2D Object -> Tilemap -> Rectangular

Step 2. Create New Palette

• 'Resources/Palette/Test palette' 생성

Step 3. Tiles 드래그 드롭

• 'Resources/Tile/Tiles 등록'

Step 4. 종류

4-1. Brush(B)

• "개별 Tile에 칠하기 가능"

4-2. Flood fill with active brush(G)

• "Tile 한 번에 채우기 가능"

4-3. Transform 조정

• "다음 Tile 회전해서 칠하기 가능"

4-4. Tile Transform 변경 가능

4-5. GameObject Brush 옵션

• "애니메이션 들어간 캐릭터를 넣어서 Brush로 쭉 그려보기"

4-6. Group Brush 옵션

• "스포이드로 짜서 원하는 Tile 만들고 Grid에 찍어보기"

4-7. Random Brush

• "랜덤으로 칠해질 Tile을 등록하고 Grid에 찍어보기"

4-8. Rule Tile (⭐)

• "매번 매끄러운 타일을 만들기 위해서 일일이 Brush 하기 번거롭고, 자동으로 타일을 매끄럽게 매핑해주면 좋을것같음"

Sprite Animation

• 이미지를 시간 순서로 변화시키는/바꾸는 것

Sprite Sheet

• 여러 개의 Sprite 이미지를 "한 장의 이미지"에 모아둔 것

Q. 사용하는 이유?

• 관리가 편하다
• 메모리 효율이 좋다 (GPU 바인딩 감소)

Unity에서 사용법

1. Texture Type -> Sprite (2D and UI)
2. Sprite Mode -> Multiple
3. Sprite Editor -> Slice (Grid by Cell Size)
4. Apply

• 위 과정을 거치면 Sprite Sheet가 "개별 Sprite들"로 분리된다.

Sprite Mode = Multiple

• 이미지 하나 = 여러 Sprite

  Pixels Per Unit (PPU)

  

• "PPU는 픽셀을 월드 단위로 환전하는 기준" "1유닛 = 몇 픽셀인가?"

64px = 1 Unity Unit

• PPU 64
• 이미지 64px -> 월드에서 1유닛

[예시]

• 이미지 크기: 96px
• PPU: 64

계산:

96 / 64 = 1.5 Unit

즉, 씬에서 높이 1.5 유닛으로 보임

Q. 중요한 이유

• "카메라 기준이 Unity Unit이기 때문에"

ex)

orthographicSize = 5;

-> 카메라 중점 기준, 위로 5 유닛

Mesh Type 설명 (중요⭐)

1. Full Rect

• "사각형 메쉬 전체 사용"

[장점]

• 안정적
• 타일맵, 캐릭터에 안전

[단점]

• 투명 영역도 포함

2. Tight

• "투명 영역 제외하고 메쉬 생성"

[장점]

• 오버로드 감소

[단점]

• 경계가 불규칙
• 타일 경계 어긋날 수 있음
• 픽셀 아트 흔들림 발생 가능

[실무 추천]

Wrap Mode

1. Repeat

• 텍스처 반복
• 타일처럼 무한 반복 가능

2. Clamp

• 끝 픽셀 유지
• 대부분 2D 게임 기본값

Q. 언제 Repeat?

• 배경 패턴
• 무한 스크롤

Filter Mode (매우 중요⭐)

1. Point (no filter)

• 픽셀 그대로 표현
• 픽셀 아트 필수

2. Bilinear

• 부드럽게 보간

3. Trilinear

• 3D에서 사용
• 2D에서는 거의 안 씀 "픽셀 게임이면 무조건 Point"

(+추가) Sprite Atlas란?

• 여러 Sprite를 하나의 큰 텍스처로 묶어서 성능을 올리는 시스템

Q. 왜 쓰는가?

• GPU는 같은 텍스처를 쓰는 오브젝트를 한 번에 그릴 수 있다. 텍스처가 다르면 -> Draw Call 증가 -> 성능 하락

Q. 언제 쓰는가?

• 모바일
• UI 많을 때
• 캐릭터 수 많을 때

- CSV

- JSON

- Scriptable Object

데이터 관리(저장)을 이해하기 위해서 알아야 할 선수지식

직렬화

객체 -> 파일로 바꾸는 것

[목적]

• HDD/SDD 저장하기 위해서
• 네트워크로 전송하기 위해서
• 유니티 인스텍터 창에 데이터 노출하기 위해

역직렬화

파일 -> 객체로 복원하는 것

데이터 저장방식

1. PlayerPrefs

• 빠르게 사용 가능
• 저장 공간에 제약
• 보안 취약

2. CSV

• 협업 효율 -> 엑셀로 편하게 수치를 기입하고 수정
• 표로 구성되어 있어서, 복잡한 구조에는 치명적

3. JSON

• 리스트, 딕셔너리 같은 복잡한 자료구조를 파일 하나로 묶을 수 있음

4. ScriptableObject

• 유니티 에디터로 지원되는 기능
• 정적 데이터 저장 시 유용

PlayerPrefs

사용처

• 게임 설정 -> 인게임에 크게 영향을 받지 않는 곳에 활용됨

• 사용 가능한곳

  • 설정창
  • 튜토리얼 완료 여부

• 사용 불가능한곳

  • 중요한 정보들 -> 변동성이 심한 데이터

사용법

PlayerPrefs.SetFloat("키", value)
PlayerPrefs.SetInt("키", value)
PlayerPrefs.SetString("키", value)

PlayerPrefs.GetFloat("키", value)
PlayerPrefs.GetInt("키", value)
PlayerPrefs.GetString("키", value)

유니티 PlayerPrefs 저장 장소

CSV

• Comma Separated Values

  ID,HP,ATK
  1,100,10
  2,200,20

• 엑셀 -> 텍스트로 저장

CSV 사용하는 이유

"몬스터 스탯 -> 필드 변수 다 선언"

[문제]

• 기획자 접근 불가
• 하드 코딩
• 데이터 변경 용이X -> 나만 알아본다

[CSV 이점]

• 코드(게임 로직) <-> 데이터 분리 -> 기획자가 데이터 값 수정 용이
• 버전 관리 & 협업 용이

[CSV 단점]

• 계층적 구조

Weapon
 ㄴ Sword
     ㄴ RareSword

Weapon,Sword,RareSword

• 중첩 데이터

  Monster
  ㄴ Skills
     ㄴ Fire
     ㄴ Ice

  ID,Skill1,Skill2 ...
  1,Fire,Ice
  2,

[CSV 한계]

• 타입 정보 없음 (int, float, bool)
• 구조적 표현이 불가
• 런타임 수정 불편

JSON

• 객체 -> 텍스트로 바꿔 외부와 교환하는 방법

실무 가지는 문제들

1) 하드코딩된 필드 변수

int level = 5;

2) 메모리 휘발

• Unity 객체는 메모리
• 게임 종료 시, 데이터 삭제

3) 서버 데이터

{
    "gold": 500,
    "items": ["sword", "potion"]
}

-> 문자열 -> 객체 보완해줘야함

public class Player : MonoBehaviour
{
    public int _level;
    public int _gold;

    public string _path; 

    public void Save()
    {
        string json = JsonUtility.ToJson(this);
        File.WriteAllText(_path, json);
    }
}

-> Player.cs 게임 로직 담당

[위 코드의 문제점]

• JSON = 데이터를 직접적으로 만짐

[역할 분리]

1.Player.cs

public class Player : MonoBehaviour
{
    public int _level;
    public int _gold;
}

-> 게임 플레이만 담당

2. JsonHandler.cs

public static class JsonHandler
{
    // 파일 변환
    public static string ToJson(Data data)
    {
        return JsonUtility.ToJson(data)
    }

    // 파일 저장
    public static void Save(string path, string json)
    {
        File.WriteAlltext(path, json)
    }
}

유니티에서 제공하는 JSON 2가지

1) JsonUtility

[특징]

• Unity 기본 제공
• 빠르다
• 제한 많음

[장점]

• 간단한 구조 적합
• 세이브/설정에 충분히 활용 가능

[한계점]

• Dictionary 미지원
• 프로퍼티(Property) 미지원
• 상속 제한

2) Newtonsoft JSON

Package Manager git URL 설치:

com.unity.nuget.newtonsoft-json

• JsonUtility는 Unity 저장 규칙 따름 (Inspector에 뜨나/안뜨나)
• Newtonsoft JSON Unity 규칙 무관 -> C# 객체를 직접 JSON 바꿈

Q. 무조건 Newtonsoft JSON을 쓰면 되지 않을까?

• 기획자와 협업? -> 데이터 수치를 기획자가 만질 일이 많다 -> CSV
• 서버 통신/ 복잡한 데이터 -> Newtonsoft JSON
• 간단한 설정/ 캐싱 -> JsonUtility

[사용처]

CSV

• 아이템 정보 스탯
• 몬스터 정보
• 퀘스트 리스트

Newtonsoft JSON

-> C# 객체가 JSON 변환해주기 때문에 JsonUtility가 제공하지 않는 것들도 제공함

• NPC 대사
• 유저 인벤토리

JsonUtility

-> Unity에서 제공하는 직렬화 객체들만 가능 = Inspector에서 보이는지 여부

• 설정창
• 업적

ScriptableObject

경량 패턴(Flyweight Pattern) 형태 비슷

public class TreeModel : MonoBehaviour
{
    Mesh _mesh;
    Texture _bark;
    Texture _leaves;
}

public class Tree
{
    TreeModel _model;

    Vector3 _position;
    double _height;
    double _width;

    Color _barkTint;
    Color _leafTink;
}

ScriptableObject

• 초기 설정값이 되는 것들
  • 몬스터 종류
  • 프리팹
  • HP/MP
  • 이동 속도
  • 연출 애니메이션
  • SFX 등등

CSV - JSON - ScriptableObject

CSV

• 수치 테이블
  • 밸런스 기획

JSON

• 직렬화 포맷
  • 데이터를 저장, 통신

ScriptableObject

• 유니티에서 제공하는 초기 데이터 설정
  • 초기 데이터 타입

- NavMesh

NavMesh

• 이동 로직을 코드로 짜지 않고 사용하는 시스템 내부적으로 (Graph)로 데이터화 해서 성능-안정성 우수함.

• NavMesh 는 Bake 시점에서 계산이 끝남.

Bake 단계 (사전 준비)

컴포넌트: NavMesh Surface -> Bake 버튼 클릭!

1. 공간 판별

Unity 씬을 훑음

• 이 표면 Walking 가능한가?
• 경사 각도 올라갈 수 있는가? [Navigation 탭 - Max Slope]
• Agent가 지나갈 수 있는 충분한 부피/반지름 인가? [Navigation 탭 - Radius]

2. 공간을 폴리곤/면(Polygon)으로 분해/생성

• 다각형(Polygon)으로 쪼갬
• 이동에 필요한 정보만 남김

3. 폴리곤/면(Polygon) 간 연결

• 폴리곤/면 간 생기는 선 엣지(Edge)

4. Area - Cost 저장

• 이동 우선 순위를 정함

Runtime 단계 (이동 요청 시)

agent.SetDestination(target.position);

1. 현재 위치가 속한 폴리곤/면 찾기 -> 내 위치 찾기
2. 목적지 폴리곤/면 찾기
3. 폴리곤 그래프(Graph)에서 최적 경로 검색 (경로 O/X ❌ -> 경로 선택)
   • A* 계열, 상대적으로 노드 수가 적음
4. 폴리곤 경로를 따라 이동 경로 생성

NavMesh가 내부에 가지고 있는 정보

[폴리곤 A] ㅡ 연결 ㅡ [폴리곤 B]
[폴리곤 B] ㅡ 연결 ㅡ [폴리곤 C]

• 좌표 X
• 텍스처 X
• 렌더링 정보 X

-> 이동 정보만 가짐 -> 그래프 기반 이동이기 때문에 이미 검증된 길만 탐색함

A* vs NavMesh

A*

• 노드 생성: 런타임(Runtime)
• 그래프 구성: 직접
• 비용 계산: 항상

NavMesh

• 노드 생성: Bake
• 그래프 구성: 엔진
• 비용 계산: 최소화

NavMesh 기본 구성

1. NavMesh Surface - 길 만들기

• 걸어다닐 수 있는 공간인지 판별해주는 매니저 역할

  2. NavMesh Agent

  

역할

• 이동
• 회전
• 충돌 회피

프로퍼티

• speed
• angular speed
• Stopping Distance

필수함수

agent.SetDestination(target.position);

유의사항

• transform.position 으로 이동 X
• Rigidbody 동시 제어 X

3. NavMesh Obstacle - 동적 장애물

필수 기능

• Carving [ON] -> 못가는 길을 만듦.

유의사항

• 많이 쓰면 성능 하락
• 많이 움직일 필요가 없는 물체 정도만 사용

Agent Settings

• Radius/Height -> 캐릭터 부피/크기
• Step Height/Max Slope -> 계단-경사 허용치

-> Agent(AI) 몸체

Areas

• 0~31번까지 있음
• Cost = 선호도 (낮을수록 우선순위)

NavMesh Link

• 끊긴 길 연결
  • 점프
  • 드롭(낙하)
  • 사다리

NavMesh Modifier Volume

역할

• 특정 영역의 길을 설정

예시

• 늪지대
• 함정 구역

- 빛

빛

Q. RP 어디 단계에서 일어나는가?

-> 픽셀/프래그먼트 쉐이더 -> GPU 연산이 일어난다? -> 과부하 요소가 있다 -> 최적화 할 필요가 있다

Q. Unity6 는 어떤 RP 방식인가?

-> Forward + RP 방식 (Default)

Unity가 지원하는 빛 컴포넌트

Light Mode

1. Realtime

   • 매 프레임 객체에 빛과 그림자를 실시간으로 계산하는 친구
   • 부하가 높음
   • 빛 연산이 민감하게 처리되야 하는 모든 곳(횃불)
   • 그림자 연산 처리도 신경써줘야한다 (특히 모바일)

2. Mixed

   • 정적 객체 -> lightmap으로 굽기

   • 동적 객체 -> Realtime으로 굽기 -> 하이브리드 방식

   • Lighting settings

     • Shadowmask(표준): 실시간 그림자 + Baked된 그림자 섞음
     • Subtractive(저사양 모바일): 가볍고 퀄리티가 낮음
     • Baked Indirect(고사양)

3. Baked

   • 빛의 정보를 미리 계산함 -> lightmap (Texture) 형식으로 저장함
   • 런타임 연산이 거의 없다
   • 부하가 매우 낮음
   • 변하지 않는 환경에 세팅된 물체

1. Directional Light

-> 모든 씬에서 태양광 역할

2. Point Light

   • 모양: 구
   • 특징: 전방향 발사
   • 사례: 횃불, 랜턴, 모닥불, 마법 효과, 반딧불

3. Spot Light

   • 모양: 원뿔형 조명
   • 특징: 원뿔형 발사
   • 사례: 손전등, 가로등

4. Area Light

   • 이 친구만 Baked -> Why? 연산 비용이 비싸서
   • 사례: 실내 형광등, 창문 채광

5. (+)Light Probe Group

   • 동적 오브젝트에게 라이트맵(lightmap)을 입히는 기능 = Baked된 Texture를 입히는 작업

6. (+)Reflection Probe

Lighting Setting

• Light Settings Asset

• Lightmapper

  • Progressive GPU권장

• Lightmap Resolution

  • 모바일: 5~15 (권장)
  • PC/콘솔: 20~40

• Max Lightmap Size

  • 텍스처 해상도
  • 표준 1024 (되도록 건들지 않기)

• Direct/Indirect Samples

  • 수치가 높을수록 Noise가 줆 -> 근데 Baked 시간 엄청 튐(되도록 건들지 않기)

- Character Controller

Character Controller 속성

• Slope Limit
  • Default: 45
  • 이 수치를 넘으면 이동 상쇄
• Step Offset
  • Default: 0.3
  • 계단 높이, 되도록 0.3을 넘기지 않음
• Skin Width
  • 충돌 계산의 완충 지대
  • 수치가 작으면: 벽에 낌
  • 수치가 크면: 캐릭터가 공중에 뜬 것처럼 보임
• Min Move Distance
  • Default: 0.001
  • 지터링 방지를 위해 기본값(0.001) 유지

이동 방식 3가지

1. Transform

• 이동X -> 순간이동
• 사례: 충돌이 필요 없는 투사체

  transform.position += direction * speed * Time.deltaTime();

  2. Rigidbody

• 물리 법칙의 지배
• velocity / AddForce()

  3. Character Controller

• 단독 캐릭터 조작할 때 많이 사용

이동 방식 3가지 실사용 사례

1. Transform

• 배경 연출
• 아이템 획득 UI (주로 UI 연출)
• 카메라 연출

  2. Rigidbody

• 레이싱 게임
• 앵그리 버드
• 게팅오버잇
• 폴가이즈

  3. Character Controller

• 바이오하자드
• 오버워치
• 소울류
• FPS류
• RPG 주인공

지터링(Jittering)

-> Character Controller + Rigidbody 같이 쓸 때 나타나는 현상. 두 컴포넌트가 서로 좌표를 잡으려고함

- 오브젝트 풀

- 파티클 시스템

- 오디오

Instantiate 함수

• 객체를 생성해주는 함수

Object Pooling

• 미리 생성된 객체를 필요할 때 꺼내고/넣고 쓰는 방식

1. Instantiate 함수 Unity 내부에서 일어나는 일

1-1. 메모리 할당 및 직렬화 해제

• 메모리 할당 -> RAM위에 올리는 단계

1-2. 역직렬화(Deserialization)

• Instantiate 함수 호출 시, 역직렬화 발생

1-3. 리플렉션 비용 발생

• 프리팹(Prefeb)을 복사(Instantiate)할 때, 어떤 데이터와 컴포넌트가 붙어 있는지 일일이 확인해서 복붙 (역시 CPU가 부담)

1-4. 드로우콜 부담

• Awake() {}
• Start() {}
• Update() {}

-> 위 이벤트 함수를 호출하는 스크립트가 붙은 오브젝트 -> 천개 단위로 있다.

2. 오브젝트 풀링

• 생성 비용 -> 활성화 비용으로 치환하는 기술

1. 화면에 필요한 양만큼 미리 오브젝트를 메모리에 적재해서 사용

2. 객체 파괴(Destroy)대신 -> SetActive(False)를 사용 -> 메모리 할당/해제 막고 GC 발생 원천 차단

3. 메모리 점유율을 일정하게 유지

(+추가) Instantiate 함수가 오브젝트 풀보다 느린 이유

1. 데이터 전송 (HDD/SDD -> RAM -> VRAM)

- 전송해야 될 데이터가 크면 클수록, CPU 부담 발생 -> 게임이 '렉' 걸림...

2. 쉐이더 컴파일

3. 오브젝트 풀링 장점

CPU & RAM 최적화

- `생성/삭제` 연산 횟수 최소화
-> 재사용성의 장점 (오브젝트 ON/OFF)
-> 매 프레임 게임 안정성 유지, GC렉 방지

4. 오브젝트 풀 -> 메서드

• 메모리 단편화(Fragment)

• GC 호출 최소화

  • Destroy 함수 호출

5. 유니티 Profiler 테스트

[Instantiate/Destroy]

[옵젝 풀]

6. 오브젝트 풀 실전 사례

1. 오디오(Audio)

   • 사용 사례: 피격음, 총 발사, 타격음

2. 파티클(Particle)

   • 사용 사례: 피격 이펙트, 트레일(궤적)

Q. 풀링은 언제 사용하면 안될까?

• 씬에 객체 개수가 그렇게 많지 않다면 + 빈번하게 생성/파괴가 일어나지 않는다면

7. 오브젝트 풀 어떤 자료구조 사용하는가?

• List
• Stack
• Queue
• Dictionary
• HashSet
• Array
• LinkedList

7-1. List (비권장)

• 특징: 순서가 있고 인덱스 접근이 가능하다.
• 문제점: 중간 데이터를 삭제하거나 삽입할 때 뒤의 데이터를 당겨오거나 밀어내는 오버헤드가 발생 풀링의 목적인 '최적화'에 부합하지 않아서 단독으로는 잘 쓰이지 않는다.

7-2. Stack (성능 중시) - "CPU 캐시 효율을 극대화하여 0.1ms라도 아껴야 할 때"

• 특징: 후입선출(LIFO)
• 사용사례:
  • 대량의 탄막/탄피: 방금 사용하고 반납된 '따끈따끈한' 객체는 메모리의 캐시(Cache)에 남아있을 확률이 매우 높다. 이를 즉시 재사용하면 CPU 연산 속도가 비약적으로 향상된다.
  • 동적 확장: 필요한 만큼만 조금씩 늘려가며 사용할 때, 최근 생성된 객체를 우선 사용하므로 `캐시 적중률(Cache Hit) 이 최상이다.
• 가치: 퍼포먼스 최상. 자원이 한정적인 모바일 환경이나 대규모 탄막 게임에서 필수이다.

7-3. Queue(★안정성 중시) - "예외 없는 초기화와 시스템의 균일한 동작이 중요할 때"

• 특징: 선입선출(FIFO)
• 사용 사례:
  • 파티클/이펙트: 연출 시간이 제각각인 이펙트들을 골고루 순환시켜, 특정 객체만 과부하가 걸리는 것을 방지하고 파티클 연산의 꼬임을 막습니다.
  • `버그 탐지(QA): 100개중 1개라도 초기화(Reset) 로직이 잘못되었다면, 순환 구조상 무조건 버그가 발견된다. "안걸리고 넘어가는 버그"를 원천 차단한다.
• 가치: 디버깅과 시스템 안정성. 로직이 복잡한 대작 프로젝트나 개발 초기 단계에서 권장

7-4 Dictionary(관리의 핵심) - "수많은 종류의 프리팹을 하나의 매니저에서 관리할 때"

• 특징: 키(Key)를 통해 원하는 바구니(Value)를 즉시 찾는다.(O(1)의 속도)
• 실무 활용: Enum이나 GameObject(Prefab) 자체를 키값으로 사용하여, 어떤 물건을 빌려줄지 결정하는 '거대 창고 관리 대장' 역할을 한다.
• 주의: 메모리를 다소 점유하므로 키값을 너무 남발하지 않도록 주의해야 한다.

[실무] 자주 사용하는 구조

Dictionary<키,자료구조<키>>

Dictionary<Enum,Queue<GameObject>>
Dictionary<Enum,Stack<GameObject>>

오브젝트 풀 구조

• PoolManager.cs -> 객체를 꺼내서 On(Get 함수) / (Release)OFF
  • Object Script : IPoolable -> 상태 초기화(OnSpawn 함수) 및 돌려주기(OnDespawn 함수)
  • Object Script : IPoolable -> 상태 초기화(OnSpawn 함수) 및 돌려주기(OnDespawn 함수)
  • Object Script : IPoolable -> 상태 초기화(OnSpawn 함수) 및 돌려주기(OnDespawn 함수)...

Particle System

협업 프로세스

1. VFX/이펙트 아티스트 or Assets
   • 파티클 모양, 색상, 텍스처 제작
2. 클라이언트 개발자
   • 제작된 파티클 프리팹 -> 오브젝트 풀 등록 -> 게임 로직에 맞춰서 호출되는 코드 작성

기본 속성

• Main Module: Start Lifetime, Start Speed등 파티클의 초기 설정을 결정
  • Simulation Space: World = 잔상 효과
• Emission: 파티클 생성 빈도를 결정
  • 단발성 피격 효과는 Rate over Time X Bursts(한꺼번에 뿜어내기) 사용
• Shape: 파티클이 방출되는 모양(구체, 원뿔, 박스 등)을 정의
• Color over Lifetime: 시간이 지남에 따라 파티클의 색상이나 투명도(Alpha)를 변화
  • ex: 연기가 서서히 투명해지는 효과
• Size over Lifetime: 입자가 크기를 변화를 줌(역동성)
• Renderer: 파티클 시각적 외형을 결정

파티클 초기화 함수

• 파티클 OFF -> 초기화X -> 파티클 켜진 상태 잔상 남은 상태에서 어색하게 Play 됨

  ps.Clear();
  ps.Stop(ture, ParticleSystemBehaviour.StopEmittingAndClear); // Clear() 함수 포함
  

ps.Play();

```

Audio

유니티 오디오 3요소

1. Audio Listener (귀)
2. Audio Source (스피커)
3. Audio Clip (음원)

Audio Clip

Load type

• Deconpress on Load(★)
  • 짧은 효과음(SFX)
    • 로드 시 압축품
• Compressed In Memory
  • 일반적인 소리
  • 메모리에 압 올리고 -> 재생시 압축 풀림
• Streaming
  • 배경음(BGM)
    • 메모리에 올리지 않고 씀

Compression Format (압축 포맷)

• PCM
  • 무압축 고음질 데이터
• Vorbis(★)
  • 압축률이 좋음 -> 실무에서 자주 사용
• ADPCM
  • PCM보다 용량 작음
    • 노이즈 섞인 짧은 소리 유용
• Force To Mono
  • 채널이 하나로 합쳐짐 -> 용량이 절반

AudioSource

핵심 속성

• Priority
  • 0~256설정 가능 -> 주로 배경음은 0 설정
• Spatial Blend
  • 01 (2D3D)

      - 0 (2D - BGM, UI)

    • 1 (3D - 발소리, 효과음)
• Volume & Pitch
  • Pitch: 0.9~1.1 사이로 조정할 때 사운드 풍부
• Play On Awake
  • 체크 시, 게임 시작과 동시에 시작

    거리 감쇄 (FallOff)

• Min Distance / Max Distance: 소리 거리 설정
• Rolloff Mode
  • 평시: Logaritmic
    • 거리감을 일정하게 주고싶을 때: Linear

오디오 실행 함수

• Play()
  • 기존 소리 끊고 새로 시작
  • BGM 교체
• PlayOneShot()
  • 기존 소리에 '중첩'해서 재생
  • 대부분 효과음

- 애니메이션과 FSM

1. FSM(유한 상태 머신) 무엇인가?

• 객체가 한 번에 하나의 상태만 가질 수 있도록 제어하는 모델.

[구조]

현재 상태(State) + 조건(Parameter) -> 상태 전이(Transition)

Idle <-> Walking <-> Running

2. Unity Animation 구성 요소

2-1. 컴포넌트

• Animation (Legacy)

  • 단순한 클립 재생
  • .anim 파일

• Animator (New)

  • 상태 전이가 활발한데 제어도 필요할 때
  • .controller 파일
  • Parameter 탭 수치를 조절

• Animation과 Animator가 둘 다 사용하는 것 -> Animation Clip (녹화본)

• Animation은 단순한 연출에 활용된다.

1. SkinnedMeshRenderer 컴포넌트

• 뼈의 움직임에 따라 변형되는 메쉬(Mesh) 를 화면에 그리는 컴포넌트

2. Animator 컴포넌트

• 애니메이션 설계도(Controller)를 읽어 뼈(Bone)을 실제로 움직이는 엔진

3. Animator Controller

• 애니메이션의 흐름도를 볼 수 있다

3-1. State (노드)

• 캐릭터가 취할 수 있는 각각의 행동 단위

3-2. Transition (상태 전이 표시, 화살표)

• 상태(State)<->상태(State) 를 잇는 통로

3-3. Parameter

• 코드에서 애니메이터로 보내는 데이터

Conditions

• Transition이 일어나기 위한 조건문(Float, Int, Bool, Trigger)
  • Float: 이동 속도처럼 부드러운 변화
  • Int: 무기 스왑이 필요한 것들
  • Bool: 상태 체크
  • Trigger: Attack처럼 단발성 이벤트

• 개발자는 위 4가지 Parameter들로 스크립트로 제어하여 State(노드)간 Transition(상태 전이)를 제어한다.

3. 추가 속성 기능

• Loop Time
  • 동작 반복 여부 결정
• Animation Type
  • 인간형이라면 반드시 Humanoid로 설정해야 다른 캐릭터의 애니메이션을 재사용 가능
• Avator (Configure)
  • 유니티가 캐릭터의 관절(머리, 팔, 다리)을 올바르게 인식하도록 지도를 매핑하는 단계
• Any State
  • 현재 어떤 상태에 있든 즉시 특정 액션(공격, 피격)으로 이동하는 만능 통로
• Has Exit Time
  • 체크하면 현재 애니메이션이 끝날 때까지 기다렸다가 이동하고, 해제하면 즉시 이동한다.
• Can Transition To Self
  • 공격 중에 다시 공격 신호를 받았을 때 처음부터 다시 재생할지 결정
  • Any State 활용 시 무한 루프 방지를 위해 반드시 해제
• Transition Duration
  • 두 동작이 섞이는 순간
  • 반응 속도를 높이려면 이 값을 0.1 정도로 줄이기(보통 0.1~0.25가 적당)
• Transition Priority
  • 멈춤(Idle)과 걷기(Walking) 조건이 동시에 만족될 때, 어떤 화살표를 먼저 검사할지 결정하는 리스트 순서

1. Blend Tree

• 한 노드 안에 여러 클릭을 넣고 수치에 따라 실시간으로 적용시킴 (블렌딩)

Parameter

• 1D Blend Type: 주로 이동(속도)과 같은 카테고리로 제어할 때 사용
  • Threshold (임계값): float형 수치로 조절해서 두 동작 사이 전환 가능
• 2D Simple Directional (2D 단순 방향)
  • 상하좌우(위, 아래, 왼쪽, 오른쪽)와 같은 방향성 애니메이션
  • 사용 사례: 4방향 혹은 8방향 걷기/달리기
• 2D Freeform Directional (2D 자유 형식 방향)
  • 방향은 같지만 속도(걷기/달리기)가 다른 애니메이션을 혼합할 때 유용
  • 사용 사례: 같은 방향으로의 걷기/달리기 속도 차이가 있는 경우

2. Avatar Mask

• 애니메이션이 영향을 미칠 '부위' 를 선택하는 필터

2-1. 실사용 예시

[Base Layer: Idle, Move(Walk, Run)]

[Shiled Layer: 다리 부분을 제외 -> 방패막기와 방패밀치기 Animation]

[Avator Mask: Base Layer 기반 -> Upper Layer Override/Additive]

- UGUI

- MVC / MVP

Image & RawImage

Image

Image Type (4가지)

• Simple: 이미지를 있는 그대로 출력(배경, 아이콘)
• Sliced: 테두리는 유지하고 중심만 늘리는 방식(버튼)
• Tiled: 이미지 (Center) 타일 형태로 반복. -> 이미지 늘릴때
• Filled: 이미지 일부를 노출(체력바, 스킬 쿨타임)
  • Fill Amount(0~1)
    • Radial 모드

Image(Sprite) VS Raw Image(Texture)

Image

• 버튼
• 배경
• 체력바
• 아이템
• 아이콘

단점: Sprite 변환 과정이 필요(자원 소모가 상대적으로 있음)

Raw Image

• CCTV 화면
• 저격총 Scope
• 영상
• 미니맵

단점: 각 텍스처당 Draw Call 발생

Slider

• Value 값 (0~1)

사용 사례

[환경 설정] [체력바 - 플레이어, 적, 보스 등등] [과열기능 - 게임적 허용]

Scroll View

• Content: 실제 아이템들이 담기는 도화지
• Movement Type
  • Elastic
    • Clamped

TextMeshPro (TMP)

Q . 왜 Text 대신 TMP를 사용하는가?

• "랜더링 방식에서 최적화가 일어났기 때문에" (Unity6에서 기본적으로 사용중)

MVC / MVP

• 게임 로직은 건들지 않고 UI만 갈아 끼우는 설계

1. 왜 UI와 로직을 분리해야 하나?

using TMPro;
using UnityEngine;

public class Enemy : MonoBehaviour
{
    public int hp = 100;
    public TextMeshProUGUI hp Text; // UI와 강한 결합

    public void OnDamage(int damage)
    {
        hp -= damage;

        // 로직 스크립트 안에서 UI를 건든다 -> UI와 강한 결합
        hpText.text = "HP:" + hp.ToString();

        if(hp <= 0)
        {
            Debug.Log("Enemy 죽음...");
        }
    }
}

• 유지보수 지옥
  • 프로젝트 커질 시 추적 불가 (어딨는지 못 찾음)

2. MVC vs MVP

1. MVC

   • 사용자 입력이 Controller로 전달.
   • 의존성: View가 Model을 직접 참조.

2. MVP

   • 사용자의 입력이 View를 통해 들어와서 Presenter로 전달.
   • 의존성: View와 Model 사이에 참조가 전혀 없음(의존 안함)

3-1. MVC (Model - view - Controller) 예시

[Model - 데이터 관리]

public class PlayerModel_MVC
{
    public int hp = 100;
}

[View - 화면에 출력 - Model 직접 참조중]

using UnityEngine;
using UnityEngine.UI;

public class PlayerView_MVC : MonoBehaviour
{
    public PlayerModel_MVC playerModel;
    public Slider hpSlider;

    public void UpdateView()
    {
        hpSlider.value = playerModel.hp / 100f;
    }
}

[Controller - 입력 처리 및 Model(데이터) 수정]

using UnityEngine;

public class PlayerController_MVC : MonoBehaviour
{
    PlayerModel_MVC playerModel = new PlayerModel_MVC();
    public PlayerView_MVC playerView;

    public void OnDamage(int damage)
    {
        playerModel.hp -= damage; // Model(데이터) 수정
        playerView.UpdateView(); // View(UI - Slider) 갱신
    }
}

3-2. 같은 코드로 MVP 패턴 구현

[Model 파트 MVC와 동일]

[View - 오로지 그려주기만 한다]

using UnityEngine;
using UnityEngine.UI;

public class PlayerView_MVP : MonoBehaviour
{
    [serializeField] Slider slider;

    public void SetFillAmount(float ratio)
    {
        slider.value = ratio;
    }
}

// Model을 직접 참조하고 있지 않다.
// 데이터 가공도 하지 않는다.
// 오로지 그려주기만 한다.

[Presenter - Model(데이터)와 View(화면) 중재]

using UnityEngine;

public class PlayerPresenter_MVP : MonoBehaviour
{
    PlayerModel_MVC model = new PlayerModel_MVC();
    [SerializeField] PlayerView_MVP playerview; // 조립할 대상

    public void TakeDamage(int damage)
    {
        model.hp -= damage;

        float ratio = model.hp / 100f;
        playerView.SetFillAmount(ratio)
    }
}

4. MVP 패턴

역할

• Model
  • 데이터 관리(값만 가짐, 순수 C#)
  • MonoBehaviour 상속받지 않음
• View
  • 그리기만 하는 녀석 -> UI 컴포넌트 수정/갱신
  • MonoBehaviour 상속받음
• Presenter
  • Model(데이터)의 변화를 감지해서 View(화면)에 전달/명령내리는 대상

사고방식

• Model: 어떤 데이터를 관리하지? (선언된 데이터)
• View: 화면에 뭘 그리지?
• Presenter: Model(데이터) 업데이트와 그려줄 View(화면)를 누가 중재/관리하나?

5. 실전 예제

1) Basic - 단일 연동 (1:1) [model]

public class StatModel
{
    public float hp = 100f;
    public float maxHP = 100f;
    public float GetHpRatio() => hp / maxHP;
}

[View]

using TMPro;
using UnityEngine;
using UnityEngine.UI;

public class SliderBarView : MonoBehaviour
{
    public Slider slider;
    public void SetValue(float ratio) => slider.value = ratio;
}

public class TextPercentView : MonoBehaviour
{
    public TMP_Text hpText;
    public void SetProgress(float ratio)
    {
        hpText.text = $"HP; {ratio * 100}%";
    }
}

[presenter]

using UnityEngine;

public class StastPresenter : MonoBehaviour
{
    StatModel model = new StatModel();
    [SerializeField] SliderBarView viewA;
    [SerializeField] TextPercentView viewB;

    public void OnDamage(float damage)
    {
        model.hp -= damage;
        viewA.SetValue(model.GetHpRatio());
        viewB.SetProgress(model.GetHpRatio());
    }
}

2) Advanced - 다중 연동 (1:N) [Model]

public class ScoreModel
{
    int score;

    public event System.Action<int> OnScoreChanged; // 전광판

    public void AddScore(int amount)
    {
        score += amount;
        OnScoreChanged?.Invoke(score);
    }
}

[Presenter]

using UnityEngine;

public class ScorePresenter : MonoBehaviour
{
    [SerializeField] ScoreView scoreView;
    [SerializeField] TargetView targetView;
    [SerializeField] RankingView rankingView;
    [SerializeField] AchievementPopupView popupView;

    ScoreModel model = new ScoreModel();

    void OnEnable()
    {
        model.OnScoreChanged += scoreView.UpdateScoreText;
        model.OnScoreChanged += targetView.UpdateTargetText;
        model.OnScoreChanged += CheckAchievement;  // Q. 왜 View쪽이 아닌 여기에 구현할까?  
    }

    void OnDisable()
    {
        // 구독 해지 안해준다면??  
    }

    void CheckAchievement(int score)
    {
        if(score >= 100) popupView.Show("팝업 떳습니다");
    }
}

6. 안전한 구독: OnEnable / OnDisable

• OnEnable (구독 시작)
• OnDisable (구독 해제) -> 메모리 누수/죽은 참조 호출 방지가 핵심

📢중요 ) 밥먹듯이 습관적으로 해주기

7. 정리

• MVC: 프로젝트가 커지면, View와 Model이 꼬이는(참조가 많이 일어나는)스파게티의 위험이 있다.
• MVP: Presenter가 Model과 View를 중재해서 깔끔하게 관리 -> 대규모 프로젝트로 가도 문제가 발생할 확률이 적다.

- Layer Mask

- Render Texture

- UI 이해와 최적화

LayerMask

• 레이어 마스크는 태그와 비슷하게 오브젝트들을 분류하여 관리할 수 있다.

- LayerMask 함수 종류

1. LayerMask.GetMask 레이어 이름으로 묶음을 생성하는 함수 Enemy 가 8번 레이어(Layer)

   LayerMask.GetMask("Enemy", "Obstacle")
   // Enemy 가 8번 레이어(Layer)라면?
   // 1 << 8 (값 256)

2. LayerMask.NameToLayer 레이어의 인덱스(int)를 반환

   LayerMask.NameToLayer("Enemy");
   // int 반환값 = 8

3. LayerMask.LayerToName 레이어의 이름(string)을 반환

   LayerMask.LayerToName(8);

4. LayerMask.Value 비트마스크 값을 나타냄. 주로 비트 연산 수행

   int bitMask = enemyLayer.value | obstacleLayer.value; (OR 연산)

- 비트 연산의 원리

• 1 << n: n번 레이어의 스위치를 켠다(ON)
• | (OR): 필터에 레이어를 추가한다.
• & (AND): 이 오브젝트가 포함되어 있다 (필터 역할)
• ~ (NOT): 지정한 레이어 제외한 나머지 다 선택

  layerMask = 7;
  // 이진수 111 -> 0,1,2

  layerMask = 7;

  0000 0000 0000 0000 0000 0000 0000 0000 0111

  layerMask = 1 << 7;

  0000 0000 0000 0000 0000 0000 0000 1000 0000

- 특정 레이어 포함 여부 체크(& AND)

public static class Extensions
{
    public static bool Contains(this LayerMask mask, int Layer)
    {
        return (mask.value & (1 << layer)) != 0;
    }

    public static bool Contains(this LayerMask mask, Gameobject obj)
    {
        return (mask.value & (1 << obj.layer)) != 0;
    }
}
if (mask.Contains(obj, layer)) {}

시나리오 A. Monster/NPC를 때렸을 때, 공격 가능 여부 체크

(this LayerMask mask, GameObject obj)
if(mask.Contains(Enemy 마스크, 몬스터/NPC obj)) {//공격하기}

Enemy는 8번 레이어

mask 0000 0000 0000 0000 0000 0000 0001 0000 0000

1<< NPC 0000 0000 0000 0000 0000 0000 0000 1000 0000 & 0000 0000 0000 0000 0000 0000 0000 0000 0000 false (공격 무시)

~ (NOT) 연산자

~(1 << PlayerLayer)
// UI 레이어까지 포함

Q . 왜 비트마스크 방식을 사용할까?

if(target == "" || target == "" || target == "" || .....)

if(mask.Contains(target, layer)) {}

Render Texture

• 카메라를 이용하여 화면에 이미지 영역을 지정해 이미지에 만들어진 카메라 뷰를 볼 수 있는 방법이다.

- 활용 방법

• CCTV
• 저격총 Scope
• 미니맵등 활용

- 흐름 도식화

[Sub Camera] (촬영)
    ↓ Target Texture 설정
[Render Texture] (저장소/필름)
    ↓ 에셋 참조
[Material / UI -> RawImage] (출력/액자)

UI 이해 최적화

1. UI의 기본 좌표: RectTransform

• Anchor: 부모 해상도가 변할 때, 부모기준으로 상대위치를 결정
• Pivot: 내가 회전하거나 커진 때, 어디를 기준으로 움직일 것인가 (자기 기준)

2. Canvas UI 처리 최소 단위

2-1. Canvas Render Mode

• Screen Space-Overlay 카메라와 상관없이 화면 가장 위 레이어에 그림
• Screen Space-Camera 특정 카메라 앞에 일정한 거리에 배치.

• 연출용 UI, 파티클이 섞인 UI

• World Space 씬 내 3D 오브젝트처럼 활용하는 UI

• 오브젝트 체력, 데미지 등등 2-2. Canvas Scaler

• Constant pixel Size 해상도가 바뀌어도 UI가 사용하는 픽셀 수를 그대로 유지
• Scale With Screen Size -> 모바일 게임 표준
• Constant Physical Size 화면 해상도와 상관없이 cm/inch 크기를 유지하려고함.

주의 컴포넌트

1. Layout Group
2. Text 대안 -> Text Mesh Pro 사용하는 이유?

-> UI가 변화하는 상황에 Text에 비해서 최적화 되어 있다.

Profiler 에서 UI 최적화 잡는법

• Layout(파란색) -> UI 위치/크기 계산하는 시간
• Render(노란색) -> 실제 메쉬 생성 시간

- 시네머신

시네머신

• 카메라 선택과 전환을 자동화한 기능이다.

시네머신의 이점

1. 상황별 연출을 코드 없이 구현 가능
2. 플레이어 이동이나 상태 변화에따라 카메라에 자연스럽게 적용 가능

카메라 추적 코드

void LateUpdate()
{
    Camera.main.transform.position = player.position + offset;

    Camera.main.transform.LookAt(player)
}

Q. 왜 이 방식을 잘 사용하지 않을까?

1. 하드코딩 로직
2. 예외 처리 지옥
3. 상태 전환 불가능

Q. 시네머신을 배우는 이유

• 카메라에 어떤 규칙을 부여해서 활용하는 시스템/기능이다.
• 그렇지않으면 코드로 다 짜야한다.

1. 카메라 로직의 분리
2. 수학적 지식이 크게 요구되지않음
3. 카메라 상태 관리 가능

시네머신 구성

1. Brain (브레인)
2. Virtual (브이캠, VC)

1. Cinemachine Brain (감독)

• 어떤 가상 카메라(Virtual Camera)를 이용할지 결정.

• 블렌딩(전환 효과) 방식을 결정함.

• 실제 카메라는 Brain만 보고, Brain은 가상 카메라(Virtual Camera, 브이캠) 중 하나를 고름.

2. Virtual Camera

• VC, 브이캠이라고도 불림
• 누구를 따라갈것인가?(Follow)
• 어디를 볼것인가?(Look At)
• 어느 거리/ 각도 / 부드러움 규칙을 설정

[계층구조]

Main Camera (실제 카메라)
 ㄴ Cinemachine Brain (결정 및 전환)
     ㄴ Virtual Camera A (상태 1: 평상시) 
     ㄴ Virtual Camera B (상태 2: 조준 시)
     ㄴ Virtual Camera C (상태 3: 이벤트 컷신)

브이캠 속성

Follow & LookAt(대상 설정)

• Follow : 어떤 대상의 몸체(Body)를 매칭
• LookAt : 기획에 따라 다르지만 따로 빈 게임 오브젝트로 빼서 설정함

브이캠 속성 핵심

• Damping: 이동을 부드럽게
• Dead/Soft Zone: 회전 안정성
• Priority: 브이캠 간 전환을 제어

3. Blend List Camera

• 사례
  • 인트로 연출
  • 컷신 시작
  • 보스 등장
• 특징
  • 여러 브이캠을 리스트로 묶음
  • 연출용 카메라

4. Clear shot Camera (시야 확보 전문가)

• 사례
  • 실내 던전
  • 좁은 복도
  • 장애물(기둥, 벽) 많은 환경
  • 시야 확보 전문가

5. Dolly Camera

• 사례
  • 특정 구간 연출
  • 추적할 때
• 구성 & 특징
  • Dolly Track (경로)
  • Dolly Camera (트랙 따라 이동)
  • 연출용 카메라 -> 정서적인 몰입감과 시각적 역동성에 특화된 카메라

6. Free Look Camera(3인칭 조작의 표준)

• 사례
  • TPS
  • 오픈 월드
  • 액션 게임
• 특징
  • 3인칭(TPS)조작 카메라의 표준
  • 사용자 주도 하에 회전 가능/제어
  • 자동 보간, 구도 유지 -> 구현하려면 수학적 지식 요구함

7. Target Group

• 사례
  • 보스 + 플레이어
  • 파티 플레이
• 특징
  • 여러 Target을 하나의 그룹으로 묶음
  • 거리, 비율 자동 조절

- URP

URP(Universal Unity Pipeline)

• 게임이 화면에 그려지는 과정 (CPU -> GPU -> 화면)

1) 정리

CPU : 이 3D 모델들을 이 카메라 시점에서 그려줘(명령, 데이터 전달)

GPU : 알겠어.

1. 3D를 2D로 변환(Vertex)하고,
2. 픽셀로 쪼개서(Raterization),
3. 색을 채워서(Pixel/Fragment)
4. 화면에 보여줄게

2) GPU관점에서 RP를 처리하는 최소 단위

2-1) Vertex(점)

• 3D 공간상의 한 점을 의미한다. 좌표(x,y,z)로 구성

2-2) Polygon(면, 다각형)

• Vertex(점)들이 모여 만들어지는 최소의 면 단위

2-3) Mesh(모델)

Mesh란?

• 면(Polygon)들의 집합

흐름

점(Vertex) -> 면(Polygon) -> 메쉬(Mesh)

• GPU가 점의 위치를 우선적으로 계산

• 그점들을 이어서 Polygon이라는 면을 만들어서 모델을 이루고,

• 최종적으로 Pixel에 색을 채워 넣는다.

정리

• Mesh Filter: 어떤 모양(Mesh)을 쓸 것인가?
• Mesh Renderer: 그 모양을 화면에 '그리는' 담당자. (Material 참조)
• Material: 어떤 색과 질감

3-1-1 UV Mapping

• 3D 표면의 위치(점/면)와 2D 텍스처의 위치(UV 좌표)를 연결하는 과정 2D 이미지를 3D 물체 표면에 정확히 붙이는 방법

3-1-2 Auto Mapping Tools

• 블랜더(blender)
• 맥스(3max)
• 마야(Maya)

3-2 Material

• 게임 화면에 보이는 질감을 담당한다
• 색상, 질감, 빛, 투명도 등 정보를 포함한다.

3-3 Shader

• Meterial이 가진 Texture 혹은 색상 정보를 조합해서 화면에 최종적으로 질감을 입히는 역할
• Shader(틀/설계도): 어떤 데이터를 담을 빈 칸(속성)을 가진다.

그래픽 처리 순서 (게임 엔진)

4가지 (거시적)

1. CPU 명령 (Draw-Call)
   • CPU가 무엇을 그릴지 정해서 명령을 내리면,
2. Vertex Shader
   • GPU가 그 물체의 `점(Vertex)을 화면 위치에 맞게 옮김
3. Rasterizer
   • 모니터 눈금에 맞춰 픽셀로 쪼겜
4. Pixel/Fragment Shader
   • 마지막으로 그 칸들에 색을 채운다.

8가지 (미시적)

1~3단계

1. CPU & Draw-Call

   • CPU -> GPU 그려라! 라고 명령하는 단계
   • 메쉬(Mesh), 메테리얼(Material)

2. Vertex Shader (정점 연산)

   • 3D 공간에 있는 어떤 메쉬/모델을 2D화면에 위치 시키는 것

3. Culling

   • 불필요한 영역을 계산에서 지워버린다.

     3가지

     [Default로 제공]
   • 프로스텀 컬링(CPU) : 카메라 시야 아예 밖에 있는가? (시야 밖 통째로 버림)
   • 백페이스 컬링(GPU) : 물체 면의 방향이 카메라 반대편(뒷면)을 보고있는가? (뒷면 버림)

   [직접 설정]

   • 오클루전 컬링(CPU/GPU) : 앞에 있는 물체에 완전히 가려졌는가?(가려진 부분 버림)

4~5단계 (비주얼 담당 = 색 칠하기)

4. Rasterizer

   • 출력될 픽셀 조각들로 쪼개는 과정
   • 이 계단 현상(Aliasing)이 발생
   • 추후에 Anti-Aliasing 개념까지 들어감.

5. Pixel/Fragment Shader (색상과 질감)

   • 실제 색을 입히는 단계
   • Texture하고 그림자 영역이 여기서 처리됨

   6~7단계

6. Depth Test(Z-Test)

   • 그려지는 우선순위 = 오브젝트의 앞뒤 판별
   • Z-Buffer(깊이 지도)
     • 새로 그릴 픽셀이 기록된 값보다 뒤에 있으면 계산을 취소한다.

7. Blending

   • 배경하고 어떻게 섞일것인가?
   • 앞뒤 판별이 끝난 후, 배경색+현재 픽셀 합성

• 불투명

• 반투명

  Q. 불투명 객체끼리 겹쳐있다면?

  • Front-to-Back
  • Z-Write ON

  Q. 불투명과 투명 객체끼리 겹쳤다면?

  • Back-to-Front
  • Z-Write OFF

  8단계

8. Post-Processing

   • Bloom
   • Color Gradient
   • Anti-Aliasing

RP를 이해하기위한 소스 개념 이해하기

RP 일련과정 이해를 위한 소스

• Vertex(점)

• Polygon(면)

• Mesh(모델)

• Texture (+UV-Mapping)

• Material

• Shader

그래픽 처리 일련 과정

• 1~8단계 키워드 기억하기

Unity가 가지고 가는 RP 이해하기 (Forward)

1) Built-in Pipeline (Legacy) - 개발자가 내부 구조를 수정할 수 없음 - 유니티에서 제공해주는 옵션 조정만 가능

2) SRP (Scriptable-Render-Pipeline) -> 기반 템플릿 URP/HDRP - Built-in 한계 - SRP 초기: C#, HLSL 언어(2018) - SRP 기반 템플릿 -> URP/HDRP(2019)

Q. URP의 장점은?

• SRP Batcher (드로우 콜 최적화)
• Forward+
• GPU Resident Drawer

1) Forward Render Pipeline

• 오브젝트를 그리면서 조명을 그때그때 계산함

2) Deffered Render Pipeline

• 먼저 화면에 필요한 정보들을 저장
  • 위치
  • 노멀
  • 메테리얼

발표

• 각팀의 게임에 대한 발표를 듣고 각각의 게임의 구현된 코드와 사용된 로직이나 기법을 알게되었고, QnA 시간을 통해 서로의 게임에서 궁금한점을 물어보는 시간을 가졌다.

시연회

(에셋 저작권으로 인해 게임 영상이나 사진은 올리지 못했습니다...)

느낀점

• 어제 갑작스럽게 기획반에서 개발팀 게임을 시연하고 싶다고해서 오늘 시연회는 기획팀도 참가하여 우리반이 만든 게임을 해보고 방명록을 남겨주셨다. 생각보다 많은 기획자분들과 같은반 개발팀들이 우리팀의 게임을 즐겨주셨고, "내가 만든 게임을 누군가가 플레이 해준다는 것"이 얼마나 뿌듯하고 기분좋은지 알게되었으며, 편의성 관련 팁이나 조언을 주시는 분들의 의견 또한 앞으로 어떤 방식으로 게임을 만들때 더 생각 해보면 좋을지에 대해서 깨닫게 되는 시간이 되었던것같다.
• 짧은 기간이었지만, 완성도 높은 게임을 만들어준 우리 팀원들에게 엄청나게 감사했고, 고생 많이해줘서 고마웠다.
• 프로젝트가 하나 끝나고 팀 디코방에서 후일담을 나누면서 헤어질때 이대로 끝나는게 약간 아쉽다는 느낌을 많이 받았다.

팀프로젝트를 마치며..

• 그동안 프로젝트를 하냐고 정신없이 코드를 생각하고, 밤을 새면서 고민하다가 기술블로그에 대해서 완전히 깜빡하고있었다! 그래서 오늘 프로젝트가 끝나서 한주간 밀렸던 TIL을 내가 한주동안 프로젝트에서 했던 담당파트와 담당로직, 회고와 같은 내용으로 쓰게되었다.

- 빌드를 뽑고 직접 플레이

- 프로젝트 작품 설명 PPT 작성

빌드 뽑고 직접 플레이

• 오늘은 우리가 한 주 동안 만든 게임을 깃에서 병합하고 메인까지 병합 작업을 한 뒤 빌드를 뽑아내서 직접 플레이하며, 게임의 난이도와 버그가 있는지 테스트를 진행해보았다.
• 플레이하면서 발견된 버그는 몹들이 죽었을때 몬스터의 시체가 유령이 되어 계속 남아있는 버그와 우리가 직접 만든 맵이 아닌 에셋을 활용한 맵이라 그런지 계단부분에서 미끄러지는 현상과 걸림 현상이 발견되었다.

PPT 작성

• 일단 우리가 지금까지 만든 게임의 설명, 사용한 주요 코드, 다른사람들도 알았으면하는 코드, 시연 영상, 회고등을 적어서 내일 있을 팀프로젝트 발표에 사용하기 위해 PPT로 발표자료를 만들었다.

- ESP Manager

• 몬스터 위치 스캔 기능 (ESP)

내가 맡은 파트

• 우리가 이번에 사용하는 맵이 생각보다 넓기 때문에 남은 몬스터가 어디있는지 알아내서 편의성을 높혀주자는 이야기가 나와서 플레이어의 스킬로 스캔기능을 넣어주기로 했다.

데일리 스크럼

🌞 오늘 할 일 (Today)

• 몬스터 위치 스캔 기능 (ESP)

🚧 현재 문제점 / 고민

• 몬스터가 한 종류만 아웃라인이 그려지고 다른 종류의 몬스터는 아웃라인이 그려지지 않는 현상이 있어서 어떻게 고쳐야할지 모르겠다.

💬 기타 메모

• 아웃라인을 그려주는 Quick Outline 에셋을 사용하여, 맵 어디있던 아웃라인을 그려줘서 위치를 찾아주는것이 가능한걸 알아냈으나, 몬스터 2종류중 1종류만 보이는 현상을 어떻게 고쳐야할지 가늠이 가지 않았는데 팀원의 도움으로 아웃라인 로직에서 좀더 코드를 수정할 수 있었고, 몬스터 프리펩에서 모델의 Write/Read 가 꺼져있어서 아웃라인이 mesh를 읽어 오지 못해서 일어난 현상이란것을 알게되었다.

일일 회고

• 오늘은 적들의 위치를 찾아내는 ESP기능을 구현했는데 나혼자 구현을 못해서 팀원들의 도움을 통해 결국 구현해내서 방법도 알게되어 배운점이 많은것같다

- Damage Text UI

• 몬스터 피격시 피해량 UI

내가 맡은 파트

• 타격감을 주기위해서 몬스터에게 총을 쏴서 피격되었을때 몬스터에서 피해량을 띄워주는 UI를 넣어서

데일리 스크럼

🌞 오늘 할 일 (Today)

• 몬스터 피격시 피해량 UI

🚧 현재 문제점 / 고민

• 몬스터 피격 피해량을 띄워주는 UI는 만들었는데 어떻게 이어줘야하는지 모르겠따..

💬 기타 메모

• 몬스터 피격 시 피해량을 띄워주는 로직은 만들었지만, 피해량의 int값을 어디서 어떻게 가져와야 할지 잘 몰라서 진도가 나가지 못했다.

일일 회고

• 몬스터 피격시 피해량 로직이 완벽한지 아닌지 정확하게 확인하지 못했다(값을 받아오는 참조를 걸어줘야하는데 어디서 어떻게 가져올지 몰라서 못해줬다.)

- 캐릭터 컨트롤러

• 플레이어 기준 카메라

내가 맡은 파트

• 내가 캐릭터 컨트롤러에 넣어둔 카메라가 위와 아래를 볼때 캐릭터 기준으로 오르내리는게 아니라 카메라 위치 기준으로 오르락 내리락해서 일명 "카메라 끄덕끄덕 현상"이 일어나서 고치기로 했다.

데일리 스크럼

🌞 오늘 할 일 (Today)

• 카메라 시점 버그 수정

🚧 현재 문제점 / 고민

• 캐릭터 컴포넌트를 다 바꾸게 되었는데 카메라 시점을 기준으로 총을쏘는게 어떻게 되는건지 궁금하다

💬 기타 메모

• 카메라 시점버그 수정을 성공해서 다행이라고 느꼈다.
• 우선 카메라 컨트롤러 스크립트를 새로 만들어주고 전에 수업시간에 배웠던 벽과 플레이어가 가까워질때 카메라가 플레이어쪽으로 줌인 되는 카메라 오브젝트 기법을 사용해서 시점을 좀 더 업그레이드 시켜주었고, 끄덕끄덕하던 현상은 플레이어 몸통에 오브젝트를 추가하여 그 오브젝트에 카메라를 상속시켜주어 카메라가 정상적으로 캐릭터 기준으로 위아래로 볼 수 있게되었다.

일일 회고

• 카메라가 고개만 까딱거리는버그가 있어서 화면을 내리면 캐릭터가 시야를 가리는 버그가있었는데 강의영상과 인터넷 검색을 통해 해결방법을 찾아내어 카메라 시점 버그를 수정해서 좋았다! 어떤 원리인지 아직 정확하게 이해하진 못했지만 그래도 카메라를 구성할때 필요한것들을 조금이나마 알게되었다.