🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 13:00 : Unity 개발
  • NPC에 TextMeshPro 말풍선 부착 및 자동 잡담 시스템 구현
  • 총알 피격 시 다른 대사 출력 기능 구현
  • 몬스터가 총알을 발사하고, 플레이어가 총알로 상쇄시키는 기능 개발
  • 여러 추가 시스템 구현 (몬스터 공격, 효과 처리 등)

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심시간

✅ 오후

• 14:00 ~ 16:00 : Unity 개발
  • NPC 및 몬스터 관련 행동 로직 수정
  • 총에 맞았을 때 씬 전환 및 게임 재시작 처리 추가
  • 무기 피격 시 애니메이션 및 상태 전환 추가
• 16:00 ~ 17:00 : 챌린지반 강의 수강
• 17:00 ~ 18:00 : Unity 개발 재개
  • 말풍선 시스템 점검 및 상태에 따른 대사 출력 로직 수정

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁시간

✅ 저녁

• 19:00 ~ 21:00 : Unity 개발 마무리
  • 화난 상태에서도 NPC 대사 순환 유지 확인
  • 개발된 시스템 전체 테스트 및 디버깅

✅ 오늘 학습 키워드

• TextMeshPro 말풍선 시스템 구현
• 상태에 따른 NPC 대사 출력 로직
• 몬스터 총알 발사 및 피격 상쇄 시스템
• 사망 시 씬 전환 및 게임 재시작 처리
• Unity 애니메이션 상태 연동 (화남, 죽음 등)
• NPC 잡담 순환 유지 버그 수정
• 다양한 시스템 통합 및 디버깅

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

오늘은 NPC와 몬스터의 상호작용과 전투 시스템을 보다 사실감 있게 만들기 위해 다양한 기능들을 구현했다.

먼저 NPC에게 TextMeshPro 말풍선을 부착하고, 자동으로 잡담이 출력되도록 구성했다. 특히 상태가 "화남"일 때에도 잡담이 멈추지 않고 계속 순환되도록 처리하는 데 집중했다. 이 과정에서 상태에 따라 말풍선 내용을 다르게 출력하는 로직을 만들면서, 상태 분기 처리의 중요성을 다시금 체감했다.

또한, 몬스터가 총알을 발사하고, 플레이어가 그 총알을 다시 총알로 쏴서 상쇄시키는 기능도 추가했다. 이때 충돌 판정과 오브젝트 제거 타이밍을 잘 맞추는 것이 중요했다. 물리적인 상호작용처럼 보이게끔 구현하면서, 게임 플레이에 생동감을 더했다.

NPC가 죽을 때에는 단순히 사라지는 것이 아니라 씬이 전환되면서 게임이 다시 시작되도록 만들었다. 이때 SceneManager.LoadScene과 GameManager.instance.StartGame()을 함께 활용해 자연스러운 흐름을 만들었고, BaseController의 Death()를 상속받아 필요한 전용 로직만 오버라이드했다.

마지막으로, 오늘 만든 여러 시스템들이 서로 영향을 주지 않도록 디버깅과 통합 점검을 진행했다. 잡담이 멈추지 않게 유지하는 부분이나, 화남 애니메이션과 말풍선이 겹치지 않도록 하는 처리 등을 하며 디테일을 챙겼다.

🧩 학습하며 겪었던 문제점 & 에러

1. 문제정의

NPC가 화난 상태일 때 잡담이 멈추는 문제

• 평소에는 잡담이 랜덤하게 출력되는데, 화남 상태로 전환되면 말풍선이 더 이상 갱신되지 않음.

시도

• 상태 전환 시에도 RandomTalkCoroutine()이 계속 돌고 있는지 확인
• 화남 상태에서도 StartCoroutine(RandomTalkCoroutine())이 실행되는지 체크

해결 방법

• 말풍선 출력 조건에 상태 제한이 걸려 있었던 부분 수정
• 화남 상태에서도 잡담이 계속 나오도록 조건 분기 보완

2. 문제정의

몬스터가 총알을 발사하지만, 총알이 생성되지 않거나 잘못된 방향으로 발사됨

시도

• Instantiate 위치 및 방향 벡터 확인
• 몬스터의 바라보는 방향 기준으로 발사 방향 설정 로직 점검

해결 방법

• 총알 생성 위치와 방향 벡터를 transform.right 또는 lookDirection 기준으로 명확하게 지정하여 수정

3. 문제정의

플레이어가 발사한 총알로 몬스터의 총알을 제거하는 로직이 작동하지 않음

시도

• OnTriggerEnter2D에서 서로의 태그를 비교하여 충돌 감지
• 총알끼리 충돌이 감지되는지 로그 출력으로 확인

해결 방법

• 총알 간 충돌 레이어 설정을 확인하고, 서로 충돌 가능하게 수정
• 태그 비교 및 Destroy() 로직 추가하여 양쪽 총알 모두 제거 처리

4. 문제정의

NPC가 죽을 때 씬이 전환되고 게임이 재시작되는 구조이지만, GameManager.StartGame()이 호출되지 않음

시도

• NPCController.Death() 안에서 SceneManager.LoadScene() 이후 GameManager.instance.StartGame()이 호출되었는지 확인
• 씬 전환 직후 StartGame 호출이 유효한지 검토

해결 방법

• SceneManager.LoadScene() 이후 바로 StartGame()을 호출하는 것이 아니라, 새로운 씬의 Start()에서 시작되도록 구조 수정 필요
• (혹은 DontDestroyOnLoad 적용 고려)

5. 문제정의

NPC 말풍선이 계속 유지되며 텍스트만 바뀌어야 하는데, 상태에 따라 말풍선 자체가 사라지는 현상 발생

시도

• 말풍선 GameObject 활성 상태 확인
• 상태 변화 시 SetActive(false)가 호출되는지 여부 추적

해결 방법

• 말풍선을 비활성화하지 않고 텍스트만 갱신되도록 구조 수정
• 상태에 상관없이 말풍선 UI는 유지되게 변경

📝 메모

오늘은 정말 많은 기능을 한꺼번에 다루면서 머리가 조금 복잡했지만, 그만큼 뿌듯한 하루였다. NPC의 상태에 따라 다른 대사를 출력하고, 몬스터가 직접 총알을 발사하고, 그 총알을 내 총알로 막아내는 시스템까지… 하나하나 구현하면서 게임 속 상호작용이 점점 풍부해진다는 걸 체감할 수 있었다.

특히 코루틴이 중간에 멈추는 문제나, 총알 충돌 시 동시 제거되지 않는 상황은 예상보다 더 까다로웠지만, 차근차근 로그를 찍고 원인을 파악하며 해결해가는 과정에서 실력이 쌓이고 있다는 걸 느꼈다.

무엇보다 오늘 하루 정말 열심히 달렸다는 느낌이 들어서 스스로가 기특했다. 작은 기능 하나하나에 의미를 부여하고, 더 자연스럽게 보이도록 고민했던 시간이 헛되지 않기를 바란다.

사실..오늘 개발만 하면서 오류 수정을 몇번이나 헀는지 모르겠다ㅎㅎ.. 너무 GPT에 의지하나 싶기도하다.. 오류 수정이나 뭐든 최대한 GPT를 덜 써야겠다 하루하루 열심히 잘 해보자구!! 시간 가는줄도 모르고 개발하다보니 벌써 9시가 다됐다ㅎㅎ 하루가 너무 빠르다..

🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 13:00 : 프로젝트 회의 및 캐릭터/무기 구조 개선

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심시간

✅ 오후

• 14:00 ~ 18:00 : 캐릭터 점프 애니메이션 구현, 무기 플립 회전 문제 해결

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁시간

✅ 저녁

• 19:00 ~ 21:30 :
  • 총알 Trail Renderer 이펙트 구현
  • 탄피 배출 이펙트 추가
  • StairsLayerTrigger 개선을 통한 2D 계단 레이어 전환 구현
  • SpriteRenderer가 자식에 있을 경우 예외 처리 추가
  • 캐릭터 Shadow 렌더링 개선

✅ 오늘 학습 키워드

• 총알 트레일 이펙트 (Trail Renderer)
• 탄피 배출 연출
• StairsLayerTrigger.cs 개선
• SpriteRenderer 동적 접근
• 무기 회전 방향 제어 (Y/Z축 구분)
• 계단 이동 시 Sorting Layer 동기화

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

오늘은 캐릭터와 무기 시각적 연출에 집중했다.

무기 회전이 Z 축만 반영되어 방향이 뒤틀리는 문제를 해결하기 위해 Y 축 기준으로 좌우 방향을 반전시키고, Z 축으로는 마우스를 따라 회전하게 구현했다. 이걸 통해 왼쪽/오른쪽을 자연스럽게 바라보는 무기 방향 연출이 가능해졌다.

총알에는 Trail Renderer를 사용해 궤적을 자연스럽게 만들었고, 탄피는 Instantiate()로 복제 후, AddForce()로 튀어나오게 구현해 생동감을 더했다.

또한 StairsLayerTrigger를 수정하여 플레이어가 계단 위/아래로 이동할 때 Layer 및 SortingLayer가 바뀌도록 개선했다. 이때 SpriteRenderer가 자식에 있을 경우 예외가 발생해, GetComponentInChildren<SpriteRenderer>() 방식으로 유연하게 처리하였다.

🧩 학습하며 겪었던 문제점 & 에러

1. 문제정의

총알 라인 이펙트가 보이지 않음

• 시도: Line Renderer로 표현
• 해결 방법: Trail Renderer로 변경하니 즉시 궤적 표현 가능
• 새롭게 알게 된 점: LineRenderer는 "지속 궤적"이 아닌 "정적인 선" 표현에 적합하며 Trail은 자동으로 궤적이 따라붙는 효과를 줌

2. 문제정의

무기 회전이 반대로 되거나 Z축만 회전됨

• 시도: Quaternion.Euler(0, 0, rotZ)
• 해결 방법: 마우스가 왼쪽일 땐 Y축 = 180, 오른쪽일 땐 Y축 = 0 설정 → Quaternion.Euler(y, 0, z)
• 새롭게 알게 된 점: localRotation은 Z만 조절하면 부자연스럽고, Y 회전도 명확히 설정해야 시각적으로 자연스러움

3. 문제정의

StairsLayerTrigger에서 SpriteRenderer 접근 시 예외 발생

• 시도: target.GetComponent<SpriteRenderer>()
• 해결 방법: 자식에서 가져오도록 GetComponentInChildren<SpriteRenderer>() 사용
• 새롭게 알게 된 점: 복잡한 구조의 캐릭터에서는 SpriteRenderer가 최상위가 아닐 수 있음

📝 메모

• 무기 회전은 Z만 보지 말고 Y도 함께 고려해야 자연스럽다.
• Trail Renderer는 속도감 있는 총알 표현에 최고다.
• 계단에서 계층(layer) 이동 구현은 단순한 트리거만으로도 충분히 가능했다.
• 에러 메시지에서 "MissingComponent"가 뜨면 항상 하위 구조도 의심해보자.

✨ 오늘의 느낀점

오늘은 캐릭터와 무기의 회전 처리 문제를 해결하는 데 많은 시간을 소모했다.

처음엔 단순히 캐릭터가 마우스를 바라보도록 회전시키는 건 잘 되었지만, 무기의 Y축 회전 처리가 문제였다.

캐릭터가 왼쪽을 보면 무기도 Y축 기준으로 180도 반전해야 했지만, 무기가 360도 회전하는 과정에서 Z축 회전까지 반전되어 마우스가 위에 있어도 총이 아래를 향하는 문제가 발생했다.

이 문제를 해결하려면 왼쪽을 바라볼 때는 Y축만 180도 반전시키고, Z축 회전은 항상 마우스를 기준으로 유지되도록 처리해야 했다. 사실 구조적으로는 복잡하지 않은 문제였지만, 단순한 연산 하나가 미치는 시각적 영향이 생각보다 크다는 걸 다시 느꼈다.

또한 오늘은 GPT를 너무 많이 의존했다는 생각이 들었다.

빠르게 해결하려다 보니 직접 문제를 탐색하거나 시도해보는 과정 없이 정답만 찾으려 했던 게 오히려 더 많은 시간을 허비하게 만든 것 같다.

앞으로는 직접 값을 찍어보면서 어떻게 동작하는지 파악하는 습관을 들이고, 필요한 부분에서만 GPT를 보조 수단으로 활용하자.

문제를 정면으로 마주하고, 하나하나 내 실력으로 해결해가는 연습이 지금 가장 중요하다.

Unity 2D TopDown에서 캐릭터와 무기의 회전 및 Flip 처리 정리

✨ 문제 배경

TopDown 방식의 2D 슈팅 게임을 만들다 보면, 마우스 방향에 따라 캐릭터가 회전하고, 무기도 함께 회전하도록 구현해야 합니다.

특히 무기가 캐릭터의 하위 오브젝트(WeaponPivot)로 존재하는 경우, 마우스가 왼쪽/오른쪽으로 이동할 때 캐릭터는 SpriteRenderer.flipX를 통해 반전시키고, 무기는 Y축 회전(localEulerAngles.y)과 Z축 회전(localEulerAngles.z)을 동시에 고려해야 합니다.

이 글에서는 캐릭터의 Flip 처리와 무기의 회전 처리를 어떻게 해결했는지 기록합니다.

🔀 캐릭터 회전 처리

private void Rotate(Vector2 direction)
{
    float rotZ = Mathf.Atan2(direction.y, direction.x) * Mathf.Rad2Deg;
    bool isLeft = Mathf.Abs(rotZ) > 90f;

    // 캐릭터의 좌우 반전 처리
    characterRenderer.flipX = isLeft;

    // 무기 회전 처리 (WeaponPivot)
    if (weaponPivot != null)
    {
        weaponPivot.localRotation = Quaternion.Euler(
            0f, // X
            isLeft ? 180f : 0f, // Y
            isLeft ? -rotZ : rotZ // Z
        );
    }

    // 무기 내부에서도 좌우 반전 처리할 수 있음 (선택)
    weaponhandler?.Rotate(isLeft);
}

✅ 핵심 포인트

• 마우스 방향을 Atan2로 각도로 변환해 Z축 회전각을 계산합니다.
• 각도(rotZ)가 ±90도를 넘는 경우 왼쪽으로 간주하여 flipX = true
• 무기 피벗(WeaponPivot)은 Y축 기준 180도 회전과 Z축 회전을 조합해야 자연스럽게 반전됩니다.

🗡️ 무기 Flip 처리 예시

WeaponHandler 클래스에서 무기의 스프라이트 반전을 처리하고 싶다면 다음과 같이 작성할 수 있습니다.

public override void Rotate(bool isLeft)
{
    // 필요 시 무기 자체 SpriteRenderer 반전 (필요 없으면 생략 가능)
    weaponRenderer.flipY = isLeft;
}

단, 무기 Sprite가 여러 개거나 별도 애니메이션이 있는 경우 flipY보다 Transform.localEulerAngles 회전을 직접 조작하는 것이 더 안정적입니다.

📅 회고 및 느낀 점

오늘 하루를 무기 회전 방향 잡는 데에 대부분 썼지만, 결국 핵심은 Y축 Flip과 Z축 회전의 조합이라는 걸 깨달았습니다. 단순히 SpriteRenderer만 뒤집는 것으로는 해결되지 않으며, 부모 오브젝트인 WeaponPivot의 localRotation을 정확히 조작해야 원하는 결과를 얻을 수 있었습니다.

✨ 최종 정리 코드 (간단 버전)

float rotZ = Mathf.Atan2(direction.y, direction.x) * Mathf.Rad2Deg;
bool isLeft = Mathf.Abs(rotZ) > 90f;

characterRenderer.flipX = isLeft;
weaponPivot.localRotation = Quaternion.Euler(
    0f,
    isLeft ? 180f : 0f,
    isLeft ? -rotZ : rotZ
);

이 방식은 대부분의 TopDown 슈팅에서 유용하게 사용할 수 있습니다. 이제 총도 자연스럽게 회전하고, 방향에 따라 무기와 캐릭터가 모두 올바르게 반응하게 되었습니다!

이거 만드느라..몇시간을 썼는지 모르겠네여.. 그냥 총을 구현하고 싶을 뿐이였는데 전에 쓰던 무기는 그냥 활이라서 스프라이트가 1개밖에 존재하지 않는거라 문제되지 않았지만 총은 부품 1개1개 전부 스프라이트로 되어있어서 조금 난감했었다.. 그래도.. 결국에는 해결했으니 다행이다ㅠㅜㅜ

❓ 왜 Generic Singleton이 필요할까?

Unity에서는 GameManager, SoundManager, UIManager 등 다양한 매니저 클래스에서 싱글톤(Singleton) 패턴을 사용한다.
하지만 매번 static instance 선언, Awake()에서 중복 제거 같은 코드를 반복하게 된다.

이런 중복 코드를 줄이고 재사용 가능한 형태로 만들기 위해 Generic Singleton 패턴을 도입할 수 있다.

🧠 Generic Singleton이란?

Singleton<T>처럼 제네릭 타입을 활용하여 싱글톤 로직을 부모 클래스에서 처리하고,
필요한 매니저들은 상속만 하면 되는 구조다.

🧩 Singleton<T> 기본 구현

using UnityEngine;

public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
    private static T _instance;

    public static T Instance
    {
        get
        {
            if (_instance == null)
            {
                _instance = FindObjectOfType<T>();

                if (_instance == null)
                {
                    Debug.LogError(typeof(T) + " 싱글톤 인스턴스를 찾을 수 없습니다!");
                }
            }

            return _instance;
        }
    }

    protected virtual void Awake()
    {
        if (_instance == null)
        {
            _instance = this as T;
        }
        else if (_instance != this)
        {
            Destroy(gameObject); // 중복 방지
        }
    }
}

🧩 사용법: GameManager 예시

public class GameManager : Singleton<GameManager>
{
    public void GameOver()
    {
        Debug.Log("게임 오버!");
    }
}

이제 다른 스크립트에서는 다음처럼 사용 가능하다:

GameManager.Instance.GameOver();

✅ 장점 정리

• ✅ 중복 코드 제거
• ✅ 유지보수 용이
• ✅ 확장성과 재사용성 증가
• ✅ 상속만으로 싱글톤 구조 구현

⚠️ 주의사항

• Unity는 다중 상속이 불가하므로, 이미 다른 클래스를 상속 중이라면 사용할 수 없다.
• DontDestroyOnLoad(this) 등의 추가 처리는 자식 클래스에서 해야 한다.

📝 마무리

Generic Singleton은 프로젝트 규모가 커질수록 코드 정리와 유지보수에 큰 힘이 된다.
공통적인 싱글톤 구조를 반복 작성하지 않고, 한 번의 설계로 여러 매니저에 적용할 수 있는 패턴으로 적극 활용해보자!

사실 이걸보면서 잘 사용할까 싶었다..ㅎㅎ.. 나중에 천천히 또 공부해봐야지..

🎮 Unity에서의 싱글톤(Singleton) 패턴

🔍 싱글톤이란?

싱글톤(Singleton)은 프로그램 전체에서 단 하나의 인스턴스만 존재하도록 보장하는 디자인 패턴이다. 게임에서는 주로 오디오 매니저, 게임 매니저, UI 매니저 등 전역적으로 접근해야 하는 매니저 클래스에 사용된다.

🧱 Unity에서의 싱글톤 구현 예시: SoundManager

public class SoundManager : MonoBehaviour
{
    public static SoundManager instance;

    private void Awake()
    {
        instance = this;
    }
}

위 코드에서 핵심은 public static SoundManager instance와 Awake()에서의 instance = this 할당이다. 이 방식으로 어디서든 SoundManager.instance를 통해 접근 가능하다.

🎯 GameManager에서도 적용된 예시

public class GameManager : MonoBehaviour
{
    public static GameManager instance;

    private void Awake()
    {
        instance = this;
    }
}

이렇게 작성하면, 다른 스크립트에서 다음처럼 쉽게 접근할 수 있다:

GameManager.instance.GameOver();

🧠 왜 사용하는가?

• 전역 접근이 필요한 매니저 클래스에 적합
• 중복 생성 방지로 안정성 향상
• 코드 간결화 (FindObjectOfType 등 비효율 제거)

⚠️ 주의할 점

• 씬에 오직 하나만 존재해야 한다 (중복 방지 필요)
• DontDestroyOnLoad(this)와 함께 사용할 수도 있음 (씬 이동 시 유지할 경우)

🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 10:00 : 새로운 팀 배정 및 팀원 자기소개
• 10:00 ~ 10:30 : Unity 입문 챕터 발제 강의 수강
• 10:30 ~ 13:00 : 2D TopDown Shooting 게임 개발 시작

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심시간

✅ 오후

• 14:30 ~ 16:00 : 이력서 작성 강의 (기본 정보, 자기소개, 프로젝트 항목 포함)
• 16:00 ~ 18:00 : 탑다운 슈팅 게임 디버깅 및 기능 구현
  • Input System 설정 오류 수정
  • Sprite 설정 문제 해결
  • 투사체 생성/충돌 디버깅
  • AudioSource 누락 문제 해결

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁시간

✅ 저녁

• 19:00 ~ 21:00 : 깃허브 README 작성 및 프로젝트 업로드, TIL 작성
  • TheStack, TopDown 프로젝트 업로드
  • 각 프로젝트 리드미 작성
  • 트러블슈팅/폴더 구조 정리

✅ 오늘 학습 키워드

• Unity 2D TopDown Shooting 개발
• Input System 이벤트 함수 매핑 (OnMove, OnLook, OnFire)
• 투사체 발사 및 충돌 처리 (ProjectileManager, ProjectileController)
• SpriteRenderer 누락 및 이미지 표시 문제 해결
• AudioSource 컴포넌트 오류 디버깅 (SoundManager)
• 애니메이션 이벤트 오류 (AnimationEvent without function)
• EnemyManager를 통한 적 생성 및 웨이브 진행 구조
• GameManager 흐름 제어 및 Init 함수 호출 구조
• GitHub 프로젝트 업로드 방식
• .gitignore 및 라이선스 설정
• README.md 작성 실습 (프로젝트 설명, 기능 요약, 트러블슈팅, 폴더 구조)
• Resume 작성 기초 강의 (기본 정보, 자기소개, 프로젝트 항목 중심)

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

오늘은 새로운 팀에 배정되고, 팀원들과 인사를 나눈 후 개인 프로젝트로 2D TopDown 슈팅 게임 개발을 시작했다. Unity Input System을 적용하면서 OnMove, OnLook, OnFire 같은 입력 함수가 자동으로 호출되기 위해서는 Input 액션 이름과 함수명이 정확히 일치해야 한다는 것을 다시 한번 확인했다. 단순한 오타로 인해 캐릭터가 움직이지 않았던 상황이 있었고, 해당 이슈를 해결하며 Input System의 작동 원리에 대해 더 명확히 이해하게 되었다.

또한 ProjectileManager와 ProjectileController를 통해 투사체를 생성하고, RaycastHit2D로 충돌 여부를 판별하여 적에게 데미지를 주는 로직을 구현했다. 화살이 생성되었는데도 이미지가 보이지 않아 당황했는데, 이는 프리팹에 SpriteRenderer가 누락된 것이 원인이었다. 이처럼 사소한 실수가 게임 동작에 영향을 줄 수 있다는 점을 다시금 느꼈다.

사운드 구현 과정에서는 SoundManager가 참조하는 AudioSource 컴포넌트가 오브젝트에 붙어 있지 않으면 MissingComponentException이 발생한다는 걸 직접 경험하며, Unity에서 컴포넌트 구조를 꼼꼼히 확인하는 습관의 중요성을 배웠다.

마지막으로, 오늘 만든 TheStack과 TopDown 프로젝트를 GitHub에 업로드하고, 리드미를 정리하면서 폴더 구조, 기능 설명, 트러블슈팅 내용을 문서화했다. 이렇게 기록하는 과정이 내가 만든 프로젝트를 더 명확하게 이해하게 해주었고, 앞으로 포트폴리오 작성에도 큰 도움이 될 것 같다.

🧩 학습하며 겪었던 문제점 & 에러

1. ❌ 캐릭터가 움직이지 않음

• 문제정의: 플레이어가 키 입력을 받아도 움직이지 않았다.
• 시도: PlayerController의 OnMove()가 제대로 작성되어 있는지, InputAction 설정이 되어 있는지 확인.
• 해결 방법: InputAction의 이름이 Lock으로 잘못 작성되어 있었음. Look으로 수정하자 마우스 방향 회전도 정상 작동함.
• 새롭게 알게 된 점: Input System은 액션 이름과 함수명이 정확히 일치해야 메서드가 호출된다.
• 다시 만나게 된다면: Input Action 설정 후 함수 연결 확인 시 오타 여부를 가장 먼저 점검하자.

2. ❌ 투사체는 생성되지만 이미지가 보이지 않음

• 문제정의: 활 공격 시 화살이 생성되지만 Sprite가 보이지 않았다.
• 시도: ProjectileController의 로직 점검, SpriteRenderer의 설정 확인.
• 해결 방법: projectilePrefabs로 등록한 화살 프리팹에 SpriteRenderer 컴포넌트가 누락되어 있었음. SpriteRenderer를 추가하자 정상적으로 이미지 출력됨.
• 새롭게 알게 된 점: 프리팹 구성 요소 중 하나라도 누락되면 기능은 작동해도 시각적으로 표시되지 않을 수 있다.
• 다시 만나게 된다면: 프리팹 등록 전 구성 요소 체크리스트를 확인하자.

3. ❌ 효과음 재생 시 MissingComponentException 발생

• 문제정의: 게임 실행 시 SoundManager에서 BGM을 재생하려다 MissingComponentException 발생.
• 시도: 로그를 따라 AudioSource 관련 코드 위치 확인.
• 해결 방법: SoundManager 오브젝트에 AudioSource가 빠져 있었음. Add Component로 추가하여 해결.
• 새롭게 알게 된 점: 스크립트에서 사용하는 컴포넌트는 Inspector에서 수동 추가가 필요한 경우가 많다.
• 다시 만나게 된다면: Awake 또는 Start에서 사용하는 컴포넌트가 Editor 상에 존재하는지 꼭 확인하자.

📝 메모

오늘은 개인적으로 만든 탑다운 슈팅 게임 프로젝트를 디버깅하면서 정말 많은 걸 배웠다.

처음엔 단순히 Sprite가 안 보이는 이유가 코드 때문일 줄만 알았는데, 오히려 Inspector에서의 누락이 문제였다는 걸 깨달았고,

Input System도 처음 도입하면서 Action 이름과 함수 이름이 정확히 일치해야 작동하는 등, 작은 오타 하나로 전체 흐름이 막힐 수 있다는 점을 체감했다.

디버깅을 반복하며 단순히 "왜 안 되지?"를 넘어서, **"내가 무엇을 놓치고 있는가?"**를 묻는 습관을 조금씩 갖게 되는 하루였다.

그리고 무엇보다 중요한 건 "작은 성공 경험"을 계속 축적하는 일인 것 같다. 하나하나 오류를 해결해 나가며 기능이 살아나는 그 순간의 기쁨은, 정말 다시 코드를 짜고 싶게 만든다.

내가 만든 프로젝트를 깃허브에 올리면서 처음으로 README를 제대로 구성해봤는데,

정리된 폴더 구조와 트러블슈팅 문서를 작성하는 경험 자체가 내 코드에 대한 애정을 더 깊게 만들어줬다.

사실 과제를 빠르게 만들고싶어서 급하게 하다 많은 오류가 났었던거같다.. 내일은 다시 코드리뷰해보면서 하나씩 되짚어봐야겠다.

하루하루 화이팅!!!~!!

TopDown 실행화면

🗓️ 오늘 하루 일정

✅ 오전

• 09:00 ~ 13:00 : 프로젝트 회의 및 코드 정리
  • 전체 구조 리뷰 및 코드 수정
  • 팀원들과 기능 분담 및 로직 개선 방향 논의

🍽️ 점심시간

• 13:00 ~ 14:00 : 점심시간

✅ 오후

• 14:00 ~ 16:00 : 프로젝트 발표
  • 팀 프로젝트 진행 상황 및 주요 구현 기능 발표
  • 트러블슈팅 내용 공유 및 발표자료 구성 피드백
• 16:00 ~ 18:00 : Flappy Bird 스타일 게임 제작
  • Player, Obstacle, BgLooper, FollowCamera, GameManager, UIManager 등 구현
  • 배경 루핑, 점프 및 장애물 통과 로직, 카메라 이동 구현

🍽️ 저녁시간

• 18:00 ~ 19:00 : 저녁시간

✅ 저녁

• 19:00 ~ 21:00 : Stack 블록 게임 UI 시스템 구현
  • BaseUI, HomeUI, GameUI, ScoreUI, UIManager 설계
  • TheStack 게임 로직 완성 및 UI 연동
  • 점수/콤보 UI 반영, 버튼 이벤트 연결 방식 개선

✅ 오늘 학습 키워드

• Unity UI 시스템
• BaseUI 및 상태 기반 UI 전환
• TextMeshPro와 버튼 이벤트 인스펙터 연결
• PlayerPrefs를 이용한 점수 저장
• 2D 배경 루프 구현 (BgLooper)
• Flappy Bird 스타일 점프 및 장애물 재배치 로직
• 카메라 따라가기 구현 (FollowCamera)
• NullReferenceException 디버깅 및 인스펙터 연결 방식 개선
• 게임 매니저(GameManager) 중심의 흐름 제어
• Stack 블록 정렬 판정 및 콤보 보상 시스템

✅ 오늘 학습 한 내용을 나만의 언어로 정리하기

오늘 오전에는 그동안 팀원들과 함께 개발해왔던 TextRPG 프로젝트를 중심으로 전체 코드 구조를 점검하고 회의를 진행했다. 기능이 많아지면서 코드가 점점 복잡해졌기 때문에, 각 클래스의 책임을 명확히 나누고 UI, 전투, 퀘스트, 저장 시스템 등 각 모듈별로 정리된 형태로 개선해보자는 공감대가 있었다. 특히 트러블슈팅 내용들을 발표 자료로 정리하면서 구조 개선의 필요성과 우리가 어떤 식으로 문제를 해결해왔는지 되돌아볼 수 있었던 의미 있는 시간이었다.

오후 발표 이후에는 완전히 다른 2D 게임들을 구현하면서 Unity의 다양한 시스템들을 익힐 수 있었다. 먼저 Flappy Bird 스타일의 게임에서는 Player 캐릭터가 점프하고 장애물을 피하는 간단한 구조를 만들었지만, 그 안에서도 배경 루프, 장애물 재배치, 카메라 따라가기 같은 중요한 기능들을 경험할 수 있었다. BgLooper에서 배경과 장애물을 적절한 위치로 재배치해 무한히 이어지는 듯한 느낌을 주는 로직이 특히 인상 깊었다.

저녁에는 Stack 블록 게임을 완성도 있게 구현했다. 블록이 일정한 속도로 좌우 이동하며, 플레이어가 타이밍 맞춰 멈추게 하면 정확도에 따라 잘려나가거나 콤보가 쌓이는 구조를 갖고 있다. 정확하게 쌓을수록 콤보가 쌓이고, 일정 콤보마다 블록이 커지는 보상이 주어져 게임성이 높아졌다. UI 시스템도 BaseUI를 중심으로 상태 기반으로 관리했고, TextMeshPro와 버튼 이벤트를 인스펙터에서 직접 연결해 오류 없이 깔끔하게 동작하게 만들었다. 특히 NullReferenceException 오류를 직접 겪고 나서 구조를 변경한 경험이 큰 배움으로 남았다.

🧩 학습하며 겪었던 문제점 & 에러

1. NullReferenceException 오류 (ScoreUI.cs)

• 문제정의
• UIManager가 ScoreUI를 초기화할 때 transform.Find()로 찾은 오브젝트들이 null이 되어 NullReferenceException이 발생함.
• 시도
• 오브젝트 이름이 잘못되었나 확인하고, 프리팹 구조를 여러 번 점검함.
• 해결방법
• 모든 UI 요소를 public으로 선언하고, 인스펙터에서 직접 연결하는 방식으로 변경함.
• 새롭게 알게 된 점
• 코드 상에서 무조건 transform.Find()로 접근하기보다는, 인스펙터 연결을 통해 안정성과 명확성을 높이는 것이 좋다는 점을 배움.
• 다시 만나게 된다면
• UIManager에서 UI 요소를 초기화할 때는 반드시 null 체크와 연결 상태를 사전에 점검해야 함.

2. InvalidCastException 오류 (BgLooper.cs)

• 문제정의
• BoxCollider2D로 캐스팅하려던 백그라운드 오브젝트가 실제로 BoxCollider2D가 아니라 오류가 발생함.
• 시도
• collision에 어떤 컴포넌트가 붙어 있는지 디버깅으로 확인하고, GetComponent<BoxCollider2D>()로 수정 시도함.
• 해결방법
• ((BoxCollider2D)collision) → collision.GetComponent<BoxCollider2D>()로 수정하여 해결.
• 새롭게 알게 된 점
• Collider2D를 바로 캐스팅하는 것은 위험할 수 있으며, GetComponent를 통해 필요한 컴포넌트를 명확히 가져와야 안정적임.

3. NullReferenceException 오류 (TheStack.cs)

• 문제정의
• 게임 시작 후 lastBlock이 null 상태인데도 MoveBlock()에서 접근하며 NullReferenceException 발생.
• 시도
• Update() 흐름을 점검하고 lastBlock 초기화 타이밍을 확인함.
• 해결방법
• if (lastBlock == null) return; 체크를 MoveBlock() 내부에 추가하여 예외 방지.
• 새롭게 알게 된 점
• 오브젝트 생성 직후 프레임 내에서 처리되는 흐름을 고려해야 하며, null 방어 코드가 항상 중요함.

📝 메모

오늘은 진짜 많은 걸 겪고, 많이 배운 하루였다.

오전에는 TextRPG 프로젝트 회의를 하면서 우리가 얼마나 많은 기능을 구현해왔는지 되돌아봤고, 그 과정에서 구조적인 한계와 개선 방향을 직접 확인할 수 있었다. 발표 준비를 하면서 트러블슈팅 내용을 정리했던 것도 내가 어떤 고민을 했는지 되짚어볼 수 있는 좋은 기회였다.

오후에는 Flappy Bird 스타일 게임을 처음부터 새로 만들면서 Unity의 2D 시스템을 적극적으로 활용해봤다. 반복되는 배경, 장애물 위치 재배치, 플레이어 사망 처리 등 단순해 보여도 실제로 구현하면 고려할 게 많은 구조였다.

저녁에는 Stack 게임을 마무리하면서 UIManager, BaseUI 구조를 직접 설계하고 버튼 이벤트를 인스펙터에서 연결하는 방식을 적용했다. 그동안 transform.Find()만 쓰다가 오류를 계속 만나고 나서 구조를 바꾼 건, 단순히 기능을 구현하는 걸 넘어 '왜 이런 설계가 더 나은가'를 직접 체험한 값진 경험이었다.

실수도 많았지만, 그만큼 코드를 더 깊이 이해할 수 있었고, 내가 만든 시스템들이 점점 단단해지고 있다는 느낌을 받았다.

내일도 화이팅!!!!!

🧩 오늘 만든 게임들!

Flappy Bird 비슷한 게임?

The Stack 게임

25.07.19 TIL

🗓️ 오늘 하루 일정 (2025-07-19)

• 09:00 ~ 12:00 : 전투 시스템 수정 및 테스트
  • 용에게 죽을 경우 특별한 부활 이벤트 추가
  • 몬스터 레벨 조건, 이름 기반 이스터에그 처리
• 13:00 ~ 16:00 : 스토리 연출 및 게임 오버/엔딩 구현
  • 인트로, 엔딩 스토리 출력 연출 개선
  • 레벨에 따라 다른 엔딩 분기 처리
• 16:00 ~ 18:00 : TIL 작성 및 전체 테스트 마무리
  • 경험치 수동 상승(스페이스바 입력 시 증가) 디버그 기능 추가
  • BattleState 흐름 점검 및 디버깅

🧠 오늘의 학습 키워드

• C# 콘솔 연출 (Thread.Sleep / 컬러 출력 / 줄 단위 연출)
• 클래스 간 static 변수 공유
• 조건 분기 처리 (if, else, switch)
• 상태 머신(BattleState) 전개 구조 이해
• 디버그 입력 처리 (Console.ReadKey())

📘 오늘 배운 내용을 나만의 언어로 정리하기

• Thread.Sleep()과 컬러 출력을 활용하여, 스토리를 줄 단위로 자연스럽게 보여주는 연출을 구현했다. 사용자 경험을 높이기 위해 ConsoleColor, 아이콘 이모지, 랜덤 딜레이 등을 활용했다.
• 플레이어가 **특정 몬스터(광포한 레드 드래곤)**에게 죽었을 경우에만 부활하는 이스터에그를 구현했고, Name.Contains() 로 문자열 일치를 판단했다.
• 레벨에 따라 게임 오버 시 나오는 엔딩 분기 조건을 player.Level >= 10로 설정하여 엔딩의 무게감을 조정했다.
• Battle.isEnd라는 static 변수를 통해 엔딩 중복 출력 방지 로직을 관리했다.
• 테스트 편의성을 위해 스페이스바 입력 시 경험치 1 증가 기능을 추가해 레벨업과 엔딩 출력 조건을 빠르게 확인할 수 있도록 했다.

🧩 학습하며 겪었던 문제점 & 에러

1. 문제정의

광포한 레드 드래곤에게 죽었는데 TriggerDragonResurrection() 함수가 실행되지 않음.

• 시도: 이름 비교 "광포한 레드 드래곤" 조건 확인
• 해결방법: Name.Contains("광포한 레드 드래곤") 으로 수정 → 정상 실행
• 새롭게 알게 된 점: 문자열 비교는 == 대신 Contains() 또는 Equals()(대소문자 옵션 포함)를 상황에 맞게 사용해야 함.
• 다시 만나게 된다면: 디버깅할 때 해당 몬스터의 Name을 로그에 찍어서 확인하자.

2. 문제정의

ShowEnding() 내부 조건문에서 컴파일 에러 발생

• 시도: if 없이 (조건식)만 작성함
• 해결방법: if (조건) {}로 감싸고 중괄호 블록 구조 정리
• 새롭게 알게 된 점: C#에서는 단독 조건식은 if, switch 등 문맥 내에서만 허용됨
• 다시 만나게 된다면: 항상 if, else는 블록으로 감쌀 것

🌈 2025년 7월 셋째 주 WIL: 몰입과 성장의 시간들

1. 지난 일주일 동안 가장 인상 깊었던 배움은?

이번 주는 텍스트 RPG에 스토리와 생명력을 불어넣는 작업에 집중했다.
기존의 전투 시스템에 연출을 입히고, 플레이어의 선택에 따라 다양한 결과와 엔딩이 발생하도록 구성했다.
특히, 광포한 레드 드래곤에게 죽으면 부활하는 이스터에그,
레벨 10 이상일 때만 나오는 '인간의 선봉장' 엔딩은 내가 직접 상상했던 세계관을 코드로 구현해내면서 정말 뿌듯했던 순간이었다.

텍스트 기반이지만 Thread.Sleep()과 ConsoleColor, 아이콘 이모지를 활용해서
몰입감 있는 이야기 전달이 가능하다는 걸 온몸으로 배웠다.
이건 분명 내가 만든 "게임"이라는 매체가 줄 수 있는 특별한 감동이었다.

2. 배움까지 다가가는데 어떤 어려움이 있었지?

• BattleState 흐름 오류 때문에 특정 상황에서 메뉴가 반복되거나 전투가 겹쳐 출력되는 문제가 발생했다.
• if 문을 깜빡하거나 Console.Clear() 위치가 부적절해서 출력이 겹치는 문제도 많이 겪었다.
• 레벨업 경험치 처리와 전투 종료 후 경험치 중복 증가 등 논리적 오류를 디버깅하면서 꽤 많은 수정을 반복해야 했다.

하지만 이러한 오류들 덕분에 프로그램 흐름을 더 깊이 이해하게 되었고,
클래스 간 static 변수 관리, 조건 분기 흐름, UI 출력 타이밍 등에 대해 한층 더 단단해진 느낌이다.

3. 그 과정을 겪으며 나는 무엇을 깨달았고, 어떤 감정이 들었었지?

가장 많이 느낀 건,

"게임은 단순히 작동하는 코드 그 이상이라는 것"
이었다.

단순히 전투가 돌아간다고 해서 재미있는 게 아니었다.
그 안에 몰입할 수 있는 문장 하나, 연출 하나, 기대하게 만드는 선택지 하나가 있을 때
플레이어가 감정을 이입하고, 이야기로 느낄 수 있다는 걸 배웠다.

그리고 내가 이걸 만들어내고 있다는 게 너무 신기하고,
처음엔 단순한 콘솔 RPG였지만, 지금은 나만의 세계가 조금씩 완성되어 가는 것 같아서 매일매일 기대됐다.
작은 부분이라도 완성될 때마다 큰 성취감이 밀려왔다.

4. 💭 메모

• 이번 주는 유독 “내가 만들고 있는 게임”이라는 감정이 강하게 들었던 한 주였다.
• 어느새 “이건 단순히 과제가 아니라, 내가 진심을 담은 작품”이라는 생각이 들었고,
• 그런 만큼 디테일 하나하나에 더 집착했고, 덕분에 내가 몰랐던 내 실력까지 꺼내볼 수 있었다.

앞으로도 단순히 “되게 하는” 코드가 아니라
“전달하고, 느끼게 하고, 기억에 남게 하는” 코드를 짜고 싶다.

이번주는 예비군때문에 많은 내용을 하지않았지만 그래도 예비군 끝나고 거의 매일 12시까지 나머지 작업을 했었다 팀원들에게도 너무 미안했고..ㅠㅜ 그래서 주말에도 남은 작업을 진행했다! 이제 이정도면 완성한거같다 ㅎㅎ.. 예비군때문에 별로 참여도못했으니 열심히라도 해야지..  이제 벌써 3주차다 앞으로도 화이팅해보자!!!!

📅 이번 주 TIL 목록